The Annotated VRML 97 Reference

1 Intro     Concepts     3 Nodes     4 Fields/Events    Conformance
A Grammar     B Java     C JavaScript     D Examples     E Related Info    References
Quick Java         Quick JavaScript         Quick Nodes   
 

  About the Book
  
Help
  Copyright © 1997-99
  Purchase the book from Amazon.com

 

 

Chapter 2
Key Concepts

2.1 Intro

2.1.1 Overview
2.1.2 TOC
2.1.3 Conventions

2.2 Overview
2.2.1 File Structure
2.2.2 Header
2.2.3 Scene graph
2.2.4 Prototypes
2.2.5 Routing
2.2.6 Generating files
2.2.7 Presentation
     Interaction
2.2.8 Profiles

2.3 UTF-8 syntax
2.3.1 Clear text
2.3.2 Statements
2.3.3 Node
2.3.4 Field
2.3.5 PROTO
2.3.6 IS
2.3.7 EXTERNPROTO
2.3.8 USE
2.3.9 ROUTE

2.4 Scene graph
2.4.1 Root nodes
2.4.2 Hierarchy
2.4.3 Descendants
       & ancestors
2.4.4 Hierarchy
2.4.5 Units coord sys

2.5 VRML & WWW
2.5.1 MIME type
2.5.2 URLs
2.5.3 Relative URLs
2.5.4 data:
2.5.5 Scripting protocols
2.5.6 URNs

2.6 Nodes
2.6.1 Intro
2.6.2 DEF/USE
2.6.3 Geometry
2.6.4 Bboxes
2.6.5 Grouping & children
2.6.6 Lights
2.6.7 Sensors
2.6.8 Interpolators
2.6.9 Time nodes
2.6.10 Bindable children
2.6.11 Textures

2.7 Field, eventIn,
     eventOut

2.8 PROTO
2.8.1 Declaration
2.8.2 Definition
2.8.3 Scoping

2.9 EXTERNPROTO
2.9.1  Interface
2.9.2  URL
2.9.3 Extensions

2.10 Events
2.10.1 Intro
2.10.2 Routes
2.10.3 Execution
2.10.4 Loops
2.10.5 Fan-in & fan-out

2.11 Time
2.11.1 Intro
2.11.2 Origin
2.11.3 Discrete/cont

2.12 Scripting
2.12.1 Intro
2.12.2 Execution
2.12.3 Initialize/shutdown
2.12.4 eventsProcessed
2.12.5 Direct outputs
2.12.6 Asynchronous
2.12.7 Languages
2.12.8 EventIns
2.12.9 fields events
2.12.10 Browser interface

2.13 Navigation
2.13.1 Intro
2.13.2 Navigation
2.13.3 Viewing
2.13.4 Collisions

2.14 Lighting
2.14.1 Intro
2.14.2 'off'
2.14.3 'on'
2.14.4 Equations
2.14.5 References

+2.4 Scene graph structure

2.4.1 Root nodes

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

2.4.2 Scene graph hierarchy

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.

2.4.3 Descendant and ancestor nodes

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.

2.4.4 Transformation hierarchy

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

2.4.5 Standard units and coordinate system

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

Category Unit
Linear distance Metres
Angles Radians
Time Seconds
Colour space RGB ([0.,1.], [0.,1.], [0. 1.])

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.

Right-handed coordinate system

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 [...] }