Contents

Acknowledgements ......................................................................................... 3

1.Introduction  ....................................................................................................4

2.CAVE5D ..............................................................................................................4

3.CAVERNSoft ................................................................................................... 5

4. CAVE6D - Collaborative Extension of CAVE5D ................................ 6

5.Collaboration in CAVE6D. ............................................................................6

6.Implementation ...............................................................................................11

7 Observations ................................................................................................ 16

8.Using CAVE6D. ............................................................................................ 18

        8.1Requirements ............................................................................ 18
        8.2Compile Instructions ............................................................. 18
        8.3Running Instructions. ........................................................... 19
        8.4Interaction. ................................................................................ 22
 

9.An example walkthrough of the Chesapeake Bay in CAVE6D ......... 25
 

10.Related Links. ............................................................................................. 30

11.References:  ................................................................................................31

Acknowledgements:

I am highly indebted to my advisors Jason Leigh, and Andy Johnson for giving me all the help I needed at the various stages of this project, and my stay in EVL on the whole. I would like to express my special gratitude to both of them for sharing their knowledge and creative ideas with me, especially the inspirational discussions with Jason which seems to be there always in my mind motivating me to improve myself on all fronts. Jason's 'just do it' attitude has changed my approach of dealing with things tremendously. With their guidance I have really learnt and grown up a lot, from what I was when I came to EVL 2 years ago.

My special thanks goes to Maxine and Tom for supporting me, and providing the extraordinary environment and equipment to work with, to Jim for coming to help to teach and trouble shoot the audio set up for the infinite number of demonstrations this project has gone through, to Mohammed for coming out to help on lots of occasions, and to Sam for creating the logo for CAVE6D.

Also I would like to thank all the students of EVL for being very helpful and accommodating and above all, very nice friends.

1. Introduction:

Cave6D, co-developed by Abhinav Kapoor, Jason Leigh, and Andrew E. Johnson, at the Electronic Visualization Laboratory, is a Collaborative Scientific Visualization Environment, that allows multiple users of Cave5d to share a same environment and  interact with each other synchronously. It uses CAVERNSoft architecture to provide the collaboration between the multiple users in the CAVE5D environment.

2. CAVE5D

CAVE5D, co-developed by Glen Wheless and Cathy Lascara from Old Dominion University and Dr. Bill Hibbard from the University of Wisconsin-Madison, is a configurable virtual reality (VR) application framework. Cave5D is supported by Vis5D, a very powerful graphics library that provides visualization techniques to display multi-dimensional numerical data from atmospheric, oceanographic, and other similar models, including iso-surfaces, contour slices, volume visualization, wind/trajectory vectors, and various image projection formats. The data is in the form of a five dimensional rectangle, 3 dimensional gridded space, one time dimension and one dimension which is an enumeration of multiple physical variables as mentioned above. Figure 1 shows Cave5D being used to view results from a numerical model of circulation in the Chesapeake Bay. The Cave5D framework integrates the CAVE VR software libraries with the Vis5D library in order to visualize numerical data in the Vis5D file format on the ImmersaDesk or CAVE and enables user interaction with the data. A set of Interface Panels, enable the user to activate the objects to be visualized, control the time clock, or change the x, y, z scales of the world. Hence CAVE5D as it exists, is an application that allows visualization and some interaction with the data. It does not however provide any form of  synchronous/asynchronous means to interact together with other people.

 

3. CAVERNSoft:

CAVERNSoft provides the software infrastructure for supporting Collaboration in CAVE5D. It retrofits CAVE5D, previously a non Collaborative application, with Tele-Immersive capabilities.  The existing functionality of CAVERNSoft is too extensive to describe here. See the CAVERNSoft homepage, at http://www.evl.uic.edu/cavern for more details.

Briefly, this framework employs an Information Request Broker (IRB) as the nucleus of all CAVERN-based client and server applications. An IRB is an autonomous repository of persistent data managed by a database, and accessible by a variety of networking interfaces. This hybrid system combines the distributed shared memory model with active database technology and real-time networking technology under a unified interface to allow the construction of arbitrary topologies of interconnected, tele-immersed participants.

4. CAVE6D - Collaborative extension of CAVE5D

Cave6D emerges as an integration of CAVE5D with CAVERNsoft [3,4,5] to produce a TIE that allows multiple users of CAVE5D to share a common data-set and interact with each other simultaneously. Any CAVE5D compatible data ie. any Vis5D format data, can be opened for a collaborative visualization session with CAVE6D. Besides having the user-data interaction as in CAVE5D, it also provides a user - user interaction between multiple participants, each running their separate instance of the visualization session. The current version of CAVE6D can support a maximum of 5 users

 

5. Collaboration in CAVE6D

An instance of collaboration in CAVE6D has the following characteristics

• Each participant runs a separate instance of CAVE6D. The design allows up to five participants to join and leave, as the session progresses. All locations have their own replicated data sets ( the Vis5d file ) and this is not shared or downloaded at run time. This is done to save network bandwidth, as the data could exceed several hundred megabytes in size.
• The Tele-Immersed participants see the virtual environment from their own perspective, and can navigate around the space freely.
• The immersed participants share the same virtual space. The virtual co-presence of these users is depicted in the form of an avatar. The avatars have a head, body, and a hand with a long pointer. They are colored differently, and have the names of the participants written on their bodies for identification. The purpose of collaboration however is not simply to provide a sense of virtual co-presence of the other users, but more importantly to allow them to jointly discuss and interact with the data-set in the environment, and voice their different opinions on what is observed in the visualization. One hand and the head of the participants are tracked, so that they can convey gestures such as nodding, waving etc. The tracking also indicates the direction in which they are looking/ facing, which gives a very useful visual clue about the participants in the collaborative visualization session. The users have a very long virtual pointer extending from their physical wand, with which they can show points of interest in the data, and/or localize a region of interest, as this pointer is mapped to their avatar?s pointer. This pointer is also used to make selections in the user-interface panels. Figures 2 shows a typical CAVE6D collaborative session, with the Chesapeake Bay data

• The participants can also talk to each other through a telephonic conference.

 

Fig. 3.a. -User 1 working independently.                                       Fig. 3b. User 2 - Working independently.

Fig3.c - User 1 shares User 2?s perspective for the Temperature Slice

Fig. 3.d. User 2 presses the Global switch for the Temp. Slice

Figs. 3. Using the global switch - Figure 3.a shows the Temperature Slices over the Rockies, but when the second user makes the Temperature slice global ( 3.d) the slices are synchronized with the second user?s setting, and move to the east coast.

• The time in the simulation of the data is globally synchronized at all times, so the time dependant variables change concurrently for all the participants. Each user has an equal control over the simulation. Any one can start it, and other users can stop it, go forward or back in time, to discuss a particular point of interest in the simulation.
• The users have the ability to set their environment locally, or make their settings global so that other participants could follow their set up. Each parameter can be made global individually, which not only makes its state (on/off/movable) global, but also synchronizes its location in the environment. This affords each participant the ability to individually customize and/or reduce the "cluttered-ness" of the visualization; one participant may be viewing the relationship between one subset of the total dimension of the data while another participant may be simultaneously correlating a different subset. Figures 3 shows how the Temperature Slice values changes for User 1, and follows that of User 2 when User 2 makes it Global.

• The use of global / local facility may be governed by the scenario of the session. In a teacher / student scenario, what might be needed is a multi-user single perspective situation, where students? view is shared and controlled by the instructor's point of view. In the other situation like that of a group of scientists/ researchers wanting to explore and learn about the data, it could be that they want to divide the set of data and view each locally and later jointly discuss/compare their discoveries in the global mode.

Virtual Director, developed by Bob Patterson, Donna Cox, and Stuart Levy at the NCSA, is an application that also provides the synchronous collaborative capability to CAVE5D to some extent. Virtual Director, acts as an interface between real-time data and user desired actions to enable animation recording, steering and editing, thereby allowing archive and playback of sessions in virtual space, which could be of immense help in the remote training and analysis sessions. Though Virtual Director provides these additional functionality of recording and playing back a session, it is very limited in terms of the collaborative abilities it provides. The users have no capabilities to partition the dimensions of the data they are visualizing  in terms of making the parameters synchronized selectively, the way CAVE6D provides it with its feature of setting the parameters global/local. Virtual Director avatars do not convey a lot about the remote users identity and about their activities in the environment. They do not possess a long pointer to show selections and localization of an area of interest in the data.

