DIVE for IPTs

DIVE/Spelunk and various demos are available on request to Anthony Steed (A.Steed@cs.ucl.ac.uk).

Overview | Config | Demos | Building | Known Bugs

Overview

DIVE versions 3.3x* (UCL numbering) have supported immersive projection technologies (IPTs) through CAVElib. Sometimes these referred to as DIVE/Spelunk or just Spelunk. In order to facilitate the CAVElib port, and also in a quest to optimise the graphics side of DIVE, the renderer was ported to Performer. There are a few minor visual differences between the OpenGl and Performer renderers, but these are not significant, and are largely due to bugs in the OpenGL renderer!

Through CAVElib, we support many IPT configurations, though note that we (UCL) only really run HMD and CAVE-like systems and although DIVE/Spelunk should run out of the box on such systems, configurations such as desk have not been tested. DIVE will run, but you may find the user-interface confusing.

For those who are already DIVE users, DIVE/Spelunk adds a new front-end interface (spelunk_init.tcl) which supports all the DIVE/Spelunk necessary configuration, and a series of new avatars that are customised for CAVE or HMD use (body_cave_* and body_hmd_* respectively). These make used of DIVE's subjective visibility functionality.

Infrastructure

DIVE version 3.3x5 (UCL numbering) introduced an integrated scheme for tracking systems. This replaces previous systems that had separate vehicle/tracker/body plugins for each tracking system (Fastrak, VRPN and CAVElib). This re-write was largely so that further trackers, body configurations and vehicles could be supported through plugins, we have several examples of such plugins. If you have previously used a 3.3xY where Y is <5, then you will need to update config files (see below).

The immersive system consists of four parts:

Renderer - responsible for updating viewpoints, rendering scene graph and generating event triggers for per-frame behaviour (such as avatar animation).
Tracker source - responsible for reading trackers
Tracker vehicle - responsible for creating user-interface metaphors such as locomotion, selection and manipulation
Avatar - responsible for animating a series of objects that represent the user.

Since 3.3x5, the latter three of these are integrated in such a way that, although DIVE presents default or example implementations of each, they can all be replaced through plugins. This is a very flexible way of extending the system, but changes things slightly from previous architectures.

The standard diva application when built to support immersion supports the following:

Tracker sources: For each of these, an unlimited number of devices are supported, and a mapping can be designed that allows easy switching from physical number to logical name.
1. CAVELib
2. Fastrak (own custom driver)
3. Custom button (own device)
4. VRPN (buttons and trackers only, no valuators)
Multiple sources can be active at the same time. Some sources, notably the VRPN plugin and Fastrak sources support multiple tracking devices.
Tracker vehicle: Only one "Default Vehicle" is supplied at the moment. Immersion is parallel to the default DIVE vehicles (keyboard and mouse). Operation with any of these is not guaranteed, but keyboard works within the Spelunk menu system. Default vehicle supports customisble controls for speed, direction of movement, toggle or absolute motion, ray selection and selection method.
No target based locomotion is supported within immersion sub-system, but this would not be hard to add based upon similar functionality that is available in the desktop clients.
Avatar: The avatar system animates the avatar depending on the complete set of tracking information available. An avatar is automatically loaded by all diva processes, and it isn't necessary to explicitly load one within the immersive code. However, of all the avatars available, only a few are actually compatiable because of their structure. When diva loads an avatar, it automatically places in the scene-graph. Avatars are actually just .vr files and can include .wrl files just as normals.
The avatar system is thus just responsible for animating the objects within the avatar hierarchy in the scene graph.

Config

Basic Configuration

Because of the dependency on CAVElib and Performer, DIVE/Spelunk is a separate binary from the standard desktop DIVE. You should receive a binary distribution which unpacks with a directory such as:

somedir/dive3.3x5/bin/mips-sgi-irix6.5cavelib/appl

This is where the executables (diva, diveserver, etc...) live. You may also have a desktop version under such a directory:

somedir/dive3.3x5/bin/mips-sgi-irix6.5/appl

You might add that directory to you PATH variable. E.G. I have the following in my .tcshrc file:

