XML.com

Extensible 3D: XML Meets VRML
by Len Bullard | Pages: 1, 2, 3, 4

Animation With Transforms, Sensors, Interpolators and ROUTEs

In this part of the tutorial, I introduce four new element types. These enable you to create movement in a world that runs automatically when the world is loaded into an X3D browser. Also, we'll explore the VRML/X3D object behavior design and how this is realized in the XML encoding.

Transform Elements

We first add an element around the <Shape>...</Shape> element. The element being added is a Transform element.

<Transform rotation="0 1 0 1.57" DEF='TheWorldTurns' > .... </Transform>

The X3D document should now look like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE X3D PUBLIC "ISO//Web3D//DTD X3D 3.0//EN"
  "http://www.web3d.org/specifications/x3d-3.0.dtd">
<X3D profile="Immersive" >
 <head>
  <meta content="Simple X3D example" name="description"/>
 </head>
 <Scene>
  <Viewpoint description="The World" orientation="0 1 0 1.57" position="6 0 0"/> 
  <Viewpoint description="Closer" orientation="0 1 0 1.57" position="2 0 0"/>
  <Viewpoint description="Heart of Darkness" orientation="0 1 0 1.57" position="0 0 0"/>
  <Transform rotation="0 1 0 1.57" DEF='TheWorldTurns' >
   <Shape>
    <Sphere/>
    <Appearance>
     <ImageTexture url="earth-topo.png"/>
    </Appearance> 
   </Shape>
  </Transform>
 </Scene>
</X3D>

The X3D transform is not an XSL transform. It represents a named coordinate space that can be changed by changing the values of the attributes of the transform element. Changing the definition of the space changes the objects contained inside that space; in this case, the sphere and the image texture mapped to the sphere. Transforms have several spatial attributes including rotation, translation, and scale, which can be manipulated using X3D behavior objects.

Transforms can contain other transforms in a nested coordinate system. In VRML X3D all objects including transforms are within the default coordinate system called the World Coordinate System (WCS). This is a 3D space with x, y and z coordinates and a 0, 0, 0 point origin. Here is an illustration of the coordinate axes.

Any object in the WCS is positioned relative to the WCS origin. If a transform is placed inside the WCS, it creates a new local coordinate space whose 3D coordinates have a local zero point origin. Objects inside that transform are placed relative to the local origin and subject to the translation, scale and rotation attribute values of the local coordinate system. If you change these values, the object inside the transform will change accordingly. To move the object, change the translation value of the transform. To make the object larger or smaller, change the scale. To rotate the object, change the rotation value. Note that this can be done in any dimension. changing only one dimension of scale flattens or expands the object in that dimension; thus a sphere can be transformed into a shield or an ovoid. Changing a value of the translation attribute moves the object in the direction of the dimension changed. Changing the transform affects all of the objects inside that space.

Earlier, when the last viewpoint caused your screen to blank, it is because the sphere is inside the World Coordinate System at a default position of 0,0,0. The last viewpoint is also at this position so moving to that viewpoint moved your view inside the sphere. Since the inside of the sphere is not rendered, all you will see is anything around the sphere, in this case, nothing.

There are books and online texts that can teach you how the VRML/X3D coordinate systems work and are manipulated. For now, think of them as boxes nested inside a large box called the World Coordinate System. Any object not inside a Transform is positioned relative to the origin of the World Coordinate System. Any object inside a Transform is positioned relative to the origin of the Transform including other transforms.

Understanding X3D Objects

To understand what we are doing next, let's talk about the tags we have been using. X3D tags provide data for VRML/X3D objects, which must behave precisely as defined by the X3D Object Model.

A VRML/X3D world is a collection of objects. These objects can be operated on individually or in collections. There are many types of objects. These objects can be collected and named, manipulated, and reused. It is this capability to create and fit these together that gives X3D it's power to simulate, and it's why standard open libraries of VRML/X3D objects such as Universal Media are so useful.

To animate or affect a VRML/X3D object such as geometry or an appearance, one uses behavior objects. In this example, the object being affected is the Transform itself. Why? Because positions in space of objects in the space are determined by the coordinate system they are in. Change the coordinates and the positions of the objects change. Other attributes such as scale can also be affected this way, but for now, we will work to animate the world by giving it a constant rotation.

To create effects such as animation or color changes, one connects the behavior objects to the objects to be affected through ROUTEs. Objects that behave or enable behaviors have in/out attributes. Think of these as plugs or sockets such as you find on your stereo. Creating an animation is much like wiring up your stereo for the first time. You have to find the right output from your CD player and connect it to the right input on your stereo amplifier. The analog of the cords you use to do this are called ROUTEs. A ROUTE object has named values for the objects to be connected and names for the outputs and inputs of each of the objects used in the animation.

Before I illustrate this, there are some jargon issues. Part of this is because the X3D standard has multiple encodings, and XML is just one of them. Part of this is because the X3D standard defines an operational object model to ensure interoperability. The abstract definition of VRML is written in terms of a non-XML set of abstract structures not unlike the XML Infoset. Just as XML languages such as XSLT and XML Schema are defined in terms of operations on the infoset, X3D operations are defined in terms of operations on the abstract objects and properties defined in the standard. As was noted by Tim Bray and others very early in the X3D design process, getting the markup right is easy; getting the object model right is everything. Fortunately for the X3D designers, the VRML designers did an excellent job and the X3D model improves on a proven working model.

VRML objects are defined in terms of nodes and fields. XML defines elements and attributes. These do not map isomorphically or hierarchically. This is sometimes called "the impedance mismatch" of XML and VRML. In VRML nodes have fields and fields can contain nodes in classic object-oriented language fashion. Of course, XML elements can have attributes but attributes cannot contain elements and that is part of the impedance mismatch, but by using names cleverly, it all works.

In X3D, a node is named by the DEF attribute value for the tag that has the data for that object. The Transform example above has the name 'TheWorldTurns'.

  <Transform rotation="0 1 0 1.57" DEF='TheWorldTurns' >

A field is an XML attribute also referenced by name. You have to learn which ones are typed as exposed fields to know if they can be inputs or outputs discussed next. Once you do, you can do neat tricks such as sending a value to a scale field to make an object grow or shrink in real time or to a color value to make an object change colors. The rule is that the types of the values being sent must match the type of the attribute or field being sent to. In other words, numeric attributes only accept numeric values and so forth. After you master using Script objects, you can do the very powerful tricks of simulation because they can send values to and receive values from other objects. It's easy to build reusuable intelligent objects that interact through cascades of events. That is the essence of real time 3D simulation and the X3D object model.

Using X3D Behaviors

Among the objects are behavioral objects used to create motion or animation, including:

Sensors: used to create clocks, controls, etc. For example, a Time Sensor creates a controllable time cycle interval that can be looped, paused, and restarted.

<TimeSensor DEF='TimeThisTurn' cycleInterval='12.0' loop='true' pauseTime='0' isPaused='' resumeTime='0' fraction_changed=''/>
Interpolators: used to create interpolated motion, that is, motion in which the discrete chunks of a movement called "key values" are averaged to create a single smooth motion. For example, an orientation interpolator changes the orientation of an object; so, when its values are sent to an object's rotation field, the object revolves. If you send this to a transform, all of the objects inside the transform turn with it. A classic problem given to animation students is to create a solar system in which every object moves according to the right dynamics for that object. It is a revealing exercise in animating nested transforms.

<OrientationInterpolator DEF='TurnTheWorld' key='0.00 0.25 0.50 0.75 1.00' keyValue='0 1 0 0, 0 1 0 1.5708, 0 1 0 3.14159, 0 1 0 4.7123889, 0 1 0 6.2831852'/>

To send values from one object to another, one needs the element name and the attribute name within that element. In the ROUTE element, the fromNode and fromField names the node and the field the values come from; the toNode and toField name the nodes and the fields the values go to. A ROUTE object looks like this.

<ROUTE fromNode='TimeThisTurn' fromField='fraction_changed' toNode='TurnTheWorld' toField='set_fraction'/>

There is one more conceptual bit to understand. If you look at the Transform example and the ROUTE example, you will see in the ROUTE, a fromField named "fraction_changed" and a toField named "set_fraction", but these are not part of the Transform element type declared in the DTD or shown in the element itself. These are fields from the VRML/X3D object and they are not mirrored in the XML definition. Think of them as invisible attributes that you get for free whenever a Transform is instantiated. They are always there to be used but have no renderable value, so they don't appear in the XML.

Looking at the route example above, you will note that it takes the value from the Time Sensor and sends it to the orientation interpolator. To get the value from the Orientation Interpolator to the Transform, we need another connection. The second ROUTE looks like this:

<ROUTE fromNode='TurnTheWorld' fromField='value_changed' toNode='TheWorldTurns' toField='rotation'/>

When the entire example is assembled, it looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE X3D PUBLIC "ISO//Web3D//DTD X3D 3.0//EN"
  "http://www.web3d.org/specifications/x3d-3.0.dtd">
