[Opensim-dev] New Network Statistics

[Teravus Ovares]

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.

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.

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.

My 2c

Thanks

T

On Mon, Jun 29, 2015 at 7:15 AM, Louden, Robert <rlouden at ist.ucf.edu> wrote:

> Currently, the default physics engine, Bullet, will always returns a 1.0
> for the time dilation.
>
>
> Robert
>
>
> On 15-06-26 06:41 PM, Dahlia Trimble wrote:
> > I have a question about the viewer stats as they exist now. I noticed in
> the
> > viewer (Singularity) that Time Dilation as displayed in the viewer stats
> > display seems to have a binary mode; it's either 1.0 for any sim or
> physics
> > frame rate greater than zero, or 0.0 if the frame rate falls to zero.
>
> Did someone break this time dilation stat? I used to see values in the 0.8
> and 0.9 ranges in the past (going back to the days of 0.6.9) for regions
> that were heavily loaded or on a server that was too busy to properly
> handle
> the load.
>
> --
> Cheers!
>
> Kevin.
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20150630/c35774f5/attachment.html>