[ODE] iterative solver: testing needed

[david@csworkbench.com]

>
> Just ran a quick test, throwing a bunch of spheres around my
> heightfield. First impressions - wow.  In situations where loads of
> spheres are touching one another (not as kinky as it sounds), the
> original solver usually kills my renderer to below 1fps.  The iterative
> solver with the recommended 5 steps runs the same (i can't spot any
> visual differences), but at a beautiful 50fps.  Way to go Dave!

<big sheepish grin>

> I had a quick play with test_crash, and I see a problem where the buggy
> is slowly moving right from the outset with Dave's solver, whilst it
> stops completely with the original (as it should).  I can toggle between
> those behaviours.  This is before any input has been applied.

Yeah, I think that's pretty much the same problem.  The easiest way to
make the bug apparent is to turn the mu down pretty low and press 'a',
where the car is spinning it's wheels a lot.  It'll head off at almost a
45 degree angle.  It only spins when you brake hard (get it going fast
with 'a', then press space).  I think the problem has something to do with
the fact that I'm accumulating forces between each joint evaluation, but
I'm not updating the velocity.  Maybe that's keeping ERP from doing it's
job.  I'll let you know when I get that in.

> Is this the problem you meant Dave?  It sounds like you were getting
> spinning - of the car itself?  I'm not seeing that, just the wheels
> rotating very slowly when it should be stationary.
> --
> gl
>
> ----- Original Message -----
> From: "gl" <gl@ntlworld.com>
> To: <ode@q12.org>
> Cc: <david@csworkbench.com>
> Sent: Sunday, March 30, 2003 10:43 AM
> Subject: Re: [ODE] iterative solver: testing needed
>
>
>>
>> Small problem compiling the test on MS VC:
>>
>> ode/test/test_crash.cpp(205) : error C2086: 'i' : redefinition
>>
>> simply remove "int i" at line 172.
>> --
>> gl
>>
>>
>> ----- Original Message -----
>> From: <david@csworkbench.com>
>> To: <ode@q12.org>
>> Sent: Friday, March 28, 2003 3:32 PM
>> Subject: [ODE] iterative solver: testing needed
>>
>>
>> > Well guys, I need some help finding out why my car is spinning when
>> it stops in the iterative solver, so I'm releasing it for y'all to
>> play
> with.
>> >  If you can help me define exactly what causes it, maybe I can track
> down
>> > my bug.  I think it has something to do with the contact constraint,
>> but I've tried all kinds of friction and slip parameters with both
>> the LCP
> and
>> > my simpler solver (there's a define at the top of stepfast.cpp --
>> FAST_FACTOR or SLOW_LCP).  And I just can't seem to find anything
>> that makes it not spin (intuitively, the last thing I changed is
>> what would have caused it....)  So y'all give it a whirl and throw
>> some ideas at
> me.
>> >
>> > http://www.csworkbench.com/stepfast.zip
>> >
>> > Place that in the ode directory and extract it.  It will replace
>> your Makefile, Makefile.deps, and ode/include/objects.h files, as
>> well as placing the stepfast.h/cpp in the ode/src directory.  Then
>> running make should compile it in.  I've also put the test file I've
>> been using (test_crash.cpp) in the ode/test directory.  You'll
>> notice lots of
> defines
>> > at the top.  You can change ROWS and COLS to a higher number to make
>> the army of cars, and uncomment #define WALL to add the box wall to
>> the simulation.  ITERS is the number of iterations per step.  You
>> can press 'f' during the simulation to switch back and forth between
>> the iterative solver and the old solver.  The green/red ball in the
>> sky tells you
> which
>> > one you're using currently (green=iterative, red=old).
>> >
>> > So, play around with it, see if you can help me find my bug.  (Or
>> just play around with it :)  I'll continue testing and work on some
>> documentation.  If you want to use the iterative solver in a current
>> program of yours, just change:
>> > dWorldStep(world, timestep);
>> > to
>> > dWorldStepFast(world, timestep, iterations);
>> > 5 seems to be a generally good start for the number of iterations in
>> the tests I've run.  But more complex systems may need a higher
>> number.
>> >
>> > Thanks for the help,
>> > David Whittaker
>> >
>> >
>> > _______________________________________________
>> > ODE mailing list
>> > ODE@q12.org
>> > http://q12.org/mailman/listinfo/ode
>> >
>>
>> _______________________________________________
>> ODE mailing list
>> ODE@q12.org
>> http://q12.org/mailman/listinfo/ode
>>
>
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode