J-S, Shayne, Thanks for the help. The threaded/shared scenegraph is the approach I had in mind, but there are still a few kinks in my understanding that I'm trying to work out. The current serial render loop looks something like:
databasePager->signalBeginFrame(...); databasePager->updateSceneGraph(...); scene->accept(updateVisitor); // process sim logic here sceneView->cull(); sceneView->draw(); databasePager->signalEndFrame(); databasePager->compileGLObjects(...); So as you can see, the scene will be changing due to the database pager adding/removing nodes, and part of the simulation will be moving subgraphs around in world space (e.g. changing matrix transforms). Would it be possible to leave most everything -- update, cull, etc. on the main thread, but push the drawing off to a separate thread? Basically I want the update and sim logic to run as fast as possible and not wait on the draw(). If a mutex is used to prevent the main thread from being in cull() while the draw thread is in draw(), would that work? Would it be possible to run cull() on the draw thread and use a mutex to prevent cull() and the updates from happening simultaneously? Finally, where does the database pager fit in -- should it signal begin/end frames on each update, or each draw? Thanks, Craig On Thursday, May 12, 2011 at 3:50 PM, Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC wrote: > J-S, > > Yes, a great point I failed to bring up about the mutex. Thanks for > mentioning that. We did have to do that to protect the shared resource when > we used threading. > > For our stuff, one process (out-the-window) does the usual traversal (via > viewer.frame) while the other sits idle until a request comes in for either > HAT/HOT or LOS. Once a request comes in, it just computes the intersection > with the terrain via the osgSim class and sends the scalar result back. Both > processes load the same PagedLOD terrain node but they're using completely > different graphs. We only check for intersection with terrain and nothing > else... > > -Shayne > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of > Jean-Sébastien Guay > Sent: Thursday, May 12, 2011 2:37 PM > To: OpenSceneGraph Users > Subject: Re: [osg-users] Intersection testing in a separate thread > > Hi Shayne, Craig, > > > Bottom line is that it can be done. It basically amounts to having > > asynchronous traversal of the same scenegraph, one for rendering traversal > > and the other for intersections. These traversals can either be done in > > different threads or different processes. > > But the case of a different thread vs a different process is not the > same. In his case, there will be (optimally) one copy of the scene > graph, and both the rendering and the intersection thread will access > it. He will need a mutex which would be held by the rendering thread > while it's in the update phase, and by the intersection thread while it > does an intersection. In your case, you have two copies of the scene > graph, so there are no threading issues. (how did you update the scene > graph between processes?) > > But that doesn't mean it can't be done, just that it's not quite as > simple as that. > > Hope this helps, > > J-S > -- > ______________________________________________________ > Jean-Sebastien Guay [email protected] > http://www.cm-labs.com/ > http://whitestar02.dyndns-web.com/ > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
