Brown Cave Software History

History of Cave Software at Brown University

3rd party software

1. World Toolkit
   1. Pros: This was the first software we used to drive the Brown Cave when it was installed in 1998. World Toolkit had lots of documentation. It handled synchronization of driving 4 displays in our 1998 Cave. It supported semi-sophisticated graphics such as alpha values and through some mechanism we never understood (though would have liked to) would draw semi-transparent geometries correctly-- normally, semi-transparent geometries are tricky technically to draw because you have to sort geometry back to front. It was scenegraph-based which sometimes was useful and sometimes was a hassle. It could import a variety of CAD models which was useful for some applications like Petra. Artery and Petra ran on WTK, plus some smaller applications. An early version of CavePainting may have run on WTK.
   2. Cons: Some visualization ideas we had we could not implement because WTK did not let us control enough of the rendering engine. It went out of business. There wasn't good support for linux at first, and when we moved from SGI to linux graphics computers it wasn't easy to port applications like Artery and Petra.
2. Ensight Gold (http://www.ensight.com/ensight-gold.html)
   1. Pros: DOE uses this commercial software for visualization at desktops and Caves. LANL in particular uses it for Cave visualization. It is a very high-quality and powerful scientific visualization software.
   2. Cons:Its support for Caves is limited, though, providing: stereo rendering, cluster-graphics support, and a heads-up-display containing a small user-defined subset of its total functionality configured in a text file. No head-tracking is provided. The code is not available for extension/modification.
3. VRJuggler (http://www.vrjuggler.org/)
   1. Pros: University of Iowa has developed and supported this software for many years. It has extensive documentation online and runs on multiple platforms.
   2. Cons: In our experience, it has grown to a large size that makes doing simple things hard. We have found most people want a small stepping stone from OpenGL/Cg to Cave-development and that VR Juggler is too big a step that overwhelms developers.
4. OpenScenegraph
   1. Pros: Juergen Schulze used this for some applications at Brown during his time as a post-doc here. It provides a scenegraph which is helpful for some tasks.
   2. Cons: It cannot drive a Cave, but Juergen used it with Brown's "Inspace-2.0" (see below) to develop "CaveVOX".
5. Java3D
   1. Pros:This is Sun's 3D graphics API for java. We especially liked the "Platform" concept for a spectrum of display environments and incorporated it Brown's home-built software where it is more often named "Room" and comes up in "RoomToWorld" transformation matrices.
   2. Cons:It runs on java and may have a performance hit over C/C++ applications.

Brown-built software

1. DOGL (Distributed OpenGL)
   1. Pros: This was the first software we used to drive the IBM cluster we used in 1998. Dmitri Lemmerman did much of the work on it. It was developed in parallel to Chromium and some of the other solutions to driving graphics clusters. It worked by using an interposed OpenGL library to capture OpenGL calls and distribute them with MPI to the nodes of the cluster. I believe some special additional commands were used to handle setting up a viewpoint for a Cave-like display.
   2. Cons: DOGL fell out of use because of its complexity and need for maintenance.
2. Jot
   1. Pros:Jot made use of some of Brown's pre-Cave 3D graphics and application framework designed for user interaction and visualization research. It was meant to be a modular system and originally ran on our Sun workstations, but also ran on SGIs and ibms, and later linux machines. Parts of it became "gluebase" which is in the Brown $G software repository and includes several low-level packages including a math library, networking code, device input, and an FSA-based interaction model.
   2. Cons:It wasn't well documented and users found it hard to use. This problem led to a move to $G and eventually "inspace-2.0" which was the next heavily used software framework for Cave development.
3. "Inspace-2.0"
   1. Pros: This is a simple approach to driving a range of systems from desktops through Caves. Unlike DOGL which synchronized applications by sending OpenGL calls between machines it synchronized applications by sending events between machines. This paper describes the approach http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.10.6599 . (The approach may been partially used by Jot as well-- check on this.) It also was used in this work investigating the large IBM rendering cluster Brown used http://portal.acm.org/citation.cfm?id=1101663 . We once used the 48-nodes of the IBM graphics cluster to get a 5x rendering boost for CaveVOX which suggests the approach scales fairly well for some rendering applications. Generally, we have stuck to the 4-node cluster to drive our 4-node Cave because of its simplicity and that replacing 4-graphics cards is much cheaper than 48-- plus the new cards that come out every ~6 months generally outpace the benefit of a large cluster of dated cards.
   2. Cons:It was hard to get it running on windows. It did not provide a scenegraph (Juergen Schulze integrated one anyway through OpenScenegraph to develop CaveVOX).
4. IS3D
   1. Pros:This framework developed by Dan Keefe incorporated Morgan McGuire's G3D (http://g3d-cpp.sourceforge.net/) which is a high-quality graphics research framework that, in particular, provided easy access to GPU capabilities. inspace-2.0 let developers familiar with OpenGL develop Cave apps-- IS3D extended this to providing a well-documented graphics toolkit and providing GPU support.
   2. Cons:(not sure.. but it was replaced with VRG3D.)
5. VRG3D
   1. Pros:This is the most recent software toolkit for desktop through Cave graphics development at Brown. It builds on G3D which has the advantages of a well-documented, high-performance advanced graphics toolkit and also good support for research involving GPU. It replaced inspace-2.0's use of MPI to network with socket-based networking. This helped with in-practice issues of applications and MPI-connections not "going away" that plagued developers. (We used MPI originally to leverage its high-performance networking-- it's not clear yet whether moving to the socket-based approach will incur performance hit-- so far applications using VRG3D appear to run as fast as the MPI-based ones.)
   2. Cons:More documentation is needed for the "VR" extensions to G3D. Testing and tuning of the toolkit is needed.

Recommendation for 2009 and into the future

There are three softwares Brown should use:

1) For general scientific visualization, Amira appears to be a solid system (http://www.amiravis.com/) for new Cave users of all disciplines.

ParaView (http://www.paraview.org/) is another good option, but it has very limited support for immersive virtual reality. With funding from DOE Brown and LANL worked on investigating a IVR-version of ParaView, but it is incomplete. However, ParaView may have a role for desktop scientific visualization and is in use by some scientists at Brown University today.

2) XVR (http://www.vrmedia.it/) is a good and free software for visual simulation

3) VRG3D is recommended for researchers doing advanced visualization and interaction research not supported by Amira or XVR.

VRG3D is currently the suggested toolkit for advanced research in visualization and user interaction.

A user who understands OpenGL can write their first program in XXX minutes. A web-page with extensive documentation on G3D and VRG3D exists at XXX.

It is a light-weight software framework that is very flexible.

VRG3D uses socket- and event-based synchronization described above.

Any devices can be made to generate data for VRG3D applications, but we build on top of VRPN (http://www.cs.unc.edu/Research/vrpn/) which provides for dozens of input/output devices and is growing regularly.

It drives a range of displays including desktop, HDTV's like the Samsung series, tiledwalls, and Caves.

It is multi-platform (linux, Windows, and MacOS).

It has XXX users including UMN, Williams College, Brown, ... (who else).