Shader Constants on a per node Basis.

[Mel]

Just that. Maybe i haven't explored the documentation enough, but i've come to an idea that could be useful (this idea is to simplify the process of the deferred shading shaders anyway) and it is to be able to have constants for shaders defined inside the scene nodes, or perhaps to be able to access the current scenenode from the constants routines to grab some data we may need.

This comes from the prior idea that, perhaps, to render the lights of a deferred shading/lighting system, those lights could be modeled using a sphere to clip the space where the lighting is done. Then, the shader would need the center of the sphere, and the radius, and those would be constants needed for the shader of the lights to calculate accurately the lighting.

Then again, that is already done, and i guess i can take a peek to the current implementations, but the idea of being able to transfer constants from the current SceneNodes wouldn't be that bad. How about it?

[BlindSide]

You currently have access to each scene node's material via onSetMaterial. Currently you can store custom attributes via materialTypeParam1 and 2. There has been deliberation to add more custom user data to SMaterial but a verdict has not been reached.

[Mel]

I didn't think about those, Thanks. Well, In fact, the point i was arguing is that instead of adding more data to SMaterial, you could add the data to the ISceneNodes themselves, so the constants were related to the scene nodes instead of the materials, so the same material had diferent reactions depending on the scene nodes.

For example, although this can be done in many other ways, but it is an example. A scene node has a field called "IsSelected" that "IsSelected" is passed as a constant to the shader it used for rendering, and inside the shader depending on the value, it is rendered red or blue. That is the kind of "Constants inside the scene nodes" i was speaking of. If there was a way to access that data, i think it would be useful.

[omaremad]

If its added to the nodes it will throw out material sorting and shader constants will have to be applied before every node (which is slow), it would work hoever if nodes can own a shader constants object that be compared to other nodes.

[Mel]

it will throw out material sorting

Ugh! i didn't take that into account. Seems a bad idea then. Still, it was an interesting feature. So, who knows?

[BlindSide]

Each node has it's own material, I don't see the difference.

[omaremad]

The previosuly rendered material is compared to the new material in the video driver to minimise unncessary state changes.

The video driver has no acess to the node its rendering, just the meshbuffer and material.

[omaremad]

Best solution would be to render all the meshes in a lights range together,ie: the scene manager fetches the nodes near a light then applies the light info in the custom material properties, that way all the nodes with the same lights and shaders get rendered properly together with minimal state changes (and we also get light management).