[ODE] Performance patch : not checking collision between disabled bodies

Adam D. Moss adam at gimp.org
Thu May 27 09:08:24 MST 2004


Nguyen Binh wrote:
>            2. Infact, disable bodies have been handled in the dynamics
>            core of ODE : see ProcessIslands(), we just handle enabled
>            bodies and bodies connected to enabled bodies so why we
>            didn't do that on collision detection?

Because cd != simulation, and while one would expect the SIMULATION
of the bodies to be affected by BODY disable/enable, I would not
necessarily expect this to imply that two geoms corresponding to two
different intersecting disabled bodies would stop receiving a
nearcallback.

I don't think it's a big deal, I just don't think it's quite the
right solution to the problem while it's moving an increasing amount
of policy into ODE that could quite easily, in this case, be left to
the app.

It wouldn't matter at all if I couldn't think of fairly mundane ways
in which the app could care about getting collision callbacks from
disabled-disabled bodies, but I can think of some... I guess most of
them can be worked around in some fashion.

> ADM> I don't think this patch is correct as it is though.  It assumes
> ADM> that both bodies are !=0 but I don't believe that this has to
> ADM> be true (otherwise the earliest existing escape of:
> if (g1->>body == g2->body && g1->body) return;
> ADM> does not totally make sense).
> 
>      Hmm, that code is not mine. It's the original. ;0

I know -- but it implies that both bodies CAN be 0 (since it
makes an explicit exception for it), while this patch would crash
if it encountered such a situation.

Regards,
--Adam
-- 
Adam D. Moss   . ,,^^   adam at gimp.org   http://www.foxbox.org/   co:3


More information about the ODE mailing list