HI Rabbi, On Mon, Feb 1, 2010 at 5:49 PM, Rabbi Robinson <[email protected]> wrote: > Thanks, that helps alot. That kinda explain why in OpenSG you have lock each > single update operation.
OpenSG is multi-buffered and the lock you make will be managing those buffers and ensuring that any changes get placed on a update list for later synchronization of the buffers. There will in effect be two costs to your update operation - the update itself, and then the later copying of data to the secondary buffers at the next frame. > I thought OSG handles that internally, but looks like its going to be more > complicated than that. The OSG multibuffers OpenGL objects, and the rendering back end, but otherwise avoids multi-buffering scene graph data. The OSG's design allow you to multi-thread cull-draw, and even multi-thread update and cull with draw but all these models require a single threaded update. The parts of the OSG that are user facing are almost all single buffered, this makes the OSG easier to use and extend that it would be with multi-buffering, without sacrificing scalability on multi-card systems. > I guess I will try to avoid multithread in this case and just have one single > thread responsible for all the updating, at the cost of possibly lower > performance. If your updates are very expensive such as physics modeling you should consider threading this out separately and then synchronization the changes each frame during the update phase. The actual cost of most update for most applications are pretty cheap though and not something that would typically break frame. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
