Registering shaders with shader system

Started by
14 comments, last by rick_appleton 19 years, 11 months ago
Hey,
James, if you have only one instance of the shader, where you put the intermidiate results or private data dependent to geometry that shader needs?(suche as i.e. private cube map texture or ,another one , the geometry estruded for fur rendering)?

Davide
Advertisement
You could forward results from one shader to another, or perhaps store data in the object to be rendered directly. Allocating a shader per object seems a bit daunting, since one type of shader will always do the same thing and all you need is some result.
davidino: You''ll need to communicate data with the shaders anyway, and to do so in an abstract manner I''ve created a hashmap with data which is bound to a GC (geometry chunk). I''m not currently doing the following, but I had though about it. You could store intermediate results in the cubemap also. You just have to make sure that each shader class does not have private variables, because that would go wrong if you only have a single instance.
I have planned to have a storage space inside the GeometryChunk where the shaders can store data for the next shader, this way I don''t need to duplicate the shaders. I think this is better becouse not every object need that special data-chunk inside the GC but every object needs a shader
quote:Original post by jamessharpe
Btw _Darkwing_ why don''t you use the copy constructor for setting the variables? simply return new Shader(*this);

Old habits die hard . And actualy most of my shaders actualy do only "return new ThisShader();"

This once again comes down to global shader system design...

You should never let your fears become the boundaries of your dreams.
You should never let your fears become the boundaries of your dreams.
I have chosen to associate with each Geometry Chunk a set of ''registers'' These are simply 32 bit values which can be initialised to anything. In the simplest case it could just be a textureID, however it could also be a pointer to a data structure. Think of it as a low level communication similar to how the CPU passes data around. Of course I do give these registers some default ''names'' for suggested uses such as shadowmap, renderToTexture, but as I say these are only names, the actual contents can be anything.

This topic is closed to new replies.

Advertisement