[ODE] Re: dTerrainAndCone contribution ready for prime time?

[Flavien Brebion]

I don't know, to me it would make more sense to support (assuming
it's not supported yet - i haven't looked at the dTerrain code for
a while) translations/rotations to the terrain. That way you could
just set up the correct transformation matrix to rotate the terrain
to the correct base, than to have to handle multiple code versions.

F. Brebion


-----Original Message-----
From: ode-bounces at q12.org [mailto:ode-bounces at q12.org]On Behalf Of
Matthew D. Hancher
Sent: dimanche 20 juin 2004 22:28
To: ode at q12.org
Subject: [ODE] Re: dTerrainAndCone contribution ready for prime time?


Quoth: "John Miles" <jmiles at pop.net>
> Would it be appropriate at this point to move Benoit's dTerraindAndCone
> contribution into the main library?  Several other users have indicated
that
> they're happy with it, and many people have emphasized the need to support
> height maps as a first-class primitive.  I think Ian Overgard (below) and
> myself had the only real problems with dTerrainAndCone, and I'm pretty
> satisfied now.

The thing that bugs me about dTerrain right now is the need for separate
Y-up an Z-up versions.  This also relates to the confusion over cylinder
orientation.  I have been meaning to propose the following: I think ODE
ought to have an option (compile-time, run-time, whatever) that specifies
whether objects with fundamental axes will be y-aligned or z-aligned.
The terrain, cylinder, and capsule geoms would all behave accordingly, as
would any future objects that needed to arbitrarily select a preferred
axis.  (Are there any others already that I'm forgetting?)

What do people think?  I'm not usually a big fan of options of this sort,
but this seems like a sufficiently religious debate that the best thing
to do is side-step it by passing the decision on to the user.

At first I was attracted by the compile-time option, but adding those
results in exponential growth in the number of pre-compiled libraries
that it makes sense to maintain.  This would be easy and efficient to
implement with a few thunks at run-time, at the expense of a minor
increase in code size.  In fact, the collider look-up-table would
make this absolutely trivial for Geoms....

mdh

Matt Hancher
NASA Ames Research Center
Official: mdh at email.arc.nasa.gov
Personal: mdh at media.mit.edu

_______________________________________________
ODE mailing list
ODE at q12.org
http://q12.org/mailman/listinfo/ode