Hi Dimity, On 12/15/06, Dmitry Baikov <[EMAIL PROTECTED]> wrote:
Thank you for such a fast reply! But it effectively means, that if our model has 300 moving parts, we will have N graphs with transform nodes. It sounds not very efficient. In our previous engine, per-instance node have compact state representation (a float per moving part, indicating animation phase) and node matrices were calculated right before actual rendering. Can it be done with OSG?
The OSG doesn't support this out of the box, the updating of scene graph is limited to update traversal if you wish to run with multiple threads/multiple graphics contexts. If you are running single threaded, or can do the updates in a thread safe way then you can use a cull callback on the nodes in question to get them to update. Another alternative is to write a custom osg::Transform node that does the compute of its matrix in demand, rather than storing it locally. This way you could update the angles of rotation of your moving parts in the update phase, and have the transform compute the final matrix on demand during the cull traversal. Since nodes will only be traversed if they arn't culled from above the compute of the matrix will only happen when you there are in the view frustum. I you have so many moving parts that it cases cull and draw dispatch issues as the scene graph has to thrash between many different trasnforms then writing a custom Drawable may be the best approach, and use a vertex program to do the placement of the individual parts. I would recommend doing the simplicist approach first then benchmark it, if performance is fine then your job is done, if it turns out to be a bottleneck then move on to a more sophisticated solution. Robert. _______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
