Sign in to follow this  
judeclarke

Applying shader variables to a material

Recommended Posts

judeclarke    129
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?

Share this post


Link to post
Share on other sites
Hodgman    51222
[quote name='judeclarke' timestamp='1310357239' post='4833578']how to design the part of the material subsystem that sets variables such as lighting information to materials that can have lighting on it.[/quote]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?

Share this post


Link to post
Share on other sites
judeclarke    129
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?

Share this post


Link to post
Share on other sites
kauna    2922
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!

Share this post


Link to post
Share on other sites
AgentC    2352
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

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