How to Keep Physics Engine Load Low

What is ODE?

Today most OpenSim installations use Open Dynamics Engine “ODE” as physics engine. It is delivered as integrated part of current OpenSim versions. It is used to simulate a (more or less) realistic physical environment in the virtual world. The physical behavior of physical objects, like some vehicle types, and avatars is calculated by ODE.

Under certain circumstances the physics engine can be very busy and that physics engine load can be experiences as server lag. This article tries to describe how to identify physics engine lag and how to improve your regions to cause less such lag.

Additionally to the server lag you experience much physics engine activity might cause that OpenSim consumes more and more memory over time, due to memory leaks. This may cause lower stability and more frequent restarts of your OpenSim installation.

How to identify physics engine lag?

Enter “show stats” on your OpenSim console window. After that you will see some output like this:

ASSET STATISTICS
Asset cache contains        0 assets
Latest asset request time after cache miss: 0s
Blocked client requests for missing textures: 0
Asset service request failures: 0

CONNECTION STATISTICS
Abnormal client thread terminations: 0

INVENTORY STATISTICS
Initial inventory caching failures: 0

FRAME STATISTICS
Dilatn  SimFPS  PhyFPS  AgntUp  RootAg  ChldAg  Prims   AtvPrm  AtvScr  ScrLPS
  1.00      55    45.5     0.0       0       0    3516       0     419      14

PktsIn  PktOut  PendDl  PendUl  UnackB  TotlFt  NetFt   PhysFt  OthrFt  AgntFt  ImgsFt
    27      10       0       0       0     5.3     0.0     4.3     0.0     0.0     0.0

MEMORY STATISTICS
Allocated to OpenSim : 152 MB

Have a look at the value shown under the label PhysFt. This number is the so called Physics Frame Time. If that value is high, above 20 or even higher,  your physics engine is quite busy. Best run “show stats” multiple times and check if you always get more or less the same PhysFt values or if you see peaks of physical engine activity.

If you see such peaks, even if nobody is currently visiting your region (use “show users” command on the OpenSim console to check that), then you probably have moving objects causing physics engine lag. Otherwise it is possible that moving avatars cause such lag, for example by walking on prim surfaces or by colliding with other objects or avatars.

The PhyFPS value shows the Physics Engine Frame Rate. Values above 45 fps are good. Usually high PhysFt values cause low PhyFPS frame rate values.

You can also display the Physics Engine Frame Rate in the viewer. Select the menu item “View > Statistics Bar”. The Statistics windows opens and shows the Physics FPS value under the label Simulator. If you cannot see it, simply click on the label Simulator.

Reasons for physics engine lag

In the following situations the physics engine has to do calculations:

  • Movements of physical objects
    • unscripted physical objects (i.e. a ball)
    • scripted physical objects (i.e. vehicles implemented as physical objects)
  • Movements of avatars
    • avatar walking over terrain
    • avatar walking over a prim surface (normal prims or sculpties)
  • Collisions between non phantom objects and avatars
    • avatars colliding with each other
    • non phantom objects colliding
    • avatar colliding with a non phantom object

Many physical movements require the detection of collisions. Collisions are detected based on so called Bounding Boxes, rectangular boxes using the X, Y and Z axis and that contain the whole object, avatar or segment of terrain.

You can toggle displaying these internal Bounding Boxes in the viewer using the following menu item in the Advanced menu (which can you open using ctrl alt D):  Advanced > Rendering > Info Displays > BBoxes

Bounding Boxes

How to reduce physics engine lag?

To reduce physics engine lag you should do the following:

  • Try to avoid physical objects (i.e. use vehicles that are not physical objects)
  • Never create huge physical objects, because they easily cause many collision events
  • Make objects phantom if possible (collision detection ignores phantom objects)
  • Make moving/rotating objects phantom
  • Use llTargetOmega and llSetTextureAnim for viewer side rotations/animations
  • Do not use hollow prims with the intention to let other objects or avatars move inside
  • Do not use too complex, rough sculpty prims and terrains as walking surface for avatars

The general rule is to try to avoid collisions of Bounding Boxes as much as possible to reduce physics engine load.

By the way, that is also the reason why avatar attachments are always phantom objects.

