[Opensim-dev] Sim and Phys Frames per Second (FPS) Issues
Diva Canto
diva at metaverseink.com
Tue Mar 3 14:55:28 UTC 2015
Again, for people interested in learning more about these design issues,
and the tradeoffs of different choices, I highly recommend this tutorial
and associated code:
http://buildnewgames.com/real-time-multiplayer/
It's a wonderful little example that explains how interactive multi-user
client-server simulations work. 100x simpler than OpenSim, but
essentially the same concepts. It doesn't explain time dilation, but
it's not hard to see where that comes in: in varying the time window of
the physics loop. The update (simulation) loop is mainly about notifying
clients about changes in the state of the simulation. We want the
physics simulation to be high fidelity (meaning high loop rate), and the
client updates to be as low as possible (low update loop rate).
On 3/3/2015 2:09 AM, Tom Bess wrote:
> Thanks. You have clarified much. I realised the rift is viewer control
> but was not so clear about the impact/relationship between viewer and
> server frame rates and the interpolation needed.
>
> Thanks again.
>
> Tom Willans BSc(Hons) MBCS CITP
> Chartered IT Professional
>
> Managing Director Bessacarr Publications Ltd
> +44 (0)121 288 0281
> email: tom.willans at bessacarr.com <mailto:tom.willans at bessacarr.com>
> skype: tom.willans
> Second Life and OSGrid: Tom Tiros
>
> Sent from my mobile
>
>
> On 3 Mar 2015, at 09:08, Dahlia Trimble <dahliatrimble at gmail.com
> <mailto:dahliatrimble at gmail.com>> wrote:
>
>> If my memory is correct, SL sims run at a default of 45
>> frames/second. OpenSimulator runs at 11. I'm not certain exactly why
>> 11 was chosen but I do know that increasing it increases the amount
>> of work the simulator must do. E.g., if you go from 11 to 45 you
>> quadruple the work the simulator must do
>>
>> The only signal I'm aware of that affects the viewer is "time
>> dilation". This value varies from 0.0 to 1.0 where 1.0 indicates the
>> simulator is running at full speed. If for some reason the physics
>> engine cannot keep up with the simulation it can signal the viewers
>> to slow movement. This value is sent with many UDP packets that are
>> involved with the scene and moving objects, so the viewers will know
>> this value as timely as possible.
>>
>> Running the simulation at 11 fps shoudl *not* affect devices such as
>> the Rift as the camera is controlled entirely viewer side except
>> under special circumstances such as a user surrendering camera
>> control to a script. The viewer frame rate is *entirely independent*
>> of the simulator frame rate and will run as fast as the hardware
>> allows if configured to do so.
>>
>> Choosing an appropriate simulation frame rate would involve weighing
>> the tradeoffs between simulation workload and responsiveness to user
>> controls such as those that control avatar position movement. Bear in
>> mind that there are also network delays involved; a simulation
>> running at 11 frames/second will respond to a user control every 89
>> ms but there will also be round-trip network delays which may
>> typically be 100-200 ms but as high as 1.5 seconds or more.
>> Increashing the simulation frame rate will likely not produce a
>> perceivable difference in performance but will *significantly reduce*
>> the capacity of the simulator to do things like host more avatars and
>> scripted objects.
>>
>> Also bear in mind that much of the code assumes 11 frames/second and
>> raising that may create motion-related and other bugs that may not be
>> apparent until much later. OpenSimulator is tuned to function
>> properly at 11 frames/second.
>>
>> To recap: the user camera is for the most part entirely controlled
>> within the viewer and is unaffected by simulation frame rate. As such
>> devices such as the Rift which manipulate the camera will not be
>> affected.
>>
>> On Tue, Mar 3, 2015 at 12:09 AM, Tom Bess <tom.willans at bessacarr.com
>> <mailto:tom.willans at bessacarr.com>> wrote:
>>
>>
>> I am reporting a comparison between sl and opensim and did not
>> realise this. Does sl run at a true 55fps? If so why bother?
>> Presumably the viewer needs 55fps sent to it to get its
>> calculations correct as at 11fps opensim does the same at sl
>> albeit in larger steps.
>>
>> Would a faster fps improve the accuracy of devices such as the
>> rift by having to interpolate over a shorter period of time?
>> Admittedly I suspect viewer rendering needs to be improved as
>> well as this aspect is holding my experience back.
>>
>> I understand that other aspects may assume that 11fps is a fixed
>> constant and not allow for this to change presumably that can be
>> changed but you guys know more here.
>>
>> Thanks for the guide btw.
>>
>> Tom Willans BSc(Hons) MBCS CITP
>> Chartered IT Professional
>>
>> Managing Director Bessacarr Publications Ltd
>> +44 (0)121 288 0281 <tel:%2B44%20%280%29121%20288%200281>
>> email: tom.willans at bessacarr.com <mailto:tom.willans at bessacarr.com>
>> skype: tom.willans
>> Second Life and OSGrid: Tom Tiros
>>
>> Sent from my mobile
>>
>>
>> On 3 Mar 2015, at 05:18, Sean M <mondesire.sean at gmail.com
>> <mailto:mondesire.sean at gmail.com>> wrote:
>>
>>> Thanks Justin, Dahlia, Michael, and everyone. I now have a
>>> better understanding of the way FPS is calculated and of the
>>> correction factor.
>>>
>>> -Sean M.
>>>
>>> On Monday, March 2, 2015, Justin Clark-Casey
>>> <jjustincc at googlemail.com <mailto:jjustincc at googlemail.com>> wrote:
>>>
>>> I think this has already been said but just to summarize.
>>>
>>> * The 11 fps are the number of scene frames processed -
>>> opportunities where avatars may be notified about changes in
>>> the scene.
>>>
>>> * Each of these scene frames is associated with a physics
>>> process where 5 physics frames are processed in each frame.
>>> Hence 11 * 5 = 55 fps.
>>>
>>> * Why this number? Others may know better but my guess is
>>> that it's related to the frequency of updates expected by
>>> the viewer. Teravus may well know more if he's still around.
>>>
>>> * Changing m_reportedFpsCorrectionFactor will do nothing
>>> except change the server FPS stat.
>>>
>>> * Changing MinFrameTime will change the number of scene
>>> frames. From my work in the past, you would also need to
>>> adjust other parameters like physics frames to stop things
>>> going haywire (this was with ODE, Bullet might work
>>> differently). I expect you also wouldn't gain much if
>>> anything in scene fidelity.
>>>
>>> On 02/03/15 18:23, Sean M wrote:
>>>
>>> Greetings,
>>>
>>> We at the MOSES project have noticed Simulation and
>>> Physics frames per second (FPS) have a few issues that
>>> we are trying
>>> to resolve. The issues are producing suspicious
>>> performance statistics for the analysis of the current
>>> version of
>>> OpenSim that we are running.
>>>
>>> First, there is a correction factor
>>> (m_reportedFpsCorrectionFactor) that the raw SimFPS is
>>> multiplied by. The comment in
>>> the following line is a bit curious because it indicates
>>> that the FPS is artificially inflated to "lie" about the
>>> actual
>>> FPS being so low:
>>>
>>> OpenSim/Region/Framework/__Scenes/SimStatsReporter.cs:
>>> Line 317
>>> // We're going to lie about the FPS because we've been
>>> lying since 2008. The actual FPS is currently
>>> // locked at a maximum of 11. Maybe at some point this
>>> can change so that we're not lying.
>>> int reportedFPS = (int)(m_fps *
>>> m_reportedFpsCorrectionFactor);
>>>
>>> Also, lines 174 and 227 mention the use of this
>>> correction factor.
>>>
>>> Second, this multiplier also comes into play in the
>>> Scene where there is a MinFrameTime, which seems to be
>>> the minimum
>>> reported amount of time to process a frame:
>>> OpenSim/Region/Framework/__Scenes/Scene.cs:Line 723
>>>
>>> Both of these variables, the correction factor and
>>> MinFrameTime, are concerning from a statistics view
>>> point as they are
>>> generating skewed and massaged numbers; therefore, I
>>> have a few questions:
>>>
>>> 1) Is it commonly known that Sim and Phy FPSs are
>>> inflated to maintain the "lie"? And if so, will it be
>>> corrected to be
>>> an accurate reporting of processed frames per second?
>>>
>>> 2) What exactly are the definitions for OpenSim's
>>> Simulation (Sim) FPS, Physics (Phy) FPS and a frame (I
>>> have found
>>> conflicting and vague definitions on the wiki)?
>>>
>>> 3) What are the known performance consequences of
>>> setting the m_reportedFpsCorrectionFactor to 1 and
>>> MinFrameTime to 0?
>>>
>>> Thanks,
>>> Sean M.
>>>
>>>
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at opensimulator.org
>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>
>>>
>>>
>>> --
>>> Justin Clark-Casey (justincc)
>>> OSVW Consulting
>>> http://justincc.org
>>> http://twitter.com/justincc
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at opensimulator.org
>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>>
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at opensimulator.org <mailto:Opensim-dev at opensimulator.org>
>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at opensimulator.org <mailto:Opensim-dev at opensimulator.org>
>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at opensimulator.org <mailto:Opensim-dev at opensimulator.org>
>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
>
> _______________________________________________
> 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/20150303/809405b6/attachment-0001.html>
More information about the Opensim-dev
mailing list