2.1 Visualization Environment
The current implementation runs on a Silicon Graphics Indigo2 workstation equipped with Impact graphics hardware. All of the data visualization code is implemented using Open Inventor, the defacto object oriented graphics tool kit written in C++ and based on the Open GL standard. Open Inventor supports objects such as three dimensional text, polyhedra, triangle strips, quad meshes, Bezier patches, and Non-Uniform Rational B-Splines (NURBS). Inventor also supports control objects such as engines and sensors that control and detect changes in the geometry of the simulation. Unlike GEOMVIEW Inventor does not inherently use UNIX pipes (although it could if it was desirable). It is possible to compile the simulation code into the same executable file as the graphical code. This eliminates the communication overhead of using UNIX pipes to transfer data since both the simulation and the graphics code share the same memory area.
Originally written in FORTRAN, the simulation was converted into C by Dr. Subramanian, and later converted into C++. The user selects a data file and the entire simulation is run at the time of the selection. The output data of the simulation is stored in an abstract data structure for later use. This offers two main advantages over the old GEOMVIEW implementation. The visualization in tandem with each time step of the simulation (1) does not dominate the computation and slow down the visualization, and (2) the storage structure makes both forward and backward traversal of the time sequence possible on demand, an extremely important and necessary capability for analysis.
All of the user interaction with the program is done through the implementation of an OSF Motif style application interface. Motif is an abstraction of the X intrinsics toolkit, which is an abstraction of the Xlib standard developed at the Massachusetts Institute of Technology. Motif uses "widgets" to develop an application interface. These widgets are objects that implement commonly used interface elements such as buttons, text boxes, and even some very high level elements such as file selection dialog boxes. It is through the use of these widgets that the user is given some degree of freedom with the viewing environment.
Each cell population is represented by three, 3-dimensional grids with dynamic z values and constant x and y values that form a 10 x 10 grid. The three grids are located at the same x and y coordinates in space and are separated only by their z axis values as indicated in figure 1. The top grid is the threshold grid representing the threshold levels in mV of the individual members of the population. The middle grid is the potential grid representing the potential levels in mV of the individual members of the population. And the bottom grid is the spike grid with Boolean z values indicating whether or not the potential has exceeded the threshold for each individual cell. Visually, as the potential and threshold surfaces rise and fall, the spike surface will remain at rest until the potential surpasses the threshold. At this point the corresponding area on the spike will "fire" or increase its z value (thus representing a neuron firing) as shown in figure 2.
![]()
Figure 1 -- Position of the Three Meshes in Space -- Threshold,
Potential, and Spike from Top to Bottom
Each fiber population is represented only by the spike surface. Its z values are Boolean as well; and they are driven straight from the results of the numerical simulation.
For all twenty-two populations, the performance has been at best approximately seven to ten time steps PER SECOND!. This is at worst an approximate one hundred times increase over the performance offered by the GEOMVIEW implementation.
![]()
Figure 2 -- Meshes in Action -- Firing of the Spike Mesh
2.2 Open Inventor Architecture
Open Inventor is an object oriented toolkit used to build interactive 2D and 3D graphics applications. Open Inventor is based on the Open GL standard. This allows it to take advantage of powerful graphics hardware while allowing the developer to remain at a very high level during the development process. Inventor allows the programmer to quickly develop powerful and flexible graphics applications with very good performance. Refer to figure 3 for a representation of each of the following descriptions.
2.2.2 Nodes
The nodes in a scenegraph can represent a color, shape, transformation, or other change to be inherited by subsequent nodes in the database. The most basic classes of database nodes are:
shape nodes (for example, spheres, lines, triangle strips, or meshes)
property nodes (for example, material, lighting, and other environment variables)
group nodes (used to group related areas of a scenegraph and allows for local changes to the graph that will not propogate to subsequent nodes)
2.2.1 Scene Databases
Inventor creates windowing system independent 3D object representations by building scene databases. Scene databases are collections of nodes, the basic building blocks of Inventor applications. Each node holds some type of information present in the database such as an environment variable or a geometric shape. A scenegraph is an ordered collection of nodes and is stored in the Inventor database. Inventor monitors and manages one or more scenegraphs in its database.
2.2.3 Scene Graphs
Inventor focuses on the creation of objects not drawings. The descriptive information about the objects is stored in the scene database. A collection of objects is known as a scenegraph. The most common use of a scene database and graph is to render images on the screen. The underlying structure of a scene graph and a database allows objects to be added, removed, and manipulated simply by operating on the scene graph. Inventor was designed to make these operations simple and efficient.
2.2.4 Node Kits
Node kits are collections of nodes that are useful together. They supply commonly needed nodes for the representation of an object in a scenegraph. For example, a node kit may contain a geometric transformation, separator, material property, and shape node all packaged together in one object. Unwanted objects are simple turned off without losing any efficiency.
2.2.5 Manipulators
Manipulators are special scene database nodes that respond to events in an application. They are typically used to detect user generated events and respond to them by changing some part of the scene database. A developer gains extensive control over the behavior of an application by incorporating custom modules into the manipulators. Common manipulators are handle boxes that can be highlighted when an object is picked, and dragged by the user to change the position of the object.
2.2.6 Component Library
The Inventor Component Library provides windowing system specific support for an Inventor application. It supplies an extended Open GL style rendering area, an event checking main loop, and an event translating utility. It also supplies some higher level tools for developing Inventor user interfaces such as editors and viewers. Editors provide an easy way to edit material nodes. Viewers supply a render area with some user control widgets such as buttons and dials that are predefined to execute commonly desired application control actions. They can also be subclassed to override the predefined behavior and fully customize the application.
![]()
Figure 3 -- Open Inventor Architecture
Back to the Table of Contents
Next Section ->