OpenSceneGraph Forum Forum Index OpenSceneGraph Forum
Official forum which mirrors the existent OSG mailing lists. Messages posted here are forwarded to the mailing list and vice versa.
   FAQFAQ    SearchSearch    MemberlistMemberlist    RulesRules    UsergroupsUsergroups    RegisterRegister 
 Mail2Forum SettingsMail2Forum Settings  ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
   AlbumAlbum  OpenSceneGraph IRC ChatOpenSceneGraph IRC Chat   SmartFeedSmartFeed 

Project osgPhysics started!

Goto page Previous  1, 2, 3
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> osgPhysics [osgPhysics]
View previous topic :: View next topic  
Author Message

PostPosted: Thu Jan 15, 2009 2:54 pm    Post subject:
Project osgPhysics started!
Reply with quote

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 -

Le Thu, 15 Jan 2009 13:42:54 +0100, Robert Osfield <> a écrit:

Hi Sukender,

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
Back to top
Wang Rui

PostPosted: Thu Jan 15, 2009 3:46 pm    Post subject:
Project osgPhysics started!
Reply with quote

Hi Sukender, hi all,

I would first introduce the implementation of osgPhysics at present:

1. Create a World (derived from Group) instance.
2. Create some RigidActor (derived from Transform) instances and add them as the World's children.
3. While the simulation running, the World will have a UpdateCallback to update itself and all its children RigidActors (calling their update() functions). 4. The matrix of each RigidActor will be got from computeLocalToWorldMatrix() funtion, which is automatically called during the culling traversal. And the object is rendered at specific position.

And it works fine with few objects and a single world. You may have a look at the latest SVN version.

If the physics simulation is put into another thread and thus have one or more PUTs parallel to the DUT, we may have to create a fix-sized queue for maintaining matrices of every RigidActor. In this case, I suggest we create a read callback and a write callback, to lock/unlock the queue during every DUT, and dispatch them to RigidActor nodes. And the FIFO (first-in, first-out) queue would have a *user-defined* size, and store framestamp-matrices data. I don't deeply read all the posts but think my thoughts a little samiliar with Robert's, but leave the decision to users. So customers may set size of buffer to 2, like Sukender suggests.

This mechanism may only affect rigid actors and may be confusing if we have more than one world (it's possible in PhysX). Maybe we have to discuss it again and again and be coding again and again, to get the final result. I'd like to first try to realize soft bodies with geometry shader / VBO in these days. And Sukender and I would make an initial multi-threaded physics update traversal and see its effects ASAP. Smile


Wang Rui

Post generated by Mail2Forum
Back to top
Display posts from previous:   
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> osgPhysics [osgPhysics] All times are GMT
Goto page Previous  1, 2, 3
Page 3 of 3

Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum

Similar Topics
Topic Author Forum Replies Posted
No new posts osgPhysics + physX Trajce Nikolov NICK General 1 Wed Mar 13, 2019 8:46 am View latest post
No new posts Advice requested: Is OSG what I need ... Slickriptide General 3 Wed Sep 05, 2018 5:55 pm View latest post
No new posts osgWidget Visual Studio project is in... Jiri_Patrak Build system [build] 1 Sat Mar 31, 2018 4:26 pm View latest post
No new posts iOS CMake project generation improvem... a.terenzi Submission 1 Mon Jan 22, 2018 11:58 am View latest post
No new posts CMake fails to generate project for iOS a.terenzi Build system [build] 0 Fri Jan 19, 2018 9:32 am View latest post

Board Security Anti Bot Question MOD - phpBB MOD against Spam Bots
Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP