<div dir="ltr">Some history... It used to be X(Number of Frames Processed per second) \ 10 since there were supposed to be 10 frames a second on the main thread. This worked OK for the most part assuming physics was capable of sending out an immediate positional update when necessary. Then someone tweaked a library and caused a hurlicane.. and other people decided that the main thread should gateway the updates. This caused some rubberbanding issues that got worse when time dilation changed. So, it was determined by someone at some point to return 1.0 for time dilation. This ensured that the viewer wasn't changing the speed of the interpolation to one that was out of sync with the server (though sometimes it was... however changing the speed sometimes made the rubberbanding worse). I'm not sure if anyone ever 'properly' fixed it after that. The key here is that objects in physics need to be at the same place that viewer interpolation would take them based on the time dilation representing a multiplier of the linear and angular velocity. So, lets say the server says that the object is at the left corner of the sim at <0,0,0> moving at 10 meters per second on the X axis, or <10,0,0> and the server says that the server is running at 0.5 time dilation. That means that the viewer will move the object at a rate of 5 meters per second on the X axis until the server gives it a new update on where the object is. Lets say that one second passed and the server hasn't sent a new update on the object. This will cause the viewer to move the object to <5,0,0>. Lets say another second passes and this time the server sends the position to be <4,0,0> moving 10 meters per second on the x axis. This will cause the object to 'snap' back to <4,0,0> and move at 5 meters per second on the X axis. Lets say another second passes and the server says that it's at <10,0,0> moving at 10m/s, this will cause the object to snap forward 1 meter. <div><br></div><div>This is the Essence of what we call 'rubber banding'. The only way to prevent it is to ensure that the physics simulation matches the viewer's thinking of where things should be based on the reported linear and angular velocity, time dilation, and time.</div><div><br></div><div>It turns out it's easier to match the simulation, in terms of programming if time dilation is always 1.0... that said.. at 1.0 there will always be rubber-banding unless we process the physics scene fully in the allotted time. It isn't as simple as just making sure a statistic is updated, the whole way that object updates get sent out and velocities and accelerations get calculated in the physics layer may be affected by time dilation. Be prepared to put on your math propeller hat.</div><div><br></div><div>My 2c</div><div><br></div><div>Thanks</div><div><br></div><div>T</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 29, 2015 at 7:15 AM, Louden, Robert <span dir="ltr"><<a href="mailto:rlouden@ist.ucf.edu" target="_blank">rlouden@ist.ucf.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Currently, the default physics engine, Bullet, will always returns a 1.0 for the time dilation.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
Robert<br>
</font></span><span class="im HOEnZb"><br>
<br>
On 15-06-26 06:41 PM, Dahlia Trimble wrote:<br>
> I have a question about the viewer stats as they exist now. I noticed in the<br>
> viewer (Singularity) that Time Dilation as displayed in the viewer stats<br>
> display seems to have a binary mode; it's either 1.0 for any sim or physics<br>
> frame rate greater than zero, or 0.0 if the frame rate falls to zero.<br>
<br>
Did someone break this time dilation stat? I used to see values in the 0.8<br>
and 0.9 ranges in the past (going back to the days of 0.6.9) for regions<br>
that were heavily loaded or on a server that was too busy to properly handle<br>
the load.<br>
<br>
--<br>
Cheers!<br>
<br>
Kevin.<br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
<a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" rel="noreferrer" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
</div></div></blockquote></div><br></div>