Hi Robert, So, to avoid having two objects updated with 2 different time stamps, is it ok if I: - Fill matrix buffers with physics timestamped matrices (PUT - physics thread) - Update in a batch all the display matrices from the latest timestamp that is available over all buffers (display thread) - Remove data that is before that timestamp on all buffers.
But then, does the batch be done before, or during the display update traversal? Does a kind of "circular buffer that can grow as vector<>" could be the best structure for the buffer (if we reserve enough at the begining)? Does that solution cost much RAM if we have a physics that run very frequently (Ex: 1kHz)? Or may we create a buffer that only stores 2 latest matrices since there is no reason for the physics to not update all objects? I suggest then our buffer to be a "Thread safe structure with 2 matrices + 1 time stamp (latest one)". Your thoughts? :) Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Thu, 15 Jan 2009 12:21:47 +0100, Robert Osfield <[email protected]> a écrit: > Hi Sukender, > > On Thu, Jan 15, 2009 at 10:48 AM, Sukender <[email protected]> wrote: >> 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"... > > Perhaps a custom or user data callback would be sufficient for > managing the common data buffer, this way you could adapt the buffer > for different purposes. > > As for the cost of the locking and unlocking - this is actually pretty > low, you don't want to be doing thousands of locks/unlocks per frame, > so if you do have a scene with many separate entities that are being > modelled then having composite buffers that have a single mutex > between them, and do a sync data to and from this buffer on batch > rather than each buffer individually would avoid making too many > lock/unlock calls. > > As for the interpolation vs choosing the most value, this is something > that could easily be done via an option on the reading side - or > simply have two different update callbacks that read from the buffers > in different ways. > > 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
