[ODE] AutoDisable issue?

[Mohsin Hasan]

Nguyen,

I downloaded their SDK and tried their demos. I tried their BoxBox test1
demo. It gives me an average of 359 FPS when the bodies are disabled. When
you drop a sphere over the stack, they collapse and fps drops to around 150
fps. It stays in that range for a while until autodisable kicks in at which
point fps jumps to around 355-360 fps regardless of the orientation of the
collapse. If on the other hand you move even a single block (thus enabling
it), the fps drops suddenly to around 250 fps. My guess is when all bodies
are resting, they are not doing any geom geom collisions at all and as soon
as a body is moved, it gets enabled and that is being checked with the rest
of the geoms (hence a sudden drop in fps). I am looking into ODE code and it
seems it is doing geom geom AABB tests for Hash Space regardless if the
bodies with both geoms are disabled (which apparently means they should not
collide?). 

Ideally if all bodies in a space are disabled, it shouldn't even generate
the AABBs for the geoms as none of the objects is moving. And once an object
is enabled, only then AABBs be generated and all the enabled bodies should
be tested with other bodies (enabled or disabled). This will remove the
checks for disabled-disabled bodies altogether and should improve
performance. This means there should no longer be collision callbacks
generated for disabled-disabled bodies (like the ones I've been getting...
around 1300 callbacks for all disabled bodies, which just get rejected from
my callback. Their AABBs shouldn't even be tested in the first place)

I've just started to look into the code so I may be wrong. Correct me if my
concepts are wrong regarding the disabled/enabled bodies.

Thanks,
Mohsin

-----Original Message-----
From: Nguyen Binh [mailto:ngbinh at glassegg.com] 
Sent: Monday, May 24, 2004 5:50 PM
To: Mohsin Hasan
Cc: ode at q12.org
Subject: Re[2]: [ODE] AutoDisable issue?

Hi Mohsin,

MH> Ok. I was wrong. It improves performance a little but still kills 100
fps.
MH> (It was basically 100 + 5-10 fps lost) and the reason being before stack
MH> collapse each Quickstep call generates only 373 collision callback (for
MH> disabled bodies) while after stack collapse Quickstep generates 1273
MH> collision callbacks (again for disabled bodies). I believe there should
be
MH> some early culling instead of calling this many collision callbacks. How
MH> does Novodex handle this? Apparently they achieve the same FPS after
stack
MH> collapse as before stack collapse.

    How could you make sure about this? Did you have their SDK or just
    look at their sample? IMHO, no physic SDK could maintain the same
    FPS after a huge stack of boxes collapsed.

-- 
Best regards,

---------------------------------------------------------------------
   Nguyen Binh
   Software Engineer
   Glass Egg Digital Media
   
   E.Town Building  
   7th Floor, 364 CongHoa Street
   Tan Binh District,
   HoChiMinh City,
   VietNam,

   Phone : +84 8 8109018
   Fax   : +84 8 8109013

     www.glassegg.com
---------------------------------------------------------------------