Hi Sukender,
On Wed, Jan 14, 2009 at 8:59 PM, Sukender <[email protected]> wrote: > Well, multithreading *is* an issue, but we need to address the problem. > I guess the order of steps would be: > - When it is time to update the physics, run the "physics update traversal" > (say "PUT") in a physics thread > - PUT > - PUT > - ... > - When the times come to update the display, lock the physics thread so that > no PUT runs > - Run the "display update traversal" ("DUT") in a display thread. During > this, copy physics positions/orientations to transforms. > - Unlock the physics. > - PUT (physics thread), cull and draw (display thread) > - and so on. > > Am I right? I'm not sure about threads because here the PUT cant run when DUT > runs, so the interest is limited, even if cull and draw steps would be in > parallel of a PUT. Maybe there could be improvements. Any idea? I would suggest supporting decoupling of the rendering and physics threads as much as possible, without either one blocking the other. The way I would tackle this would be via thread safe data buffers that can be read by the rendering thread, and written to by the physics thread, this buffer would typically be a matrix (or similar transform representation) with a time stamp, new entries would be push to the end of buffer, and then the rendering thread would pull at the time interval required - perhaps interpolating between two entries or even estimating the position beyond last entry if physics is lagging behind. This type of buffer need only have one mutex and would only be locked when the physics thread pushes data into it, and when the rendering thread pulls data from it. This way neither threads should be halted and will run happily decoupled. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
