[ODE] collision strategy.
cyrille.potereau at wanadoo.fr
Wed Jan 31 13:14:50 MST 2007
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.
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.
>> ODE mailing list
>> ODE at ode.org
More information about the ODE