InSpace is meant to work with the $G software organization. If you're new to $G, check out the documentation in $G/shared/man/get-started.txt, which is at /map/gfx0/tools/shared/man/get-started.txt in the Brown CS dept.
If you're setting up inspace for the first time under $G, then a quick way to make sure you have all your dependencies setup is to run the init-test-inspace-2.0 script, which will check out, compile, and install everything needed to run the test-inspace-2.0 project. This script should be in your path once $G is setup. The source is in $G/shared/src/gfxscripts.
InSpace no longer relies on VRJuggler. Any GL-based system can now be used to open and handle GL windows in InSpace through the ISVREngine abstraction. InSpace gets all its info about the display from the base class ISVREngine. Each windowing system implements a subclass of ISVREngine. For example, there is a GlutEngine that uses the glut library to interface with GL. Soon, there will be a VRJugEngine that does the same with VRJuggler as the back end. There could also be a G3D (Morgan's library) Engine.
Currently, the GlutEngine cannot handle a situation where you're on a SGI multi-pipe computer, like at the Cave. VRJuggler is good at this. Part of what makes it good is its vjGlContextData<> template. There is now an InSpace wrapper around this template called isGlContextData<>. Once a VRJugEngine is implemented, you can use this template, and it will act exactly as vjGlContextData<> does in VRJuggler. When you're not using VRJuggler as a back end, then the interface to the template remains the same, but there's no funky context specific data management going on underneath. So, to make your program portable, you should always use the isGlContextData type. That way, if you want to run it on a multi-pipe SGI at some point with VRJuggler, you can.
The ISVREngine reads in the display settings from glueconfig values. There are currently several glueconfig files that setup proper display values for common displays. All of these are in the $G/src/inspace-2.0/config directory, which gets installed to $G/shared/lib/inspace-2.0/config. Note, that there are also device specific glueconfig files for common setups in this directory. Here's a common way to start your inspace program:
Example: program -f $G/shared/lib/inspace-2.0/config/glueconfig-desktop-display \
-f $G/shared/lib/inspace-2.0/config/glueconfig-desktop-devices \
-c DISPLAY=desktopfullscreen
The first two -f arguments tell gluebase to parse those glueconfig files. The -c argument tells gluebase to override the glueconfig variable named DISPLAY and set its value to desktopfullscreen. The glueconfig-desktop-display file sets up two possible displays, one for running in a 640x480 window, and one for running fullscreen. It defaults to the desktopwindow setup, but you can override this as was done here. InSpace will look for information on how to setup the display (number of tiles, resolution, stereo/mono, etc..) based on the value of the DISPLAY glueconfig variable. Look at the example glueconfig files in the config directory for more info.
Use $G/src/test-inspace-2.0/ as an example. Copy this and modify it to fit your needs. The TestApp class is what you want to change to be your application.
Glue no longer automatically loads certain config files. You have to specify exactly which config files you want to load on the command line. You can also specify individual name=value pairs on the command line. Run any program with a "--" argument to see a usage message. Here's one:
test-inspace-2.0-d [-f filename [-f filename...]] [-c name=value [-c name=value...]]
options: (defaults in [...]'s )
-f filename Specifies a GLUE-style config file to process. [null]
-c name=value Specifies a GLUE config name=value pair to process. [null]
'value' overrides any values for 'name'
specified in glueconfig files.
The args package that is part of dhl's libgg from CalTech is now used to do argument parsing. I took it out of libgg and put it in its own library called ggargs for now so that I could tweak it to compile on windows. I would recommend using this package as a standard for program argument parsing from now on. It's very powerful and convenient. This adds a dependency to inspace.
InSpace depends on the gluebase, ggargs, GL libraries, and glut. Optionally, it depends on openal for integrated sound.
In turn, gluebase depends on vrpn-6.02 for some devices.
So, if you want everything for a VR setup, you need:
1.2.18