Sign in to follow this  
Narf the Mouse

Should texture slots in a shader be hard-coded or flexible?

Recommended Posts

Narf the Mouse    322
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.

Share this post


Link to post
Share on other sites
Aressera    2919
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.

Share this post


Link to post
Share on other sites
Narf the Mouse    322
[quote name='Aressera' timestamp='1339281569' post='4947774']
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.
[/quote]
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. Edited by Narf the Mouse

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this