As mentioned earlier, CAVE5D, a non-collaborative application was retrofitted with TeleImmersive capabilities using CAVERNSoft, to produce CAVE6D. CAVERNSoft employs the Information Request Broker (IRB) [3,4,5] (Figure 5) which provides a unified interface to all the networking and database needs of the collaborative environment to support the distribution of data across the clients. Each Client/Server has its own 'personal' IRB, which is used to cache data retrieved form the other IRBs. Creating a communication channel, between the personal IRB and the remote IRB and declaring its properties does this. Once the channel is set up, a number of keys can be created across the channel, and linked together by giving them a unique identification. A Key acts as a sort of a handle to the storage location in the IRB's database. Each key can be assigned to a specific data to be transmitted across the network. These can then be set to trigger a callback whenever they get filled by some data,  which can then transmit the data to the remote key through the link. This way the personal IRB transparently manages data sharing with the remote subscribers. Any information received by a key is automatically propagated to all the other linked keys.

An IRB Interface present between an IRB and the  application provides a tightly coupled mechanism to automatically transfer messages between the two. In Cave5D however, this idea could not be properly exploited due to a conflict in the integration of CAVE5D and CAVERNSoft. CAVERNSoft is based on pthreads (the POSIX threading model)  which are not supported by the 'sproc' model of threading, as used in CAVE5D. Thus the IRB interface could not be embedded directly into CAVE5D. Instead a shared memory arena was used between them (Figure 6). Two shared memory arenas are created for each location. The IRB writes the data it gets from the remote IRB on one of them, which is read by the local CAVE6D application, which writes its data onto the other shared memory block, for the IRB to read.

The application writes data into the shared memory at a particular frequency, which could keep pace with the CAVERNSoft IRB reading speed (in the current implementation it writes once in 5 computations). The IRB stores the information into the corresponding keys. The IRB then updates the respective keys at the remote end. The frequency at which the IRB sends information across the network is governed by a lot of factors such as the network conditions, and the local processor power. For slow networks / processors the IRB should send information at a lower rate.

The content of the information sent across the network is as shown in Figure 7 Each instance of the application maintains a list of all the active avatars present in the environment, and stores their data. It sends the packet that has its own state information and receives such packets from all the active avatars. This way it updates its list every time it receives a packet from an avatar. The data packet consists of:

• Id is the avatar id, which is unique, and is assigned at run time
• Avatar?s positional coordinates in the world, and the head and hand tracked values.
• Time stamp to synchronize the simulation.
• States of the button of the graphical parameters,
• Location of the switched graphical parameters

Id - identifies the packet,

Tracker co-ordinates are used to draw the avatar.

Time stamp values help to synchronize the simulation at each stamp. The values received by the remote locations is compared with the time of the local clock, and set to the highest of them. This methodology makes the slower one catch up with the others every time stamp, and prevents the faster to go back in time to synchronize with the slower ones.

States of the buttons indicates if a particular global/local switch button is turned on, and if it is then make the corresponding graphical parameter synchronized.

This synchronization is done by using the Location of the parameters, for the participant who is moving, and making it the same at all the instances of the application, across the network. The application then reads the data corresponding to this location (grid location) and displays it.

It is to be noted that the current state values are passed to the remote instances of the application, rather than the events. For example instead of sending one move event, when an object moves, the current position co-ordinates are sent continuously, so that new participants can join the session anytime, and still be in synch with the others.

An effective locking mechanism is needed to deal with the parameters when in the global state. In global state, all the immersed participants can manipulate them equally, but two people should not be able to do that at the same time. Strange results would be seen if they try to move a global parameter in the opposite direction at the same time. In order to avoid such a situation CAVE6D temporarily gives the lock to the user who started moving it first, and then takes the lock back as soon as the move event is over.

The color of the avatar is decided at run time, if the user does not specify it. At the start of the application it waits to see who all are there in the environment( by just receiving the packets and not sending them), and based on that it assigns an unused avatar color to itself.

A Shared Centralized Network topology is used in CAVE6D, wherein all the clients connect to a server. All the client IRBs invoke a link to send the information to this central server IRB.  Each client links a key to the central server's key, the latter being capable of accepting links from all the clients. Each client IRB transmits continuous packets of data of the local state information to the server, at constant small time intervals. The server on the other hand, receives all these packets, and each time it receives such a packet it sends this packet to all the connected clients. It also sends its own local information, at constant time intervals like the other clients. In this way, each client gets information of all the other connected remote clients.

