Horde3D

I've been tackling this idea around in my head for a bit. There's a lot of practical cases where a uniform that can be set differently for each model would be handy (quick example: weapon model, with a rusting effect applied in a shader, not all instances should be equally rusted, so a uniform could be used to determine the curve for the rust layer).

Resource cloning could be used, but the number of duplicates would rise rapidly, and in these cases only a few uniforms would be changing, so cloning is overkill.

My quick thoughts, setting the uniform during the rendering loop is trivial, but deciding where and how to assign it isn't intuitive. Add a <Variable a="#" b="#" c="#" d="#" /> to the material definition. Whenever a material with "Variables" is assigned to a model it creates and sets the variables to their defaults assigned in the material. An additional API function setModelVariable(nodehandle, variableName, float = 0, float = 0, float = 0, float = 0) is then used to alter the variables as needed.

Something like this would definitely be useful - my wrapping layer for Horde handles setting material uniforms on a per-object basis, but it would be better to have this in the engine itself.

_________________
Tristam MacDonald - [swiftcoding]

IIRC, the engine used to support this functionality (maybe in v0.6 or something?), but it was removed because uniforms "belong" in the material.

Maybe if we had an "inheritance" system for materials, then the current cloning approach would be more usable:
- Instead of cloning the entire material resource, a new resource is created.
- This new resource inherits from the original (It links to the original, instead of copying the original)
- New uniform values can be specified in this new material, and these values override the original values.

@DarkAngel,

I can't picture how that would work in the rendering loop since it currently uses material as the primary sorting mechanism. How would you guarantee that the overrides in the child material won't "stick" or cause unnecessary setting of texunits and all the other material related items. I suppose you could fragment the material setup into two seperate functions.

Dealing with cloned resources, even if inherited, requires the application to manage those. In engine assignment of the parameters to models leaves it to assignment of data for the application side.

I'll go ahead and write it up the way I envision and post a patch, and then mess around with trying out an inherited approach, the right answer should become more apparent with working methods available to mess with.

I've got the basic gist of it working.

This setup: MeshNode and MaterialResource both receive a std::vector< Uniform > _variables.

When a material is assigned to a mesh node, its existing variables are cleared and then duplicated from the assigned material. When a mesh node is loaded, it will also assign the variables, assuming the texture resource has already been loaded, otherwise there's problems and setNodeParami() has to be used to assign the material currently. I'm still working on a fix for that. Right now I'm looking at checking mesh nodes before drawing them, and if their _variables.size() doesn't match with the material's _variables.size() to perform the setup operation. Then it needs some testing with multiple models all with different mesh settings.

XML syntax: <Variable name="" a="" b="" c="" d="" />
API Addition: setMeshVariable(NodeHandle meshNode, const char *variable, float a, float b, float c, float d)

The attached picture shows the knight model, all meshes use the same material but during initialization their variables have been set differently. No change in performance. HDR isn't on, and the particles are using alpha test.