[ODE] iterative solver: testing needed

[david@csworkbench.com]

>
>> Since this is a logical method and easily
>> tweakable, I don't see why it shouldn't be added to the source, where
>> there is direct access to body internals.  I'll see if I can't squeeze
>> this in the stepfast files.  I guess a new body flag will need to be
>> added to disable auto-disabling for that body.
>
> Sounds good.
>
>> Right, but if you automatically disable bodies accross the board, when
>> a car is stopped, it gets disabled.  When you then up the velocity on
>> the joint motor, it's acting on a bunch of disabled bodies, so nothing
>> happens until the car gets run over....  So I'll need to re-enable any
>> bodies that were auto-disabled if they are connected to a powered
>> joint.
>
> Makes sense (I dont' support joints in my engine yet).
>
>> Well, if you implement these "glue" constraints as fixed joints with a
>> settable fmax, which destroy themselves automatically the first time
>> their fmax is breached.... it might just work.  The problem is, the
>> contact joints generally do the job of holding the wall up, but it's
>> generally not a good idea to collide stuff that's connected by a
>> joint.  So the "glue" joint would have to hold up the weight of all
>> the blocks above it, forcing you to vary fmax by how high in the wall
>> it was....
>
> The idea was that once you have connected bricks into a wall, you assume
> the wall is stable and solid, and no longer simulate it until an
> external force is applied.

Right, but as soon as that external force is applied, those bottom joints
would become crushed under the weight of the wall.... unless you disabled
gravity until the wall crumbles, but that has its own problems.

>> Cloth-like problems generally deal with particle based systems.  Since
>> you want the blocks to roll around like blocks when they hit the
>> ground, I think it would be better to simulate them as rigid bodies.
>
> Yes, but once the constraint is broken, you can turn seperated bricks
> into full-blown bodies again.  The idea is to avoid having to treat a
> massive wall (or entire buildings) as seperate bricks with a full
> dynamics solution until necessary.  Even with the iterative solver that
> may be out of the question.

Well, I'll have to think on this one for a while (and get a verlet
integrator running at some point), but I see a few problems.... a particle
mesh is 2D, so you simulate the face of the wall, and have to have
something to stabilize it.  There is no feedback for how much force
(strain) is being placed on this particular constraint, other than how far
off it is at the end of the iterations, but you could still use that as a
break parameter.  I kind of have a feeling that you would end up ripping a
seam straight up from the impact point, then the rest of the bricks on
either side would flap around like.... cloth.  But I don't know without
trying it, and I want to get the iterative solver completed, optimized,
and integrated before I start on the next tangent.

>>  On the other
>> hand, the best approach to the destructible wall problem may be Finite
>> Element methods, but I haven't read up on them enough to tell just how
>> feasible they are for a real-time engine.
>
> Not aware of those yet.

http://graphics.ethz.ch/~muellerm/publications/fracture.pdf if you're
interested...  Theirs is probably the method I would use at first glance,
since deformable bodies are modeled as rigid bodies until they need to
deform (or fracture).  It would be interesting to be able to shatter glass
and warp plastic in ODE...  There's just not enough hours in a day.

> --
> gl
>
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode