This first installment gives you an introduction to the basic VRML programming styles. This overview starts with a description of the most common programming languages you can use to bring your virtual worlds to life. You will learn about various VRML browsers and how to setup a proper programming environment. The second part walks you through an example using two different programming styles/languages in parallel.

Before we start I have to say a few words about the browsers used for this tutorial. All examples are tested with WorldView2.0 + Netscape 3.02, Cosmo Player2.0 + Netscape 4.0, and MS VRML2.0 + IE 4.0 (all three on Windows95). I chose these browsers mainly because they seem to be the market leaders. Code that runs in these browsers should run just fine in any other VRML97 compliant browser. I hope that the manufactures of other honorable VRML browsers forgive me for my lazy reluctance to test their implementations.

The most common programming languages for VRML are Java and JavaScript. Even though both languages are not (yet) required by the VRML97 specification, one or the other (or both) are implemented by most of the current VRML97 browsers. Listing 1 shows a VRML Script node with a JavaScript file and a Java class in its URL field. If a browser can not fetch the JavaScript file successfully or can not interpret it, the browser will run the Java class instead and vice versa.

JavaScript is a scripting language, which gets interpreted by the browser at runtime. JavaScript (originally dubbed LiveScript) has a superficial resemblance to Java. It has a similar syntax but is more famous for its ability to directly interact with the HTML browser. You might find 'VrmlScript' mentioned once in a while. It was proposed as a subset of JavaScript but was dropped by its creators in favor of JavaScript. JavaScript has the advantage of being independent from the infamous Java CLASSPATH. Unlike Java, it does not depend on this environment variable and thus can be less sensible to configuration errors. Endusers who have installed more than one VRML browser, or whose systems suffer from improper uninstall/install procedures of VRML plugins, are very likely to run the wrong set of VRML Java classes with their VRML browser.

Java is compiled bytecode and usually runs within the Java Virtual Machine (JVM) of the host (HTML) browser. Java classes are restricted to the security sandbox in the same way as applets are, e.g. you can neither open sockets to hosts other than where the classes came from nor can you write to files on your local hard drive. There are two ways to use Java with VRML: JSAI and EAI.

JSAI stands for ‘Java in Script Nodes Authoring Interface’: A Script node receives eventIns, Java code processes these and returns instructions to VRML nodes via eventOuts. This is very similar to JavaScript-in-script-nodes and you might wonder why you should go through all this Java hassle. The JavaScript versus Java questions ultimately asks the question whether you want to use an object-oriented language or not. The speed difference between the two depends on the VRML browser and might not be that significant. Depending on the complexity of your application or behavior, a truly object-oriented language like Java might be a must in order to cope with complicated programming issues.

EAI stands for ‘External Authoring Interface’: It is an API for Java applets that want to access nodes in a VRML scene. This interface lets you control your VRML world from an HTML page, e.g. you could select items from a drop down box, which are then displayed for further examination in the browser. The EAI is still a proposal but is fully implemented by the major VRML browser manufacturers.

This all might sound very intimidating to the novice VRML/Java programmer but learning Java will reward you in many ways. As we walk through the tutorials I will try to demonstrate all code in JavaScript as well as in Java. This will hopefully reduce the learning curve enough to keep your interest alive ;).

The following example will take a 3D model of my favorite winter diet (Gummibären or Gummibears) and enable you to change the color and to squeeze it here and there. First you will build this demo with a VRML control panel (Figure 1) and later you will use the EAI to trigger VRML events from an applet (Figure 2). In both cases, you will have the choice to assign various colors to the Bär and squish it in three directions.

The VRML control panel will need to follow you around where ever you move. The easiest way to implement this is with the use of a (very) large ProximitySensor. This sensor will capture your position and orientation in space at every simulation tick and provide you with two eventOuts: position_changed and orientation_changed. You can use this data to transform and reorient the control panel and thus make it follow you. All the geometry that composes the control panel needs to be in one single Transform. The eventOuts are routed to the Transform's corresponding eventIns: set_translation and set_rotation ( Listing 2). The size of the ProximitySensor is somewhat arbitrary. It will depend on the size of your world and you should make it always twice as big just to be on the safe side.

