[Opensim-dev] New Network Statistics

[Teravus Ovares]

One more comment to the wall of text I sent previously.    The changes
mentioned previously were not all bad.   There were benefits to the new
ways of doing things.   Having the main thread gateway the updates meant
that the main thread could better limit updates increasing the number of
possible avatar on the same simulator before flooding the UDP queues with
positional updates..   which, once flooded,  increase the processor time
for processing of UDP packets..  which in turn..  leaves less available to
physics which creates a vicious cycle feedback loop.    So there's that.

On Tue, Jun 30, 2015 at 10:14 PM, Teravus Ovares <teravus at gmail.com> wrote:

> 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/fe04adf6/attachment.html>