setenv PATH  /cs/research/vr/dive/starship/dive/dive3.3x6/bin/mips-sgi-irix6.5/appl:${PATH}

If you haven't already, then you must set an environment variable DIVEPATH, which points to a shared directory containing configuration files. E.G. I have the following in my .tcshrc file:

setenv DIVEPATH /cs/research/vr/dive/starship/dive/dive3.3x5/data

DIVE can be then started with a command line such as:

diva -init spelunk_init.tcl -conf ${DIVEPATH}/spelunk_config -body body_cave_blockie.vr

You might want to create an alias for doing this. Several of the UCL demo worlds have examples of centralising scripts for passing configuration to programs.

The main options are:

-init spelunk_init.tcl

This specifies that diva should start up with a desktop menu system on the console which you can use to configure the system, change options and even edit the world.

-conf ${DIVEPATH}/spelunk_config

This tells diva to load spelunk_config into the configuration system. This is in addition to the default configuration from ${DIVEPATH}/.dive_configure. If you do not have spelunk_config in your distribution (it was missed from a couple), then download it here.

-body body_cave_blockie.vr

This tells diva that you want to use a specific avatar that was designed for the cave. If you are using a HMD, you should use

 -body body_imm_blockie.vr

instead, so that you can see your own avatar.

As you build DIVE worlds, you will probably want to customise the latter two of those options, the configuration and the avatar.

Spelunk Menus

The desktop UI that is created supports most of the functionality you will want to change regularly. The UI is designed for editing and control purposes, so that most of the time you will not need to shut down diva when making changes or changing options. Indeed since the menu system and world animation are based on DIVE/Tcl, you can even dynamically the behaviour of both at run time.

The lower part of the pane has a keyboard entry widget. If you place the mouse over this region, you can force the user to move around to rectify problems or help them along. We also commonly attach application triggers to keyboard events, so the supervisor can activate phases of the virtual experience (of course you are free to script these however you like in Tcl).

Most common immersive interaction options are on the menu Navigate where you can disable CAVElib, and change the movement mode from planar to flying, and from direction of look to direction of point. You can also scale up and down the velocity, or move the user to fixed positions in the world.

Avatar

When the avatar plugin starts up, it must identify objects by their name, so it is important that avatars respect certain naming convention. Two avatar plugins are built-in, default and virman.

Default animates just three parts, the head, the hand and the body. These are located simply by finding objects called "head", "right_hand", and "body". The body object is optionally rotated in yaw only to lie under the direction of the head. The head, hand (if it exists) and body need to lie as direct children of the top objects of the avatar definition. body_newimm_blockie.vr and body_cave_blockie.vr are examples of these avatars. The relevant config variables are:

### Default tracker body plugin 
default_body_on 0                 # Tracker default body starts enabled
default_body_type head_slaved     # Animated body types (none|head_slaved)

For the default avatar plugin, it doesn't actually matter whether the tracked limb is left or right handed, since there are no connecting joints.

The virman plugin supports three modes, left, right and two-handed. It animates the right arm to provide connection between a shoulder and the relevant arm. It uses a simple kinematic connection where the elbow position is minimised. The upper and lower arm joints must be the same length. The body is rotated under the head, and is also scaled so that the neck connects to the head.

### Virman tracker body plugin
virman_body_on  0                   # Tracker virman body starts enabled
virman_body_type virman_righthand   # Animated body types 
				    # (none|virman_righthand|
				    #  virman_lefthand|virman_bothhand)

All the moving joints needs to be direct children of the top object. Examples are body_newimm_virman.vr, body_cave_virman_twohand.vr, etc... If you have no tracking capability you can see how a similar process works coded in Tcl, not C++, in body_imm_virman.vr. The plugin versions are much faster since they can be synchronised to the frame rate, unlike the Tcl versions.

In general vehicles send events (called interaction signals) when locomotion, selection and manipulation occur. The default avatar system (see below) customises avatars to give the user's avatar a default wand that indicates interaction events, by drawing lines or arrows that indicate the direction or target of the interaction

Advanced Configuration

