[ODE] on changing the world-up vector

[Jon Watte]

There could be significant runtime overhead in coding collision tests to account for a global "up" vector, rather than allowing a compile-time switch of a fundamental, axis-aligned vector.

For example, a capsule test is fairly pleasant if done along a major axis; you only have to multiply by the inverse of the capsule orientation to get into that space. If the capsule at "zero" orientation is assumed to point in an arbitrary direction, you need to multiply by TWO inverses, or the inverse of two multiplies, which is twice as much transform work per collision test.

If you want to emulate this behavior, you can do it with a GeomTransform(); wrap your geom creation in something that allows you to also create an encapsulating transform, and you have what you need, with the exact runtime cost outlined above. Meanwhile, people who don't care, won't have to wade through anything special.

Last: do you ACTUALLY have a use case for this feature; to allow all objects to be created aligned to some global reference orientation? Software development is full of features which sound good on paper, but which nobody ACTUALLY has a good use case for. If you have one, I'd like to hear it.

Cheers,

			/ h+


-----Original Message-----
From: ode-bounces at q12.org [mailto:ode-bounces at q12.org]On Behalf Of Doron
Tal
Sent: Monday, July 12, 2004 7:47 AM
To: ode at q12.org
Subject: [ODE] on changing the world-up vector


A wish, to add to the wish list: not only allow allow the "world-up 
vector" 
to be the y- or z-axis, but allow the world-up vector to be *any* arbitrary
3D vector.   Either compile time or run time are fine with me.
The code would be cleaner if it referred to a variable corresponding
to the "world-up vector" rather than referring to some arbitrarily
chosen vector such as the Y-axis.

-DT



Matthew D. Hancher wrote:

>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....
>  
>


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