Virtual Windtunnel
Steve Bryson
MRJ Inc./NASA Ames Research Center
Sandy Johan
NASA Ames Research Center
Leslie Schlecht
MRJ Inc./NASA Ames Research Center
Abstract
This paper describes the software framework for the vir-tual windtunnel, a virtual reality-based, near-real-time inter-active system for scientific visualization. This frameworkmeets the requirements of extensibility, interactive perfor-mance, and interface independence. Creating a frameworkwhich meets all of these requirements presented a majorchallenge. We describe this framework’s object-orientedstructure and process architecture, including interprocesscommunications and control. Device independence of boththe command and display structures are developed, provid-ing the ability to use a wide variety of interface hardwareoptions. The resulting framework supports a high-perfor-mance visualization environment which can be easilyextended to new capabilities as desired.
1 Introduction
The virtual windtunnel is the application of virtual real-ity interface techniques to the visualization of the results ofcomputational fluid dynamics (CFD) simulations. Simulta-neously meeting the requirements of general-purpose fluidflow visualization and virtual reality has proven to be verychallenging. Issues of extensibility, scaling of code complex-ity, configuration of the environment at run-time, and speci-fied computation rates and response times all had to beaddressed. These issues often result in conflicting require-ments. The software frameworks that provide solutions tothese problems are the subject of this paper. While thesestructures are designed for scientific visualization, they canalso be used for other computationally intensive near-real-time interactive applications.
Several early prototypes of the virtual windtunnel [1][2]were developed which had very limited visualization capa-bility. These prototypes proved the concept of virtual-reality-based visualization of simulated fluid flow, and demon-strated the advantages of three-dimensional display andinteraction provided by virtual reality. Particle integrationvisualization techniques were implemented in both single-
workstation and distributed modes of operation. Interactionwas built around the VPL Dataglove Model II and displayaround the FakeSpace Labs BOOM family of displays. Theproblems addressed by these prototypes included time-vary-ing visualization, manipulation techniques, and collaborativeoperation though shared distributed environments. Becausethese prototypes were dedicated to a single class of visual-ization techniques, they were very limited in their scope.
Two fundamental weaknesses in these prototypes wereidentified: lack of versatility in terms of visualizationoptions, and the requirement of the researcher to use a partic-ular interaction hardware. Both of these weaknesses areaddressed in the version of the virtual windtunnel describedin this paper. Versatility in terms of visualization techniqueswas addressed by implementing an object-oriented structurethat made it easy to add both new visualization capabilitiesand new visualization and environment control tools. Visual-ization and interface techniques that have been implementedusing this framework are described in [3] and [4]. The lackof versatility in terms of interface hardware options wasaddressed through the implementation of a structure thatabstracts interaction and display to a layer to which it is easyto add new hardware options. Both of these types of versatil-ity have been demonstrated by the rapid implementation ofnew features by individuals with no prior knowledge of thevirtual windtunnel.
The current version of the virtual windtunnel is imple-mented in C++ on Silicon Graphics platforms and supports avariety of visualization techniques and interface hardwareconfigurations. The virtual windtunnel has been released forevaluation purposes to two sites: NASA Langley ResearchCenter and NASA Goddard Space Flight Center. Theresponse has been enthusiastic and the virtual windtunnelhas been used by CFD researchers to investigate their simu-lations. Several further evaluation releases are scheduled forearly 1996, with a public release expected in mid to late1996.
This paper describes the underlying framework of thevirtual windtunnel. In the next section several requirements
1
for the virtual windtunnel are outlined. Section 3 brieflydescribes related work. In section 4 the object structure ofthe virtual windtunnel framework is motivated anddescribed. Section 5 describes the run-time software processstructure, with particular attention being paid to process con-trol. Section 6 presents the structure that simplifies the addi-tion of commands to the virtual windtunnel in a way that isindependent of the source of that command. Section 7describes thedevice structure, that implements interfacehardware devices in a “plug and play” modular manner. Weclose with a summary of accomplishments in section 8.
2 Requirements for the Virtual Windtunnel
The virtual windtunnel is at the intersection of twohighly demanding applications of computer graphics: near-real-time interactive virtual environment systems and time-varying fluid flow visualization. In this section we outlinethe requirements of the underlying software frameworkdescribed in this paper. Due to space limitations we do notaddress requirements of fluid flow visualization [5] or thevirtual reality interface [3] beyond those relevant to this soft-ware framework. For these additional requirements we referthe reader to the above references.
2.1 Requirements of Computational Fluid DynamicsVisualization
The numerical data resulting from CFD simulations aretypically vector and scalar fields in three-dimensional spacethat change over time. Time-varying datasets are providedon computational grids, with the time evolution of the databeing encoded as a series of data files. Thus there is a dis-crete sense of time built into the data. A given visualizationtask can involve the simultaneous examination of severaldata fields, such as pressure, density and velocity.
Fluid flow visualization typically involves the two-stageprocess shown in Fig. 1. Data (usually a precomputed file ondisk) is processed into visualization geometry calledextractswhich are displayed using three-dimensional com-puter graphics. Extracts are specified by user input. Whilesome extracts such as arrows for a vector field involve littlecomputation, others can involve significant computation.Isosurfaces, for example, involve interpolating values on thecomputational grid to compute surfaces reflecting a valuespecified by the user. Streamlines involve the integration of avector field starting from a point in space specified by theuser. Once the extracts are computed they may be displayedwith a variety of user options. In a complex flow simulationseveral visualization extracts may be required to exhibitinteresting phenomena, as shown in Fig. 2.
Computationally Intensive
DataExtractRenderedImagesUser InputFig. 1The visualization process: data is processedto produce visualization extracts, that are renderedon the computer screen.
Fig. 2An example of a complex visualization envi-ronment, showing streamlines, isosurfaces and cut-ting planes displaying the velocity vector field anddensity scalar field around a harrier aircraft in hover[6].
2.2 Requirements of Virtual Reality
Virtual reality (sometimes referred to as virtual environ-ments) is the use of various computer technologies includinggraphics, computation and interfaces to produce the effect ofa three-dimensional computer-generated environment. Thiseffect is attained primarily through the use of a head-trackeddisplay system. In the virtual environment objects have astrong sense of a location in three-dimensional space relativeto the user, which we callobjectspatial presence,or simplyspatial presence. Spatial presence provides enhanced percep-tion of three-dimensional spatial structure as well as theenhanced ability to directly manipulate objects in threedimensions. These three-dimensional capabilities combineto make the exploration of complex three-dimensional struc-tures significantly easier and faster than conventional visual-ization systems [5].
2
One of the lessons learned from the virtual windtunnelprototypes described in section 1 is that near-real-time three-dimensional interaction is the primary advantage of a virtualreality interface. Virtual reality interfaces require high per-formance in terms of high frame rates and low delaysbetween user input and system response. The specificrequirements will depend on the application. For applica-tions in which interactive objects do not move except whenmanipulated by the user, experience has shown that a mini-mum frame rates of 10 frames per second and maximumlatency of 0.1 seconds is tolerable. At lower frame rates, thevirtual reality effect of object spatial presence is lost. Athigher latencies user control of the environment becomessignificantly impaired [7]. When interactive objects them-selves move in the virtual environment, higher frame ratesand lower latencies are required [8].
The computation of visualization extracts easily satu-rates this 10 frames per second time constraint, even whenthe resulting visualizations can be displayed at 10 frames persecond. For this reason the virtual windtunnel separates thecomputation and rendering of the visualization extracts intotwo asynchronous processes. This introduces two framerates into the virtual windtunnel: thegraphics frame rateand thecomputation frame rate. The graphics frame ratesupports the virtual reality effect of spatial presence and theresulting interactivity. The computation frame rate producesnew geometry either in response to a change in data or thechange in the location of a visualization.
Experience has shown that the computational frame rateand latency requirements are somewhat more relaxed thanthose for the graphics. Latency in the response of a visualiza-tion to user motion can be as much as 0.2 to 0.3 seconds andstill be useful, though longer latencies significantly impairthe usefulness of the direct manipulation capability. Thecomputation frame rate can be as low as 5 frames per secondand still by useful so long as the 10 frames per second graph-ics animation rate is maintained.
As mentioned above, low frame rates impair the abilityto directly manipulate objects in the environment. This isparticularly true if the objects to be manipulated are moving.When the data varies with time the visualizations will ingeneral be moving, updated at the computation frame rate.Because these moving visualizations would be difficult tomanipulate, one of the design decisions of the virtual wind-tunnel is that user interaction be via tools that are stationaryexcept when they are moved by the user. These tools are pri-marily graphics objects and so update at the graphics framerate, providing fast user manipulation feedback. These tools,described in section 4.1, are easier to manipulate and controlthan the visualizations.2.3 User-Driven Requirements
There are several higher level requirements that a gen-
eral purpose visualization system must meet in order to beuseful to the scientific visualization community.
•Extensibility: The visualization environment shouldbe extensible in order to accommodate new visualiza-tion and interaction techniques. This extensibilityshould, whenever possible, be consistent with existingvisualization and interaction techniques. As we willdiscuss throughout this paper, this extensibility iscomplicated by the complex list management, processcommunication, and user interaction logic structuresin the virtual windtunnel. One of the primary motiva-tions for the virtual windtunnel object structure is tohide these complications in high levels of the objecthierarchy. In this way programmers can add newobjects by following a template without having tounderstand the entire virtual windtunnel structure.• Versatility: The user must be able to configure theenvironment at run-time, adding or deleting visualiza-tion and control objects at will. In addition, the usermust be allowed to access any portion of the data set,at any timestep and control the flow of data timesteps.•Cooperative visualization: The fluid flow community,like any scientific community, operates by coopera-tive investigation of phenomena. Thus a flow visual-ization system should support shared, cooperativevisualization. This requirement is met in the virtualwindtunnel either through a shared distributed envi-ronment option, or through displays options whichallow several viewers at once.
•User acceptance: Flow researchers will use a systemwhen the difficulties and training investment are out-weighed by the advantages of the visualization sys-tem. To reduce the burden of use, the system shouldrun with a variety of interface options, to match theuser’s needs, available hardware, and budget.2.4 The Requirements of Direct Manipulation
Direct manipulation in the virtual windtunnel is throughabstract static gestures (sometimes called poses) at a positionand orientation in space determined by the tracking device.These gestures may be the result of button pushes or gesturerecognition based on a glove device. There are three staticgestures defined in the virtual windtunnel:grab,point, andnull. The action of each gesture is dependent on the contextin which the gesture is made [4].
Direct manipulation is based on mapping data at a posi-tion in space, usually the position of the user’s hand or arrowpointer, to an action in the virtual environment. This positionand orientation data must be mapped to visualizations in
3
order to specify their extracts. Visualizations that are speci-fied using data at a point in space are calledlocal visualiza-tions. For visualization techniques such as vectors,streamlines, and cutting planes this is straightforward. Isos-urfaces, however, are usually specified by value, without aspatial manipulation metaphor. For the virtual windtunnel,the concept of local isosurface was developed [9]. This isos-urface is specified by sampling the value of a scalar field at apoint in space and constructing the isosurface around thatpoint. Using local isosurfaces the user can interactivelyexplore the geometry of the scalar field.
While we anticipate implementing non-local visualiza-tions such as conventional isosurfaces in the future, whichwe shall callglobal visualizations, at this time all visualiza-tions in the virtual windtunnel are local. We expect the addi-tion of global visualizations to the virtual windtunnel to fit inwell within the framework described in this paper. For theremainder of this paper, whenever we say “visualization”,we mean “local visualization”.
3 Related Work
Scientific visualization systems fall into roughly twoclasses: modular data-flow systems such as AVS [10] anddedicated visualization systems such as FAST [11]. The vir-tual windtunnel falls into the class of dedicated visualizationsystems.
Data flow systems allow the user to reconfigure visual-ization capabilities through the use of modules that act onthe data. These modules typically transform the entiredataset, compute extract geometry, or render that geometry.Virtual reality interfaces have been implemented for render-ing modules on these systems by some individuals, but thisadditional virtual reality capability only allows non-interac-tive viewing of the visualization results. Because data flowsystems transform the entire data set, they are not well suitedto the near-real-time visualization of time-varying databecause of the very large amounts of data involved (thoughthis issue is being addressed in more recent versions of dataflow). For this reason, the data flow approach was not usedin the virtual windtunnel.
There have been many scientific visualization systemsproduced that are designed for work in a particular scientificdiscipline. Many software architectures have been imple-mented in these systems, ranging from single process batch-based to distributed multi-platform visualization environ-ments. Those systems that were designed for easy extensibil-ity, however, were not designed for performance, while thosedesigned for performance were programmed for a particularscientific problem rather than as a flexible system that can beused for a wide array of problems. The prototype virtualwindtunnel systems were in this latter class. None of theframeworks of these systems served as a useful starting pointfor the production virtual windtunnel framework. Some of
these dedicated systems have been implemented with aninteractive virtual reality interface, such as those developedat the University of North Carolina [12][13], and particularlywith the CAVE environment [14].
A system which has many of the features described inthis paper was developed at Brown University [15]. Thissystem is based on an interpreted, object oriented, multipro-cessing system developed at Brown. While this systemmeets the extensibility requirements described in this paper,it does not have the required performance due to its inter-preted nature.
Several virtual reality systems have been developed[13][16] which separate the graphics and computation pro-cess, usually by distributing these functions among severalplatforms.
4 Class Structure
The primary motivations for the class structure in thevirtual windtunnel are the ability to add new interface andvisualization objects without either effecting or necessarilyunderstanding the entire virtual windtunnel system, and toscale, that is to allow an unlimited number of new objects tobe inserted into the system without having the software col-lapse from excessive complexity. Several individuals, rang-ing from sophomore summer students to experiencedprofessionals, who have no previous knowledge of the vir-tual windtunnel have added subclasses of both vtool andvisualization after only a week’s worth of effort, proving theextensibility of this class structure.
4.1 Environment Objects and the Environment ListThe virtual windtunnel is conceptualized as an environ-ment that contains objects. All of these environment objectsmust know how to render themselves and may have compu-tational tasks. This motivates a class hierarchy, shown in Fig.3, with the classenvobj for environment objects at the high-est level. An envobj contains identifier information,draw,andcompute member functions. The envobj class also con-tains thefind member function, as well as thegrab andpointmember functions that respond to user gestures as describedin section 4.3. Even though there are environment objects,such as visualizations, whose interactivity is not currentlyused, thefind,grab andpoint functions are defined at theenvobj level because other applications of this frameworkmay allow all environment objects to be interactive.
The envobj class is the parent of two subclasses:toolandvisualization. The tool class is the parent of such objectclasses as menus, sliders, markers, and the visualization con-trol tools described in section 4.2. Unlike conventionalgraphical user interfaces, interface tools such as menus andsliders appear inside the virtual environment. These tools aredescribed more fully in [4] and will not be discussed in this
4
paper.
Envobjs in the environment are managed through theenvlist object, that contains lists, implemented as arrays, ofall environment objects. It is the envlist object which iteratesthe environment objects, causing them to be computed,drawn, and, in the case of tools, to be found by the user.There are two primary lists in the envlist class: a list of allenvironment objects and a list of all tool objects. The list ofenvironment objects is used to cause each object to computeits state in a compute traversal and draw itself in a draw tra-versal. The list of tool objects is used for the user search tra-versal to determine if the user is interacting with that tool, asdescribed in section 4.3. The reason for maintaining a sepa-rate tools list is that there are typically many more visualiza-tion objects than tool objects. Restricting the search to thetools objects improves the search time. Insertion into theenvobj list is handled by the envobj constructor calling anenvlist member function. Insertion into the tool list is han-dled similarly by the tool constructor. In this way when anew subclass of visualization or tool is implemented in thevirtual windtunnel it will be properly inserted into the appro-priate lists.
4.2 Visualizations and Visualization Tools
As described in section 2.2, the virtual windtunnel classstructure is designed with the philosophy that visualizationsare not manipulated directly, but rather through visualizationtools, orvtools. Vtools can be spatially extended objects,containing groups of visualizations which are manipulated atone time.
There are two types of objects defined for the communi-cation of data from vtools to visualizations. Anemitter is a
class which specifies a set of visualizations at a point inspace. The emitter class contains a list of visualizationobjects, and aseedpoint. The seedpoint class contains all thedata at a point in space necessary to specify a local visualiza-tion. A vtool contains one or more emitters. When a vtool ismoved, the seedpoints contained in each of that vtool’s emit-ters is set to the new position of that emitter. The emittersthen inform all of their visualizations of the new seedpoint.Several visualizations can be displayed on the same vtool.Local visualizations contain an identifier of the data field tobe visualized, a seedpoint, and a function which takes thatdata field and seedpoint as input and outputs visualizationextract geometry.
The emitter structures within a vtool allows one vtool tocontain emitters with different sets of visualizations, as wellas having these visualizations display different data fields. Adesign decision was made to specify the visualization con-tent and data field at the level of the vtool. Thus all emittersin a vtool have the same visualizations displaying the samedata.
With this vtool/local visualization structure, new localvisualization techniques can be implemented using a tem-plate of move, compute and draw functions. When imple-mented in this way the new visualization subclass willautomatically work with all existing vtools. Similarly, a newvtool can be defined containing a set of emitters and willautomatically work with all implemented local visualiza-tions. In this way easy extensibility is achieved for any visu-alization technique that uses local spatial data as input. Noknowledge of the rest of the virtual windtunnel structuresuch as the nature of the process structure, list management,or interaction logic is required.
humanenvlisttoolenvobjvisualizationslidermenu...vtoolrake...streamlineisosurface...sample_pointcontainsemitters which communicateseedpoints tovisualizations getdata fromdataFig. 3The object hierarchy of the virtual windtunnel. Sample_point and rake are example subclasses of vtool, whilestreamline and isosurface are example subclasses of visualization. The envlist object maintains lists of the envobjs inthe environment, and the human object manipulates objects through the envlist.
5
4.3 User Interaction
User data, including head and hand tracker position andorientation data, gesture, and environment transformationssuch as scale are encapsulated in ahuman object. Thehuman object controls the interaction with tools in the envi-ronment. Inside the human object there is a function pointercalleddoit which is executed once per graphics frame. Thedefault content ofdoit is a pointer to a search function (con-tained in the envlist class) which traverses the list of toolsand passes the human object to each tool. If the tool returnsthe message that the user is interacting with it,doit is set to apointer to either thepoint orgrab function of that tool asappropriate to the current human gesture data, and thepointer to the tool is stored. Thegrab orpoint function of thetool is then executed once per graphics frame, with thehuman object as input data.
The C++ syntax of this operation is sufficiently obtuseto warrant explicit mention. Using thegrab function of anobject as an example, the functionget_grab_pointer takesthe function pointerdoit as an argument and sets it to apointer to the object’sgrab function:
Inside the human class doit and the gesture variables aredeclared:
void (envobj::*doit)(human *being)int old_gesture;
int current_gesture;
Inside the envobj class the grab functions are defined
virtual void grab(human *);void get_grab_pointer(int
(envobj::*(&f))(human *)
{ f = &envobj::grab; }
In the envlist class, when envlist determines that an objecthas been grabbed, get_grab_pointer is called a pointer to theobject is stored in curobj.
human *being;
envobj *toollist[];
toollist[found_object]->
get_grab_pointer(being->doit);
being->curobj = toollist[found_object];
being->old_gesture = being->current_gesture;
In the human class doit is executed by:
(curobj->*doit)(this);
The result of this example is that a pointer to the tool’sgrab function is placed intodoit. This grab function is exe-cuted once per graphics frame, moving the tool in a waydetermined by the tool and the human object’s hand trackerdata.Doit is set back to the default function pointer when-
ever there is a change in the gesture data in the humanobject. Using this structure there is no need to maintain stateinformation about which object is being manipulated beyondthe contents ofdoitand curobj.
5 Run-Time Software Architecture
The run-time software architecture of the virtual wind-tunnel is designed to support both consistent high renderingrates and large amounts of computation. This architectureconsists of two groups of processes, reflecting the differencein times scales between the rendering and computation tasksdescribed in section 2. There is a graphics process groupexecuting the draw functions of the environment objects, anda computation process group executing the compute func-tions, both executing asynchronously from each other. Bothof these groups access environment objects through the env-list class as described in section 4.1, leading to the require-ment of process locking particularly during object creationor deletion. In addition, the results of the computational pro-cess must be communicated to the rendering processesrespecting the requirements outlined in section 7. These pro-cesses are outlined in Fig. 4.
Graphics Process GroupComputationProcessGraphicsChildProcessGraphicsMainGroupInteractionandBuffersData...Pipelinefor 2ndProcessSynchronizationFig. 4The computational processes of the virtualwindtunnel, including the optional child graphicsprocess created when there is a second graphicspipeline used for stereoscopic display. The compu-tation process creates several parallel subpro-cesses that call the compute functions of theenvironment objects.
This structure fits with a client-server distributed archi-tecture, which allows shared environments for collaboration.The computational process group is on a server system andthe graphics process group acts as the client. This is essen-tially the architecture implemented in the distributed virtualwindtunnel [2].
6
5.1 The Graphics Process Group
When supported by the graphics hardware, the virtualwindtunnel uses two graphics pipelines to produce visualstereoscopic images, one pipeline for each eye. The virtualwindtunnel currently uses the SGI GL graphics library, sothe use of two graphics pipelines requires the use of two full-weight processes. When using two graphics processes, allenvironment objects are allocated in shared memory via theSGI IRIX shared arena library so that the same object data isaccessed for rendering by both processes. These sharedobjects are implemented by overloading thenew operator,adding a pointer to the shared arena as an argument. If thisargument is non-null memory for the object is allocated fromthe shared arena. Free is also replaced by a function thatdeallocates the memory from the shared arena if appropriate.With this structure, objects created with the syntax “new(pSmArena) object”, where pSmArena is the shared arenapointer, will be automatically shared when appropriate.
The virtual windtunnel is currently being ported toOpenGL, which will allow lightweight shared-memory pro-cesses obviating the use of the above described shared mem-ory structure.
The graphics processes are synchronized through theuse of a pair of flags in shared memory. At the end of a drawcycle, each process does not proceed unless the other processhas indicated it has also completed its draw cycle.
The parent graphics process (which is also the parentprocess of the virtual windtunnel) handles user interaction,polling the interface devices and calling the human’s interactfunction. Changes in the environment state, including thecreation and deletion of objects are executed by this func-tion.
5.2 The Computation Process Group
The computation process group is designed to takeadvantage of available multiple processors. It is comprisedof one lightweight process which executes the environmentobjects’ compute function in parallel using the SGIm_forkfamily of functions. The environment object list is traversedin parallel with each processor taking charge of an object inturn. Because the object list is implemented as an array, theparallel execution of this list is straightforward.
Environment objects only recompute themselves whentheir seedpoint has changed or when the data to be displayedhas changed due to, for example, time variation. The objectsthemselves determine whether or not they require computa-tion at the start of their compute functions, so all objects’compute functions are called by the computation process.5.3 Process Locking
When objects are created and deleted in the parent
graphics process these objects must be locked so that theyare not being accessed by the computation process. Due tothe implementation of the environment object lists as arraysin the envlist object, locking of the entire array is required.When this lock is requested by the graphics process, a flag isset which causes the computation process to stop. There aretwo reasons for stopping the computation process. The firstis that some user interactions involve continuous parameterchanges which create and destroy objects. An example is theselection of the number of emitters on a vtool, which is con-tinuously controlled by a slider and results in the creationand destruction of many objects in several successiveframes. If the computation process is allowed to reacquirethe array lock between graphics frames, the continuous con-trol becomes very jerky as the graphics process waits to reac-quire the array lock. The second reason for stoppingcomputation is that the array lock request by the graphicsprocess is an interrogation which returns for processing. Thevery small time window between when the computation pro-cess releases and reacquires the array lock would often causethe graphics process’ lock request to be missed it the compu-tation process were not stopped. When the interaction iscompleted the computational process it told to proceed.
6 The Command Object Class
Commands in the virtual windtunnel can come frommany disparate sources including user gestures, menu com-mands, slider callbacks, start text scripts, keyboard input,and network messages. In the future we envision commandsfrom voice recognition. In order to simplify the addition ofnew commands, thecommand object was created. The com-mand object contains a name field and two overloaded func-tions:SetValue which executes the command andGetValuewhich returns information about the state determined by thecommand. These functions are overloaded by argument sothat the same command can be executed with several differ-ent argument protocols. An example is the command whichsets the scale of the environment. There are two versions ofSetValue implemented for this command with two types ofarguments: one which takes the scale value directly, and onewhich takes a pointer to a string of text from which the scalevalue is to be read. TheGetValue function for the scale com-mand returns the current scale value.
Commands are accessed by the actuator class, that con-tains a command pointer, set at creation time using the com-mand’s name. Actuators are contained in menus, sliders, orother command-generating objects.
Several commands determine the state of a vtool or thevisualizations on that vtool. These commands access theselected tool through a global vtool pointercurrent_vtool.The value of current_vtool is set by the user through a vari-ety of vtool selection methods.
7
7 Interface Hardware Independence
As described in section 2, the virtual windtunnel isrequired to support several user interfaces, to allow the userto use the interface hardware that is available. A variety ofinterface hardware is currently supported by the virtualwindtunnel, including the FakeSpace family of displays, ste-reoscopic projection screens, and conventional workstations,and several types of gloves and the conventional mouse forinput. The ability to rapidly add new devices is key to theuser acceptance of the virtual windtunnel. The effectivenessof the approach described in this section was demonstratedby the addition of new display and interaction hardware bythe graphics group at Stanford University with no priorknowledge of the virtual windtunnel.
This versatility is implemented for user input byabstracting input devices as providers of tracker data: a heador hand tracker is defined in the virtual windtunnel as a pieceof software that provides a position as a two- or three-dimensional vector and an orientation. A gesture tracker isdefined as software what returns the current user gesture.Software is then written for each hardware interface that pro-vides that data using a standard protocol. The hand trackermay be three dimensional for position and orientation track-ers, or it may be two dimensional as in the case of the con-ventional mouse. The tool subclasses then implement theirfind andgrab member functions (see section 4) in both two-and three- dimensional versions. The conventional mousemay also be used as a logical head tracker to provide viewcontrol when a three-dimensional head-tracked display is notavailable. In this case mouse motions are converted into ori-entation data that is passed to the virtual windtunnel.
Display independence is implemented by providing asingle display function which takes a pointer to a graphicsfunction as an argument. The display function then calls therendering function in a way appropriate to the display hard-ware.
These display and input functions are implemented asswitch statements in a support library function. Adding aninterface device involves adding the code that handles thedevice hardware, and converts its data into the required for-mat, to the library, then adding that device to the switchstatements as appropriate. The virtual windtunnel code itselfknows nothing about the devices being used except thedimensionality of the hand tracker device.
The devices that are used in a particular user session ofthe virtual windtunnel are specified at start-up time by anascii file.
8 Conclusion
In this paper we have presented a framework whichaddresses many of the systemic problems that were encoun-tered in the development of the virtual windtunnel. The solu-
tions to several difficult problems are presented:
•Through a carefully designed object hierarchy, thisframework provides the ability for a programmer toadd both new visualizations and new interface tech-niques to the virtual windtunnel without having tounderstand the entire system.
•Through the decoupling of computation and render-ing, high graphics frame rates are not impeded bytime-consuming computational tasks.
•The implementation of commands from disparatesources is streamlined through the creation of genericcommand and actuator classes.
•Interface hardware independence is achieved byabstracting these hardware devices and encapsulatingtheir operations in libraries with a standard interfaceto the virtual windtunnel
While work remains to be done on the virtual windtun-nel to enhance its visualization capabilities, we feel that theframework described in this paper is complete and will servethe needs of these new capabilities.
9 Acknowledgments
Our branch chief Tom Lasinski of NASA Ames hasgiven continual support and steering to the virtual windtun-nel over the years. We would also like to thank the NASmanagement for their continued support of the virtual wind-tunnel.
Brook Connor of Brown University and Al Globus ofNASA Ames provided many helpful insights in the design ofthe object structure for the virtual windtunnel. Andries vanDam of Brown University has been a continual source ofexcellent summer students.
The virtual windtunnel has had many participants.Creon Levit and the first author designed the initial conceptand prototype. The distributed architecture was originallydeveloped by Michael Gerald-Yamasaki and the first author.Jeff Hultquist contributed computational code to the originalprototype, and Rick Jacoby and Diglio Simoni contributedinterface code.
10 References
[1]
Bryson, S. and Levit, C.,” The Virtual Wind Tun-nel: An Environment for the Exploration of ThreeDimensional Unsteady Flows”,Proceedings ofVisualization '91 San Diego, Ca, Oct. 1991,alsoComputer Graphics and Applications July 1992
8
[2]
Bryson, S. and Gerald-Yamasaki, M., “The Distrib-uted Virtual Wind Tunnel”,Proceedings of Super-computing '92 Minneapolis, Minn., Nov. 1992[3]
Bryson, S., Johan, S., Globus, A., Meyer, T., andMcEwen, C. “Initial User Reaction to the VirtualWindtunnel”, AIAA 95-0114, 33rd AIAA Aero-space Sciences Meeting and Exhibit, Reno.,Nevada. Jan. 1995
[4]
The Virtual Windtunnel Users Manual, available athttp://www.nas.nasa.gov/NAS/VWT
[5]
Bryson, S., “Virtual Environments in ScientificVisualization”, Proceedings of 1994 Virtual RealitySoftware and Technology, Singapore, Aug. 1994also to appear inCommunications of the ACM.
[6]
Smith, M., Chawla, K., and Van Dalsem, W.,
“Numerical Simulation of a Complete STOVL Air-craft in Ground Effect”, paper AIAA-91-3293,American Institute of Aeronautics 9th Aerodynam-ics Conference, Baltimore Md. 1991
[7]
Sheridan, T. and Ferrell, W,Man-Machine Systems,MIT Press, Cambridge, Ma. 1974
[8]
Bryson, S., “Impact of Lag and Frame Rate on Var-ious Tracking Tasks”,Proceedings of SPIE Confer-ence on Stereoscopic Displays and Applications,San Jose, Ca., Feb. 1993
[9]
Meyer, T. and Globus, A., “Direct Manipulation ofIsosurfaces and Cutting Planes in Virtual Environ-ments”, RNR Technical Report RNR-93-019,NASA Ames Research Center
[10]
Upson, C., Faulhaber, T., Kamins, D., Laidlaw, D.,Schlegel, D., Vroom, J., Gurwitz, R., and van Dam,A., “The Application Visualization System: AComputational Environment for Scientific Visual-ization”, IEEE Computer Graphics and Applica-tions, Volume 9, Number 4, July 1989
[11]
Bancroft, G. V., Merritt, F. J., Plessel, T. C., Kelaita,R. K., McCabe, R., K., and Globus, A., “FAST: AMulti-Processed Environment for Visualization ofComputational Fluid Dynamics”,Proceedings ofVisualization ‘90, IEEE Computer Society Press,October 1990
[12]
Brooks, F. P. Jr., Ouh-Young, J., Blatter, J. J., andKilpatrick, P. J., “Project GROPE - Haptic Displaysfor Scientific Visualization”,Computer Graphics:
Proceedings of SIGGRAPH 90,July 1990
[13]
Taylor, R. M., Robinett, W., Chi, V. L., Brooks, F. P.Jr., and Wright, W., “The Nanomanipulator: A Vir-tual Reality Interface for a Scanning TunnelingMicroscope”,Computer Graphics: Proceedings ofSIGGRAPH 93, Aug 1993
[14]
Cruz-Neira, C., Leigh, J., Barnes, C., Cohen, S.,Das, S., Englemann, R., Hudson, R., Papka, M.,Siegel, L., Vasilakis, C., Sandin, D. J., and DeFanti,T. A., “Scientists in Wonderland: A Report on Visu-alization Applications in the CAVE Virtual RealityEnvironment”,Proceedings of the IEEE Sympo-sium on Research Frontiers in Virtual Reality,October 1993
[15]
Herndon, K.P. and Meyer, T., “3D Widgets forExploratory Scientific Visualization”,Proceedingsof UIST ‘94, ACM SIGGRAPH, November, 1994,[16]
Pausch R., Burnette, T., Capeheart, A.C., Conway,M., Cosgrove, D., DeLine, R., Durbin, J., Goss-weiler, R., Koga, S., and White, J., “A Brief Archi-tectural Overview of Alice, a Rapid PrototypingSystem for Vitrual Reality”, IEEE ComputerGraphics and Applications, May 1995.
9
因篇幅问题不能全部显示，请点此查看更多更全内容