One of my renters could reduce Physics Engine Frame Rate values from about 50 with peaks up to 150 to much lower values of about 4. The main reason was a hollow prim with a scripted vehicle constantly moving inside. This did cause physics engine lag. But a bigger issue was the constantly growing memory consumption (memory leak) and thus more frequent region restarts than necessary.

Appendix

This is a short description of the more cryptic labels of the “show stats” console output:

  • Dilatn time dilation
  • SimFPS sim FPS
  • PhyFPS physics FPS
  • AgntUp # of agent updates
  • RootAg # of root agents
  • ChldAg # of child agents
  • Prims # of total prims
  • AtvPrm # of active prims
  • AtvScr # of active scripts
  • ScrLPS # of script lines per second
  • PktsIn # of in packets per second
  • PktOut # of out packets per second
  • PendDl # of pending downloads
  • PendUl # of pending uploads
  • UnackB # of unacknowledged bytes
  • TotlFt total frame time
  • NetFt net frame time
  • PhysFt physics frame time
  • OthrFt other frame time
  • AgntFt agent frame time
  • ImgsFt image frame time

Snoopy Pfeffer
Founder and CEO of Dreamland Metaverse

snoopy.pfeffer@yahoo.com
http://www.3dmetaverse.com/

Advertisements

3 Responses to “How to Keep Physics Engine Load Low”


  1. 1 Wordfromthe Wise June 7, 2010 at 7:21 pm

    Ty for that .. Even that i know this it will be very helpfull for others …

  2. 2 Mystique Aeon October 17, 2010 at 7:23 pm

    It’s gonna be pretty hard not to have avatars walking around inside of hollow prims. No round buildings or rooms made with a hollow cylinder such as my Alcatraz prison. No hollow cylinder hallways such as are used all over my space station. Even my bridges to neighbouring regions are made with hollow prims. I also use hollow prims in entranceways, and doorways. To avoid walking through hollow prims I’d have to make everything square and flat and boring and use a lot more prims. I guess I’ll just have to pay a price in performance. Maybe someday computers will be powerful enough that it won’t matter.

  3. 3 Gwyneth Llewelyn August 21, 2012 at 12:26 pm

    Very informative article, thanks so much for posting this! I know it’s almost two years later, but thanks to your article, I think I managed to track down an annoying “bug” which has been reported by one of my users: cyclically, FPS and Ktris would drop to a third of the usual, remain like that, and go up again. This happens in intervals of perhaps half a minute or so.

    Intrigued, I looked at whatever statistics I could. Logs don’t show anything wrong, either on the server or on the client. Performance on the server is rather good, with plenty of CPU cycles to spare. There are no scripts on the region — which just has a single building anyway — and avatars working on the build are looking to the open sea, with a short drawing distance (so even if they turn the camera around, they will not see content from other neighbouring sims who might be influencing the Ktris/FPS fluctuation).

    By chance I checked if there were any collisions through the Estate Tools. And sure thing, there were a few! But the objects in itself are not hollow, not much tweaked — they’re just regular cubes — and not set to physical. Two of them have on of the sizes above 10 m, but not much more so. The only

    What do the colours on the Bounding Boxes display option mean? I’m assuming the following:

    Aqua — ground
    Green — no collisions (objects do not interpenetrate)
    Yellow — moderate collisions (objects do interpenetrate somehow)
    Orange — no idea, but perhaps “high collisions” (it’s rare to see those)
    Magenta — severe collisions. Avatars, for instance, always have a magenta bounding box

    On further investigation, this cycling tendency seems to come and go and it just happens on some sims but not on others (none have scripts; none have objects set to physical). Oh well. It shall be worth investigating further.

    In any case, thanks for the tip about Bounding Boxes as an useful tool to figure out if a sim is being unnecessarily stressed out at the physics level because of misaligned, interpenetrating prims. I suppose that this tip might also be useful on Second Life and not only on SL, even though Havok is a far more powerful physics engine and might deal with interpenetration more efficiently than ODE. It’s worth a try!


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s




Blog Stats

  • 21,588 hits

Pages

June 2010
M T W T F S S
« Dec    
 123456
78910111213
14151617181920
21222324252627
282930  

%d bloggers like this: