Extensible 3D: XML Meets VRML
August 6, 2003
"VRML was born dead. It never solved any real problems. Good riddance." -- from the wwwac mailing list Thursday, February 25, 1999
Remember VRML?
The remark quoted above, to paraphrase Mark Twain, is an example of "what we know that just ain't so". The Virtual Reality Modeling Language is very much alive and being used to solve real problems. In this article, we will examine the new VRML standard, Extensible 3D (X3D), as well as software and other resources available to support it. Examples and a short tutorial on the new X3D XML-format are provided.
Why Do They Say Such Things?
Ever since the meteoric rise of HTML, the dot-com explosion and then implosion, a criterion for success on the Web has been speed of adoption. Some say that open standards are critical to success; others claim that proprietary systems do well if supported by lots of marketing cash and free products. Some say it simply comes down to the View Source test. It is evident that the success of a product or standard on the Web is just as complicated as in any other market and depends on many factors of which these are just more extreme positions. VRML never died or went away; yet it's clearly not the juggernaut that XML or HTML are. Why not?
-
3D is hard work though generally easier than 2D for the same results. A 3D model can be manipulated easily to get multiple views and to animate realistic motion. Doing this in 2D is quite hard, requires deep technical knowledge of perspective, and lots of practice. On the other hand, a child can animate a VRML 3D world and several have and do.
-
VRML is used for real time 3D simulation. There is much more to do when modeling an object as opposed to drawing it when one considers collisions, moving viewpoints, and so on.
-
Validity counts. VRML is not tag soup. While it passes the View Source test, working with it on a regular basis means acquiring tools. High end professional tools for 3D animation are orders of magnitude more expensive than the same order of tool for HTML.
-
Real-time 3D animation pushes a processor hard. Much of the discipline required to build in this language is centered around learning how to optimize, but the performance needed to properly render many VRML97 worlds built eight years ago is now common from home desktop systems. The challenge is to get full interoperability among the 3D applications and this is the goal of VRML/X3D.
|
Contents Animation With Transforms, Sensors, Interpolators and ROUTEs |
A real-time, 3D multimedia language is not meant to be ubiquitous in the sense that all web designers will learn and apply it. VRML is a language for animators and modellers who are specialists. VRML is meant to be perform well. If that requirement had been made of HTML, HTML would be Postscript. Even in the fields it is designed for, more optimum languages exist for more narrow applications, but VRML nicely hits the sweetspot of complexity, capability, and performance. And for those who value standards, it is standard. To those who say it is a dead language, has no real use, or solves no real problems, they're simply wrong. With VRML the artistry of 3D animation and the disciplines of software programming and object-oriented design merge in a multimedia/hypermedia modeling language to enable some of the most compelling and useful content on the Web.
Who is Using VRML Today
The use of the VRML97 standard has been steadily increasing ever since the first beta VRML browsers were introduced. These are published to the Web or closed systems where they serve multiple purposes such as education, training, or entertainment. Universities, architectural design firms, emergency management training firms, engineering firms, and others have discovered that VRML really is the cheap, ubiquitous way to rapidly simulate things like
- A historical recreation of Yuri Gagarin's space flight (April 12, 1961)
- A model of a cybernetic building.
- A simulation of the Monterey Bay Aquarium Research Institute (MBARI) remote operated vehicle dives.
- Data Visualization for Mine Engineering
- VRMath (an educational site for learning geometry while interactively constructing 3D worlds)
Companies like Bitmanagement Software GmbH, which supports the Contact VRML97 browser, and Parallel Graphics, which develops Cortona VRML97 browser have steadily improved their browsers: increased rendering speed, smaller downloads, and language extensions (many of which are now in the new X3D standard). These are a few examples that illustrate the intense commitment VRML artists and engineers have to their work and the language.
What Is New With VRML? X3D
The new web 3D standard is X3D/ Extensible 3D. Open source libraries and commercial plugins have already been released in beta for this new standard. Exporters from commercial editors and dedicated editors are in development. Freeware editors are already available.
What features of X3D distinguish it from VRML97? According to Tony Parisi, from Media Machines Inc., the most important new features are the following.
- Multiple data encodings (XML, VRML "classic", Binary)
- New graphics features (NURBs, Humanoid Animation, Multitexturing, Triangle primitives, 2D shapes inside 3D)
- New networking features (LoadSensor, improved Inline)
- Improved APIs, more language/object model bindings (e.g. DOM) and many clarifications to event model for better conformance
- Modularity (the standard is broken up into profiles and components so it can be supported at many levels)
- MPEG-4 has streaming interactive 3D using VRML
Another important goal was to create specification which would allow the widest possible interoperability; that the worlds created would render and behave identically in different implementations. VRML97 makes it 80% of the way to this goal, but that isn't good enough in a graphics app. For the VRML97 authors, getting identical rendering fidelity and behavioral fidelilty from multiple browsers for the same world was difficult. Has this goal been met in X3D? Tony Parisi says that
We need to be careful: "identical" is a relative term. And the tolerances people have will vary greatly depending upon the target application. In a real-time game "identical" visuals may be less important than consistent behavior. In a CAD viewer the emphasis may be on pixel identity. etc.
Given the early tests, it appears that this goal is close to being achieved, but it will take more time and practice to determine how close is close enough.
Work on the standard at the Web3D Consortium in partnership with ISO is ongoing. This relationship between ISO and the Web3D Consortium is one of the most successful and open of any involving ISO and a web standard. Richard Puk, the ISO/IEC JTC1/SC24 Liaison to the Web3D Consortium, says that
the ISO and the Web3D Consortium have had a mutually successful relationship since the publication of the first Web3D-originated standard, VRML 97 (ISO/IEC 14772). This relationship is based on a formal Cooperative Agreement that satisfies the requirements and responsibilities of both organizations while ensuring timely standardization of Web3D Consortium specifications. The two organizations are in the final stages of standardizing X3D, a second generation of three-dimensional functionality for the...Web.
Why XML?
The original syntax for VRML 1.0 and VRML97 is the so-called curly bracket syntax familiar to C and C++ programmers. It is compact, has very fast parsing speed, and is context free. The following is an X3D example of a red sphere and a blue box lit by a directional light. This is an example of the new VRML Classic syntax.
#X3D V3.0 utf8
PROFILE IMMERSIVE
META "filename" "RedSphereBlueBox.wrl"
Transform {
children [
NavigationInfo {
headlight FALSE
avatarSize [ 0.25 1.6 0.75 ]
type [ "EXAMINE" ]
}
DirectionalLight {
}
Transform {
translation 3.0 0.0 1.0
children [
Shape {
geometry Sphere { radius 2.3
}
appearance Appearance {
material Material { diffuseColor 1.0 0.0 0.0
}
}
}
]
}
Transform {
translation -2.4 0.2 1.0
rotation 0.0 0.707 0.707 0.9
children [
Shape {
geometry Box {
}
appearance Appearance {
material Material { diffuseColor 0.0 0.0 1.0
}
}
}
]
}
]
}
Parsing speed was very important to early VRML work because performance is the sine qua non of real time animation. Given that RelaxNG sports a similar compact syntax, having syntax alternatives isn't that controversial in the XML world. While the decision to provide an XML syntax was quite controversial in the early days of designing the successor to VRML97, few dispute the wisdom of that decision today. According to Yumetech President, Alan Hudson, who is chair of the Web3D Open Source Working Group, the reasons are that
- We need XML to interoperate with the Web
- We need to incorporate new graphics technologies in a standardized way
- We need VRML content to run the same across browsers
- We need a standard which can evolve faster then every 5 years
While sharp eyed XML veterans will quickly note that XML cannot guarantee item three, the application of other XML application languages such as XSLT are considered sufficient reason to demand an XML encoding. The example above when encoded as XML 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"
xmlns:xsd="http://www.w3.org/2001/XMLSchema-instance"
xsd:noNamespaceSchemaLocation="http://www.web3d.org/specifications/x3d-3.0.xsd">
<head>
<meta name='filename' content='RedSphereBlueBox.x3d'/>
</head>
<Scene>
<Transform>
<NavigationInfo headlight='false'
avatarSize='0.25 1.6 0.75' type='EXAMINE'/>
<DirectionalLight/>
<Transform translation='3.0 0.0 1.0'>
<Shape>
<Sphere radius='2.3'/>
<Appearance>
<Material diffuseColor='1.0 0.0 0.0'/>
</Appearance>
</Shape>
</Transform>
<Transform translation='-2.4 0.2 1.0' rotation='0.0 0.707 0.707 0.9'>
<Shape>
<Box/>
<Appearance>
<Material diffuseColor='0.0 0.0 1.0'/>
</Appearance>
</Shape>
</Transform>
</Transform>
</Scene>
</X3D>
The rendering for the XML encoding looks like the following image:
Note that a VRML Classic encoded world will not render in a VRML97 browser. Although the two browsers cited in this article both render VRML97, that is not an X3D standard requirement, though many consider it a market requirement. Those that want to experiment with the examples in this article should download one or both of the browsers described here.
Why Binary?
Binary formats have been debated hotly among XML developers list for years. It can be said that the requirement for a binary comes down to the application itself. Some need them, others don't. The work on the binary for X3D is not complete as of this writing. Alan Hudson suggests why one is necessary for X3D:
- Parsing Speed. I routinely process 20 to 30 MB VRML files. CAD users are pushing around 100+ MB. My desire is to push VRML into the simulation space where they routinely have databases representing the world or a very detailed region. I think a lack of binary format is a big issue. The combination of XML plus binary formats gives us both answers they need. But they must be 1:1 convertible, that's a key issue.
- Delivery Size. A big chunk of the VRML applications I've written have been local, so delivery size has not been that big of an issue. But I'd like to move the training applications I do to the a web delivery strategy. For an application I did 3 years ago the VRML file was 16 MB uncompressed, gzipped it's 3.5 MB. In my prototype binary work I've gotten it down to 1.5 MB binary gzipped. I've seen other work which has gotten the same type of file down to 300K with unpatented technology. At 300K it becomes feasible to deliver a full training application (this one involved 300 parts, 2 rooms, about 2.5 hours of training time). No streaming needed, just deliver the whole thing and run.
MIME Type Support
VRML97 files use the "wrl" (uncompressed) and "wrl.gz" (gzip-compressed) extensions to identify their MIME types. To prevent confusing the users and interfering with the installed base of VRML97 tools, the following MIME type extensions have been selected for X3D given the multiple encodings as of this writing:
| Classic VRML | XML | Binary |
|---|---|---|
| x3dv | x3d | x3db |
| x3dvz | x3dz | x3dbz |
| model/x3d+vrml | model/x3d+xml | model/x3d+binary |
X3D Resources
It is common for application languages to be tossed over the transom to authors and developers without the resources needed to get started quickly. The Web3D community is not doing that for X3D. Because of the existing legacy of VRML97, and because the standards development team and others have been working hard to create the necessary resources, X3D users start with a treasure trove.
X3D Browsers and Toolkits
There are three outstanding browsers that support the XML-encoding now. First, Xj3D is a Java browser. The second, Flux, is an Active-X plugin for use inside Internet Explorer. The third is Contact, an OCX for Internet Explorer from Bitmanagement Software GmbH.
Xj3D
Xj3D is an open source Web3D Consortium project. It is a Java toolkit for VRML97 and X3D content and provides a browser that can handle VRML97 and X3D in both the XML-encoding and VRML Classic. Development of Xj3D has been financially supported by various institutes and companies. Developers interested in the project, the product, or the source code can start at the Xj3D homepage.
Stephen Matsuba, at Yumetech, the Seattle-based company that is the prime developer of the Xj3D toolkit, cites the two projects where the XML encoding feature of X3D could or did represent a significant factor.
The first example is...an application that taught and tested maintenance personnel for an encapsulation machine that produced 100,000 to 200,000 pills per hour...Users could be shown the various steps in the standard operating procedure for the encapsulation machine and then be tested on what they learned. It would also track and record their progress through the tutorials. The system required links between the 3D viewer and a database that could track the user inputs and return the appropriate response.
This system was developed using VRML and Java 3D. The user inputs within the VRML environment utilized scripts to send and receive information from the database. There was no direct way for the visualization software to communicate with the database, and so the development team needed to create various methods to facilitate this task. It was the not most efficient method for linking a database with a 3D real-time graphics system. Indeed, the training application was...'held together with baling wire and Perl'.
|
|
|
|
The other project is the Digital Rare Book Library System (DiRBS): a project developed by the UNC's School of Library and Information Science and Yumetech. DiRBS is designed to reintroduce the experience of viewing a book into the digital form. It consists of two components. The first is a system for viewing rare books and historically significant material in a form that provides users with the sense that they are "handling" an actual book. This experience is not limited to individual items, but also includes a 3D system for viewing an entire collection. The second component is a set of procedures and software tools for scanning, converting and distributing all this material online.
Unlike the training application, DiRBS was able to utilize the X3D standard for its graphics format and incorporate its XML encodings into the system. The XML encodings greatly improved the interaction between the database and the 3D graphics system. Information about the books, the 3D models, behaviors and other elements were stored in XML and could be dynamically send to the X3D viewer. Moreover, the availability of Xj3D allowed the Yumetech team to incorporate new graphic overlays directly in the browser code.
|
|
|
|
Flux
For high level development on the Direct X platform, the Flux Media Player is ideal. For the end user, there is the ActiveX plugin to view and navigate X3D and VRML97. For the professional application programmer, there is the Flux Engine and Flux Web. Flux supports XML and VRML97 file loaders; GIF, JPEG, and PNG texture readers; and integration with ActiveX and XML/DOM within IE and Netscape. Developers interested in the patented MPEG-4/BIFS technology can license the Flux library for this work. You can download the Active-X Flux browser here. Media Machines is sponsoring an active beta program and provides examples of content to get the author started with X3D.
Contact
Bitmanagment Software supports and improves the industry standard Contact player. The new 6.1 version supports X3D XML encoding with a flexible MSXML/IE DOM Integration model. The engine offers highly optimized OpenGL and Direct X rendering support. Scenes can be composed in real-time out of 2D, 3D, audio, video objects and other subscenes. Due to a flexible COM API the player is used in several industrial applications. Bitmanagement products for 3D include other tools such as exporters and optimizers and the SDK Package for integration in third party products and applications.
Many new concepts like Multitexturing and NURBS Primitives have been brought by Bitmanagement's key engineers to the X3D specification. Bitmanagement also showed the world's first realtime integrated MPEG-4 2D/3D Player with live-streamed MPEG-4 video.
Here are images of two high-end sophisticated VRML applications produced using BitManagement tools for the Web.
|
|
|
|
Linux Browsers
For the Linux community, there are three well known browsers for VRML and X3D:
Xj3D supports the XML encoding. John Stewart promises support in FreeWRL soon. OpenVRML only supports VRML97 today.
X3D Editors, Exporters and Converters
While VRML has good editor support from editors such as Spazz3D and exporters for professional systems such as Maya, XML support is only now being adopted. An open source project for an exporter from 3DStudio Max is underway. The basics of an exporter are available from the Web3D Consortium's source group. Qiming Wang developed a VRML97 to X3D convertor to ease the pain for those who already have a substantial amount of VRML97 content. You can get that here. Bitmanagement provides the BS Exporter Converter for 3ds max to VRML as well as BS Internet Optimizer for reduction of VRML data.
X3D-Edit
X3D-Edit provides XML-encoded X3D editing support for scenegraphs; it's freeware with good I18N support. It incorporates authoring and validation. This editor was developed by the specification team under Don Brutzman to support development of the X3D language. It is available for multiple platforms including Windows and the Mac.
Brutzman's work at the Naval Postgraduate School q combines VRML with Distributed Interactive Simulation (DIS) has produced some of the most technically sophisticated, elegant, and forward looking work in 3D on the Web. A DIS component set is part of the standard ensuring that X3D can be used in forward looking distributed simulation projects.
Spazz 3D
The Spazz3D editor is a cheap VRML97 editor with advanced features. Keith Victor creator of Spazz3D, promises X3D XML support in a future version of the product. Meanwhile, users of this editor can avail themselves of the NIST translator to create X3D.
Universal Media (UM)
Universal Media is a library of textures, sounds, and objects that can be used to build a 3D world without having to start from scratch. The advantages of using this library are that it's free, cross-platform, and fast.
Web3D Chat
Web3D Chat is a Web3D technology showcase; it features Universal Media worlds. The Daybreak world is an example of a Web3D Chat world that is both edgy and serenely beautiful. Here is a scene from that world.
Aaron Walsh is the chair of the the Web3D Consortium's Universal Media Working Group, which is responsible for the development of Universal Media, and the architect of the Web3D Web(tm) for which Web3DChat is the 3D chat system. Scheduled for public release this December (2003) the Web3D Web is a digital media network. UM 2.0, the next major revision of the system, will represent 3D objects in X3D with XML encoding.
The Web3D Specification Examples
As part of the development of the X3D standard, a comprehensive set of examples has been developed. VRML veterans will recognize many of these from the bible of the VRML97 developers, the VRML 2.0 Sourcebook.
Other examples have been provided in VRML Classic and the XML encodings. These are also incorporated into the X3D-Edit editor described above.
Scripting Language Bindings
While X3D has the built in behavioral nodes such as interpolaters, scripted language nodes are also available for the more strenuous and sophisticated applications. The Final Committee Draft (FCD) for the X3D ECMAScript and Java language bindings is in the registration and balloting process at ISO. The text for these two parts is available here.
X3D By Example
Now that you have enough overview material to understand what X3D is and where to find sources of software and support, let's look at an example. While it is not possible to survey all the features, this example will acquaint you with the basics of X3D modeling. For this example, I will be using the Flux browser.
The X3D DTD is another example of the complexity and obscurity made possible by the use of XML parameter entities. For this example, I will defang the DTD and use simpler element productions exploring each one used in the basic example. There is a W3C XML Schema for X3D, but it doesn't seem that anyone has written a RelaxNG schema.
X3D: Root Element
<!ELEMENT X3D ( head? , Scene ) > <!ATTLIST X3D profile (Core|Interchange|Interactive|Immersive|MPEG4|Full) #IMPLIED version CDATA #FIXED "3.0">
The element tree looks familiar. It is the head/body structure found in HTML. The head is optional and only one is allowed. Unsurprisingly, the majority of the world is a scene.
The attributes are more interesting. The PROFILE attribute is worth noting. Profiles are combinations of different X3D productions meant to enable X3D to operate on a variety of devices from the desktop, to the cell phone, to fully immersive CAVE visualization systems. Profiles aren't well supported yet, but this is an indication of things to come.
Head Element
<!ELEMENT head ( component*, meta* ) >
The X3D Head element type consists of component and metatag declarations. Metatags are the more frequently used elements and are a means to pass generic descriptive information in the document. One will typically see things such as author names and publication dates in these tags.
<!ELEMENT meta EMPTY> <!ATTLIST meta http-equiv CDATA #IMPLIED name CDATA #REQUIRED content CDATA #REQUIRED scheme CDATA #IMPLIED %i18n; >
Scene Element
<!ELEMENT Scene ( %ChildrenNodes; | %WildcardNodes; )* >
The Scene element contains the meat of the X3D document. In the element type declaration for this element type, I've deliberately left the parameter entity declarations in to make the point that profiling, while indicated to the X3D processor by the profile attribute value on the document root, definitionally depends on CDATA sections in the DTD. Working out which productions belong to which components in which profiles is worthy of a book and a good reason to use an XML X3D editor.
So far we have an unremarkable X3D instance.
<?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> ......... </Scene> </X3D>
Shape Elements
It is time to add some content to display. Here is the Shape element type:
<!ELEMENT Shape (IS?, (
( (%AppearanceNodes;), (( %GeometryNodes; ) | %WildcardNodes;)? ) |
( ( %GeometryNodes; ), ((%AppearanceNodes;) | %WildcardNodes;)? ) |
( %WildcardNodes;, (( %GeometryNodes; ) | (%AppearanceNodes;) | %WildcardNodes;)? )
)? ) >
We will concentrate on only two of these, starting with a geometry node. While the majority of performant graphics use collections of vertex information in shapes such as face sets, X3D also includes a set of primitive Euclidean shapes -- sphere, box, and cylinder -- to enable a user to create and modify basic shapes. While not always performant, a lot of work can be done using only basic shapes. Here is an example of a creature made up entirely of X3D basic shapes. He is ugly but great for picking up trash off the roadside.
For this exercise, we use the sphere. For now, the only important attribute is "radius" which defaults to a value of one meter.
<!ELEMENT Sphere (IS?) > <!ATTLIST Sphere radius %SFFloat; "1" containerField NMTOKEN "geometry" class CDATA #IMPLIED DEF ID #IMPLIED USE IDREF #IMPLIED>
Here is a sphere inside a shape element. Note that the radius value is defaulted by simply not using it in the production.
<Shape> <Sphere/> </Shape>
To make it more apparent, we'll add some color. Colors, textures and so on are added to X3D geometry using an element type called, appropriately, an Appearance element.
Appearance Elements
The Appearance element type is scarier looking in the declaration than it is to actually use. The actual number of potential elements is not that large. This version of the element type was created by Heiko Grussbach to provide a "complete, unordered, concisely enumerated version of the Appearance" element type. I'm not sure if this makes the case for keeping XML parameter entities or getting rid of them.
<!ELEMENT Appearance (IS?,
( (FillProperties, LineProperties?) | (LineProperties, FillProperties)? )?,
( ((%MaterialNodes;), (((%TextureNodes;),((%TextureTransformNodes;)|%WildcardNodes;)?) |
((%TextureTransformNodes;),((%TextureNodes;)|%WildcardNodes;)?) |
(%WildcardNodes;,((%TextureNodes;)|(%TextureTransformNodes;)|%WildcardNodes;)?) )? )
| ((%TextureNodes;), ( ((%MaterialNodes;),((%TextureTransformNodes;)|%WildcardNodes;)?) |
((%TextureTransformNodes;),((%MaterialNodes;)|%WildcardNodes;)?) |
(%WildcardNodes;,((%MaterialNodes;)|(%TextureTransformNodes;)|%WildcardNodes;)?) )? )
| ((%TextureTransformNodes;), (((%MaterialNodes;),((%TextureNodes;)|%WildcardNodes;)?) |
((%TextureNodes;),((%MaterialNodes;)|%WildcardNodes;)?) |
(%WildcardNodes;,((%MaterialNodes;)|(%TextureNodes;)|%WildcardNodes;)?) )? )
| (%WildcardNodes;, ( ((%MaterialNodes;),((%TextureNodes;)|(%TextureTransformNodes;)|%WildcardNodes;)?) |
((%TextureNodes;),((%MaterialNodes;)|(%TextureTransformNodes;)|%WildcardNodes;)?) |
((%TextureTransformNodes;),((%MaterialNodes;)|(%TextureNodes;)|%WildcardNodes;)?) |
(%WildcardNodes;,((%MaterialNodes;)|(%TextureNodes;)|(%TextureTransformNodes;)|%WildcardNodes;)?) )? )
)? ) >
<!ATTLIST Appearance
containerField NMTOKEN "appearance"
class CDATA #IMPLIED
DEF ID #IMPLIED
USE IDREF #IMPLIED >
Here is the much less intimidating element instance inside a shape.
<Shape>
<Sphere/>
<Appearance DEF='RED'>
<Material diffuseColor='1 0 0'/>
</Appearance>
</Shape>
The appearance node is named using a DEF attribute. As in most uses of name values, this is useful for reusing or manipulating the named element. We'll come back to this use of naming later. Notice that the Appearance element contains a Material element.
<!ELEMENT Material (IS?) > <!ATTLIST Material ambientIntensity %SFFloat; "0.2" diffuseColor %SFColor; "0.8 0.8 0.8" emissiveColor %SFColor; "0 0 0" shininess %SFFloat; "0.2" specularColor %SFColor; "0 0 0" transparency %SFFloat; "0" containerField NMTOKEN "material" class CDATA #IMPLIED DEF ID #IMPLIED USE IDREF #IMPLIED >
The Material element provides the color information to be applied to the sphere inside the shape element. If you add the production above to your file and display it in Flux, you see a red sphere floating in a sea of black. Still, unremarkable as worlds go, but not much markup either. Next, instead of using a Material element, we will use an ImageTexture.
<!ELEMENT ImageTexture (IS?) > <!ATTLIST ImageTexture url %MFString; #IMPLIED repeatS %SFBool; "true" repeatT %SFBool; "true" containerField NMTOKEN "texture" class CDATA #IMPLIED DEF ID #IMPLIED USE IDREF #IMPLIED >
The Shape production with an ImageTexture element looks like this:
<Shape>
<Sphere/>
<Appearance DEF='RED'>
<ImageTexture url="earth-topo.png"/>
</Appearance>
</Shape>
Paste that into your X3D example. Save the following image into the same directory where you are creating the X3D example and give it the name "earth-topo.png".
Open the new X3D example. If you have the Flux X3D browser installed, you can play with the Flux navigation controls at the bottom of the screen. Click on the one with the down arrow looking icon with the sticky note that says "Move". Place the mouse cursor over the world and move it toward the top of the screen. The world comes to you or you go to it. Put the arrow elsewhere on the screen and experiment. The following things are worth noting.
- You wrote very little code to create this world. Most of the work is in creating the image texture.
- You wrote no code to create the animation effects that enable you to examine the world.
- The geometric 3D world can be easily manipulated into many different views using only the browser controls.
Viewpoint Elements
That's pretty good for a starter world, but not good enough. Real time animation deserves some real animation. First, let's add another element type that enables you to control where a world opens, what one sees when it does, to instantaneously move to different views of the world, and to move the user view in real time under author control. Appropriately, this is a Viewpoint element type.
<!ELEMENT Viewpoint (IS?) > <!ATTLIST Viewpoint fieldOfView %SFFloat; "0.785398" jump %SFBool; "true" orientation %SFRotation; "0 0 1 0" position %SFVec3f; "0 0 10" description %SFString; #IMPLIED centerOfRotation %SFVec3f; "0 0 0" containerField NMTOKEN "children" class CDATA #IMPLIED DEF ID #IMPLIED USE IDREF #IMPLIED >
Paste the following into the file just above the <Shape> element.
<Viewpoint description="The World" orientation="0 1 0 1.57" position="10 0 0"/>
Select the web browser refresh button to reload. Notice:
- The world is closer and centered in the view.
- The side facing you is the Western hemisphere.
- The Flux control now has a Viewpoint name in it, "The World" instead of "Default".
- If you use the Flux controls to move the world, then hit the Viewpoint button, the display returns to the Viewpoint named "The World".
No world is complete without diverse points of view, yes? So let's add some more.
<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"/>
If you click on the arrow controls next to the button with The World on it, you will see the world appear to come closer. Click again and the screen goes black. Note that the left most position attributes are ten, six, two and zero. That last viewpoint is inside your world at its center.
Note that it is not the sphere that is moving; it is the currently active viewpoint changing, which is why the move is instantaneous. A viewpoint is an object in the X3D world; there can be many of them, and they can be animated using the same kinds of animation element types as are used on the geometry. Think of a viewpoint as a camera that can be fixed or moving. Selecting a different active viewpoint is selecting among the cameras. Moving a viewpoint in the world can move the user along with it.
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.
Related Articles
The following are related articles on the topic of VRML by this author:
Other articles online:
Paper copy only:
- "Building a Better Golem"; Markup Languages: Theory and Practice 2.4 (2001): 337-351 Copyright 2001 by the Massachusetts Institute of Technology