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! :)
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
Le Thu, 15 Jan 2009 13:42:54 +0100, Robert Osfield <> a écrit:
On Thu, Jan 15, 2009 at 12:06 PM, Sukender <> 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
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.
Post generated by Mail2Forum