For example, DiffuseMap, SpecularMap, BumpMap, etc., versus Texture1, Texture2, Texture3, and TextureUseAs1, TextureUseAs2, TextureUseAs3, etc.?
Or, more concisely, does anyone have a tutorial that explains this? Because I recently realized that I'm essentially just going head-first into method #2 (and having all textures be able to be all texture types, at that).
Thanks.
Should texture slots in a shader be hard-coded or flexible?
My engine works by getting the shader's information from OpenGl after shader compilation. It gets the handles/names/types of all shader attribute variables and stores them for later. My material system consists of 'ShaderPass' objects which indicate how a single shader pass should be rendered and also contains all of its shader's uniform attributes and textures. Within a shader pass, each shader attribute variable can have a 'usage' value, specified by an enum. This value indicates what that particular variable is used for.
At load time, the engine uses a hash map to associate attribute usages with shader input variables. This information would generally be determined in an external material editor, where the shader programmer would specify the usage for each variable.
Since some shader attributes are 'global' (lights, shadow maps, environment maps, etc.), meaning that they are determined by global scene state, we can't store all shader parameters in the ShaderPass object. In order to handle this, I maintain a 'GlobalAttributeSet' object which contains a hash-map based cache for these global attributes, indexed by attribute usage.
Then, at render time, the engine looks at all input variables for the shader program being used and determines the attributes for those variables. First, it looks in the ShaderPass object for an associated value or texture. If none is specified, it examines the GlobalAttributeSet for that value.
The end result is that shaders and their inputs are totally decoupled from the renderer.
At load time, the engine uses a hash map to associate attribute usages with shader input variables. This information would generally be determined in an external material editor, where the shader programmer would specify the usage for each variable.
Since some shader attributes are 'global' (lights, shadow maps, environment maps, etc.), meaning that they are determined by global scene state, we can't store all shader parameters in the ShaderPass object. In order to handle this, I maintain a 'GlobalAttributeSet' object which contains a hash-map based cache for these global attributes, indexed by attribute usage.
Then, at render time, the engine looks at all input variables for the shader program being used and determines the attributes for those variables. First, it looks in the ShaderPass object for an associated value or texture. If none is specified, it examines the GlobalAttributeSet for that value.
The end result is that shaders and their inputs are totally decoupled from the renderer.
Author
My engine works by getting the shader's information from OpenGl after shader compilation. It gets the handles/names/types of all shader attribute variables and stores them for later. My material system consists of 'ShaderPass' objects which indicate how a single shader pass should be rendered and also contains all of its shader's uniform attributes and textures. Within a shader pass, each shader attribute variable can have a 'usage' value, specified by an enum. This value indicates what that particular variable is used for.
At load time, the engine uses a hash map to associate attribute usages with shader input variables. This information would generally be determined in an external material editor, where the shader programmer would specify the usage for each variable.
Since some shader attributes are 'global' (lights, shadow maps, environment maps, etc.), meaning that they are determined by global scene state, we can't store all shader parameters in the ShaderPass object. In order to handle this, I maintain a 'GlobalAttributeSet' object which contains a hash-map based cache for these global attributes, indexed by attribute usage.
Then, at render time, the engine looks at all input variables for the shader program being used and determines the attributes for those variables. First, it looks in the ShaderPass object for an associated value or texture. If none is specified, it examines the GlobalAttributeSet for that value.
The end result is that shaders and their inputs are totally decoupled from the renderer.
If I'm reading this right, the shader .fx file itself uses attributes to specify what it uses a texture for; then, your ShaderPass object fills available texture slots that match the texture slots it has?
So Shader1 might have TextureMap, SpecularMap and BumpMap, and specify each as that with an attribute.
Then Shader2 might have a number of TextureMaps, two SpecularMaps and two BumpMaps, because it needs to interpolate between different textures (say, a terrain shader).
If the TextureMap has three TextureMaps and a BumpMap, it'll fill two textures in Shader1 (TextureMap and BumpMap) and four textures in Shader2 (Three TextureMaps and one out of two BumpMaps)?
Am I getting this right?
Thanks.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