Both TCP and UDP protocols are used. A TCP channel is used to pass data such as time stamp, and the button states, as they are very crucial, and none of the packets should be lost. A loss of a time stamp value, could cause the simulation to jump a valuable step, or a missing button state value might cause to lose a global / local switch event. The tracker values and the parameter state values can be sent however through the UDP channel to save overhead. These values if lost would not cause a big damage. The following packet would restore the state of the parameters and the avatars, even if an earlier one is lost.

7. Observations

CAVE6D has been demonstrated at a number of conferences (including NGI, Internet 2, Alliance?98, HPDC? 98, SuperComputing?98 etc.), where collaborative demos were carried out between the exhibit floor and a number of remote locations. Besides these, other various collaborative sessions have been conducted using CAVE6D, which produced some interesting observations about how people used the application and its features, which kinds of existing collaborative abilities they liked, and what more they expected in such a collaborative visualization session. These provide valuable suggestions to the design of a collaborative visualization application. Some of them are enumerated below. Generally there were 2 kinds of scenarios - one in which a member of the session is a teacher or a guide, and the others are students or tourists; the other scenario was where the participants are closely related in their knowledge of the environment, and are performing an exploration of the data, and collaboratively correlating what they see in the environment.

• Audio turned out to be the most important medium of collaboration. In fact it was a requirement, as no collaboration could happen if the audio broke.
• People wished they could have a list of the current participants in the session displayed in the front somewhere, which could keep updating as participants joined and left. This was especially important at the I-Desk where the field of view is not much, and all the avatars might not be visible. Also, whenever the audio broke the users felt a need to find out, who all are there in the shared space.
• When there were a lot of unfamiliar participants, it was hard to make out who among the visible avatars was speaking. Incorporating lip movements when the avatars speak would solve the problem.
• Lots of users had a few problems with the Interfaces. They wished they could move the menus like the ones on the desktop. Menus in CAVE6D are fixed in the local co-ordinates of the user, and travel with it, and hence sometimes get hidden by the data. They liked the fact that they move with the navigation of the user, and are not fixed in space. Such observations were more prominent from experienced VR users than novice users.
• It is hard to see the clock and the data together when following the simulation. Some kind of a sound cycle varying with the time, could provide a useful means to follow the cycle of the simulation. Also when trying to step through the simulation one at a time, one has to look at the menu to keep hitting the step button, and it is difficult to follow the data pattern. There could be a way to lock the button, and then use the wand buttons to move in the time cycle.
• Though the buttons are collaborative the menu is not. In a teacher/tour guide scenario it would be good to have the menu also collaborative so they look at the same menu at the same time, and thus see them making changes to the button states. Having different menus opened sometimes confused the participants, especially if a parameter was switched on remotely, and it suddenly popped up.
• Menu items such as ?Set all Global?, and ?Set all Local? would have improved user interaction.
• Currently there is no collaboration on the scales of the world that the participants share. It could be useful to provide global common scales, or shrink/ enlarge the avatars to show their scale settings and localization/field of view.
• In a teacher - student scenario it was very useful to have a global time synchronization, and give controls to all the users. Students could stop the time, and ask questions at an instant in the simulation. However it was not a very desirable feature in the scenario where the users wanted to explore the data independently for some time, and later wanted to collaborate to discuss their discoveries.
• It would be useful to have the capability of selecting / changing the data files at run time, and propagate the selection to the other users, so all the collaborators use the same data, and do not open separate ones accidentally.

8. Using CAVE6D
 
 8.1 Requirements:

  Hardware - The distribution package needs 25MB of space, which has in it 2
                         demonstration data set files. The Chesapeake Bay data set is another 250MB. Would be best viewed on
                          an  Idesk driven by SGI Onyx 2 / Octane.

    Software  - CAVE Library, CAVERNSoft Library, pthreads patched IRIX Operating System over 6.3. It has been
                            successfully tested on IRIX 6.3, 6.4, 6.5, 6.5.2.

    Network - The data sent across the network consists of 1.7 K bytes. CAVE6D allows the users to set the frequency with which the data is to be communicated through the network. A typical frequency is 10 packets a second, which would need a bandwidth of 17 K Bytes per second.
 

8.2 Compile instructions:

Certain paths in the Makefile would need to be changed
to point to the libraries and includes on your system
(See Makefile)

then type

make cave6d
(to compile cave6d)

then type
make irbsend
(to compile irbsend)
 

8.3 Running Instructions:

In CAVE6D one machine will act as the server and all
the others, will link up to it as clients.

1. CAVE6D running as the server

On the machine which is designated to be the server, eg. on
laurel, type :

irbsend &

This process should be started before anything else, and can be kept running on itself without the application, so that all the clients can link up to it and establish the connection at any time.

After the irbsend process is ready ie. after it prints a message:

"READY ... RUN CAVE6D NOW..."

the application can be started. The information on how to run the application is mentioned below.
 

2. CAVE6D as a client

On the machine which would be the client, eg. hardy, and connecting to the server eg. laurel,
type the following on the client ( hardy)

irbsend laurel &

Again, when the irbsend prints the message ..
"READY ... RUN CAVE6D NOW..."

CAVE6D application can be started.
 

NOTE: The irbsend uses the default frequency of sending 10 packets
      a second, to the remote end. The frequency can be set from the
      command line, using the following command:
 
      irbsend [server-name] [ -<f || freq || frequency <rate ]
 
      where rate is the frequency rate you might want to set,
      and any of -f , -freq or -frequency option can be used, before
      it. eg.
 
      irbsend -f 15 & ( for the server irbsend process sending at
         15packets/sec.) or
 
      irbsend laurel -f 15 & ( for the client process )
 
      irbsend laurel -frequency 20 ( for client process sending at
               20 packets a second )
 

3. Running CAVE6D

The Command line for cave6d is:

cave6d <config-file> <name> [avatar-color]

where <config-file> is the path to the data-set file (see below).
      <name> is the name of the user,
      [avatar-color] is OPTIONAL and need not be mentioned,
                     unless you want your avatar to be of a
                     particular color.
Currently CAVE6D can connect upto a maximum of 5 participants. The
avatar-color could be one of cyan / magenta / red / blue / white.

4. Config Files

There are 2 sample data sets included in the package:
a. demos/lamps.cave5d
b. demos/tstorm.cave5d

The command line config-file could be one of these files.

The Chesapeake Bay dataset is around 250 MB, so it is not included this package, but can be obtained separately on request. It is included in the CAVE6D CDROM.

To prepare a config-file to be used by cave6d, it should have the  proper paths to all the data files. So you must open the relevant  .cave5d file and see if all the paths are mentioned correctly.

The first data set, the lamps.v5d dataset was generated by the Limited Area Mesoscale Prediction System around1986, and thus represents an early effort at mesoscale weather prediction. It shows warm and cold fronts moving across the continental United States, as part of a simulation of an extratropical cyclone.
 

8.4 Interaction:

1. Press the left mouse button to bring up the main menu- the Master menu ..

   The various menu items in it are as follows :

two rotation styles: object and airplane.

Graphical Objects
     Display the panel with graphical objects.

  ScaleX
  ScaleY
  ScaleZ
     Toggle scaling of X,Y,Z dimension on/off.

   Fast
      Increase the animation speed.

    Slow
     Decrease the animation speed.

     t=0
     Reset to first timestep.

     >
     Move forward one timestep

     >>
     Toggle animation On/Off

     Close
     Close this panel.

     Exit

Exit the application.

8.4b Wand Interactions:

1. Rotation:  to rotate the scene around , press the middle wand button and move the

wand in the direction on intended rotation.
2. Move Slice ( Graphical Objects ) - The objects to be moved should be in the movable state ( indicated by black text on yellow  background ) and then moved by clicking on the right mouse button, and moving the wand in the direction of the new position on the Slices. To make an object movable, 2 clicks are needed from the off state or one more click after turning them on. eg. to open Horz_HSLice in the movable state, click on it twice, and then move the wand up/down to move the plane up/down.
3. To make the  graphical objects  global ( seen in the same position and the state by all the participants )  turn on the corresponding G/L  option  on the graphical object menu ( ie blue text over yellow background ) . If they are Local ie. yellow text over blue background,  then you can move them without changing the remote users' view.

9. An example walk through of Chesapeake Bay data set in the CAVE6D environment.

