[ODE] iterative solver: testing needed

[david@csworkbench.com]

I think I left the world ERP at 1 and CFM at 0 in the version I released. 
Anyone who is having the stuff disappearing problem, try changing these to
0.8 and 1e-5.  I had the same problem on a few test runs, except the other
way around (the old solver disappeared and the new one worked).  Let me
know if that fixes it.

I've traced my bug to the slip parameter.... it seems the iterative solver
is just a bit more sensitive to CFM in general.  I did a little more
re-arranging, went back to evaluating joints every iteration, but moved
the moving and rotating bodies outside of the iteration loop, and enabled
random joint ordering each iteration.  That helped a good bit, so now the
sliding friction problems are only as bad as the original solver, so I
guess that means they're right :)  Now joint evaluation is right up there
with either half of the "compute A" cycle timewise :(  But it's still
fast.  (btw, if you're trying to do timing I'll post a replacement
timer.cpp that should make a bit more sense out of the numbers.... it adds
up all the times for a given code segment before displaying the result
instead of showing every time each piece of code was executed).

As far as the micro-jitter/driving around problem goes, I imagine all code
that employs the iterative solver will have it's own way of resolving that
through the use of body disabling (which should work now, I'm about to
start testing it).  I'll put an example into test_crash for people to use
as a reference point (and see how big a wall I can build then :).  I
figure I'll go through after each step and disable all bodies who's
velocity components (angular and linear) are all less than .01 (probably
be tweaked).  Then any time I add power to a joint, if I set the velocity
!= 0, I'll enable the bodies that are connected to it.  Is that pretty
much what those who have disabling bodies in their code are doing?

The only thing i don't like about that is, say I wanted to build a whole
city out of disabled blocks, or at least a few large buildings.  From
playing around with the wall in test_crash, if just one car runs in to it,
it tends to bust a triangle-shaped hole in it, which seems just fine
physically.  However, if you start building bigger walls than the 100
blocks or so in that one, even with the iterative solver you'll slow down
when the whole thing becomes active at one time.  I'm trying to think of a
good way to only activate the part of the wall that would be affected by
the collision. My first thoughts are switch from a breadth-first to a
depth-first search for the bodies in an island, and limit the number of
consecutive disabled bodies you can go through with a new function added
to the API.  Say you set the AutoEnableDepth (sound like a decent name?)
to 2 (this number should probably be based on the size of a brick relative
to what may hit it).  When the car first ran into the wall, a circle of
radius 2 blocks would become enabled.  Assuming the car pushed the blocks
fast enough, they wouldn't get disabled, and next step the circle would
widen to radius 4, and so on until the motion of enabled blocks fell below
your disabling threshold.  Then, if you were sure to disable those slow
moving bodies after every step, then an enabled/disabled edge should form
right along the bodies that are just at that threshold.  Those bodies
would be re-enabled the next step, and if they moved fast enough, the edge
would move out again, otherwise, they would get re-disabled after the
step.... I think.  Does that sound like a good solution to you guys?  Or
does someone have a better idea?  I'll post the updates to the internals
in a little while, then I'll start working on the test_crash reference and
the revised Island creation code.  And I'll make wall boxes change color
when they are disabled.  That should give a clue whether the algorithm
works or not :)  But if it does work, you should be able to build
arbitrarily large destructible walls and still keep the framerate in a
reasonable territory..... unless, of course, you start dropping weapons of
mass destruction on your city of a million bricks.... then the iterative
solver will only take a few steps longer to segfault than the old
method... but hey, I guess that's the physically correct solution in that
case :)

David

>
> david@csworkbench.com wrote:
>>>I can't seem to make test_crash.exe display anything except
>>>the ground-plane and the ball-in-the-sky -- though it's
>>>simulating something because it gets slower when I add more
>>>cars or wall blocks!
>
> The same thing happened for me. If I started with the old solver, the
> objects were there. If I started with the new solver, they were not. If
> I toggled to the new solver, they disappeared. The caterpiller worked
> though. I was using vc6 btw. I was not using the latest stuff from cvs.
> Just the .035 release.
>
> Adam D. Moss wrote:
>>It looks like I **may** have been confusing a friction problem
>>with your Erroneously Sliding Things bug -- since a similar thing can
>> be seen in test_boxstack using dWorldStepFast(), with just a
>>few or as many as 40 iterations!  (About 1/4 of the bodies micro-
>> jitter along the ground, looking like they're slowly sliding.)
>
> I had a similar problem in my own weird (non opende) iterative solver.
> My objects tended to slowly drive themselves around if they did not have
> any objects on top of them to hold them in place. The problem was
> friction based. If I removed the friction math all together, the objects
> sat still. In reality it was not a big deal. Those objects could always
> just go to sleep right away and that was easy enough to detect. Still it
> bothered me, so I poked at it for awhile and ended up using a scalar
> ramp based on the iteration number. Lone bodies still drives themselves
> around a tiny bit, but it helped a lot.
>
> -billy
>
>
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode