Last updated: Feb 12th '98 by Juha Vesanto

Self-Organizing Map in Virtual Light

The Self-Organizing Map (SOM) is an unsupervised neural network method, specifically suited for data mining purposes because of its visualization capabilities. The purpose of this project is to take a look at the possibilities that Virtual Reality offers for the visualization of the Self-Organizing Map.

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:

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

Document contents:
Longer introduction to the project
Goals and methods
Overview of the current implementation

What is Self-Organizing Map?
VRML 2.0 specification
SOM Toolbox for Matlab computing environment
CosmoPlayer or some other VRML 2.0 compliant browser is required to view the worlds
Questions? Comments? Juha Vesanto is there answer them (when he has time)


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, thus, be used for data mining purposes in the case where there are large amounts of numerical measurement data.

One of the advantages of the SOM is that it is a highly visual method. When the model vectors are organized on a 2D grid, the SOM can be efficiently visualized using methods like component planes view and the unified distance matrix (u-matrix). Typically the visualization is done using colour images in 2D.

Virtual Reality, or more specifically VRML version 2.0, offers powerful and easily useable methods for visualizing 3D objects and scenes. While 2D visualization is adequate in most cases, offers full 3D space even more possibilities. 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 using Virtual Reality.

This project is initially performed as a course exercise for the Virtual Reality course in the Helsinki University of Technology. If the results are encouraging the project will be continued as part of the ENTIRE project in the Laboratory of Computer and Information Science. The aim then would be development of a specialized data-mining environment for the utilization and visualization of Self-Organizing Maps.

Goals and methods


The Laboratory of Computer and Information Science has recently published a free Matlab function library, SOM Toolbox, which implements the SOM algorithm in Matlab. In this project the Toolbox is used to train the maps, and VRML models are used to visualize them. Thus, the actual end product of the project at this stage is to implement a Matlab function (ie. som2vrml.m) which exports the trained map to a VRML model. A VRML browser is then used to visualize the map.

Note: only maps with 2D grid are considered. In practice most maps are of this kind, so effectively it is not a very big limitation.


The initial goal will be to investigate different kinds of 3D visualization methods regarding component planes. There are a number of VRML 2.0 geometries that cab be utilized for this purpose: ElevationGrid, IndexedFaceSet, IndexedLineSet and Cylinders/Extrusions. Using Indexed(Face/Line)Set visualization of the Sammon's (or some other) projection is also feasible.

To be sufficiently informative, the component plane figures must be accompanied by all kinds of information bits:


Real value of VRML will become apparent when some interactivity is added to the model. For example:

After the basic visualization is ready and easy to use, the VRML model might be extended to a full-blown data-mining system using java scripts to perform calculations. This would remove the need to calculate everything beforehand.

Special project features

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' 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. Scripts were done using the VrmlScript language.



The SOM visualization in VRML 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.



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: