Hi, I've had same problems with physics simulation (but i'm using bullet physics engine). For me problem was that i had inconsistent frame time from frame to frame, and physics simulation is kind of one frame behind (when you update stuff with physics data, frame not rendered yet, so when its get rendered your simulation is behind on time that was taken to render current frame). If your frame time about constant or changes slowly its not a problem because your simulation each frame behind on some about constant amount of time, but If your frame time inconsistent (like current frame takes 1.5 sec, next frame 2.5 sec, next 2.0 etc ) this problem shows its ugly face, and there are not that much you can do (at least i cant find any good solution yet). For now i basically limit my framerate to make it stable.
If you dont have jitter with osg and physics simulation running different but constant(make sure each frame rendered in about same time with usleep + timers or whatever) framerate (for ex 60hz for physx and 35hz for osg) while using interpolation between physics simulation frames -> seems like you have same problem. 24.01.2011, 12:45, "Arif Yetkin Sarı" <[email protected]>: > Hello everyone. > > We have been using OSG with nvidia physx for a driving simulation and we have > jitter problem, where the cars and other objects in the scene (controlled by > the physics) jitter annoyingly :). We believe that we update the scenegraph > in a wrong way. > > In our code : > There is a physx thread. > There is an OSG library thread where we can add new entities, remove them, > start rain effects, call an animation of a skeleton character etc. > There is an OSG render loop thread, where osgviewer::...frame() is called. > > Our Nvidia physx thread produces new "x y z pitch head roll" values for the > scene entities at 60Hz (or any other frequency we want). > Physx thread calls the updateEntity() function of our OSG library thread. > This function simply updates scene entities with matrixtransform::void > setMatrix(const Matrix& mat). > > In other words, we move an object with this chunk of code: > > Code: > osg::Matrixd mxT = createTransformMatrix(x,y,z,h,p,r); > mt->setMatrix(mx); > > Here what we tried: > 1-we fed OSG lib directly whenever a physx output is produced (every 16.6 ms > or so - 60Hz): there is jitter. > 2-we maintained a queue of frames on OSG lib, fed OSG at the end of each > frame() : there is jitter. > 3-we implemented a sampling mechanism on this queue, where OSG requests the > interpolated frame from the queue for the current timestamp : there is jitter. > 4-we saved a few minutes long log of the physx to a file (many frames). > Started a dummy thread, and fed OSG from this log. : there is jitter. > > When OSG works with 60FPS, and physx thread is running at 60Hz, there seems > to be quite low jitter (sometimes unnoticeable) . > > Thanks in advance for any hints or advices. > Arif Yetkin > > ------------------------ > http://www.youtube.com/watch?v=naX3hOkDx8w > > ------------------ > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=35912#35912 > > _______________________________________________ > 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
