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: [email protected]
skype: tom.willans
Second Life and OSGrid: Tom Tiros

Sent from my mobile


> On 3 Mar 2015, at 09:08, Dahlia Trimble <[email protected]> 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 <[email protected]> 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
>> email: [email protected]
>> skype: tom.willans
>> Second Life and OSGrid: Tom Tiros
>> 
>> Sent from my mobile
>> 
>> 
>>> On 3 Mar 2015, at 05:18, Sean M <[email protected]> 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 <[email protected]> 
>>>> 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
>>>>> [email protected]
>>>>> 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
>>>> [email protected]
>>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> [email protected]
>>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>> 
>> _______________________________________________
>> Opensim-dev mailing list
>> [email protected]
>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> 
> _______________________________________________
> Opensim-dev mailing list
> [email protected]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev

Reply via email to