Hi Tim, On Wednesday 08 April 2009 22:25:49 Tim Moore wrote: > Here's the theory: the values in question, such as material colors > or vector parameters for a shader, must be set in a vector operation > in OSG. The values are set at startup and also at runtime by material > animations. Typically the raw C++ values that could be set by a property > system "tie" are protected members and not accessible. > > Currently a big performance hit is the need to run an update callback on > every state set involved in a material animation (not to mention on every > animation). It might not seem like this could be expensive, but the need > to traverse the big scene graph every frame is expensive in terms of what > is costly on today's hardware: pointer chasing, cache misses, etc. If we > can move away from update callbacks, we will see a gain. However, if the > individual components of the values in question exist independently in > the property tree and can be set individually, this greatly complicates > the bookkeeping needed to avoid update callbacks, or forces us to just > use update callbacks.
Well, yes, the atomicity of setting of properties is preserved with that change. And yes this will help to move some animations into the cull step and make them asyncronous. Is this where you are heading to? I would like to move the animations having a transform node into this direction. So we could hopefully narrow the sub trees that need the update visitor. Greetings Mathias ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
