Crossposting at https://stackoverflow.com/questions/29993547/rigidbody-physics-concept-why-translate-collision-shape-on-the-fly-instead-of-m

I've spent some time going through physics engine's sourcecode in Java like JBox2D, Phys2D (both 2D) and JBullet (3D).

I observed that, while the rigid bodies move and are mutated in each step, the collision shapes that are attached to them, are not. Instead, they always stay located around the coordinate origin. When checking two rigidbodies for collisions, a "translation" object is fetched from each and is used to translate the two checked shape's vertices (or other defining properties, depending on the shape type) to their attachment's world position on-the-fly. These information are then used to detect collisions and react to them.

I've concluded the main purpose is, that you can reuse the same shape instance for multiple bodies, as they are stateless in the described scenario and save some memory as the needed information are calculated on-the-fly in each step.

However, I currently see more advantage in mutating the shape's positional properties as in their member values. Each shape's aabb and vertices would change ONE TIME in each step, so you don't need to calculate the same vertices multiple times when intersecting one shape to multiple other ones. Plus, you could also change areal properties (damage deformation) of the shape, because it is only used by one body.

So the questions is:

Why is it common to use positionally immutable collision shapes instead of mutable ones?

Edit: Found quite the same question, but without much of an answer at Storing rigid body collision shapes in local or world coordinates

  • \$\begingroup\$ And plus it is easier to update just one position value in the Rigidbody or the Transform than update the many vertices of a collider. If you have a 10000 vertices collider (if you need accurate collisions) you won't update all of them. That would just be way unoptimized, instead you just need to update the position and rotation value and let the rendering thread take care of all the vertex transformation work. \$\endgroup\$
    – EvilTak
    May 4, 2015 at 4:46

1 Answer 1


One major advantage is that many collision detection operations are more efficient when performed at the origin. A classic example is box vs sphere. When done in a box's local space the tests are very simple axis aligned distance point-plane tests instead of the more costly non-axis aligned planes.

Furthermore objects moving through space may not actually hit anything for a frame so there is no value performing the costly operation of moving the shape and all of its vertices each frame. Instead the transform of the rigid body is updated every frame - it has to be to integrate linear and angular velocities, anyways - and then the axis aligned bounding box of the shape(s) is updated. Only when potential intersection exist do the costly tests get performed. If we had to move the vertices every frame it would be far too expensive. Good collision detection libraries are a series of steps that start from simple (AABB overlap) and move towards more complex (specific pair-wise collision agents) in the hopes that the higher level tests will prune out the costlier ones.

  • 1
    \$\begingroup\$ Besides those reasons stated, another reason is that as a floating point number gets farther from 0 they lose precision. Keeping an object at the origin means maximal precision in the math. Also, if the object is made of vertices, you'd have to update all the vertices each time the object moved, which would be quite a bit of waste. \$\endgroup\$
    – Alan Wolfe
    May 4, 2015 at 1:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .