Hi Robert, I like your idea. I'm not a threading expert, but won't this cost much? I mean locking/unlocking is quite expensive, as far as I know, and depending on the number of matrices to lock, this could cost much. Anyway much less that waiting for a complete traversal to end, of course! :) Maybe our implementation could be a "ThreadSafeMatrixTransform"...
Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Thu, 15 Jan 2009 10:10:05 +0100, Robert Osfield <[email protected]> a écrit: > 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 _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