The Bär's geometry has to be in a single Transform like the control panel since you want to scale the entire model. You have to give this Transform a name so that you can use it in your script:

DEF gummibearTransform Transform { … }

In VRML you DEFine nodes in order to USE them later in the scene. You want to manipulate the size (scale) and the color of the Gummibär and therefore have to give these nodes names. The color of the model is set in the node Material:

DEF gummibearMaterial Material { … }

Now you can use these two nodes in a Script node ( Listing 1) and actually start programming. The Transform and the Material nodes are both used by two helper nodes, gbTransform and gbMaterial. They give you a pointer to the corresponding nodes in the scene. For each button in your VRML control panel you will need to set up an eventIn, e.g. 'set_redBear' or 'set_scaleBearX'. In JavaScript these eventIns are identical to the names of the functions ( Listing 3). Clicking on the 'Squeeze Bear' button will route the touchTime eventOut from the TouchSensor of this button to the script's 'set_scaleBearX' eventIn and trigger the function 'set_scaleBearX'. This function now takes the pointer to the Gummibär Transform and sends the eventIn set_scale to it: The Bär gets squeezed. The color is dealt with in a similar way: the function 'set_redBear' takes the pointer to the Gummibär Material node and sends it the eventIn set_diffuseColor. In both cases you created new fields on the fly: new SFColor(1,0,0) and new SFVec3f(0.5,1,1). The diffuseColor field of the Material node requires data of type SFColor (SF as in Single Field), which in turn uses RGB (Red Green Blue) color space. A color with value (1,0,0) has 100% red, and zero blue or green components. The scale field of the Transform node requires data of type SFVec3f, which in turn is composed of x, y, and z values. A scale only in the x-axis is expressed with (0.5,1,1) whereas 0.5 stands for 50% in the x direction, and 1 for 100% in the y and z direction.

Listing 4 shows the same script using Java. It starts with importing classes from the package vrml and extends the class Script. When the Script node receives an eventIn the VRML browser invokes the processEvent method of class Gbear. The event is examined for its name and then processed. If no matching event name is found nothing will happen. The method 'set_redBear' first needs to get access to the Material node 'gbMaterial'. The script does this with a call to getField("gbMaterial"), which will return a pointer to the corresponding field. This pointer needs to be cast into a SFNode and can then be used to access the exposedField diffuseColor. However, before we can do this, the value of the SFNode 'gbMaterial' has to be retrieved with a getValue call. The method getExposedField("diffuseColor") returns a SFColor node, which is a pointer to the exposedField diffuseColor of the Material node 'gummibearMaterial'. The last step is to call setValue on the color field. The scaling is done in the same way: first you get the field and cast it to its type (SFVec3f), then you get the exposedField scale after you casted the VRML node to a Java node, and finally you set the new value with setValue(new SFVec3f(0.5f,1,1)).

As you can see, there are quite a bit more steps involved when you deal with Java in script nodes. Mini-scripts like this one certainly don't reward you for the extra effort of coding in Java and I hope that I can show you in later tutorials some of Java's advantages.

This crash introduction was intended to give you an overview of the major aspects of VRML programming. The next tutorial will continue this example with a detailed walkthrough of the EAI and you will learn how to eat the Bär's head.

Markus Roskothen is a multimedia consultant with www.infoplasm.com. He specializes in the design of interactive information spaces. He can be reached at markus@vruniverse.com. The Bär was modeled by Michael Siebielec. Special thanks to Lord Gary the Great and Fantastic Frankie for their support.

URLs:

Tutorial source: http://www.vruniverse.com/vrdj/tutorial1.html
VRML browsers: http://www.intervista.com http://vrml.sgi.com http://www.microsoft.com/vrml (challenge: try to find this site from the main microsoft site!)
Plugin chooser: http://vs.spiw.com

---

Copyright © 1996-98 Markus Roskothen. All rights reserved.