The Chesapeake (means Great Shellfish Bay from the Algonquin Indians) Bay is the largest estuary in the United States and serves as nursery grounds or spawning areas for many commercially important species [LIKE: Blue crab and oysters].    It is one of the most productive and commercially important but a threatened ecosystem. There is an abundant growth of pelagic, benthic and vegetative communities, all of which are affected by seasonal and annual variations in the circulation, environmental forcing and inputs of nutrients from the local watershed. Also, the urbanization of the surrounding watershed is harmfully affecting the Chesapeake Bay ecosystem.

The Chesapeake Bay Virtual Environment is the answer to a need for an application which could simulate such governing factors and their effects on the ecosystems, and could provide the users to examine the output in a clear and concise manner. The Chesapeake Bay data set is generated using the Princeton Ocean Model, a three dimensional hydrodynamic circulation model.   The model solves the time-dependent, nonlinear equations of motion in a free surface formulation as well as the governing equations for temperature and salinity. The data is a fifteen day simulation of the effects of winds, tides and river runoff on the general circulation features of the Chesapeake Bay and on the transport of passive larval fish in to the Bay from the adjacent continental shelf. The  data describes the temporarily varying 3D fields such as salinity, temperature, density, velocity etc. from the circulation model. This data set, which consists of these numerically generated outputs, and other observations  is then loaded up in the CAVE6D application which provides a multiuser, collaborative,  interactive 3D visualization environment for the Chesapeake Bay.

Walkthrough Instructions:

1. Click on the left wand button to bring up the menu. Then click on the 'Graphical Objects' Panel, to bring up the graphical objects panel.

There would be lots of different parameters in the graphical objects panel. Click on the 'topography', the ''contour salinity', 'surface_Horz_Vec' and 'tracers_iso' buttons.

 

Some of the buttons and their meanings are:

                                                                                                          Topography - The terrain of the data.

4. Now whenever the other participants join you, their initial set up is the same as yours, so they need not be told about the options they need to select. They can see 'at least' the parameters you have opened and made global. and can add their view by putting on other parameters.     Each one of them would also be synchronized together with time.

5. Now press the middle button and turn around the world to about 180 degrees, so that now you are looking at the Bay from the other side, facing south. This position lets you face the other collaborators when they join in the session.

6. Now move closer to the mouth of the bay, and ask the others to come closer to it too, and face you, so they while you are standing north of the bay facing south and they are standing south of the  mouth facing the north.

7. As certain objects are global, you can  show them the circulation at the mouth. The flow pattern there consists of buoyant water out flowing along the southern reaches of the Bay entrance and over the shoals, whereas inflow of dense, saline shelf water is generally restricted to the bathymetric depressions or channels, in the opposite direction. It is shown by the difference of directions of vectors with the depth.  This can be shown at an instance in the simulation by stopping the time.

8. Pointing at the salinity blob at the entrance of the bay, tell the users that - The salinity field  ( more red - more saline, more bluish lesser saline )  is controlled primarily by fresh water runoff, changes in rainfall or drainage, evaporation, and wind direction and velocities.

9. Wait till the simulation plays for 1/3 of the whole cycle. SInce the whole simulation is for 15 days, this would mean data for 5 days. At this point stop the time. Till this period in the simulation,   environmental forcing was  limited to river discharge and the resultant circulation and salinity fields are consistent to this outflow which is  more than the inflow from the sea. Thus up till now the bay water was quite saline ( red ).

10. The low salinity water discharged from the river sources has moved down the western side of the Bay and out of the Bay mouth to form a buoyant plume. The plume rotated anticyclonically (clockwise) as it exited the estuary due to the effect of the earths rotation. A coherent downcoast-flowing coastal current was visible south of the Bay mouth. Outflowing buoyant water was seen to be confined to the south side of the Bay mouth and a weak return subsurface flow of saline shelf water was evident on the northern side.

11. Start the time again, and stop it this time, when it has reached half of its cycle. At this time, approx 8 days of simulation  strong seaward flow is evident, at maximum ebb stage.

12. Saline shelf water enters the bay still in the nothern side of the bay mouth at max. flood stage, yet the outflow plume is still present south of the bay mouth. Flow strength decreased with depth due to bottom friction and lateral gradients were high in the areas between the channels and the shoals. Mixing effects are clearly seen by the temporarily varying color gradations in the salinity field.

