[ODE] Likely bug: non static deltaTime in the step (worldStep(world,deltaTime) instead of worldStep(world,0.05)) => problem?

[Adam Rotaru]

  After some further though I think Frederic
discovered 
a real bug with variable-size time steps in ODE.
If there is a collision constraint in one time step,
and
the next step is of much smaller size, the resulting
velocities
are wrong.  I suspect somewhere internally something
(v or v.m) 
is stored as an absolute entity within a time step,
and it is
used in the next step, ignoring that the step size
changed.
I also suspect that Russ can contradict/confirm this
relatively 
easily.  Unfortunately I can't spend more time on this
right now,
and I'm not very familar with the ODE internals to
look into
the code.

  In some more detail: assume you typically use a
small time step.
A body approaches a plane. Then suddenly you use a
much larger
time step, so the body moves a bigger step, and is
more likely to
collide.  Assume it does collide.  There is a change
in the velocity
(due to the collision).  Then the next time step is
small again, but
the velocities incorrect.  I post a simple code (based
on Frederic's
test case) below.  It uses step 0.001 for 9 steps,
than one 0.1 (100 times
larger).  The ball goes up to height 10 (and later
higher).
If I change the ratio of the two time steps, the
height changes, so the
ration of the time steps does matter.

deltaTime=0.0010000000  timeCount=6    
Pos=1.1772019394
deltaTime=0.0010000000  timeCount=7    
Pos=1.1750927893
deltaTime=0.0010000000  timeCount=8    
Pos=1.1729738291
deltaTime=0.0010000000  timeCount=9    
Pos=1.1708450590
deltaTime=0.1000000015  timeCount=0    
Pos=1.1687064789
deltaTime=0.0010000000  timeCount=1    
Pos=0.8567484690        Touch!
deltaTime=0.0010000000  timeCount=2    
Pos=0.8710736221        Touch!
deltaTime=0.0010000000  timeCount=3    
Pos=0.8853889652        Touch!
deltaTime=0.0010000000  timeCount=4    
Pos=0.8996944983        Touch!
deltaTime=0.0010000000  timeCount=5    
Pos=0.9139902214        Touch!
deltaTime=0.0010000000  timeCount=6    
Pos=0.9282761345        Touch!
deltaTime=0.0010000000  timeCount=7    
Pos=0.9425522376        Touch!
deltaTime=0.0010000000  timeCount=8    
Pos=0.9568185307        Touch!
deltaTime=0.0010000000  timeCount=9    
Pos=0.9710750138        Touch!
deltaTime=0.1000000015  timeCount=0    
Pos=0.9853216869        Touch!
deltaTime=0.0010000000  timeCount=1    
Pos=2.3118889468
deltaTime=0.0010000000  timeCount=2    
Pos=2.3251448099


  It is really funny how in his original program the
extra CPU to deal with the collision
detection was the *cause* for the bigger time step!


--- Nate W <coding@natew.com> wrote:
> I wonder if this is related to the "boiling" that
> has been described here
> in a few other posts.  If the object/plane collision
> function only creates
> one joint betweeen te box and surface, the object is
> free to rotate around
> that joint, and thus it is likely to penetrate the
> plane.  It makes sense
> that the simulation would respond by putting a lot
> of force onto the
> object, which might cause the jump you're seeing.

In this case the X and Y coords are always 0, the
contact
point is always below the CM, so the normal force has
no
torque, it does not cause the sphere to rotate.


cheers,
  Adam


__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/