[ODE] ode/opcode and heavy objects

[nlin@nlin.net]

On Sat, Aug 30, 2003 at 06:46:28PM +0100, Jan wrote:
> Hi I'm a newbie here - I've just integrated ODE into my game. It's all
> working to an extent, but I'm having problems with stuff not colliding
> properly.

> I'm colliding box bodies vs. a trimesh. 
[...]
> If I lower the density the objects don't fall through the floor as 
> much.
[...]
> I've had a similar problem colliding against a plane 

This isn't really a problem with ODE per-se, but is a problem with discrete
numerical simulation. Since during collision you are just taking a snapshot
of the discrete object states, it's possible for fast-moving objects to
jump "through" thin objects instead of colliding with them.

A couple of suggestions.

1) Reduce the timestep. However, this means increased CPU load if you want
to maintain the same real-time (wall clock) performance. E.g. if you're
stepping by 0.01, try stepping by 0.005, but then you're doing twice as much
work (but each step is smaller in time, meaning the objects move less,
meaning fewer collisions will be "missed")

2) As much as possible, use ODE primitives instead of trimeshes. This is
because a trimesh is "hollow", meaning that collisions only take place
on its surface, so if an object completely passes through a trimesh surface,
it will not register a collision. By contrast, ODE primitives (boxes, spheres,
planes, capsules) are "solid", meaning that if another object is embedded
inside of it (even totally embedded), a collision is registered.

With reference to your comment above having "a similar problem colliding
with a plane", this actually should never happen with an ODE plane. If an
object is on the negative side of the plane, ODE's collision detector
should always report a collision. Put a debugging printf in your collision
callback function and check if a collision is really taking place with the
plane or not. Now, what may be happening is that you have extremely high
gravity which is pulling your the object down very far into the plane (the
floor). ODE registers a collision, but the object is already deep on the
negative side of the plane. ODE's ERP (error reduction parameter) tries
to pull the object back onto the positive side of the plane, to reduce the
error (i.e. to eliminate the collision or the penetration), but your
gravity is so high (and/or your object mass is so high), so that the
force generated by gravity (F = m a) overpowers the force generated by
the ERP, so your object continues to infinitely fall down.

3) If you must use trimeshes, try to make them "non-hollow" by filling them
with smaller versions of the geometry. E.g. if you have a trimesh box, then
instead of just modeling the surface of the box like this:

+----------------+
|                |
|                |
|                |
|                |
|                |
+----------------+

Try modeling the interior of the box too, like this:


+----------------+
|                |
| +-----------+  |
| |           |  |
| +-----------+  |
|                |
+----------------+

In other words, have smaller versions of the same geometry "inside" of the
original trimesh surface, so that even if an object completely passes through
the outer hull, it will (hopefully) collide with the inner hull. You can
have multiple inner hulls, one inside another, like a Russian doll. If the
hulls are spaced closely enough, then the ERP will push the object all the
way out to the outermost hull (if the hulls are too widely spaced, then the
object could get embedded somewhere between two interior hulls).

You can do the same thing with floors by having multiple floors, spaced
tightly, beneath one another.

Of course, adding geometry like this burdens the collision detector a bit more.
Depending on how much geometry you are duplicating, the additional collision
burden may or may not be significant.

Another option is to treat the trimesh as a height field - whether this is
applicable depends on your app. Someone on the list has modified the trimesh
to be treated as a height field - try searching the mailing list archives.
Not sure if that was ever released, though.

> I
> set my object dimensions to 20,20,50 (as opposed to the 0.2,0.2,0.5 in
> the boxstack sample) the object simply passes through the plane. Once I
> scaled all my numbers by 1/64 it all worked fine. Is this normal?

This comment I find interesting since here, you are talking about modifying
the size, not the mass, of the object. I would think that a larger sized object
would have fewer problems with a "tunneling" collision than a smaller
sized object; in other words, the described behavior is opposite what I
would expect. Do I understand correctly - you are saying that given
a plane (not trimesh) as a floor, and a box with dimensions 0.2,0.2,0.5 and
some fixed mass, and some fixed timestep, and some fixed gravity, the box
falls and collides with the floor, but if you increase the dimensions to become
20,20,50, leaving all other parameters the same, the box falls through the
plane? I am at a loss to explain this behavior, since increasing the size
of the box alone should not affect the speed at which it falls, therefore
not leading to tunneling behavior. A sample program demonstrating
this behavior would be helpful in diagnosing this.

-Norman