Physics Optimization

Physics Optimization

(See handy script below)

NOTE: Setting prims to Phantom does not stop them from being simulated by the physics engine!

The less the physics engine has to calculate, the smoother your region will perform. Creating clean "Wikipedia logo" low poly physics shapes for your complicated meshes is helpful, but you can also remove prim, mesh, and sculpted objects from the physics calculations completely. Obviously, if you need avatars or pathfinding objects to navigate over or around your object then it does not make sense to remove the physics shape completely, but you may be able to simplify physics shape without loss of realism.

Physics Optimization also helps with Pathfinding. Pathfinding objects will only have to calculate to go around simple objects instead of complex builds, making everything work smoother and faster without sacrificing looks.

The way to Physics Optimize is to link your complicated builds to a simple shape like a cube or cylinder. The simple shape should be the root prim and then set all child prims to PRIM_PHYSICS_SHAPE_NONE (in Edit > Features > Physics Shape Type)


Manual Instructions

1. Build your object as you normally would

2. Create a simple shape, such as a cube or cylinder

3. Right click on your object, hold down shift and select the simple shape last

4. Press control and L to link it all (the simple shape should now be the root prim highlighted in yellow)

5. Tick edit linked parts

6. Hold down shift and de-select the root prim (the simple shape)

7. Under the edit menu, in the features tab, select physics shape type, and from the drop down menu select, physics type none. This will set all the child prims to none.

8. Select the root prim (the simple shape) and make it transparent.


Using the script below

Or to make it even simpler just follow the above instructions 1 to 4 and then use the handy script attached below. Just drop it in the root prim (The new simple shape you just linked your build to).

Tip: Cubes, spheres, and circular cylinders are the cheapest shapes to use. Up to 14 cubes equates to the same value as one cut hollowed cube. Other shapes, such as pyramids, with no cuts, twists, hollows, or holes, or any shape set to PRIM_PHYSICS_SHAPE_CONVEX give a potentially more accurate (albeit more expensive) result. Any shape that contains holes, cuts, twists, or hollows (such as a torus) fall into the most expensive category.

Here we linked a tree to a cube and set all child prims to physics shape type None (in Edit > Features > Physics Shape Type):

Collision

When you are physics optimizing you need to plan where you want the collision to be, because all the individual shapes set to physics none will act as though they are phantom. In this example we are using a tree. The actual original tree will be set to physics none and act as though it is phantom so an avatar will be able to walk through it. The root prim, which in this case is a cylinder, will be the only solid part of the whole linked set. By putting the root prim/simple shape around the tree trunk, you simulate a solid and avatars will collide with it.

Here we used a cylinder, but we could have also used a stretched cube to achieve a similar effect.

For more complicated builds you can set certain parts to PRIM_PHYSICS_SHAPE_PRIM and others to PRIM_PHYSICS_SHAPE_NONE. The parts set to prim will act solid, and the parts set to physics shape type none will act as phantom. Alternatively, all prims could be set to PRIM_PHYSICS_SHAPE_CONVEX for a potentially more accurate (albeit more expensive) result. This still produces a physics shape significantly simpler than the default. However, this second option will have no effect on sculpts.

More Examples

Use the following script to set all child prims to None. Be sure to check what physics are needed for your linkset prior to using, and/or add a simple cube as the root prim. 

default
{
    state_entry()
    {
        llOwnerSay("Setting all child prims to PRIM_PHYSICS_SHAPE_NONE");
        llSetLinkPrimitiveParamsFast(LINK_ALL_CHILDREN, [PRIM_PHYSICS_SHAPE_TYPE, PRIM_PHYSICS_SHAPE_NONE]);
        llRemoveInventory(llGetScriptName());
    }
}

Debugging Regions With Physics Performance Issues

This section describes how to approach regions with low physics performance.

