From this grammar a message can be constructed. The message format will take one of two main formats. It will either be a navigational information or object manipulation information. In the case of navigational information, either speed or direction information will be transmitted. When transmitting object information there are three important components: the object identification, the property that is being changed and its value, and how the change will be implemented. The object identification is a unique ID that is used to specify the object that is being changed. It is essentially the object’s name. The objects property can be either position, scale, or color. The method of change defines whether the new data is to be relative or absolute. A relative value specifies that a change or delta value will be transmitted. That is to say, that the new value is to be added to the existing value of the parameter. An absolute value specifies the new value. That means that the new value is to replace the existing value. For example "S A 2 2 2" specifies that the object is to be scaled to the value (2, 2, 2), whereas "S R 2 2 2" specifies that the scale is to be increased by (2, 2, 2). By defining relative or absolute values this greatly enhances the overall flexibility of the system. This information is used differently by different devices. Some devices work better as relative positioning devices (such as the keyboard), whereas others work better as absolute positioning devices (such as the magnetic tracker).

From the above grammar the following messages to the clients can be constructed:

"V S 10" ; Change the new speed to 10 units.

"O 2 T A 10 0 0" ; Change the absolute position of object 2 to (10, 0, 0).

"O 3 DC R 0 0.5 0" ; Increase the green component of object 3’s color by 0.5.

A Graphical User Interface (GUI) is provided to control the mapping of input device to navigation and object manipulation. It is provided here to aid in the understanding of the implementation of the server in the following section (Server Device Input Loop). Figure 8 illustrates the GUI for the Device Map.

Figure 8: Snapshot of Device Mapper

The Device Mapper dialog has two separate functions.

First, it provides a means to map device input to 3D-world navigation. The "Navigation" list allows the mapping of a device to navigation. When a device in the list is selected, that device will control the navigation. Only one device can be selected at any one time.

Second, the Device Mapper provides a means to map device input to the control of objects in the 3D world. The "Object" list is used to select the object to manipulate in the 3D virtual world. The "Property" list is used to select the property of the object to manipulate. The "Device" list is used to select the device input to use for manipulation. These three lists (Object, Property, and Device) are used in tandem to create a device mapping. First an object is selected, then the property to manipulate, and finally the input device of choice is selected. Once a mapping has been entered, the "Device Mapping" output list displays the selection. This allows the user to keep track of multiple device mapping. In the above example three device mappings have been entered. In this case voice input, the keyboard, and the glove input are being used to concurrently control the properties of different objects. To further complicate the issue, voice input has also been selected to control navigation. It is up to the user to decide how many properties he/she can effectively control at one time. The interface, however, has put no limits on the number of mappings.

The server implementation is split into two separate sections: initialization, and server loop. The initialization sets up all of the input devices. It is responsible for setting up the initial parameter of the devices. In fact the initialization is merely a call to start all of the different input device interfaces. The actual device interface talks directly to the device drivers and establishes the connection and sets up the initial parameters.

The meat of the server is in the device input loop. The following pseudo-code shows the implementation of the server loop.

Forever Loop

{

# Process device input data for navigation

switch Navigation_Device:

{

case Glove_Device:

ProcessGloveNavigationData();

break;

case Voice_Input:

ProcessVoiceNavigationData();

break;

case {Other Input Device}:

Process{Other Input Device}NavigationData();

break;

}

# Process device input data for object manipulation

for ( All object manipulation device mappings ) do

{

device_map = Next device mapping;

switch Object_Manipulation_Device:

{

case Glove_Device:

ProcessGloveManipulationData(device_map);

break;

case Voice_Input:

ProcessVoiceManipulationData(device_map);

break;

case {Other Input Device}:

Process{Other Input Device}ManipulationData(device_map);

break;

}

}

}

There are two main part of the server device input loop: navigation and object manipulation. In the navigation section, the current device that is selected for navigation is called. As the current toolkit supports only one navigational mapping, only one device needs to be called.

Since the toolkit supports multiple device mappings, the object manipulation portion of the loop must process the device data for each device mapping. This device loop provides a simple mechanism for the addition of new devices. The addition of a new input device requires adding initialization code, and adding an extra case statement for navigation and object manipulation.

At the moment the device mapping is controlled by the functions ProcessGloveNavigationData and ProcessGloveManipulationData (in the case of the glove). These functions are user specified. If a new mapping is required, these functions must be modified to produce the new mapping. In the next chapter, I will discuss an application that uses these functions and describe how they are implemented.

Once a message has been formatted and sent to the client, the client must in-turn receive, parse, and execute the received command. The following pseudo-code shows the way in which a received message is handled.

Forever Loop

{

message = blocking_read();

tokens = break_incoming_message_into_token( message );

if ( tokens.first_token == Navigation_Command )

{

process_navigation_command( tokens.remaining_tokens );

}

else if ( tokens.first_token == Object_Manipulation_Command )

{

process_manipulation_command( tokens.remaining_tokens );

}

else

{

print( "Command not supported" );

}

}

The client blocks until a message is received. The VRML application runs concurrently since the client runs as its own separate thread. Once a message is received, it is converted into a set of tokens (or simple parts) and further parsed. At the moment the toolkit will process only navigation and object manipulation commands. Should new commands be required they must be added to this client loop.

The following section explains how the received and parsed commands are used to control the VRML application.

Java provides the engine behind the scene that brings the VRML world to life. Using a set of Java classes, one has access to the VRML world and has a means to add behavior and interaction.

In order to take control of the world, a set of low-level libraries have been provided (by different companies such as Netscape) that allow the programmer to access objects and nodes in the VRML world, and control their properties. Since I needed a means by which to control the properties of these objects in a scaleable and robust manner, I created a Java object class that provided a simple way to control an object. I wanted to work at a level of abstraction above what the existing interface provides for. The following methods from the vrmlObject class show what is available from the client interface.

public class vrmlObject

{

// vrmlObject constructor. It takes a pointer to the VRML browser

// and the name of the top-level node as it is named in the

// VRML file.

public vrmlObject(Browser browser, String name)

// Set the translation of the object in either relative or

// absolute mode.

public void setTranslationRelative(float x, float y, float z)

public void setTranslationAbsolute(float x, float y, float z)

// Set the scale or the object in either relative or absolute mode.

public void setScaleRelative(float x, float y, float z)

public void setScaleAbsolute(float x, float y, float z)

// Set the objects diffuse color in either relative or absolute mode.

public void setDiffuseColorRelative(float x, float y, float z)

public void setDiffuseColorAbsolute(float x, float y, float z)

}

This set of methods provide a robust means for interacting with the object. Should other properties, such as orientation and transparency, be needed for manipulation, the methods can be easily added. The overall architecture of the system will not be greatly affected by the addition of the new methods.

This section covered the toolkit. It shows the data path and the different parts of the toolkit that are provided to process the data. The server provides a means to easily add new devices and create the mapping that is required for the task. The grammar can used to convert a set of input device values to the required commands to interface with the client. Once the data has been sent the client provides a means for receiving and parsing the data. The architecture of the client is such that new commands can be added to scale the architecture. In addition to sending and receiving messages, a graphical user interface has been provided to easily map device data to required command.

This toolkit is a first step to provide a means to quickly add and prototype new devices and new interaction techniques. This framework will provide as a launch pad for quickly testing interaction techniques. It also provides the framework for using these devices within a VRML world. This will prove to be very useful as the consumer market begins to use these new input devices.

In order to test the usefulness and efficacy of the system it will need to be tested. To test it, an application will need to be created that puts the toolkit to work. The next chapter will document this application.