Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualAressera

Posted 27 January 2013 - 04:05 AM

One concept that I think is particularly useful is thinking about uniform/attribute/texture variable usages. Since the shader writer knows what the semantic usage of each input variable is, they can tag each variable with a usage enum value which specifies the semantic purpose of that variable (vertex position, normal, color, diffuse map, environment map, shadow map, model-view matrix, etc...). This could be done in some XML shader metadata format or something, accompanying the shader source.

At render time, the renderer looks at the input variables for a shader. If any of these inputs are not set (with constant uniform/texture values), the renderer can choose to provide the information needed from the current scene rendering state. For instance, tagging a shader variable as the model-view matrix tells the renderer that it needs to provide the proper transformation matrix for the current transformation stack being currently rendered. This prevents you from having to define certain hard-coded variable names as representing those semantic usages (ugh, fragile!). The shader's metadata provides this information, linking variable usages to scene data.

This technique can also be used to bind shaders to meshes/textures that are not otherwise related. The mesh specifies that it has a buffer of vertex positions, buffer of UVs, colors, etc, each with a usage enum. At render time, the renderer matches up the vertex buffers with the correct semantically-tagged shader attribute variables for those usages.

In addition, each usage enum object also contains an index value, indicating that it refers to the i'th usage of that type. This can be done to allow things like multiple lights, multiple texture coordinates, or anything else that can be enumerated (probably not model-view matrices!). A shader for 2 point light sources would provide input variables for the usages (light position - 0, 1) and (light color - 0, 1). The renderer (which knows about the light sources in view) then can find the two most important lights and provide them to the shader automatically!


#4Aressera

Posted 27 January 2013 - 04:04 AM

<p>One concept that I think is particularly useful is thinking about uniform/attribute/texture variable usages. Since the shader writer knows what the semantic usage of each input variable is, they can tag each variable with a usage enum value which specifies the semantic purpose of that variable (vertex position, normal, color, diffuse map, environment map, shadow map, model-view matrix, etc...). This could be done in some XML shader metadata format or something, accompanying the shader source.</p>
<p>&nbsp;</p>
<p>At render time, the renderer looks at the input variables for a shader. If any of these inputs are not set (with constant uniform/texture values), the renderer can choose to provide the information needed from the current scene rendering state. For instance, tagging a shader variable as the model-view matrix tells the renderer that it needs to provide the proper transformation matrix for the current transformation stack being currently rendered. This prevents you from having to define certain hard-coded variable names as representing those semantic usages (ugh, fragile!). The shader's metadata provides this information, linking variable usages to scene data.</p>
<p>&nbsp;</p>
<p>This technique can also be used to bind shaders to meshes/textures that are not otherwise related. The mesh specifies that it has a buffer of vertex positions, buffer of UVs, colors, etc, each with a usage enum. At render time, the renderer matches up the vertex buffers with the correct semantically-tagged shader attribute variables for those usages.</p>
<p>&nbsp;</p>
<p>In addition, each usage enum object also contains an index value, indicating that it refers to the i'th usage of that type. This can be done to allow things like multiple lights, multiple texture coordinates, or anything else that can be enumerated (probably not model-view matrices!). A shader for 2 point light sources would provide input variables for the usages (light position - 0, 1) and (light color - 0, 1). The renderer (which knows about the light sources in view) then can find the two most important lights and provide them to the shader automatically!</p>

#3Aressera

Posted 27 January 2013 - 04:04 AM

