A VRML file contains zero or more root nodes.
The root nodes for a file are those nodes defined by the node statements
or USE statements that are not contained in other node or PROTO statements.
Root nodes must be children nodes (see "2.6.5 Grouping and children nodes").
A VRML file is hierarchical; node statements
can contain SFNode or MFNode field statements that, in turn, contain
node (or USE) statements. This hierarchy of nodes is called the scene
graph. Each arc in the graph from A to B means that node A has an
SFNode or MFNode field whose value directly contains node B. See [FOLE] for details on hierarchical scene graphs.
The descendants of a node are all of the nodes
in its SFNode or MFNode fields, as well as all of those nodes' descendants.
The ancestors of a node are all of the nodes that have the node as a
descendant.
The transformation hierarchy includes all of
the root nodes and root node descendants that are considered to have
one or more particular locations in the virtual world. VRML includes
the notion of local coordinate systems, defined in terms of transformations
from ancestor coordinate systems (using Transform or Billboard nodes).
The coordinate system in which the root nodes are displayed is called
the world coordinate system.
A VRML browser's task is to present a VRML file
to the user; it does this by presenting the transformation hierarchy
to the user. The transformation hierarchy describes the directly perceptible
parts of the virtual world.
The following node types are in the scene graph
but not affected by the transformation hierarchy: ColorInterpolator,
CoordinateInterpolator, NavigationInfo, NormalInterpolator, OrientationInterpolator,
PositionInterpolator, Script, ScalarInterpolator, TimeSensor, and WorldInfo.
Of these, only Script nodes may have descendants. A descendant of a
Script node is not part of the transformation hierarchy unless it is
also the descendant of another node that is part of the transformation
hierarchy or is a root node.
Nodes that are descendants of LOD or Switch
nodes are affected by the transformation hierarchy, even if the settings
of a Switch node's whichChoice field or the position of the viewer
with respect to a LOD node makes them imperceptible.
The transformation hierarchy shall be a directed
acyclic graph; results are undefined if a node in the transformation
hierarchy is its own ancestor.
tip
Coordinate systems are a fundamental and difficult
topic to understand. There are a variety of books that provide excellent
explanations and tutorials on this subject. One that stands out is
The OpenGL Programming Guide by Mason Woo, Jackie Neider, and Tom
Davis (see Chapter 3, Viewing and Modeling Transformations, in their
book).
VRML defines the unit of measure of the world
coordinate system to be metres. All other coordinate systems are built
from transformations based from the world coordinate system. Table 2-2
lists standard units for VRML.
Table 2-2: Standard units
design note
The VRML convention that one unit equals one
meter (in the absence of any scaling Transform nodes) is meant to
make the sharing of objects between worlds easier. If everyone models
their objects in meters, objects will be the correct size when placed
next to each other in the virtual world. Otherwise, a telephone might
be as big as a house, which is very inconvenient if you are trying
to put the telephone on a desk inside the house.
Put a scaling Transform node on top of your
objects if you want to work in some other units of measure (e.g.,
inches or centimeters). Or, if compatibility with objects other people
have created is not important for your use of VRML, then nothing will
break if you disregard the one-unit-equals-one-meter convention. For
example, if you are modeling galaxies then it probably isn't important
that a telephone be the proper real-world scale, and you might just
assume that one unit equals one light-year.
Radians were originally chosen for Open Inventor's
file format to be compatible with the standard C programming language
math library routines. Although another angle representation might
be more convenient (e.g., 0.0 to 1.0 or 0.0 to 360.0), the benefits
of compatibility have always outweighed the minor inconvenience of
doing an occasional multiplication by 2 × pi.
Times are expressed as double-precision floating
point numbers in VRML, so nano-second accuracy is possible. Although
there are no time transformation functions built into VRML, time values
may be manipulated in any of the scripting languages that work with
VRML.
VRML uses a Cartesian, right-handed, three-dimensional
coordinate system (see Figure 2-2). By default, the viewer is positioned
along the positive Z-axis so as to look along the -Z direction with
+Y-axis up. A modelling transformation (see "3.6 Transform" and "3.52 Billboard") or viewing transformation
(see "3.53 Viewpoint")
can be used to alter this default projection.
Figure 2-2: Right-handed Coordinate
System
design note
The VRML convention of the Y-axis pointing
in the up direction is intended to make it easier to share objects.
Not only will objects be the right size (assuming they obey the units-equals-meters
convention), but they will also be oriented correctly. Walking around
worlds is also easier if your VRML browser and the world you load
agree about which direction is up; if they disagree, you'll find yourself
climbing the walls.
Deciding which way is up was perhaps the longest
of all of the debates that happened on the www-vrml mailing list during
both the VRML 1.0 and the VRML 2.0 design processes. There are two
common conventions: the Y-axis is up (the convention in mathematics
and many of the sciences) or the Z-axis is up (the convention for
architects and many engineering disciplines). It is easy to convert
from one to the other. Putting the following Transform as the root
of your VRML files will switch the file from the Z-is-up convention
to the VRML-standard Y-is-up:
Transform { rotation 1 0 0 -1.57 children [...] }
