Hi Robert, hi all, Robert, I didn't say it before, but thanks for giving us your thoughts/ideas.
So there is, IMO, 3 viable solutions: 1. A simple thread safe matrix transform. Benefits: Simple and fast. Drawbacks: You may have t and t-1 matrices. Can't do interpolations/extraploations. That may fits some needs (OpenTissue as Ahmed explained?), but not be the common solution I guess. 2. A full thread safe timestamped matrix buffer (your idea), with an option to record matrices once each n-th physics frame. Benefits: Can handle complex updates, like interpolations and such. Useable with any engine. Drawbacks: Complex, and may consume RAM and CPU (reallocations of buffers when there is a lag). 3. A thread safe structure with 2 matrices + 1 time stamp Benefits: Intermediate solution that fits most engines and usages. Drawbacks: Physics engine must update all matrices on each update. Can't do interpolations/extraploations. I suggest we provide the user multiple possible implementations (by the way of a pre-processor define?). Does that sounds good? About getting the best framestamp (for solution 2), I think it is far safer to do a batch update to avoid having "t and t-1 matrices", as in solution 1. Or we may let the user do a custom processing by simply giving him/her the latest framestamp that is common to all buffers? I'm waiting for comments! :) Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Thu, 15 Jan 2009 13:42:54 +0100, Robert Osfield <robert.osfi...@gmail.com> a écrit: > Hi Sukender, > > On Thu, Jan 15, 2009 at 12:06 PM, Sukender <suky0...@free.fr> wrote: >> 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. > > I'd have one time stamp per matrix/value that is pushed in from the > physics thread, and then the rendering thread pulls the appropriate > matrix/maitrces/values according to the time stamp(s) that look most > appropriate. > > One could also do a batch copy of from all the buffers to all the > scene graph related values at one time. > > As for the data structure required, a custom ring buffer implemented > on top of a std::vector<> would probably work just fine. However, I'm > just waving my hands around, I haven't actually done much work with > physics integration personally, others who've been there and done that > would probably be best placed to give the low level recommondations. > >> 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? > > If you running at really high frequences then one would need to take > in account how big these buffers might get, in which case you'd want > to cut down the number of matrices/values you store, perhaps not even > record them every frame, all the rendering thread needs to one > matrix/value per frame. > > Robert. > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