<p>One concept that I think is particularly useful is thinking about uniform/attribute/texture variable usages. Since the shader writer knows what the semantic usage of each input variable is, they can tag each variable with a usage enum value which specifies the semantic purpose of that variable (vertex position, normal, color, diffuse map, environment map, shadow map, model-view matrix, etc...). This could be done in some XML shader metadata format or something, accompanying the shader source.</p>
<p>&nbsp;</p>
<p>At render time, the renderer looks at the input variables for a shader. If any of these inputs are not set (with constant uniform/texture values), the renderer can choose to provide the information needed from the current scene rendering state. For instance, tagging a shader variable as the model-view matrix tells the renderer that it needs to provide the proper transformation matrix for the current transformation stack being currently rendered. This prevents you from having to define certain hard-coded variable names as representing those semantic usages (ugh, fragile!). The shader's metadata provides this information, linking variable usages to scene data.</p>
<p>&nbsp;</p>
<p>This technique can also be used to bind shaders to meshes/textures that are not otherwise related. The mesh specifies that it has a buffer of vertex positions, buffer of UVs, colors, etc, each with a usage enum. At render time, the renderer matches up the vertex buffers with the correct semantically-tagged shader attribute variables for those usages.</p>
<p>&nbsp;</p>
<p>In addition, each usage enum object also contains an index value, indicating that it refers to the i'th usage of that type. This can be done to allow things like multiple lights, multiple texture coordinates, or anything else that can be enumerated (probably not model-view matrices!). A shader for 2 point light sources would provide input variables for the usages (light position - 0, 1) and (light color - 0, 1). The renderer (which knows about the light sources in view) then can find the two most important lights and provide them to the shader automatically!</p>

#2Aressera

Posted 27 January 2013 - 04:04 AM

<p>One concept that I think is particularly useful is thinking about uniform/attribute/texture variable usages. Since the shader writer knows what the semantic usage of each input variable is, they can tag each variable with a usage enum value which specifies the semantic purpose of that variable (vertex position, normal, color, diffuse map, environment map, shadow map, model-view matrix, etc...). This could be done in some XML shader metadata format or something, accompanying the shader source.</p>
<p>&nbsp;</p>
<p>At render time, the renderer looks at the input variables for a shader. If any of these inputs are not set (with constant uniform/texture values), the renderer can choose to provide the information needed from the current scene rendering state. For instance, tagging a shader variable as the model-view matrix tells the renderer that it needs to provide the proper transformation matrix for the current transformation stack being currently rendered. This prevents you from having to define certain hard-coded variable names as representing those semantic usages (ugh, fragile!). The shader's metadata provides this information, linking variable usages to scene data.</p>
<p>&nbsp;</p>
<p>This technique can also be used to bind shaders to meshes/textures that are not otherwise related. The mesh specifies that it has a buffer of vertex positions, buffer of UVs, colors, etc, each with a usage enum. At render time, the renderer matches up the vertex buffers with the correct semantically-tagged shader attribute variables for those usages.</p>
<p>&nbsp;</p>
<p>In addition, each usage enum object also contains an index value, indicating that it refers to the i'th usage of that type. This can be done to allow things like multiple lights, multiple texture coordinates, or anything else that can be enumerated (probably not model-view matrices!). A shader for 2 point light sources would provide input variables for the usages (light position - 0, 1) and (light color - 0, 1). The renderer (which knows about the light sources in view) then can find the two most important lights and provide them to the shader automatically!</p>

#1Aressera

Posted 27 January 2013 - 02:16 AM

One concept that I think is particularly useful is thinking about uniform/attribute/texture variable usages. Since the shader writer knows what the semantic usage of each input variable is, they can tag each variable with a usage enum value which specifies the semantic purpose of that variable (vertex position, normal, color, diffuse map, environment map, shadow map, model-view matrix, etc...). This could be done in some XML shader metadata format or something, accompanying the shader source.

 

At render time, the renderer looks at the input variables for a shader. If any of these inputs are not set (with constant uniform/texture values), the renderer can choose to provide the information needed from the current scene rendering state. For instance, tagging a shader variable as the model-view matrix tells the renderer that it needs to provide the proper transformation matrix for the current transformation stack being currently rendered. This prevents you from having to define certain hard-coded variable names as representing those semantic usages (ugh, fragile!). The shader's metadata provides this information, linking variable usages to scene data.

 

This technique can also be used to bind shaders to meshes/textures that are not otherwise related. The mesh specifies that it has a buffer of vertex positions, buffer of UVs, colors, etc, each with a usage enum. At render time, the renderer matches up the vertex buffers with the correct semantically-tagged shader attribute variables for those usages.


PARTNERS