Chapter 3: Node Reference--The Annotated VRML97 Reference Manual

TIP: Remember that TimeSensor outputs fraction_changed events in the 0.0 to 1.0 range, and that interpolator nodes routed from TimeSensors should restrict their key field values to the 0.0 to 1.0 range to match the TimeSensor output and thus produce a full interpolation sequence.

TECHNICAL NOTE: The CoordinateInterpolator was near the edge of the "cut line" for what features should be included in VRML 2.0 and what features should be left out. The following pros and cons influenced the decision and should give you an idea of how decisions were made on which features should be part of the specification.

Con: There is a strong desire to keep the VRML specification as small as possible. A big, bloated specification is hard to implement, hard for which to write conformance tests, takes a very long time to create, and encourages incompatible, partial implementations.

Pro: Coordinate morphing is a feature that many people requested. VRML 2.0 was designed "in the open." Drafts of the specification were constantly made available on the WWW; polls were taken on general, high-level design issues; and there were constant discussions and debates on the www-vrml mailing list. This provided invaluable information that helped prioritize decisions about what should be included and excluded, and provided time for unpopular decisions to be either justified or reversed.

Con: CoordinateInterpolator functionality can be accomplished with a Script node. Features that are not "fundamental" (that can be implemented using other features of the specification) were likely to be cut.

Pro: CoordinateInterpolator calculations can require a lot of computing power. Interpolating hundreds or thousands of coordinates is computationally expensive compared to interpolating a single translation or rotation. Making CoordinateInterpolator a standard node encourages highly optimized implementations, which will be much faster than a Script node equivalent.

Con: Implementing shapes with coordinates that may change over time can be difficult. Many interactive rendering libraries are optimized for the display of scenes made up of rigid-body objects, assuming that not many objects will change shape. Changing coordinates also requires that normals be regenerated (if explicit normals are not specified), which is also a fairly expensive operation. Adding CoordinateInterpolator to the specification encourages world creators to use a feature that might result in poor performance on many machines. In the end, the positives outweighed the negatives, but it was not an easy decision and several other possible interpolators did not make the cut (there is no TextureCoordinateInterpolator because there isn't a strong enough demand for it, for example).

EXAMPLE (click to run): The following example illustrates a typical use of the CoordinateInterpolator node (see Figure 3-12). A TouchSensor is routed to a TimeSensor that fires the CoordinateInterpolator:

#VRML V2.0 utf8
Group {
  children [
    DEF CI CoordinateInterpolator {
      key [ 0.0, 1.0 ]
      keyValue [ 1 0 -1, -1 0 -1, 0 0 1, 0 0.5 0,
      keyValue [ 1 0 -1, -1 0 -1, 0 0 1, 0 3.0 0 ]
    }
    Shape {
      geometry IndexedFaceSet {
        coord DEF C Coordinate {
          point [ 1 0 -1, -1 0 -1, 0 0 1, 0 0.5 0 ]
        }
        coordIndex [ 0 1 3 -1  1 2 3 -1  2 0 3 ]
      }
      appearance Appearance { material Material {} }
    }
    DEF T TouchSensor {}  # Click to start the morph
    DEF TS TimeSensor {   # Drives the interpolator
      cycleInterval 3.0 # 3 second morph
      loop TRUE
    }
    Background { skyColor 1 1 1 }
  ]
}
ROUTE CI.value_changed TO C.point
ROUTE T.touchTime TO TS.startTime
ROUTE TS.fraction_changed TO CI.set_fraction

3.13 CoordinateInterpolator

Figure 3-12: CoordinateInterpolator node