UPBGE / BGE – Physics cost performance order

by admin · January 23, 2019

Have you ever been making a game/app in the BGE or UPBGE and then somehow the frame rate drops when camera is pointing to some specific area? This is a common mistake among newcomers, and although there are several causes for this to happen, physics objects are one of the most commonly so here are some advices to take into account so you can use the correc physic type and shape in order to avoid the excesive resource consumption while executing the game engine.

I’m assuming you have some basic understanding with the BGE/UPBGE

Here are some important things to take into account when using the UPBGE or the BGE

Physics Type Order:

No Collision (least processor intensive)
Static
Dynamic
Rigid Body
Soft Body (most processor intensive)

Physics Shape Order:

A collision shape is the shape of an object as “seen” by the collision/physics engine.

Think of a square box and a circle:

enter image description here

Near the corners, objects will hit or collide with the box but not the circle even though the height and width of the objects are identical.

More complex shapes as also possible. Circles/spheres are the simplest (and fastest) but tend to poorly represent many kinds of objects. Axis-aligned bounding boxes (AABBs) are the next most common/efficient. Capsules (a cylinder with half-spheres on each end) are common for characters. The common collision algorithms all support convex hulls (a polygon/polyhedron with only convex angles), and decent physics engines are typically capable of dealing with objects which have multiple shapes (allowing for objects to incorporate shapes with concave features, even though the collision engines typically can’t handle them directly).

Source

Sphere (least processor intensive)
Capsule
Cylinder
Box
Convex Hull
Triangle Mesh (most processor intensive)

Notice that every collision shape reacts very different to each other, the more simple the less CPU expensive. You can also note that we have physics visualization enabled to see how many vertex are being computed to calculate collisions on each shape.

Other things to note:

Static objects should have a collision margin of zero, all other objects should have sane collision margins to prevent jittering.
Convex hulls are an order of magnitude more stable than triangle meshes. Use compound shapes and convex hulls wherever possible
Ghost objects can be the most expensive objects. The more objects they overlap with the more processing time they use, and it gets expensive fast (for some reason, the collision resolution still seems to run. Not sure why it doesn’t stop after collision detection). Use no collision or use collision layers wherever possible.
Don’t manually move dynamic/rigid body physics objects. Always use forces or velocities.
If you do not select collision bounds, it selects triangle mesh as the representation (the most expensive).

Source