[ODE] Collision Shapes - was : FPS Player physics

[Megan Fox]

Previous to being employed, I used a file format that defined
positions and scales of geoms per actor, and that file was
hand-written.  I did, however, have an in-game vis system for checking
the position of the phys volumes, and the ability to move them in
game, so what I would do is make .setpos calls to them through my
console until they looked right, then alt-tab out of the application
and write the values into the file.


Now that I'm employed and have reason to right toolsets, we just
export them from Maya.  We put a flag in the shape name ("PHYS_"), and
the artists make sure to NOT clear history on the object if it needs
to be a dynamic geom vs trimesh (because clearing history in Maya
makes everything "just a mesh" and loses the data of what shape it
started as).

Works nicely, no complaints.

On 8/1/06, Michael Molkenthin <molle at michael-molkenthin.de> wrote:
> thank you for the valuable recommendations, Jon.
>
> Okay, i am going to change my moving trimeshes to collision proxy
> primitives.
>
> How are doing the people getting the parameters for their proxy objects?
> Do they hardwiring them into their code? Or do they have special
> exporter plugins in their modeling tools?
>
> so long,
> Michael
>
>
> On Mon, 31 Jul 2006, Jon Watte (ODE) wrote:
> > When a trimesh is involved, ODE calls out to OPCODE. When trimeshes are not
> > involved, ODE uses its own collision primitives.
> >
> > The trimesh <-> trimesh case ("moving trimeshes") is not as well behaved as
> > most other cases, even with the numerous hacks you can employ, and is usually
> > often a lot slower, so people usually use collision proxy objects (capsules,
> > boxes, etc) for the moving actors and/or their limbs.
> >
> > Using static trimeshes (for terrain/buildings/etc), and proxy objects for
> > moving actors, is the well-tested, well-behaved, well-performing "standard
> > case" when using ODE.
> >
> > Cheers,
> >
> >         / h+
> >
> >
> > Michael Molkenthin wrote:
> >> i thought, ode is making transparently usage of OPCODE for all
> >> trimesh/trimesh collisions. Are there any cases ODE is doing collision
> >> without OPCODE? Perhaps i have not understanded your post.
> >>
> >> Is somebody here converting its trimeshes into approximating
> >> Boxes/Cones/tubes dedicated for collision to simplify trimesh/trimesh
> >> situations to box/trimesh or trimesh/cube?
> >>
> >> regards,
> >> Michael
> >>
> >
> >
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode
>


-- 
-Megan Fox
Idyllon, LLC
http://shalinor.circustent.us/megan/resume/