Virtual Reality Course - Exercise Document

Tik-111.400 Keinotodellisuus (3 ov) L
Juha Vesanto


The purpose of this project was to take a look at the possibilities that virtual reality (specifically in this case VRML) offers for the visualization of the Self-Organizing Map.

The Self-Organizing Map (SOM) is an unsupervised neural network method. It constitutes of an organized set of model vectors that during the training organize themselves so as to represent the distribution and topology of the training data. It can be used for data mining purposes in the case where there are large amounts of numerical measurement data.

VRML 2.0 offers powerful and easily useable methods for visualizing 3D objects and scenes. What's more, VRML 2.0 enables the user to interact with the visualization (or more appropriately with the VRML model). It is probably the possibility of interaction that will be the biggest benefit of visualization in virtual reality.

Goals and methods

The actual goal of the project work was to implement a Matlab function (ie. som2vrml.m) which exports a self-organizing map to a VRML model. A VRML browser is then used to view the model.

Owning to the fact that the goal was not to make a single VRML model of an object or environment, but a general-purpose tool for creating such model of any given map, there were three important special features in the project:

  1. A VRML builder could not be utilized. Instead, all code had to be written by hand (ultimately of course by the som2vrml.m function).
  2. Because wide applicability was the goal, the visual appeal is the result of 'looks tolerable for all maps' rather than 'looks really good for one type of map'.
  3. Prototypes and scripts were heavily utilized.

Silicon Graphics' CosmoPlayer 1.0.2 (for IRIX) and 2.0 (for Windows95) were used as testing platforms. Version 1.0.2 because the development platform was IRIX and 2.0 because of it being more advanced (in principle, anyway). Scripts were done using the VrmlScript language.



The model consists of the following objects:

Many of the objects were realized as prototypes. Implemented prototypes include a box with a label on one side, a selection button (on/off), a push button (returns automatically to off state), scalebox which acts both as axis indicator and colormap and the various height field components.

Height fields

There were several different possibilities for implementing the 3D visualization.

Elevation grid
Easy to use, but only rectangular grid was possible.
Clearly the most flexible of the possibilities, though the hexagonal grid does not always look very nice. An additional benefit is that this allows the visualization of projections of maps: the unit coordinates need not be fixed on a regular grid.
Implemented as a prototype, but not utilized by som2vrml function. Might be useful for 3D presentation. Colors didn't work properly.
Cylinders and flakes (thin boxes floating on air)
Implemented using Extrusions. Problem with these was that they produced a huge number of objects so that presentation on the Indy workstation took quite too long.

User interface

There is some simple interaction in the model. The height field can be rotated by grapping and dragging (SphereSensor). The component planes can be moved by grapping and dragging from the white transfer button (PlaneSensor). The component shown in the 3D visualization can be selected by touching the corresponding 2D component plane (TouchSensor).

In the 3D height field there are four controlling buttons (TouchSensor). Three of these buttons control the visibility of the slicing planes, the position of which is controlled by the axis indicators (TouchSensor). The fourth button returns the height field to base rotation position.

The axis indicators / colormaps (prototype ScaleBox) are interactive, too. There is a TouchSensor which detects when the pointing device is on the axis. The value corresponding to the position is shown.

There are three different Viewpoints that can be used for navigation purposes.


As a case data, a small data set having properties of different animals was utilized. The animals were different types of birds (duck, eagle), predators (fox, cat, lion) and some larger herbivores (horse, cow) and the features were: 'small', 'medium', 'large', 'two legs', 'four legs', 'hair', 'hooves', 'mane', 'feathers', 'hunts', 'runs', 'flies' and 'swims'. The features were binary.

Several different mappings were done with the data. (The base URL for the files below is

Map size Lattice Height field mode file
10 x 10 rectangular ElevationGrid som_eg.wrl
10 x 5 hexagonal IndexedFaceSet so_ifs.wrl
5 x 10 hexagonal Cylinder som_cyl.wrl
10 x 7 rectangular Flakes som_flake.wrl
10 x 10 rectangular IndexedFaceSet, with unit coordinates from a 3D projection som_proj.wrl



Overall the project was both educating and useful. Most of the initial goals were reached - but not all. There were a number of difficulities along the way and the structure of the VRML model had to be reconsidered several times.

One of the most annoying problems was that code which worked all right with CosmoPlayer 1.0.2, caused CosmoPlayer 2.0 to fail with segmentation violation or some other fatal error. Especially this happened often when the Scripts in the prototypes became too long. Possibly it had something to do with directOutput mode, but the errors weren't really that consistent. Initially the structure depended heavily on scripts (especially 'initialize' functions), but due to the problems with CP2.0, much of the flexibility of the prototypes had to be sacrificed.

Also some things of VRML 2.0 specification were not properly implemented in the CP2.0. For example PixelTexture didn't work properly at all (a bug report has been submitted to SGI). Some features were equally strange in CP1.0.2 and CP2.0: when implementing hexagon with Extrusion node, the coordinates in z-direction had to be scaled by 1.25.

There were also problems inherent to the structure of the VRML itself. As the maps encompassed considerable amounts of data, the initial idea was to have a data node from which the visualization nodes could have requested data. This way the data would only have had to be inserted to the file once.

However, this proved to the very cumbersome (not to mention the problems with the scripts) as there are no function calls in VRML: each request route would have had to be implemented (routed) separately. Another way would have been to share data fields between nodes, but unfortunately only Nodes can be USEd in this way.

A small, but annoying problem has to do with VrmlScript. As its string handling (specifically float to string) functions are a bit limited, the values written by ScaleBox prototype had to be first multiplied, rounded to requested precision, and finally divided back to the original scale. This operation sometimes fails with the results of writing e.g. 3.450000000000005 instead of 3.45.

Further development

Although the models now work adequately, there is a lot that should be refined. For example, to be really useful, the 3D presentation mode (cylinder, flake, indexed face set, indexed line set) should be selectable online - not as separate files.

Other future developments would include:

Juha Vesanto
Last modified: Thu Nov 2 13:09:28 EET 2000