Using texture atlas can help improve the possibility of batching in a more coarse grained way, but this requires a modeller to get involved. Automating this would be possible, but you'd still want some user interaction to get the best results.
As for the threading of update, cull and draw, my plan is to avoid multi-buffering the scene graph itself, so the type of threading model in Performer isn't possible. The OSG's multi-threading works without multi-buffering by having single threaded write of the scene graph (update traversal) then multi-threaded read only cull-draw pairs. This allows us to scale to multiple CPU-GPU systems efficiently, but as things stand it precludes overlapping update with cull-draw pairs.
However, we potentially could relax the single threading update, multi-threaded cull-draw by taking advantage of the fact that most parts of the scene graph are static, as this arn't being update they in theory could be read from the cull-draw threads safely while the update phase is progressing. My though was to keep track of all the dynamic objects that are in being dispatched in the draw thread, once all these have been dispatched then the update thread could be released from its barrier. This would allow the update traversal to overlap part of the draw dispath thread.
Another potential step beyond this is to move cull and draw into seperate threads. For each graphics context we would have one graphics thread that does all the draw dispatches for that graphics context. Then seperately we'd have multiple threads one per cull traversal, these cull threads could be dispatched straight after the update thread completes, and once they are complete they place a rendering object on the graphics contexts threads pending operations lists. A futher variation to this model would be to allow multiple cull threads to work on the same camera cull travesal, by spliting the view frustum into several parts, and each thread takes it own section of the frustum does its traversal, then after they all complete the rendering graphs are merged and then passed as a single object to the associated graphics thread.
I have done a little of the preperation work towards this model with the osg::GraphicsThread class, it isn't widely used yet, only the osgcamera example and some pbuffer code (not used by default) in src/osgUtil/RenderStage.cpp utilise it so far. My plan for the osgViewer library is to provide options for implementation the above threading model. However, the osgViewer work is something that I don't yet have time to tackle, and can't provide any estimates to when it might happen as I have a number of other projects on going.
Robert.
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