<X3D profile="Immersive" >
 <head>
  <meta content="Simple X3D example" name="description"/>
 </head>
 <Scene>
  <Viewpoint description="The World" orientation="0 1 0 1.57" position="10 0 0"/> 
  <Viewpoint description="Closer" orientation="0 1 0 1.57" position="6 0 0"/> 
  <Viewpoint description="Near" orientation="0 1 0 1.57" position="2 0 0"/>
  <Viewpoint description="Heart of Darkness" orientation="0 1 0 1.57" position="0 0 0"/>
  <Transform rotation="0 1 0 1.57" DEF='TheWorldTurns' >
   <Shape>
    <Sphere/>
    <Appearance>
     <ImageTexture url="earth-topo.png"/>
    </Appearance> 
   </Shape>
  </Transform>
  <TimeSensor DEF='TimeThisTurn' cycleInterval='12.0' loop='true'
      pauseTime='0' isPaused='' resumeTime='0' fraction_changed=''/>
  <OrientationInterpolator DEF='TurnTheWorld' key='0.00 0.25 0.50 0.75 1.00'
      keyValue='0 1 0 0, 0 1 0 1.5708, 0 1 0 3.14159, 0 1 0 4.7123889, 0 1 0 6.2831852'/> 
  <ROUTE fromNode='TimeThisTurn' fromField='fraction_changed' toNode='TurnTheWorld' toField='set_fraction'/> 
  <ROUTE fromNode='TurnTheWorld' fromField='value_changed' toNode='TheWorldTurns' toField='rotation'/>
 </Scene>
</X3D>

If you have all of this in a file and open it in the FLUX viewer, you should see a world rotating on its axis as it should, still in empty space, but now that you know how to make X3D objects, you can always add more.

Background Element

The Background element is simple. It enables you to use colors or images to surround a world and serve as a backdrop.

<!ELEMENT Background (IS?)>
<!ATTLIST Background
	groundAngle %MFFloat;  #IMPLIED
	groundColor %MFColor;  "0 0 0"
	backUrl     %MFString; #IMPLIED
	bottomUrl   %MFString; #IMPLIED
	frontUrl    %MFString; #IMPLIED
	leftUrl     %MFString; #IMPLIED
	rightUrl    %MFString; #IMPLIED
	topUrl      %MFString; #IMPLIED
	skyAngle    %MFFloat;  #IMPLIED
	skyColor    %MFColor;  "0 0 0"
	containerField NMTOKEN "children"
	class       CDATA       #IMPLIED
	DEF         ID         #IMPLIED 
	USE         IDREF      #IMPLIED >

As before, copy the following production into your file and copy the following image into your example directory.

<Background backUrl="babystars.png" bottomUrl="babystars.png" 
               frontURL="babystars.png" leftUrl="babystars.png" 
               rightURL="babystars.png" topUrl="babystars.png" />

X3D is in your hands like a world spinning alone in a cold night; so, let there be stars!

For those who would like to experiment with text and sound, the sample of this tutorial world has a sound node, some text nodes, a TouchSensor, and the necessary ROUTE statements. Simply uncomment these and add a WAV file of your own choosing, then change the name of the WAV file referenced in the sound node.

Conclusion

It's now possible to create real-time simulations using a powerful combination of XML and VRML. The potential for applying XML technologies such as XSLT to combine higher level language descriptions that can then be rendered into free-roaming worlds full of intelligent and even mischievous objects is on the horizon. There are interesting aspects of X3D such as GeoVRML and Human Animation (standard avatars) as well as scripting with exciting applications to such diverse domains as virtual theater and public safety systems. The challenge of creating real-time 3D applications using a standard XML application language for the Web has been realized.

Contributors: I want to thank the following individuals for contributing to this article: Tony Parisi, Alan Hudson, Stephen Matsuba, Phillip Hansel, Richard Puk, Don Brutzman, Aaron Walsh, Keith Victor, Mike McCann, Holger Grahn, Andy Yeh and Tony Gill. I particularly want to thank the members of the VRML Big List and the X3D Contributors list, past and present, for keeping VRML/X3D alive through the dry times. I want to thank Mark Pesce, Tony Parisi, Brian Behlendorf, Gavin Bell, and Rikk Carey for breathing life into 3D on the Web eight years ago. Not forgotten.

The following are related articles on the topic of VRML by this author:

Animation With Transforms, Sensors, Interpolators and ROUTEs

Transform Elements

Understanding X3D Objects

Using X3D Behaviors

Background Element

Conclusion

Related Articles

Recommended for You

About O'Reilly

Community

Partner Sites

Shop O'Reilly