The tracking and IPT support sub-system requires a whole range of configuration. In DIVE default configuration is supplied by the .dive_configure file, and on the command line you can specify a file to over-ride configuration. In this section we highlight the meanings of individual lines in the .dive_configure (in bold) and explain their effect, the range of choices and some obvious choices for immersive systems.

##########################################################################
# Tracker input section
##########################################################################

### Tracker core
tracker_on        0

This line, simply turns on the tracking/immersive sub-system. In the example spelunk_config this is just set to one

tracker_ratelimit 100 # How frequently (in ms) tracker data is sent to the network

This is an experimental option that sets a minimum time to wait before sending tracking data to the network. In collaborative systems, the limiting network bottleneck is usually packet receive.

###  Default tracker vehicle
default_vhcl_on      0     # Tracker default vehicle starts enabled
move_dir            look   # Tracker Vehicle Move Direction (point/look/aim/torso)
move_mode          planar  # Tracker Vehicle Move Mode (flying/planar/superman)
use_joystick         1     # Use Joystick if available
joystick_deadzone    0.05  # Joytick dead zone (symetrical)
joystick_anglescale -0.7   # Scale the joystick value for rotation rate
joystick_dirscale    1     # Scale for speed (multiplied by vehicle_speed as well)

This set of options are self-explanatory. Note that the deadzone might need to be much bigger if you have a system with a force based joystick they generally do not centre well.

use_wand             1     # Use the wand and add one if one does not exist under avatar

The wand is an object added to the hand of the avatar. The wand (actually new_wand.vr in $DIVEPATH directory) is usually used as an interaction feedback device. If you want to replace the wand, either edit new_wand.vr, or add an object called "wand" into you avatar - the vehicle will not add a 2nd wand.

use_distr_velocity   0     # Use velocity OR absolute rotation and translation

This affects network behaviour. Using velocity is better on low-loss networks since it generates smoother animations on the receiving side. However in the presence of loss, you will see the avatar fly off into the distance. If this starts occuring, then switch to the absolute mode. This actually generates more network packets, but looks better when loss occurs.

tracked_tags  RIGHTHAND HEAD # Tags of objects to track

The tracker vehicle must know the complete collection of tags that are tracked. The following logical names map to the joint names:

LEFTHAND left_hand
RIGHTHAND right_hand
HEAD head
LEFTFOOT left_foot
RIGHTFOOT right_foot
TORSO torso
LOWERBACK lowerback
RIGHTEYE right_eye
LEFTEYE left_eye
OTHER1 other1
OTHER2 other2
OTHER3 other3
OTHER4 other4
OTHER5 other5
OTHER6 other6
OTHER7 other7
OTHER8 other8
oTHER9 other9
OTHER10 other10
OTHER11 other11
OTHER12 other12
OTHER13 other13
OTHER14 other14
OTHER15 other15
OTHER16 other16
OTHER17 other17
OTHER18 other18
OTHER19 other19
OTHER20 other20
OTHER21 other21
OTHER22 other22
OTHER23 other23
OTHER24 other24
OTHER25 other25
OTHER26 other26
OTHER27 other27
OTHER28 other28
OTHER29 other29
OTHER30 other30
OTHER31 other31
OTHER32 other32

Avatar plugins will always animate these limbs if they are tracked. Tracker sources also need to define which logical tags they read and support. Each source plugin does this differently. CAVElib always tracks HEAD and RIGHTHAND. Fastrak allows you to specify it in the config file. VRPN specifies it in its own configuration file.

### CAVElib tracker plugin
cavelib_on      1  # CAVElib vehicle starts enabled
cavelib_button_tags GRASP_BUTTON SELECT_BUTTON SPEEDUP_BUTTON SPEEDDOWN_BUTTON # Order in which the buttons are returned by the buttonserver

You need to turn CAVElib on! The button tag list is presented in logical order. You can use this to switch buttons affect which behaviours. You might want disable some if a joystick is available. If one isn;t, then you will need the logical buttons FORWARD_BUTTON and possible BACKWARD_BUTTON. Plugins can extend the logical button list by using these names, or a series of GENERIC_BUTTON0, etc...