Determine the source of a performance issue

    • Is performance related to any content in the region?
      • Does physics performance suffer when certain physical objects are in the region? If so, does it only happen when the objects are in certain areas?
        • If so, investigate the #Collision geometry of the physical objects and any objects which they are in proximity to.
      • Does physics performance suffer due to scripted content in the region?
        • Scripted objects which rapidly change their physical shape can greatly impact performance. In the statistics bar, this is measured under 'Time Details (ms)' -> 'Update Phys Shapes'
        • For debugging purposes, an estate manager may pause all running scripts in a region via 'World' -> 'Region / Estate' -> 'Debug' -> 'Disable Scripts'.
        • While scripts are running, rapidly updating objects will be highly visible to any viewer when 'Develop' -> 'Show Info' -> 'Show Updates to Objects'. While this display will also show objects which are updating in non-physical ways, it is a good starting point
      • Does physics performance suffer due to pathfinding?
        • In the statistics bar, pathfinding time can be found under 'Pathfinding' -> 'AI Step Time'
        • An estate manager may disable 'dynamic_pathfinding' in the SimConsole, which will disable all dynamic pathfinding actions following a region restart. When this option is disabled, only the static navmesh will exist, and no pathfinding characters will be able to move
        • Simplifying the navmesh (as described elsewhere in this page) will greatly improve pathfinding performance in the region.

Debugging collision-related performance issues

The pathfinding tools allow you to view the physics geometry of objects, which is very helpful for debugging.

  1. Set the non-moving objects near the collision area (e.g. floor prims and other nearby objects) to either 'static obstacle' or 'walkable' pathfinding types.
    • Step-by-step instructions can be found here ).
    • If you want pathfinding characters to walk on the objects, use 'walkable'. Otherwise, use 'static obstacle'.
    • In general, any non-phantom object which doesn't need to move should be set to one of these types.
  2. Rebake the region
  3. Open the "Pathfinding view/test" floater, and follow #Identifying and fixing bad physics geometry
    • Disable 'show world' to get a clearer view
    • Enable either 'walkables' or 'static obstacles' to view your objects
  4. Check to see if there are any hidden objects which may be contributing to bad collisions
    1. In the "Pathfinding view/test" floater, enabled "World" and "Movables Only". Disable "Walkables", "Static Obstacles" and so forth. The remaining view should show only movable objects
    2. Remove any unnecessary movable objects you see.
    3. Set the remainder of the movable objects to a static pathfinding type, as explained above, then repeat #Identifying and fixing bad physics geometry on them after rebaking the region
  5. Next, inspect the physics geometry of the physical objects which are generating the collisions
    1. Temporarily set the vehicle or other physical object to 'static obstacle', then rebake the region. Note that this will prevent the object from moving, and is only useful for debugging purposes
    2. Repeat #Identifying and fixing bad physics geometry on the normally-physical object. The shape in this case is extra important, since these objects will be involved in many collisions.
      • For example, a 'well designed' motorcycle should be represented by a cylinder or sphere for each wheel, and a simple box or two for the chassis.
  6. Look for other sources of bad collisions
    • Even if the physics shapes are individually 'clean', certain arrangements of objects will cause more collisions (and thus more physics time). One typical bad case is having a floor with many solid layers stacked on top of each other. If a physical object collides with such a surface, it will generate collision events with each layer, impacting simulation efficiency and potentially causing strange behaviors. If the cross-section of your floor resembles a gâteau de mille-feuilles, consider changing some of the layers to have no physics shape.
    • Piles or other large collections of physical objects will never be good for performance, even if each object is a simple sphere or box.

Identifying and fixing bad physics geometry

Verify that the physics geometry is not too complicated looking:

Fixing physics-shape-update related performance issues

If an object has been identified as causing physics performance issues in a region (see #Determine the source of a performance issue), there are two options for fixing it:

  1. If the prims triggering the shape update don't need to be physically simulated, set the physics shape type to 'none' to remove the problem.
    • If you lack modify permission on the object, set the physics shape type to 'static obstacle' or 'walkable'. This will prevent the object from changing its physics shape, fixing the performance issue at the expense of preventing visible motion.
  2. If the prims triggering the shape update do need to be physically simulated (for example, a moving drawbridge), unlinking the movable part from the rest of the build so that there are no shape updates (just moving linksets) will fix the problem.
    • In this case, consider using keyframed motion instead of llSetPos or similar. Keyframed motion is more performant and also looks smoother than a sequence of 'stop-motion animation' movements

↩️ Back to Good Building Practices