[ODE] collision strategy.

Cyrille Potereau cyrille.potereau at wanadoo.fr
Fri Feb 2 11:24:38 MST 2007


Ok thanks, so just one big space for everything static and dynamic :)

Cheers,
Cyrille



Jon Watte (ODE) a écrit :
> 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
>>>>  
>>>> http://mooshika.org/mailman/listinfo/ode
>>>>       
>>>     
>>
>>
>>
>> _______________________________________________
>> ODE mailing list
>> ODE at ode.org
>> http://mooshika.org/mailman/listinfo/ode
>
>





More information about the ODE mailing list