13. At this stage turn the isosurfaces also to global, and start the time again. A region containing concentrations of fish larvae was established just offshore of the Bay mouth, represented by the isosurfaces. Wind from the southwest resulted in the  advection of larval fish away from the Bay mouth to the north and east. At day 12 (3/4 of the simulation cycle), when the winds were reversed  and blowing from the northeast (downwelling favorable), saline shelf water was advected into the Bay   on the northern side of the Bay mouth. The distribution of simulated    larval fish was then advected   shoreward and larvae entered the Bay on  the flood tide.

14. Towards the last 1/4 th of the cycle, winds have reversed to be blowing from the north, in the process  moving the larval fish  distribution  into the tidally influenced region near the Bay mouth. Note the   strengthening coastal current south of the Bay  mouth, the resurgence of the outflow plume and the variability in circulation throughout the domain.

15.Once in the Bay proper, individual larvae may decrease their depth through self guided motion during slack water, sink to depths where   tidal velocities are small to avoid flushing on the ebb tide, then rise again and subsequently move to more favorable nursery grounds farther north up the Bay on the subsequent flood phase.
 

10Related Web Links:

• CAVE6D homepage: http://www.evl.uic.edu/akapoor/cave6d
•  CAVE5D homepage. : http://www.ccpo.odu.edu/~cave5d
• Vis5D homepage.: http://www.ssec.wisc.edu/~billh/vis5d.html
• CAVERNSoft homepage.: http://www.evl.uic.edu/cavern
• Virtual Director + CAVE5D page at NCSA : http://www.ncsa.uiuc.edu/VR/grants/virdir

11. References

[1] Carolina Cruz-Neira, Daniel J. Sandin, and Thomas A. DeFanti.

Surround-screen projection-based virtual reality: The design and implementation of the CAVE.
In James T. Kajiya, editor, Computer Graphics (SIGGRAPH '93 Proceedings), volume 27, pages 135-142, August 1993.

[2] Bill Hibbard and Brian Paul.

Vis5D http://www.ssec.wisc.edu// 6#6billh/vis5d.html, 1998.

[3] Andrew E. Johnson, Jason Leigh, Thomas A. DeFanti, and Daniel J. Sandin.

CAVERN: the cave research network.
In Proceedings of 1st International Symposium on Multimedia Virtual Laboratories, pages 15-27, Tokyo, Japan, March 1998.

[4] Jason Leigh, Andrew E. Johnson, and Thomas A. DeFanti.

CAVERN: a distributed architecture for supporting scalable persistence and interoperability in collaborative virtual environments.
Journal of Virtual Reality Research, Development and Applications, 2(2):217-237, 1997.

[5] Jason Leigh, Andrew E. Johnson, and Thomas A. DeFanti.

Issues in the design of a flexible distributed architecture for supporting persistence and interoperability in collaborative virtual environments.
In Proceedings of Supercomputing'97, San Jose, California, Nov 1997. IEEE/ACM.

[6] Rick Stevens, Paul Woodward, Tom DeFanti, and Charlie Catlett.

From the i-way to the national technology grid.
Communications of the ACM, 40(11):51-60, Nov 1997.

[7] Marcus Thiebaux.

The Virtual Director.
Master's thesis, Electronic Visualization Laboratory, University of Illinois at Chicago, 1997.

[8] Glen H. Wheless, Cathy M. Lascara, A. Valle-Levinson, D. P. Brutzman, W. Sherman, W. L. Hibbard, and B. Paul.

Virtual chesapeake bay: Interacting with a coupled physical/biological model.
IEEE Computer Graphics and Applications, 16(4):52-57, July 1996.

[10]. Vijendra Jaiswal
CAVEvis: Distributed Real-Time Visualization of Time Varying Scalar and Vector Fields Using the CAVE Virtual Reality System.
Proceedings of IEEE Visualization 1997.

Contact Information
For questions and comments, please contact:
Abhinav Kapoor,
akapoor@evl.uic.edu
Jason Leigh,
jleigh@eecs.uic.edu
 

CAVE6D Logo courtesy Samreong Thongrong, EVL, UIC.

CAVE6D URL is located at: http://www.evl.uic.edu/akapoor/cave6d