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.11 Time

2.11.1 Introduction

The browser controls the passage of time in a world by causing TimeSensors to generate events as time passes. Specialized browsers or authoring applications may cause time to pass more quickly or slowly than in the real world, but typically the times generated by TimeSensors will roughly correspond to "real" time. A world's creator should make no assumptions about how often a TimeSensor will generate events but can safely assume that each time event generated will be greater than any previous time event.

design note

The sampling of time is controlled by the VRML browser. This makes it much easier for the world creators, since they don't have to worry about synchronization of events, writing a "main loop," and so on. It also makes it much easier to create VRML authoring systems. If VRML had a model of time where independent applets each ran in a separate thread and made asynchronous changes to the world, then it would be very difficult for the user to "freeze time" and make necessary adjustments to the virtual world. Because time events all come from a single place— TimeSensor nodes—it is easy for a world creation system to control time during the authoring process.

2.11.2 Time origin

Time (0.0) is equivalent to 00:00:00 GMT January 1, 1970. Absolute times are specified in SFTime or MFTime fields as double-precision floating point numbers. Negative absolute times are interpreted as happening before 1970.

Processing an event with timestamp t may only result in generating events with timestamps greater than or equal to t.

design note

Defining an absolute origin for time isn't really necessary for proper functioning of VRML worlds. Absolute times are very rare in VRML files; they are almost always calculated during execution of the world relative to the occurrence of some event ("start this animation 2.3 seconds after the viewer walks into this room").

If you know where in the real world the VRML file will be viewed, then the absolute origin for time allows you to synchronize the real world and the virtual world. For example, if you know that your world will be viewed in California, then you can create a day-to-night animation that is driven by a TimeSensor and will match the sunrises and sunsets in California. VRML does not include a RealWorldPositionSensor that outputs the real-world position of the real-world VRML viewer, but if it did (perhaps when every computer includes a Global Positioning System satellite receiver, . . .) many very interesting applications merging the virtual and real worlds would become possible.

A frequently asked question is how can something be scheduled to start some amount of time "after the world is loaded." If time were defined to start "when the world is loaded," then this would be easy—the world creator would just give a TimeSensor an appropriate absolute startTime. One problem with this is defining precisely what is meant by "when the world is loaded." VRML browsers may load different parts of the world at different times or may preload parts of the world before they're actually needed. If the browser decides to preload part of the world because it knows that the user is traveling at a certain speed in a certain direction and will arrive there in 20 seconds, the world creator probably doesn't want a 5-second welcome animation to be performed before the user is anywhere near that part of the world. In this case, it is better for the world creator to use a ProximitySensor or a VisibilitySensor to generate an event that can then be used as the basis for starting animations, sounds, and so forth. Instead of thinking in terms of "when the world is loaded," it is better to think of "when the user enters my world" (ProximitySensor) or "when the user first sees . . ." (VisibilitySensor). Worlds created this way will be composable with other worlds, allowing the creation of the potentially infinite cyberspace of the future.

design note

The rule that "events in the past cannot be generated" means that browsers are not responsible for simulating anything that occurred before the VRML file was loaded. The mental model is that a VRML file expresses the complete state of a virtual world at a given point in time. If the VRML browser knows exactly when the VRML file was written, then it could theoretically simulate all of the events that occurred between when the file was written and when it was read back into memory, just as if it had been simulating the world all along. However, VRML files do not record the time the world was written, and it is not always possible or convenient for the VRML browser to retrieve that information from the underlying operating system or transport mechanism. In addition, requiring the VRML browser to simulate the passage of an arbitrary amount of time after reading in every VRML file would be an unnecessary burden.

2.11.3 Discrete and continuous changes

VRML does not distinguish between discrete events (such as those generated by a TouchSensor) and events that are the result of sampling a conceptually continuous set of changes (such as the fraction events generated by a TimeSensor). An ideal VRML implementation would generate an infinite number of samples for continuous changes, each of which would be processed infinitely quickly.

Before processing a discrete event, all continuous changes that are occurring at the discrete event's timestamp shall behave as if they generate events at that same timestamp.

design note

This follows from the premise that an ideal implementation would be continuously generating events for continuous changes. A simple implementation can guarantee this by generating events for all active TimeSensors whenever a discrete event occurs. More sophisticated implementations can optimize this by noting dependencies and ensuring that if a node depends on both a discrete event and a continuous event, then it will always receive a continuous event along with the discrete event.

Beyond the requirements that continuous changes be up-to-date during the processing of discrete changes, the sampling frequency of continuous changes is implementation dependent. Typically a TimeSensor affecting a visible (or otherwise perceptible) portion of the world will generate events once per frame, where a frame is a single rendering of the world or one time-step in a simulation.

design note

Thinking in terms of the ideal VRML implementation is a useful exercise and can resolve many situations that may at first seem ambiguous. It is impossible to implement the ideal, of course, but for well-behaved worlds the results of a well-implemented browser will be identical to the theoretical results of the ideal implementation. "Well behaved" means that the world creator didn't rely on any undefined behavior, such as assuming that TimeSensors would generate 30 events per second because that happened to be how quickly a particular browser could render their world on a particular type of machine.

In its quest to be machine- and implementation-neutral, the VRML specification tries to avoid any notion of rendering frames, pixels, or screen resolution. It is hoped that by avoiding such hardware-specific notions the VRML world description will be appropriate for many different rendering architectures, both present and future.