Physics best practices
Collidable objects in the world require physics processing to determine if something is interacting with them. Optimize physics processing by disabling colliders on any objects that aren’t interacted with or are outside the game play areas. In manual traces, large numbers of colliders will be reflected in Physics.Simulate times. If you have access to developer builds of Meta Horizon Worlds, the number of colliders in the world will be broken out in the Physics::Overlaps # trace. As a rule of thumb, the number of overlaps should be kept below 400.
UpdateRunner::PrePhysicsUpdate and UpdateRunner::Physics.Simulate in high collider world
To view colliders in the world, toggle Collision in the Utilities menu. This highlights all collidable objects in the world with an orange tint.
Collision in the Utilities menu
Collision off
Collision on
With highly detailed objects in play, disable the detailed colliders, then wrap the detailed object in a primitive collider such as a cube (best), sphere, or capsule collider. This only requires one physics test for collision and usually results in no loss of functionality or visual fidelity.
Complex object made of non-collidables with simple collidable cube
Enclosed in a non-visible collidable object
For best performance, you should attempt to leverage primitive colliders (as shown below). The only exception is for things that you collide with very often/all-the-time may be better as a single, large mesh. Testing can help determine which gives better performance.
This is especially true for worlds that are using Custom Model Import, as using non-mesh colliders and non-primitive colliders will incur an additional, high, and spiking cost associated with rendering.
World Editor showing raw primitive colliders
In order for grabbables to have good performance, it is important to minimize the number of collidable components on the grabbable object. For a rule of thumb, the maximum number of collidable components any grabbable should have is 2.
The number of triggers in the world has a runtime cost associated with it. This is seen by an increase in Physics.Simulate and the TriggerRuntimeIntegration::Update markers. Active triggers still have a runtime cost in the world even if they are inaccessible to the player.
Even objects outside the player area that have a trigger will still contribute to frame time.
For best performance, disable triggers far away from the player, in areas like buildings (until the player enters the building), and areas inaccessible to the player.
