[ODE] Slow performence in a given scene - optimizable, or "just how it is"?

[Geoff Carlton]

If you can treat entities as a capsule for almost everything (except ray 
tests and ragdolls), then you might have more luck performance wise.  
Cluttering up the collision space with these low level geoms seems far 
more expensive than having a large number of creatures that own simple 
primitives.

Geoff

Megan Fox wrote:

>Eh, there's presently a lot of inner-collision between the trigger
>bodies on a given entity (arms vs torso vs legs vs head vs sword hit
>zones), and that's dead easy to optimize out... it's just that 246
>doesn't seem terribly extreme for a larger scene, with piles of random
>boxes and such - and I still need that level of scene to run better
>than this.  Never mind that the larger scene would have dynamics going
>as well, vs the present almost-no-dynamics-at-all-just-collisions
>scene.
>
>On 11/5/05, Geoff Carlton <gcarlton at iinet.net.au> wrote:
>  
>
>>Just on the face of it, 246 callbacks for 9 bodies seems alot.  Either
>>its picking up static-static collisions, or else you've got almost 30
>>geom primitives knocking around each active body.  If its the latter
>>case, I'd think about condensing it into a static trimesh, or exploiting
>>game knowledge to get a better partioning scheme than one of the
>>standard ones.
>>
>>Geoff
>>
>>Megan Fox wrote:
>>
>>    
>>
>>>Hrm... surprising results - I'd always though the total number of
>>>calls was larger than the number that actually go through.
>>>
>>>Profiling says that, yes, in the "bad" collision case, the total
>>>number of calls to my collision callback more than double.  However,
>>>that's still only, in this case, 246 calls, as compared to 145 in the
>>>"better" case.  These numbers seem a lot smaller than what I thought
>>>it would take to bring the system down.
>>>
>>>
>>>Does this seem right?  Is 246 collision callback calls, with a
>>>stepsize of 0.016 and 5 quickstep iters, in a world with very, very
>>>few actual dynamics objects (9 physical bodies total) enough to bring
>>>the system down like this?  Or am I seeing a problem elsewhere?
>>>
>>>(this is on an Athlon 64 2800+ - and the bad case is enough to bring
>>>me down to unplayably jumpy FPS)
>>>
>>>On 11/3/05, Jon Watte (ODE) <hplus-ode at mindcontrol.org> wrote:
>>>
>>>
>>>      
>>>
>>>>My first instinct would be to bake the collision of all static things
>>>>into a single static mesh (or a few, block-sized, static meshes).
>>>>
>>>>Another thing you can do is to add profiling code to count how many
>>>>near-callbacks you get, and store information about what attempts to
>>>>collide with what, and plot that. That should show you some spikes.
>>>>
>>>>Characters and other complex systems should probably be in their own
>>>>spaces (spaces can be hierarchical), so that they can be quickly culled
>>>>when not colliding with other entities.
>>>>
>>>>Last, I would absolutely use a profiler to figure out where the most of
>>>>the time is being spent. That would also guide me into making whatever
>>>>optimizations necessary.
>>>>
>>>>Cheers,
>>>>
>>>>                      / h+
>>>>
>>>>
>>>>Megan Fox wrote:
>>>>
>>>>
>>>>        
>>>>
>>>>>Alright, I'm coming up against a performence problem in a semi-dense
>>>>>scene.  Semi-dense because, while there are a lot of objects in the
>>>>>world, it really isn't all that "dense"... it's just a desert with
>>>>>rocks and a single building.  I'm trying to determine if this is
>>>>>expected/normal, or if I can bail myself out in some fashion.
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>        
>>>>
>>>--
>>>-Megan Fox
>>>Lead Developer, Elium Project
>>>http://www.elium.tk
>>>
>>>_______________________________________________
>>>ODE mailing list
>>>ODE at q12.org
>>>http://q12.org/mailman/listinfo/ode
>>>
>>>
>>>
>>>      
>>>
>>_______________________________________________
>>ODE mailing list
>>ODE at q12.org
>>http://q12.org/mailman/listinfo/ode
>>
>>    
>>
>
>
>--
>-Megan Fox
>Lead Developer, Elium Project
>http://www.elium.tk
>
>  
>