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: [email protected] <mailto:[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]
<mailto:[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]
<mailto:[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 <tel:%2B44%20%280%29121%20288%200281>
email: [email protected] <mailto:[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]
<mailto:[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] <mailto:[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] <mailto:[email protected]>
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected] <mailto:[email protected]>
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected] <mailto:[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