Demos

All our demos have a similar structure, with wrapper scripts that set all necessary config. Scipts have obvious names such as "run_desk" and "run_cave". "run_hmd" scripts are somewhat special in that they usually reset the graphics configuration of the screen - you should always check that these will perform the correct step. They will cause no damage to you installation, since they refer to UCL specific wrapper scripts which you will not have.

We usually centralise all configuration steps into a single file called "dive_env", which sets the particular version of DIVE required, and any binary files needed. Note we make extensive use of the facility to extend the DIVEPATH from within the configure file. This is to prevent shell variables getting too long. We also usually keep platform dependent config in configure files with obvious names such as "desk_configure" and "cave_configure".

XX to do - add downloadable packages

WhoDo Game
Pit
Village
Cubes
Womb World
Fear of Public Speaking
Paranoia Demo
your demo here

You can, of course, load practically any static VRML97 model into DIVE.

Building

If you have access to the DIVE source code, then the following notes may help you configure properly. You need to arrange with SICS to get access to the source code. You do not need the complete source code to build plugins. You should look for a "library and plugin" release. There is not an up to date version of such a release, but we can generate them here at UCL with SICS permission.

Building diva

Here is the UCL configure statement for a _desktop_ version:

/cs/research/vr/home2/starship/ucacajs/3.3x5/configure --enable-tcl=/cs/research/vr/dive/starship/build/dive_tools/n32-mips3/tcltk/irix6 --enable-audio --enable-zlib=/cs/research/vr/starship/common/vr/dive/dive_tools/n32-mips3/zlib/irix6 --enable-tts=/cs/research/vr/starship/common/vr/dive/dive_tools/n32-mips3/tts/irix6 --enable-gsm=/cs/research/vr/starship/common/vr/dive/dive_tools/n32-mips3/gsm/irix6 --enable-video --enable-sproc --enable-jpeg=/cs/research/vr/starship/common/vr/dive/dive_tools/n32-mips3/jpeg/irix6 --enable-png=/cs/research/vr/starship/common/vr/dive/dive_tools/n32-mips3/png/irix6 --enable-mips3 --enable-cxx-plugin --enable-vrpn=/cs/research/vr/starship/vr/vrpn/vrpn6.02

and here is the equivalent immersion configure statement:

Only the last two options are CAVElib specific, and they are self-explanatory. Note that since dive3.3x* (UCL numbering), we have supported C++ run-times as well as C. This is necessary for building VRPN plugin. All other options are standard options for diva. Up to date library dependencies such as Tcl/Tk, gsm, etc... can be downloaded as a binary package from UCL for Win32, Irix(n32) and Solaris platforms on request.

Writing plugins

The new immersive sub-system in 3.3x5 allows tracker source, avatar and vehicle plugins. Two examples are given that implement exactly the same functionaltiy as default behaviour, but through the plugin interface rather than within the dive libraries. These are body_virman_plugin.c, and vrpn_plugin.c. The instructions for compiling these is exactly the same as other plugins. Note that avatar and vehcile plugins have no direct dependencies on the tracker source such as VRPN or CAVElib, so have no dependencies themselves other than the DIVE libraries.

Bugs

Subjectivity support is a little flaky. The OpenGL has different bugs, and making the two coincident is extremely difficult.
DIVE background nodes with texture do not work. The VRML97 support includes the VRML97 background node, which works at UCL, but apparently does not work on someone else's build.
There is a problem in MultiTransform packing. With some network configurations, receiving side claims MT packets are mal-formed. Not a show stopper.
Latency issues. There is a problem in the SRM implementation which it seems that the immersive system triggers a lot. Buffering times can get very long. Note that buffering problems can be exacerbated by having Tcl scripts that run on every frame. Tcl scripts do not support network rate limiting. If you have an object calling on every move event of an object, you will probably flood the network. Such code should probably be moved into a custom immersive vehicle so it can use the tracker system's rate limiting system (which is a simple message modification system).

Anthony Steed, A.Steed@cs.ucl.ac.uk