The Multi-Dimensional Graphic Visualiser Design Document
Aims:
The Multi-Dimensional Graphic Visualiser was created so that it could become a part of the Core Data Mining System (CDMS). The idea of the Visualiser was to create an extendible set of classes that would enable a User to see a multi-dimensional representation of their data. It needed to allow the User to manipulate the representation so that patterns could be found. It also needed to cope with any amount and type of data that it was presented with.
Method:
Java was the programming language chosen for CDMS, and so the Visualiser is also written in Java, using the extended Java3D classes. The choice to use the pre-packaged classes was based on the assumption that Sun had probably written the classes for creating and viewing 3D constructs in the most efficient way possible, so creating my own would be "reinventing the wheel" and likely to be less efficient. Also, at the time of programming, Java3D implementations were available for Windows and Solaris platforms with the Linux version under development. It was also noted that the Java3D classes were being released with the updated versions of Java, and were therefore (theoretically) becoming more common.
Program Overview:
In the future, the CDMS core program will create an instance of a class called a GO3DVisualizer. This object will receive data in a form recognisable to CDMS and create a new object with that data, a GO3DVizPanel. This 'VizPanel' will be placed in a window by CDMS and displayed for the User automatically. The 'VizPanel' itself handles all operations on the data it displays (such as moving in 3D, changing axes types, changing sampling, etc) and does not (currently) allow outside functions (etc.) to modify it. There is no real reasoning behind this 'one-way' method of interaction implementation, and I expect that it will be altered so that it can be manipulated externally at some stage in the future.
The output of the 'VizPanel' is, for the most part, visual data. In the future it is assumed that the User will be able to select some of that data and pass it to yet another part of the CDMS, but this is not yet implemented.
Implementation details:
The inside of a 'VizPanel' is quite complex. It contains many Java3D constructs, most of which form the 'Scene Graph' which is the set of objects describing every part of everything in the virtual 3D space. A yet larger set of objects inside the 'VizPanel' deal with the buttons, panels, dialogs, etc. that make up the GUI that runs the visualiser. All these were created using the 'Swing' interface in keeping with the CDMS style. Of course, a copy of the input data values is kept in there too.
The most interesting classes inside the 'VizPanel' (at least from my point of view) were the GO3DAxis and GO3DSubObj classes. As you can tell from their names, these were also created by me and, therefore, require the most explanation.
| GO3DAxis | |
|
For future reference, I use the term "axis" (or the plural "axes") to describe a kind of transformation between a value in a kind of "data space" and a value in "representation space". For example, suppose you had height data that ranged between 1.0 meters and 4.0 meters. This data is going to be displayed on a gradated colour scale using the colour Green. A value of 2.5 meters is in "data space" and a "green colour axis" would convert this to a "representation space" value of 50% green. The axes in the visualiser pose an interesting problem because the CDMS is supposed to be flexible enough to allow a User to manipulate their data using any method they choose. Currently, the number of axes in the visualiser extends beyond just the 3 space axes (namely X, Y and Z) to another 3 separate colour axes (namely R, G and B). The visualiser could in fact cope with more than 6 axes and a User may well want a "Transparency Axis" or even a "Sound Axis". But not only do the representations of the axes change the method in which they transform data may also change. For example, some data may appear to have an undetectable pattern in its native form, but when you compare the natural log values the pattern may be quite obvious. Hence, we would expect some way of making any axis able to become a log scale. Besides, a User may not like the way I drew my axes and want them to be a funky purple and green pattern! The main problem is, that it is nigh on impossible to guess all the representations and methods every user will require. Therefore, the axis calculations and representations were abstracted away and made into a pattern that can be built on by subsequent Users. The basic axis system consists of an abstract GO3DAxis class which contains the data and methods common to all types of axes. There are two extensions of GO3DAxis, namely GO3DSpaceAxis and GO3DRGBAxis. These contain basic abilities that space and RGB-colour axes should be able to perform. Now, a "GO3DFunkySpaceAxis" class can be created from the GO3DSpaceAxis class that overwrites the method getBranch() and returns differently shaped and/or coloured axes. Or perhaps a User might create a "GO3DLogScale" interface that enables a "GO3DLogSpaceAxis" and a "GO3DLogRGBAxis". All of which can be created and added in as new axis representations. |
|
| GO3DSubObj | |
|
A similar problem occurred with the actual representation. Not everyone wants to see a simple scatter-plot of his or her data. Some people may want a histogram or a plot containing error margins, for example. The same design concept of creating a basic class and its specialities was used here too. The GO3DSubObj is a graphic object representing the data. Two implementations of which, the GO3DStarFieldPlot and the GO3DScatterPlot have been created. As with the axes, in the future the User will be able to make and use their own representations from within the CDMS. |
GUI Design:
The layout for the 'VizPanel' is quite simple: It is completely button oriented. This means that worrying about window focus and keystrokes is not needed. The 3D version of the Canvas takes up most of the space with two toolbars along the bottom and right hand edges. The bottom edge contains all the navigational controls and the right hand edge contains the other tools.
The navigation was based on the simple idea that the less buttons, the easier. A toggle switch chooses whether the User is in "Translate Mode" or "Rotate Mode". In "Translate Mode" the six directional arrows -move the object- in the direction of the arrow. In "Rotate Mode" the 6 directional arrows -rotate the object- in the direction of the arrow. Note that all navigation affects the object, not the camera position. For reasons only known to Java3D, I have been unable to find a way of making the transformations apply to the "camera" position rather than the object position.
On the other tool-bar are:
