Navigation, Input Devices, and Collision - Interactive Web-Based Virtual Reality with Java 3D - page 230

In this section, the joystick will be used as an example input device. Note that, in
general, a custom device driver that suits the specific joystick used will be required in any
implementation. Specifically, the required native functions from the device driver must be
obtained and specified in a *.java file.
In the example in this section, we will take the device driver as joystick.dll. In addition,
as shown in the code segment in Figure 12, there are five native methods that are provided
by the device driver. However, before discussing how these are used in our example imple-
mentation, it is worthwhile to take note of the following three generic ways for getting
information from the device or device driver:

• Blocking: This signifies that the device driver is a blocking one and that Java 3D

should be scheduled to read from the driver regularly. Technically, a blocking driver
is one that can cause the thread (pollAndProcessInput in Java 3D) accessing the
driver to be blocked while data is being transferred.

• NonBlocking: This signifies that the device driver is a non blocking one and that

Java 3D should be scheduled to read from the driver regularly. Technically, a non
blocking driver is one that will not cause the thread accessing the driver to be blocked
while data is being retrieved. When there is no data available, pollAndProcessInput
will return without any updating of the relevant sensor read value.

• DemandDriven: This is in a certain way non-blocking also and will give the cur-

rent sensor value on demand whenever pollAndProcessInput is called through one
of the getRead methods for the sensors of the device. The implication is that there is
no need for scheduled regular reads.

Figures 13 and 14 show the code segment in an example for using the joystick as an
input device. A demand driven device driver is assumed. Essentially, we need to perform
the following operations:

• Construct the appropriate class and any necessary supporting methods.

• Read from the device and perform preprocessing.

• Use the input values to change the runtime environment.

Specifically, the setting up of the JoystickInputDevice class starts with creating in-
stances from the Joystick, Sensor, and SensorRead classes in lines 3 to 5 in Figure 13. After
declaring the other important variables and objects, the class constructor is declared with
input arguments given by the transform groups that need to be modified. In this navigation
example, the main interest is the transform group that contains the ViewPlatform and any
other attached objects.
Next, an initialize method that will be invoked by the system upon initialization is supplied
in lines 22 to 28 so that the joystick can be properly initialized. In this example, the trans-
formation matrix is set up and checks for any device driver link error are performed.