My project is a set of 3 visualization techniques to visualize 3 dimensional data sets of 3 dimensional vectors using smart particles (sparts). I use a set of C++ libraries called OpenSteer to control the particles themselves. The user is able to "spray" these particles towards a data set, and the particles react to the data in one of three ways.

First visualization, the particles may be given a set of lower and upper bounds for each the X, Y, and Z values of the data set (or one lower/upper bound for the magnitude for each red, green and blue). The particles will then, once fired towards the data set by the user, travel until they find a data point that matches those paremeters (at each frame each particle uses a tri-linear interpolation to determine the value of the data at its current location). If a particle finds a point of data that matches one or more of its parameters it will render a polygon at that point. The polygon will be a small square on a plane perpendicular to the vector of the data at that point, centered at that point. The color of the polygon can be determined in 3 ways, choosable by the user. The first way to determine color is XYZ Component based, in thie color mapping scheme, if the threshhold of X is satisfied, a polygon has a red component, Y, a green component, and Z a blue component, thus each polygon can by one of 2^3=8 colors. The second color mapping scheme is magnitude threshhold based. In this color scheme the magnitude of the point at which a polygon is rendered is checked vs the red magnitude thresshold, green magnitude threshhold, and blue magnitude threshhold, and again, for each check that is true the polygon is givin a corresponding componenent in that color. Again this has 2^3=8 possible colors. The last color mapping scheme is a color mapping that maps the magnitude at the point rendered on a standard blue to red color map, blue being smallest, red being largest, ranging from one standard deviation below the average of the data set to one standard deviation above.

The second visualization is a flowline visualization. In this visualization the sparts will again travel until they find data that matches the parameters set by the user. Upon finding said data the spart will then set its trajectory to that of the data it has encountered. It will proceed to travel along the trajectory of the data at its current location each frame until it is no longer in data that matches its parameters. As it travels it will leave behind it a line, ranging from blue to red depending on the magnitude of the data (simple blue to red linear color map from 1 standard deviation below the average magnitude of the data set to 1 standard deviation above).

The third visualization is what I call an "explosion visualization." Again, the spart fires towards the data, looking for data that meets the user-input parameters. However, in this visualization when a spart finds data that meets its parameters it analyzes a 6 nearby points (above, below, right left, forward, backward), and for each of the adjacent points that also meets the criteria of the user, this spart spawns another spart travelling towards that point. Each spart travelling within valid data also leave behind a line which is color mapped in the same way as the color mapping for visualization 2 (according to magnitude of data at that point).

OpenSteer is (from their website)

“OpenSteer is a C++ library to help construct steering behaviors for autonomous characters in games and animation. In addition to the library, OpenSteer provides an OpenGL-based application called OpenSteerDemo which displays predefined demonstrations of steering behaviors. The user can quickly prototype, visualize, annotate and debug new steering behaviors by writing a plug-in for OpenSteerDemo.

OpenSteer provides a toolkit of steering behaviors, defined in terms of an abstract mobile agent called a "vehicle." Sample code is provided, including a simple vehicle implementation and examples of combining simple steering behaviors to produce more complex behavior. OpenSteer's classes have been designed to flexibly integrate with existing game engines by either layering or inheritance.

OpenSteerDemo's plug-in framework allows a game AI programmer to quickly prototype behaviors during game design, and to develop behaviors before the main game engine is finished. OpenSteerDemo allows the user to interactively adjust aspects of the simulation. The user can: start, stop and single step time, select the vehicle/ character/ agent of interest, adjust the camera's view and its tracking behavior.

Last modified: October 25, 2004 OpenSteer is distributed as open source software in accordance with the MIT License. OpenSteer was developed with the generous support of Sony Computer Entertainment America. OpenSteer is supported on Linux, Mac OS X and Windows.”

Compiling this program requires on os x GLUI 2.3+ to be installed on the host computer (http://glui.sourceforge.net/). To compile on on unix or linux machine unzip final_prog.tar, cd into Project/build/ and run "sh conf. sh linux", to compile this on mac from the same directory run " sh conf.sh mac", to compile this on unix run "sh conf.sh unix ". There are a number of compiler warnings, please ignore them:) To run it on any machine machine then change directories into objs_optimized (Project/linux/objs_optimized) and run "./OpenSteerDemo.elf". It is important to run this from IN the directory Project/build/objs_optimized because unfortunately paths to data etc are still relative to the working directory.

Prior to running be sure to place any .vtk data sets you wish to visualize into a directory data_files that is in the same directory as the executable

Once the program is running (to run see "Compilation/Installation" above), the user may set what criteria they want the data to meet in order for a spart to choose to render. This is done on the left by setting X, Y, and Z upper and lower threshholds (remember data that meets the X threshhold has a red component, Y green, Z blue). If the user checks "Use Magnitude Threshhold however, the other 3 component-specific threshholds are ignored (for choosing where to render, but are still considered for choosing the color to render). The user may then choose a render type, isosurface, flow lines, or explosion (render types described above). It is worth mentioning that explosion can "explode" in a very processor intensive sort of way (again, see description above for why), and that it is made to view a specific section of the data, not the entire data set. That said it has been tested on the entire data range of a 60 by 60 by 60 (6MB) data set, and did not crash, but it took a very very long time to run. On a 15 by 15 dataset there is an example under the the explosion tab showing a very slow but successful run. The last controls available to the user are clear screen, which clears the screen of all sparts and rendered visualizations, and load. The load box is fairly straight forward, double click the file you want, then press load. However, GLUI's file browser appears inconsistent about changing directories depending on the operating system it is on, so its best to put all files you would like into a directory called data_files in the same directory as the executable prior to running (this is what the load box defaults to).

To rotate the camera either right-click and drag, or control-left-click and drag depending on operating system (usually Mac is right click, linux/unix is control-left-click). A function allowing the user to follow a given spart is also implemented, but currently this makes the camera have issues when that spart dies or takes to sharp a turn, thus it is currently disables

Keyboard Shortcuts

• r: reset the demo.
• f: changes the frame-rate rules (fixed-framerate 24fps can help explosion stay slightly calmer.
• f1: same as clicking (fires spart towards mouse).
• f2: destroys random spart (should no longer ever be needed, but in the off chance a spart escapes death when it should die this can be useful).
• ?: Shows keyboard commands in terminal.

To make this concept actually useful in a practical way would require a couple of key changes. One way I could see this being useful is using "explosion" or "polygon" rendering to help find a part of an MRI that meets a certain set of criteria, and get a good visualization of that portion in 3d. The white matter tracts we rendered in Program 1 would be much easier to "seed" and follow by just firing sparts until an explosion reaction started and followed the white matter tract it found. The only significant change required here would be to write a data-reader for MRI file types. Though how many paramters an MRI has may also be more or less than 3. However, other than flowine rendering this program should generalize to n-dimensional data fairly trivially. Flowline visualization may have practical applications as well, but I'm not sure. Certainly it allows an easy way to understand the flowlines in the data set, watching the sparts travel around the set, and viewing the color mapped trails they live gives a fairly intuitive way to view the vectors in the data set.

• A few memory leaks are still present if the App runs a long time
• File browser cannot always change directories