Gavin writes:
> I could have sworn I put a section on coordinate systems in the spec, but I
> must be remembering the 3D metafile spec we've submitted to the ANSI/ISO X3H3
> subcommittee.
>
Let me clarify my previous message (it was intentionally short to avoid flaming).
The problem seems to have arisen from USAGE, not from the SPEC. This is similar
to some work I was involved with using TIFF a few years back. In that case, the
color table in the SPEC clearly stated that color table values would be from
0 to 65335 - however, most programmers used only 0 to 255. This meant that
TIFF file readers had to be smart enough to scan all the color table values to
see if they needed to be scaled!
The SPEC is supposed to be your guide for USAGE, and for IMPLEMENTATION both.
In VRML, the problem increases slightly in that the ground plane may
be very important to moving around in the space; or important to agent software
that expects the ground to be on a specific place. A simple rotation of the
world will work only for viewing not for virtual vehicles and simulation code
that assume where the ground is.
You have a good point - such orientation/rotation issues are important
when the worlds are no longer static, and things are free-moving, with
no tie (transformation) from the top of the scene graph that was so
'neatly and conveniently rotated'.
I have been working with VR386 on the PC for 18 months, about half of my worlds
are Z elavated and the others use the normal right handed coord system. At this
point it is not a matter for committee discussion or arguement; Y up is the way
to go in the spec. HOWEVER, we can possibly create TAGS or FILTERS to help
people straighten out their worlds.
It is a point for consideration by the committee - everyone maintains
that it is so easy to just rotate - however several people have said
"we should not change it - this would affect all the inventor models
and primitives" which tells you right off it is not just as easy as a
rotate.
At any rate, whatever this group decides should be explicit in the
spec, both for implementers and users. And it should say the order in
which rotation angles are applied yaw first, pitch second, roll third,
because it makes a difference. Do not confuse this with the order of
rotation fields in a file - we are discussing here how they are
applied mathematically. Or - if it is a quaternion based orientation
system - then say it explicitly in the spec. Give some references to
quaternions, such as Ken Shoemake in the 85 Siggraph proceedings.
// Randy Stiles Office: 415.354.5256 Orgn 9620 Bldg 255
// [email protected] Fax: 415.354.5235 3251 Hanover Street
// Lockheed AI Center Lab: 415.424.2690 Palo Alto, CA 94304-1191
// http://hitchhiker.space.lockheed.com/~stiles/HOME.html