What was reasoning behind OSG Z up axis

[etrek]

Hello,
I looked at the archives and found someone else posted question about Z axis. Here is link: http://lists.openscenegraph.org/htdig.cgi/osg-users-openscenegraph.org/2007-July/000209.html


I question this part of the answer:
"The OSG follows the majority of the vis-sim industry in having +ve Z up, +ve Y north and +ve X east."


In OpenGL Y axis is up ( world and view ).
In DirectX Y axis is up ( world and view ).

The two most popular graphics API's consider Y axis as up. So do most Graphics texts like Foley et al.

OSG uses OpenGL as its graphics API, so why not use the same coord system?

Just curious as to the reasoning behind this design decision.


NOTE:
How to transform the axes is explained here: http://lists.openscenegraph.org/htdig.cgi/osg-users-openscenegraph.org/2007-August/001059.html . So I know how to change it programmatically if I wanted to.


Thanks,
Eday

[Paul Martz]

I think you quoted the "why" in your own email -- Z-up corresponds to the
predominant usage in the vis-sim community.

OpenGL doesn't enforce an up vector policy. Object coordinates are arbitrary
and up to the application. If you don't set the modelview matrix, then
object coordinates are equivalent to eye coordinates, and OpenGL defines eye
coordinates as Y-up. However, I know of no applications that use the default
(identity) modelview matrix -- every app sets it, and every app therefore
determines their own up vector.

Most OpenGL-based vis-sim apps set the modelview so that Z is up. OSG
provides this same orientation by default.

Note that, just like in OpenGL, you can set your own modelview matrix in
OSG, and therefore set your own up vector.

Does that answer your question?

Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com <http://www.skew-matrix.com/>
303 859 9466




_____

From: osg-users-bounces-***@public.gmane.org
[mailto:osg-users-bounces-***@public.gmane.org] On Behalf Of etrek
Sent: Thursday, December 13, 2007 2:03 PM
To: osg-users-***@public.gmane.org
Subject: [osg-users] What was reasoning behind OSG Z up axis


Hello,
I looked at the archives and found someone else posted question about Z
axis. Here is link:
http://lists.openscenegraph.org/htdig.cgi/osg-users-openscenegraph.org/2007-
July/000209.html


I question this part of the answer:
"The OSG follows the majority of the vis-sim industry in having +ve Z up,
+ve Y north and +ve X east."


In OpenGL Y axis is up ( world and view ).
In DirectX Y axis is up ( world and view ).

The two most popular graphics API's consider Y axis as up. So do most
Graphics texts like Foley et al.

OSG uses OpenGL as its graphics API, so why not use the same coord system?


Just curious as to the reasoning behind this design decision.


NOTE:
How to transform the axes is explained here:
http://lists.openscenegraph.org/htdig.cgi/osg-users-openscenegraph.org/2007-
August/001059.html . So I know how to change it programmatically if I
wanted to.


Thanks,
Eday

<http://lists.openscenegraph.org/htdig.cgi/osg-users-openscenegraph.org/2007
-August/001059.html>

[Robert Osfield]

Post by etrek
In OpenGL Y axis is up ( world and view ).
In DirectX Y axis is up ( world and view ).

They define Y up in *eye* coordinates. The modelview matrices put you
into eye coordinates, of which must be standardised. They don't
actually say anything about the coordinates of the world, this is what
the inverse of the view transform defines.

Post by etrek
The two most popular graphics API's consider Y axis as up. So do most
Graphics texts like Foley et al.
OSG uses OpenGL as its graphics API, so why not use the same coord system?
Just curious as to the reasoning behind this design decision.

The OSG is built around the concept of worlds coordinates rather than
eye coordinates - its about creating virtual worlds, which in turn
have a counter part in the real world and in the real-world
(disciplines beyond computer graphics) one generally to X going east,
Y going north, Z going up. Z is most commonly up and refers to
height. Not surprisingly the vis-sim market grew up around this too
rather than getting fixated on eye coordinates being akin world
coordinates...

For me one of the key things in grasping real-time computer graphics
is to get a handle on the ideal of different coordinate frames - world
coordinate and eye coordinates being two different coordinate frames
used for two different things.

Robert.

[Roger James]

[Controversial mode on]

I think a better question to ask would be.

How consistent are all osg's plugins at enforcing osg's stated z up world
convention?

I would expect all the plugins that "knew" the default orientation of an
external model either by convention or by data, to ensure that models where
rotated to z_up on input and from z_up on output.

I am just wondering ;-)

Just to start the ball rolling....

Plugin Enforces
====== ========
Osg yes
Ive yes
Dae no
Ac no

Roger

-----Original Message-----
Sent: 14 December 2007 10:04
To: OpenSceneGraph Users
Subject: Re: [osg-users] What was reasoning behind OSG Z up axis

[Robert Osfield]

Hi Roger,

Which way is up for the plugins can be plugin specific, but it can
also be down to individual modeller and the convention they use. For
instance terrapage and OpenFlight you can pretty well guarantee that
they'll come in Z up as that the convention used in the modelling
programs and the industry they are tied to. With other modelling
packages the convention is often far less regulated. My guess systems
that deal with whole worlds rather than individual artifacts will be
more regulated in orientation.

Robert.

Post by Roger James
[Controversial mode on]
I think a better question to ask would be.
How consistent are all osg's plugins at enforcing osg's stated z up world
convention?
I would expect all the plugins that "knew" the default orientation of an
external model either by convention or by data, to ensure that models where
rotated to z_up on input and from z_up on output.
I am just wondering ;-)
Just to start the ball rolling....
Plugin Enforces
====== ========
Osg yes
Ive yes
Dae no
Ac no
Roger

-----Original Message-----
Sent: 14 December 2007 10:04
To: OpenSceneGraph Users
Subject: Re: [osg-users] What was reasoning behind OSG Z up axis

_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[Roger James]

You are spot on there Robert.

Most of the plugins result in a Z up model on input because they pass the
vertex data through unchanged from their native Z up environment.

The only one I know from memory that does a flip is the obj loader although
that can be suppressed by a "noRotation" option. Does anyone know of any
others?

Would it be a good idea if I put static transforms in the ac and dae plugins
which are by default Y up and had this behaviour controlled by a
"noRotation" parameter? This could be made standard across other plugins
that "know" when their data is not Z up. Users (like me) who have viewing
environments that are Y up by default could then have the option to specify
that parameter and avoid having to put in an extra transform to flip the
models back to their original orientation.

Ah well .... maybe next year!

Roger

-----Original Message-----
Sent: 14 December 2007 11:30
To: OpenSceneGraph Users
Subject: Re: [osg-users] What was reasoning behind OSG Z up axis
Hi Roger,
Which way is up for the plugins can be plugin specific, but it can
also be down to individual modeller and the convention they use. For
instance terrapage and OpenFlight you can pretty well guarantee that
they'll come in Z up as that the convention used in the modelling
programs and the industry they are tied to. With other modelling
packages the convention is often far less regulated. My guess systems
that deal with whole worlds rather than individual artifacts will be
more regulated in orientation.
Robert.

[Mike Weiblen]

Random thoughts:

COLLADA, in an attempt to address this common issue, does provide a flag
to specify which axis to call "up".

For applying a static rotation, that was exactly the motivation for the
.rot and .trans pseudoloaders: to adjust coordinate systems via data
filenames rather than code or special flags in every plugin.

Eg: osgviewer mydata.anyformat.0,0,-90.rot

Cheers
-- mew

-----Original Message-----
Sent: Friday, December 14, 2007 7:51 AM
To: 'OpenSceneGraph Users'
Subject: Re: [osg-users] What was reasoning behind OSG Z up axis
You are spot on there Robert.
Most of the plugins result in a Z up model on input because they pass the
vertex data through unchanged from their native Z up environment.
The only one I know from memory that does a flip is the obj loader although
that can be suppressed by a "noRotation" option. Does anyone know of any
others?
Would it be a good idea if I put static transforms in the ac and dae plugins
which are by default Y up and had this behaviour controlled by a
"noRotation" parameter? This could be made standard across other plugins
that "know" when their data is not Z up. Users (like me) who have viewing
environments that are Y up by default could then have the option to specify
that parameter and avoid having to put in an extra transform to flip the
models back to their original orientation.
Ah well .... maybe next year!
Roger

-----Original Message-----
Sent: 14 December 2007 11:30
To: OpenSceneGraph Users
Subject: Re: [osg-users] What was reasoning behind OSG Z up axis
Hi Roger,
Which way is up for the plugins can be plugin specific, but it can
also be down to individual modeller and the convention they use.

For

instance terrapage and OpenFlight you can pretty well guarantee that
they'll come in Z up as that the convention used in the modelling
programs and the industry they are tied to. With other modelling
packages the convention is often far less regulated. My guess

systems

that deal with whole worlds rather than individual artifacts will be
more regulated in orientation.
Robert.

_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-
openscenegraph.org

[Roger James]

Mike,

For information, my latest collada plugin submission makes the axis
orientation, units and scaling information available to callers via
parameters passed back by the reader.

Roger

-----Original Message-----
Sent: 14 December 2007 16:35
To: OpenSceneGraph Users
Subject: Re: [osg-users] What was reasoning behind OSG Z up axis
COLLADA, in an attempt to address this common issue, does provide a flag
to specify which axis to call "up".
For applying a static rotation, that was exactly the motivation for the
.rot and .trans pseudoloaders: to adjust coordinate systems via data
filenames rather than code or special flags in every plugin.
Eg: osgviewer mydata.anyformat.0,0,-90.rot
Cheers
-- mew

[Jan Ciger]

Post by Mike Weiblen
COLLADA, in an attempt to address this common issue, does provide a flag
to specify which axis to call "up".
For applying a static rotation, that was exactly the motivation for the
.rot and .trans pseudoloaders: to adjust coordinate systems via data
filenames rather than code or special flags in every plugin.
Eg: osgviewer mydata.anyformat.0,0,-90.rot
Cheers
-- mew

Ah, what a neat trick! I didn't know about this one :)
That will save me a "y-up" flag in my config files ..

Thanks,

Jan