Applying shader variables to a material
Author
I have been doing research and prototyping for my material system and there is one key aspect that I am not understanding, and that is how to design the part of the material subsystem that sets variables such as lighting information to materials that can have lighting on it. Does anyone have any suggestions or examples on how this can be done?
how to design the part of the material subsystem that sets variables such as lighting information to materials that can have lighting on it.Can you be a bit more specific in describing the problem, provide some background/context, tell us what you've tried, and detail the specific parts that are causing trouble?
Author
Well a lot of what I have been trying to research is the theory. Previously I have a supremely hacked version of a "material" subsystem, which was really just hacked together ways to do a alpha and materials, and it always knowing what it was going to be lighting. This was a hack, and the hack worked for a small scene. As I now move onto a larger scene, and for the sake of wanting to learn/not have a huge hacky system I am trying to figure this out.
One thing I am having a hard time figuring is how do lighting properties, such as lighting color, point light radius, etc get set to the material. Does the lighting subsystem handle this automagically, but doing something like hold onto the pointers to the shaders used for lighting (like for DeferredRendering, have the lighting subsystem hold on to the RenderGBuffer shaders), then have the material checked for "lighting enabled" and then submit the material/light properties?
One thing I am having a hard time figuring is how do lighting properties, such as lighting color, point light radius, etc get set to the material. Does the lighting subsystem handle this automagically, but doing something like hold onto the pointers to the shaders used for lighting (like for DeferredRendering, have the lighting subsystem hold on to the RenderGBuffer shaders), then have the material checked for "lighting enabled" and then submit the material/light properties?
Sounds like a lot of confusion here and for that reason it is hard to understand what you are really asking.
However, most of the methods to handle materials and lighting in real time 3d graphics are more and less "hacks". The question is, which "hack" to use for your current problem. By saying hack, I mean a framework which supports the features you'll need to implement the desired output.
I am not sure if your question is technical in the sense that you don't know how some particular API works or it is more like a design issue.
In my personal projects I use deferred rendering. The good side with it is that rendering objects isn't coupled with lighting, other than that the objects need to write values to render targets for the lighting to work correctly. Rendering objects is merely a question of setting correct textures (the material contains list of textures + other parameters) and correct transformations. Lighting is done afterwards by reading data from the render targets.
With deferred shading you may store material indices in the render target and use that value later to index materials. The material may contain a flag to indicate if light should affect the pixel or not.
Can you specify your question a bit more?
Cheers!
However, most of the methods to handle materials and lighting in real time 3d graphics are more and less "hacks". The question is, which "hack" to use for your current problem. By saying hack, I mean a framework which supports the features you'll need to implement the desired output.
I am not sure if your question is technical in the sense that you don't know how some particular API works or it is more like a design issue.
In my personal projects I use deferred rendering. The good side with it is that rendering objects isn't coupled with lighting, other than that the objects need to write values to render targets for the lighting to work correctly. Rendering objects is merely a question of setting correct textures (the material contains list of textures + other parameters) and correct transformations. Lighting is done afterwards by reading data from the render targets.
With deferred shading you may store material indices in the render target and use that value later to index materials. The material may contain a flag to indicate if light should affect the pixel or not.
Can you specify your question a bit more?
Cheers!
Here's one way, which actually would phrase your question the other way around: applying material variables to a shader 
Typically, only part of the shader variables come from the material itself. The rest such as the view/projection/object matrices and light properties come from elsewhere. And typically, these "other" variables are hardcoded, so that the engine knows what variables it actually needs to set for objects to render correctly.
Let's assume a system where your material has a pointer to a vertex shader and a pixel shader. The shaders can be queried for the variables they need, and provide functions to actually set the variables to the graphics API. Let's also say the shader variables are identified by text strings, such as "ViewMatrix", "LightColor" or "LightRadius" or "MaterialDiffuseColor". In this case, only the last would be a material's shader variable.
The material's shader variables could simply be stored in a std::map, with the variable name as the key. When rendering, you'd go through this map, and if the shader(s) need each variable in question, set the variable. For optimization, you'd need a caching system to know the "last source" (for example, a material or light pointer) for each shader variable, so you aren't needlessly telling the API to set the shader variables to the same values.
The flow would go for example like this:
Set vertex and pixel shader (from the material)
Set camera & object matrix shader variables
Set light related shader variables (for simplicity, we can assume only 1 light per pass)
Set material's shader variables (go through the material's shader variable map)
Render
Typically, only part of the shader variables come from the material itself. The rest such as the view/projection/object matrices and light properties come from elsewhere. And typically, these "other" variables are hardcoded, so that the engine knows what variables it actually needs to set for objects to render correctly.
Let's assume a system where your material has a pointer to a vertex shader and a pixel shader. The shaders can be queried for the variables they need, and provide functions to actually set the variables to the graphics API. Let's also say the shader variables are identified by text strings, such as "ViewMatrix", "LightColor" or "LightRadius" or "MaterialDiffuseColor". In this case, only the last would be a material's shader variable.
The material's shader variables could simply be stored in a std::map, with the variable name as the key. When rendering, you'd go through this map, and if the shader(s) need each variable in question, set the variable. For optimization, you'd need a caching system to know the "last source" (for example, a material or light pointer) for each shader variable, so you aren't needlessly telling the API to set the shader variables to the same values.
The flow would go for example like this:
Set vertex and pixel shader (from the material)
Set camera & object matrix shader variables
Set light related shader variables (for simplicity, we can assume only 1 light per pass)
Set material's shader variables (go through the material's shader variable map)
Render
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement