Hi,
are you making sure that, whenever a frame renders, the calculated
positions of the objects are all synchronised for the same simulation time?
What I mean is, are you sure you are drawing all cars at time t=0.5s
e.g. and not one at 0.5 and one at 0.51?
regards
jp
On 26/01/11 12:25, Arif Yetkin Sarı wrote:
Tomlinson, you are right, so i uploaded a video.
http://www.youtube.com/watch?v=hmqevNbXzy0
you can see that the movement is likely to freeze every few moments. Simply the
simulation is not smooth. One may think its due to fps drop or performance
issues. Nope, i still get this jittering effect for example at 50fps.
Buckley, we are around origin. Example x y z h p r values :
-252.750 385.134 0.100 0.000 0.000 0.000
If you are talking about precision problem, that is not the type of issue we
got in my opinion.
Chuck, even if the camera is still, i can see the cars jittering on the road.
So, i am sure the entities jitter, but not sure if cam is jittering. But, we
attach our camera to cars, then i am sure camera jitters too, since the car is
jittering.
Here is a very simplified draft of our system:
THREAD1 : Of course we have a class where the osg is initialized, and utility
functions are provided like : addEntity, updateEntityPosAndOri,
camFollowEntity, camAttachEntity, deleteEntity, updateCamPosAndOri, enableRain,
setTextOverlayOnScreen, ..... etc.
THREAD2 : and we have an osg render loop thread :
Code:
while (!mViewer->done())
{
mLib->frame();
microSleep(1000);
}
THREAD3 : and we have yet another thread that physx is running on. It produces
x y z h p r values, and uses functions like updateEntityPosAndOri and
updateCamPosAndOri to alter the scenegraph.
(again)Here what we tried:
1-we called the utility functions (updateEntityPosAndOri) directly whenever
THREAD3 produced a physx output (every 16.6 ms or so - 60Hz): there is jitter.
2-we accumulated x y z h p r information (produced per ~16.6 ms) that comes
from THREAD3 on a queue on THREAD1. And we updated the entities of the scene
after each frame() function is called in THREAD2 - in other words, we
serialized our asyncrhonious mechanism. : 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. - in other words,
we act like that we have a continous input signal, and we sample it according
to current time, whenever a frame() is completed : there is jitter.
4-we saved a few minutes long log of the physx to a file (that means many
frames). Started a dummy thread (instead of THREAD3), and fed OSG from this
log. : there is jitter.
But, whenever the fps is 60, and physx thread works in 60Hz, there is
relatively low jitter (or unnoticeable)
Thanks for your comments.
Arif Yetkin
Thanks for the advices.
------------------------
http://www.youtube.com/watch?v=naX3hOkDx8w
------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=35982#35982
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean. MailScanner thanks Transtec Computers for their support.
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
