Cave Software Overview
Software layers for the Cave
Running in the Cave under Linux:
3D Application
| |
G3D, QT, GLUT VRG3D / MPI <--------------> MPI / VRG3D
optional peer peer
| |
Open GL VRPN <--------------> VRPN <---> I/O
| client server
CPU / GPU
Desktop debugging under Linux or Windows:
3D Application
| |
G3D, QT, GLUT VRG3D
optional desktop
| |
Open GL VRPN <---> I/O
| dektop
CPU / GPU
VRG3D
VRG3D implements an API for developing virtual reality applications. It uses G3D for managing lower layers. In a cave environment an application is run on a different computer for each wall. VRG3D translates the view for each wall and synchronizes events between all instances of the application.
The VRG3D source code currently resides at Brown. It is probably out of sych with supported G3D releases. A consideration is to establish support for VRG3D consistent with supported versions of G3D.
http://vis.cs.brown.edu/resources/doc/VRG3D/index.html
VRPN
The Virtual-Reality Peripheral Network (VRPN) is a set of classes within a library and a set of servers that are designed to implement a network-transparent interface between application programs and the set of physical devices (tracker, etc.) used in a virtual-reality (VR) system. Note that it is possible to use VRPN with devices that are directly connected to the machine that the application is running on, either using separate control programs or running all as a single program.
VRPN also provides an abstraction layer that makes all devices of the same base class look the same; for example, all tracking devices look like they are of the type vrpn_Tracker.
http://www.cs.unc.edu/Research/vrpn/
G3D
http://g3d-cpp.sourceforge.net/manual/guideoverview.html
G3D makes low-level libraries like OpenGL and sockets easier to use without limiting functionality or performance.
+ You can use pieces of the library without the whole.
+ Allows bypass to lower layers. You can always execute OpenGL functions directly and mix them with RenderDevice calls.
G3D is built on OpenGL because it is platform independent and allows access to newer features than DirectX. Unlike higher level engines G3D does not restrict access to low-level features-- every graphics card function in OpenGL is exposed under G3D, even if it isn't wrapped by a higher level API. This means you can always drop down to raw OpenGL calls if needed.
Although G3D provides its own native window management, you can use the G3D::OSWindow API to replace that with GUI libraries, likw wxWindows and Qt.
It is possible to use DirectX instead of OpenGL. The easiest way is to link against G3D.lib only and use DirectX calls instead of the GLG3D equivalents. A more full-featured solution is to replace the RenderDevice and Texture implementations with DirectX versions and rebuild the entire library. We have not investigated the latter.
G3D uses zlib, libpng, libzip, and libjpeg, which are distributed as part of G3D (as headers and a windows .libs).
On Linux and FreeBSD, G3D::SDLWindow uses SDL. SDL is not included with the G3D installation and must be downloaded separately from http://libsdl.org if it is not installed on your machine already.
In addition to those mentioned above, you may be interested in using the following libraries to complement G3D:
- Image Magick's Magick Wand (http://www.imagemagick.org/)
- Free Type2 (http://freetype.sourceforge.net/index2.html)
- STLport (http://www.stlport.org/download.html)
QT
Qt is a cross-platform application and UI framework. Using Qt, you can write applications once and deploy them across many desktop and embedded operating systems without rewriting the source code. It is particularly useful for composing menu interactions.
SDL
Simple DirectMedia Layer is a cross-platform multimedia library designed to provide low level access to audio, keyboard, mouse, joystick, 3D hardware via OpenGL, and 2D video framebuffer.
- Video
- Events
- Audio
- CD-ROM audio
- Threads
- Timers
- Endian independence
You can set the environment variable "SDL_VIDEODRIVER" to the name of the driver you want to use. The drivers available depend on the platform and SDL compile-time options. Here is a partial list for some platforms:
- Linux:
- x11 - (default) Use the X11 windowing system
- dga - Use XFree86 DGA 2.0 for fullscreen hardware acceleration
- fbcon - Use the framebuffer console
- directfb - Use the DirectFB API
- svgalib - Use the SVGAlib API
- ggi - Use the General Graphics Interface API
- aalib - Use the Ascii Art library
- Win32:
- directx - (default) Use the DirectDraw API
- windib - Use the standard Win32 GDI
SDL supports Linux, Windows, Windows CE, BeOS, MacOS, Mac OS X, FreeBSD, NetBSD, OpenBSD, BSD/OS, Solaris, IRIX, and QNX.
The code contains support for AmigaOS, Dreamcast, Atari, AIX, OSF/Tru64, RISC OS, SymbianOS, and OS/2, but these are not officially supported.
SDL is written in C, but works with C++ natively, and has bindings to several other languages, including Ada, C#, D, Eiffel, Erlang, Euphoria, Guile, Haskell, Java, Lisp, Lua, ML, Objective C, Pascal, Perl, PHP, Pike, Pliant, Python, Ruby, Smalltalk, and Tcl.
HID
The USB HID class is defined in a number of documents provided by the USB Implementers Forum's Device Working Group. The primary document used to describe the USB HID class is the Device Class Definition for HID:
http://www.usb.org/developers/devclass_docs/HID1_11.pdf
There are two levels of APIs related to USB HID: the USB level and the operating system level. At the USB level, there is a protocol for devices to announce their capabilities and the operating system to parse the data it gets. The operating system then offers a higher-level view to applications, which do not need to include support for individual devices but for classes of devices. This abstraction layer allows a game to work with any USB controller, for example, even ones created after the game.
- Microsoft Related HID Documentation:
http://www.usb.org/developers/hidpage/microhid/
- Linux Related HID Documentation: