- right hand rule (+x=thumb direction, +y=index finger, +z=middle finger)
- compatible global & body-relative definitions
- analytically valid
Here are the two major conventions I've found in common modeling use:
- +x right, +y up the page, +z out of the page vertically
(same as the most recent proposal, also the same as what most people will
draw on a piece of paper when you ask them to plot y = sin (x) )
- for airborne and underwater vehicles, (global/local)
+x is North/direction of forward motion, +y is East/direction of right hand
when facing forward, +z is distance from center of vehicle to ground/sea
level pointing in downward direction through the belly of the level vehicle
This system is usually used for ground vehicles as well, and +z
then corresponds to local terrain elevation.
These are compatible mathematically but require two 180 degree rotations about
two axes (or a single 180 degree rotation about the y=x line) to align.
Try this with your right hand if you want to stop a conversation.
Rotations can be much harder to figure out. As long as you follow
standard rotation matrices or homogeneous transformation matrices,
you will stay out of trouble. These correspond to strictly ordered
and strictly defined Euler angle rotations for roll, pitch and yaw,
respectively.
A common pitfall for beginning computer graphics programmers is to define all
of their objects in the coordinate system peculiar to their graphics
tools. Things quickly become frustrating due to counter-intuitiveness
and it doesn't take long before they are changing values by trial &
error until things look "good enough."
Further definitions exist for earth coordinates. There are multiple ways
to define latitude and longitude depending on the accuracy of the earth model.
There are also many many ways to define terrain data. Last time I checked, the
Spatial Data Transfer Standard (SDTS) working group was pretty far along in
resolving these definitions in compatible ways. I believe information on SDTS
pointers can be found in the sci.data.formats FAQ. This effort is driven by
Geographic Information System (GIS) vendors and the U.S. Geological Survey.
The IEEE Distributed Interactive Simulation (DIS) protocol standard has
strictly defined coordinate system that many virtual worlds &
autonomous agents comply with. It works well. Information on DIS & protocol
reference manuals are available from the Institute for Simulation &
Training at the University of Central Florida.
Is there reason to despair here? Perhaps! :)
I suggest that this group recognize first that multiple definitions are
possible, conversions can be confusing, but compatibility is achievable.
Second be aware that we really want to define a world in terms that make sense
for a world, not necessarily what makes sense for a viewer (since viewers
can adapt).
One significant benefit of the proposed model
>-x = left
>+x = right
>-y = down
>+y = up
>-z = back
>+z = front
is that it is easily memorable and intuitive for vrml-writers who are
thinking in terms of the flat screen in front of them. However if you
ask "what are the back and front coordinates of the room I occupy" or
"gee is this bird's-eye view, or the front door view?" it seems a lot vaguer.
That is probably because it is defined in terms of a person sitting in
front of a screen, instead of in terms of what makes sense for the
world itself. Memorability is good but vagueness is bad.
My recommendation: use an existing coordinate system based on the real world
that people can remember and follows the right-hand rule. Then define
a few typical views based on that coordinate system (this also has been
done many many times).... Then, if an individual really wants something
different, maintain complete compatibility with DIS/STDS/GIS/
(_____ your standard here) by using the coordinate conversions that anyone can
obtain from the SDTS effort (or by looking in a graphics book, or by doing
a little honest-to-goodness 3D trigonometry which you later correct by going
back to the book). Conversions are always a little confusing so these
might be officially incorporated when practical in future versions of VRML.
What not to do: jump on the first thing that seems popular. If VRML is
compatible with the world, it will eventually connect all the datasets in
the world. That will be very nice.
Bottom line: make it easy but make it correct.
regards, Don
Don Brutzman work (408) 656-2149
Code OR/Br Naval Postgraduate School [Glasgow 204] fax (408) 656-2595
Monterey California 93943-5000 USA home (408) 372-0190