Horde3D

Next-Generation Graphics Engine
It is currently 24.11.2024, 21:16

All times are UTC + 1 hour




Post new topic Reply to topic  [ 5 posts ] 
Author Message
PostPosted: 30.11.2008, 20:21 
Offline

Joined: 19.11.2007, 19:35
Posts: 218
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.


Top
 Profile  
Reply with quote  
PostPosted: 30.11.2008, 22:28 
Offline

Joined: 22.11.2007, 17:05
Posts: 707
Location: Boston, MA
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]


Top
 Profile  
Reply with quote  
PostPosted: 01.12.2008, 01:19 
Offline

Joined: 08.11.2006, 03:10
Posts: 384
Location: Australia
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.


Top
 Profile  
Reply with quote  
PostPosted: 01.12.2008, 03:47 
Offline

Joined: 19.11.2007, 19:35
Posts: 218
@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.


Top
 Profile  
Reply with quote  
PostPosted: 02.12.2008, 01:06 
Offline

Joined: 19.11.2007, 19:35
Posts: 218
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.

Attachment:
quicktrial.jpg
quicktrial.jpg [ 80.75 KiB | Viewed 9136 times ]


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 9 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group