[ODE] collision strategy.

[Jaroslav Sinecky]

I was going to say the same ...
I was also playing with the idea of hierarchy of collision spaces, it's 
sounds nice, but when you have to do space vs. space collision, it's 
very slow, in ODE it always means to do brute force m x n test. So one 
big space usually performs better.
Also, it's recommendable to merge all your static meshes into one.

Jaroslav


Jon Watte (ODE) wrote:
> The big cost will come in the space/space traversal code. Not all spaces 
> are as efficient as you would like in that case. One large quadtree 
> space, or one large hash space, will perform very well on its own.
>
> Cheers,
>
>           / h+
>
>
> Cyrille Potereau wrote:
>   
>> Well, because I thought it could help to not test every geom against 
>> every others as it is explain in the manual: "Spaces may contain other 
>> spaces. These sub-spaces will typically represent a collection of geoms 
>> (or other spaces) that are located near each other. This is useful for 
>> gaining extra collision performance by dividing the collision world into 
>> hierarchies.". And the example following with cars, leads me to the idea 
>> of one actor (with several geoms) for each car so one space per actor.
>>
>> So your recommandation is to use 1 space for everything (static & 
>> dynamic) and just set the bits to not generate the static / static one ? 
>> or still separate in different space the static and dynamic geoms?
>>
>>
>> Thanks a lot.
>>
>> Regards,
>> Cyrille
>>
>>
>>
>>
>> Jon Watte (ODE) a écrit :
>>   
>>     
>>> Why would you have a space per actor? That makes no sense.
>>> I would throw them all into a single quadtree space or hash space, and 
>>> use collider bits to separate out static/static collisions.
>>>
>>>          / h+
>>>
>>>
>>> Cyrille POTEREAU wrote:
>>>     
>>>       
>>>> Dear all,
>>>>
>>>>
>>>> I'm sorry if it has been already asked but I couldn't find a clear 
>>>> answer anywhere.
>>>>
>>>> I'm working on adding ODE in a FPS engine and I've got some 
>>>> performance issue due to collisions detection. Anyway I think this 
>>>> question is very generic and can be useful for a lot of projets.
>>>>
>>>> I can split my scene objects into 3 kind of objects:
>>>>
>>>> The ground based on a trimesh.
>>>>
>>>> The static actor (houses for example) also based on trimesh.
>>>>
>>>> Dynamic actor like player, crate, barrels etc ... based on one or 
>>>> several primitives.
>>>>
>>>> My question is, what do you think is the best strategy to handle the 
>>>> collision between all these objects ?
>>>>
>>>>
>>>> My idea was to do the following:
>>>>
>>>>
>>>> - One quadtree space for each static actor
>>>> - One quadtree space for ground. (so the ground is finally just 
>>>> another static actor)
>>>> - One hashspace for each dynamic actor.
>>>>
>>>>
>>>> Is it worth adding the category and collide bitfields to avoid 
>>>> generating collisions between static objects ? Or is the gain be 
>>>> marginal ?
>>>>
>>>> And a last question, in the wiki, it is written that: "ODE's 
>>>> collision detection is optimized to detect geoms that do not move and 
>>>> to precompute as much information as possible about these objects to 
>>>> save time."
>>>>
>>>> How is the "static" element detected ? Do I need to take care of any 
>>>> thing to be sure that it is not mistaken with a dynamic geom ? Is 
>>>> linked to the Transform geom ?
>>>>
>>>>
>>>> Thanks a lot for your feedback.
>>>>
>>>> Regards,
>>>> Cyrille
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> ODE mailing list
>>>> ODE at ode.org
>>>> http://mooshika.org/mailman/listinfo/ode
>>>>       
>>>>         
>>>     
>>>       
>>
>> _______________________________________________
>> ODE mailing list
>> ODE at ode.org
>> http://mooshika.org/mailman/listinfo/ode
>>     
> _______________________________________________
> ODE mailing list
> ODE at ode.org
> http://mooshika.org/mailman/listinfo/ode