In the ToDo list it was mentioned that adding rotation to the physics system was desirable.

Note that with arbitrary rotation, to have physics-stackable boxes and stable resting contact you need either

  • a constraint-based physics system with an LCP (LinearComplementarityProblem) solver. Accurate and stable, no penetration of objects, but slow and hard to implement.
  • a penalty method (springs and dampers). Easy to implement, but can be unstable (system blows up easily). Objects penetrate (sink slightly) into one another.

The current physics system is an impulse-based system, with the additional restriction that collision geometry is always an axis-aligned bounding box. Collisions are resolved by temporal backtracking/binary search to find the collision time within a particular numerical tolerance, then applying an impulse to the two bodies to ensure they move away from each other. Both constraint-based physics and penalty methods do not necessarily need to backtrack to find "exact" collision times because these methods can move the system from an illegal (penetrating) configuration to a legal configuration (via constraint stabilization with constraints, or via penalty forces with penalty method). This "graceful handling" of illegal configurations can potentially simplify and speed up the physics code, because temporal backtracking/searching is not strictly necessary, and the engine does not have to abort when penetration occurs (as is currently done via an assert).

Note, however, that this assumes the simulation frequency is high enough so that tunneling effects (high-speed objects flying through each other) do not occur and that object penetrations will be minimal, thus allowing a graceful return to a nearby legal configuration.

It is of course possible to combine constraint or penalty methods with temporal backtracking for greatest accuracy. It's just that it is much less necessary with these approaches than with a strictly impulse-based approach.


KevinSeghetti -- While it is true the existing method of determining the exact time of a collision is a bunch of math, it occurs in near constant time, there is no binary searching (see the function ComputeOverlapTimes in wfsource/source/physics/ Or click here . However, from reading this I now realize that if/when collision rotation is added it will either be a whole bunch more math (which I am probably not qualified to write, not really knowing any calculus) or become a binary search. Both of these other collision prevention systems sound interesting, I would like to work toward being able to plug in different physics behaviors so we can play with them.

MrLin -- BTW one other method I forgot to mention is the projective "fix-up" method, where physical evolution of the system is allowed to proceed in an unconstrained manner, then the geometric constraints are iteratively and procedurally "fixed up". This is an astonishingly simple and effective way to get "real-looking" rigid body dynamics while indirectly avoiding most of the math. See

Also the aero package is a penalty-based simulator and has excellent documentation (for understanding the theoretical basis) at!braunl/aero/ftp/

A couple of other packages (GPL) worth looking at are DynaMo (constraint-based with iterative solution for constraint forces, but no direct support yet for resting contact) and ODE (constraint-based with analytical solution for constraint forces, support for resting contact).

There are also several impulse-based simulators available, see for a good tutorial with sample code. However impulse-based simulation does not support resting-contact (i.e. only good for bouncing boxes around, not stacking them).

All of the above methods allow for arbitrary rotation.

All of these physics systems need a better collision detector. For collision detection the ODE library provides several good box-box, box-sphere, box-cylinder, etc. tests. Also the FastCar library has a free collision detection library. If doing anything other than impulse-based physics, then the collision detector must provide the penetration depth (in the form of a penetration vector or closest-features points in space) of overlapping bodies; this penetration depth is used then to compute a constraint or a penalty force to correct the penetration. This is not necessary with impulse-based systems because the impulse is applied at the exact instant of collision, thus needing no penetration depth to compute the collision response. The availibility of penetration depth information is the reason that constraint- or penalty-based simulators can gracefully move from a penetrating to a non-penetrating configuration.
Topic revision: r1 - 08 May 2002, MrLin;
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback