[ODE] 3 beginner questions

[david@csworkbench.com]

What seems to be the problem is that increasing the density of an object
increases it's mass, and increasing it's mass increases it's force due to
inertia.  If you only add a damping force/torque in relation to it's
speed, then a more massive object _should_ take longer to slow down than a
less massive (dense) object (a bowling ball takes more force to stop it
than a basketball).  So to get the behavior you want, scale the damping
force by the mass of the object.  btw, a coefficient of -1 doesn't
necessarily imply a "total damping" force.... you can use larger
coefficients to great effect (I wrote one app that had scaling factors of
-100, but scaling by the mass should help this).

If you add drag after the step, it doesn't get incorporated into the
system until the next step, but I guess that doesn't really matter.  If
you're objects are _sliding_ to a stop, increase mu and decrease the slip
parameters to get them to come to a stop faster.  If they aren't sliding
to a stop, drag is the only thing that will slow it down faster.

Aerodynamic drag *can't* be implemented internally.  ODE uses point masses
to represent it's bodies, and geoms are created in the separate collision
detection engine.  However, the collision detection engine is designed to
be modular so it can be replaced by your own CD routines if you want to. 
This means that the internal ODE functions don't really have access to the
goem, and thus the shape of an object.  So aerodynamic drag *must* be
implemented externally.

From the docs:
--------------------------------------------
9.7.3. Plane class

dGeomID dCreatePlane (dSpaceID space,
                      dReal a, dReal b, dReal c, dReal d);

Create a plane geom of the given parameters, and return its ID. If space
is nonzero, insert it into that space. The plane equation is
    a*x+b*y+c*z = d
--------------------------------------------
It's not a bug.

David

> Thanks for the replies, people.  Its good to find such a helpful
> usergroup.
>
> to David McClurg:
> 2. I am applying both a force for velocity damping and a torque for
> rolling resistance, though right now I´m more interested in the former.
> I´ve tried just the velocity damping, a combination of both, total
> damping ( coefficients of -1.0 for both ), your constant force method,
> but nothing helps me to bring my objects to a quick stop except
> paradoxically reducing their mass.   Thanks for your pragmatic method,
> with tweaking it worked for me but I´m hesitating to use it for the
> sensitivity of the friction parameter to body velocity...  Instead I´m
> just leaving it as force applied based on a high (-0.9)  coefficient of
> the linear velocity.
>
> to david@csworkbench.com:
> 2. Drag.  I have now experimented with various flags in the contact mode
> parameter.  From the beginning I had the dContactApprox1 flag included,
> so thats not the problem, unless another flag is interfering.  But
> trying to remove other so far flags retains this behaviour, ie that the
> time taken to slide to a stop increases with extra density...  Anyway
> any illumination you give on how combining these flags and their
> parameters can effect contact response is very welcome. One thing you
> mentioned in your later elaboration of drag and friction is that you´d
> apply the former after collision detection but before the step.  I´m
> doing this after the step, but I´m not sure if that might be
> significant.  It seems that the constraints entailed by the contact join
> generate the forces/torques during the step....  si it doesn´t matter if
> I try to intervene before or after. The problem is probably as you
> suggested originally that I´m generating the wring sort of contact
> joints.
>
> Btw regarding aerodynamic drag, I´d love to see that implimented.   The
> moment that really convinced me how important good dynamics could be was
> watching Karl Sims swimming creatures evolve to use their limbs as
> paddles :)=
>
> 3. I´ve added bounding planes as per your suggestion.  Duh!  One curious
> thing though: I use the standard ax+bx+cx+d=0 equation for my planes,
> but I found I had to negate d when passing the plane to ode for the
> collision to work correctly ( at least with dCollideSpherePlane ).  Does
> Ode use ax+bx+cx-d=0 or is that a bug?
>
>
>
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode