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. :) Cheers, Wang Rui
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
