The purpose of this article is to explain how to change the appearance of some shapes as a result of the user clicking on one of them. This article assumes that you are a beginning VRML developer.

VRML and JavaScript
One is a language used to describe 3D worlds while the other is the most popular scripting method for the Internet. When you put these two together you get a way to change the attributes of the virtual world as the result of outside events. The new VRML 2.0 standard finally offers the VRML developer avenues to create interactivity within the VRML world as a result of user activity. This powerful and flexible ability is made possible by the new Script node that basically allows the programmer to use code that does not exist within the native VRML syntax.

For this article we will create a world that displays three primitive shapes. A click of the mouse on any of these shapes will change the appearance of the one clicked as well as the other two. To make this happen we will discuss how to "sense" a click from the mouse using the TouchSensor node. Then we shall look at class specifiers and type specifiers that specify criteria for what kinds of data can be received or sent from node to node. After that, we will look at the Script node and, finally, routing data between nodes. Also, for our example, I assume that the reader is familiar with the fundamentals of the VRML specification as well as the basics of JavaScript.

First, we need to set the stage. Using the code in Listing 1, I have created the three primitive shapes that have come to symbolize VRML: the red cube, green sphere and blue cone. The resulting world is seen in Figure 1. Looking at the code you should notice that each object is contained in a Transform node. This grouping node can contain many other nodes within its children field. So far, I have placed only one node as a child to the Transform node, the Shape node. Like the Transform node, the Shape node is a grouping node that can contain other nodes. I use the Appearance, Material and three different "shape" nodes to build this scene. Later, however, we will add the TouchSensor and Script nodes to the list of children.

Now we need to add an element that is capable of "sensing" the actions of the user's mouse. The VRML 2.0 specification includes the TouchSensor node that is capable of detecting whether the mouse pointer is either over an object or has clicked on an object. Think of the TouchSensor node as the VRML equivalent of the JavaScript event methods "onMouseOver" and "onClick". The TouchSensor node "senses" mouse actions for all of the shapes contained as children within the group. In other words, the TouchSensor node acts as a catchall sensor for its siblings. So, now we need to add this node as a child node in each one of the Transform nodes. Listing 2 shows the code after these additions. Now our three primitive shapes are capable of being clicked.

Next, we need to add code that says: "When an object is clicked, make that object glow and make the other objects dull." But before we can do that, we need to digress and understand the concept of class specifiers and type specifiers. Each node in the VRML standard has a definition. Included in the definition are the class specifiers and type specifiers for each item. The class specifiers are eventIn, eventOut, field and exposedField. These define how accessible the items of the node are to other nodes. Think of them as setting a "scope" for different items in the node. The eventIn specifier defines an event that the node is capable of receiving. In opposition, the eventOut specifier defines an event that the node can generate. These specifiers are enforced very strictly. A field class specifier is a private member of a node and cannot receive or generate events to any other nodes or elements. Its contents are used only within the node itself. Finally, there is the exposedField specifier. This specifier is a hybrid of eventIn and eventOut. When it receives an event (eventIn) it automatically generates a corresponding eventOut. However, it is not necessary to have any element "catching" the resulting eventOut from an exposedField. What the class specifiers allow us to do is set up mail slots for our nodes. Think of eventIns as a node's incoming mail slot that receives messages and events from other VRML elements. EventOuts are a node's outgoing mail slot which sends messages and events to other VRML elements. The field specifier is like mail kept in the top drawer, hidden from the view of the other VRML elements, and exposedFields are like a revolving door: they just receive an event in and send it out to any other node that may be waiting for it.

Along with the class specifiers are type specifiers. Type specifiers define what kinds of data the class specifiers are capable of sending and receiving. All type specifiers start with "SF" or "MF". An "SF" type means that this item can contain only a single value. An "MF" type means that this item can contain multiple values. Following the "SF" or "MF" is the identifier that tells us the type of data being defined. For example, "SFString" means that this particular item can only hold a single string value. "MFInt32" means that this particular item can hold multiple integer values. Think of type specifiers as having two distinct halves. The first half defines how many values can be held and the second half defines the type of data.

These two specifiers work together to restrict what kinds of data can be received as an eventIn or generated as an eventOut. The same works for an exposedField and a field. Therefore, looking at the definition, we see that the TouchSensor node has seven items: six eventOuts and one exposedField. Note that it does not have any eventIns. This only makes sense considering the purpose of this node. This node only sends messages to other nodes about the mouse actions that it senses and it does not need the ability to receive messages.