[ODE] Lots of stacked boxes/breaking constraints (was Re: Inside ODE)

[Phil Teschner]

The problem with the boxes in ODE is that the collision routine only
returns a single contact point between boxes.  This means that face-face
or edge-face contacts aren't treated nicely.

I found that you can stack quite a few boxes without the wobbling if you
interleave boxes with spheres:

-----
o   o
-----
o   o
-----
o   o

This is because the box-sphere intersection works quite well (as you
pointed out the spheres only have one contact).  It also shows that the
constraint formulation works nicely for the boxes even with multiple
contacts (8 per box in my example).  I think it also shows that if ODE
had a better box-box contact/collision function you could stack boxes
without getting the wobbling.

Phil

-----Original Message-----
From: nlin@nlin.net [mailto:nlin@nlin.net] 
Sent: Tuesday, March 12, 2002 10:56 AM
To: ode@q12.org
Subject: [ODE] Lots of stacked boxes/breaking constraints (was Re:
Inside ODE)

> If I create a wall made of several independant bricks, wouldn't
> the wall slightly "vibrate" then eventually collapse ? I guess it
> will only if at the beginning of the simulation, bodies are already
> interpenetrating each others...

Yes - if contact forces resulting from collisions are the only forces
holding the boxes together. I've haven't seen a real-time sim that
doesn't have this problem. The problem is that collision detection finds
a limited number of intersecting points, which is merely an
approximation
to the contact configuration. (For boxes, I think a max. of 3 points
are returned.)  By using this approximate contact configuration to
determine the contact force (which keeps the bricks/blocks resting on
one another and not interpenetrating), only an approximately correct
contact force is applied. This can cause a miniscule difference in
the contact configuration in the next frame, again causing a minutely
different contact force, etc. The problem gets propagated with stacked
boxes because a tiny, visually imperceptible change in contact
configuration
for the bottom-most box propagates to a changed configuration for the
next
box in the stack, which propagates to the next box in the stack, etc.

With a hacked test_boxstack program I can stack up around 5 boxes (maybe
more - I was dropping them all from a great height, which may cause
unneeded instability), but the stack rotates and wobbles slightly (but
it did not fall down). With spheres you can stack up many more (I just
tried it and can stably stack many more than 30 spheres, perhaps even an
infinite number, if they are all dropped from exactly the same position
with
exactly the same orientation) because the contact configuration between
spheres is mathematically simpler - just a point. 

Question to Russ - there was some talk about "breakable" constraints if
the force needed to maintain the constraint exceeded a certain
threshold.
Would it be possible to set up a stable box stack with a grid of joints
between adjacent boxes which had a very low breaking threshold? This
way the wall would be more stable (not relying on changing approximate
contact configurations) but still be destroyable. In other words, the
wall would be a "curtain" of bricks connected by weak joints, instead
of a loose collection of unconnected boxes resting on one another with
contact joints. Would this indeed be more stable?

Would such a large number of joints be computationally manageable? How
might an interface look for the breakable joints? Would deactivated
joints
still bog down the LCP solver? Maybe breakable joints need to be put
into their own group, just as contact joints are (so they can be quickly
created and destroyed). I think the future planned automatic suspension
of "still" groups would be beneficial here, too - all the joints in
the stable wall are inactive until, say, a car rams into the base of
the wall, at which point the wall either vibrates and stays standing
(if the forces are below the threshold) or shatters (if the joints
break).

Hm, this would be a fun enhancement to the test_buggy program :-)

-Norman

P.S. For a short-term solution to making a stable brick wall, you can 
apparently just use spehres, because they do stack quite nicely. You
can always draw a box instead of the sphere for visual display, and set
the mass distribution of the object to correspond to a box instead of a
sphere - though then your bricks would smoothly "roll" instead of
roughly
tumble once they hit the ground.
_______________________________________________
ODE mailing list
ODE@q12.org
http://q12.org/mailman/listinfo/ode