FreeVR: Virtual Reality Integration Library
User Guide




    Function List
    Library Dev
    Socket Interface


All materials
Copyright © 2013
William R. Sherman

Manpage of FREEVR


Section: FreeVR Overview (7FV)
Updated: 4 December 2013
Index Return to Main Contents



FreeVR - A virtual reality (VR) integration library and toolkit overview.  


FreeVR is an open-source application programming interface (API) for interfacing with virtual reality (VR) input/output hardware. It also includes a suite of utilities for testing input devices and for analyzing serial and network protocols. FreeVR applications are not written for any particular VR display, but conform to any individual system at run-time based on a flexible configuration specification.

The FreeVR library then handles all operations involving perspective rendering, graphics setup, multi-processing, as well as input devices, producing an experience that puts the user in the middle of a virtual world --- an immersive experience. FreeVR immersive experiences include artistic worlds, fun worlds as well as data visualization worlds. The type and style of virtual world can be whatever the application developer can produce.

There are choices in what graphics rendering libraries applications can be written for, and a wide variety of input devices that it can be configured as interfaces.  

Rendering Library Options

The primary low-level graphical interface that FreeVR uses is OpenGL. Applications can be written directly using the OpenGL API, or instead, using one of a handful of higher-level graphics libraries.

Over time FreeVR has been interfaced with a handful of these higher-level graphics APIs. Of these OpenSceneGraph has been most currently tested.


Iris Performer

Input Options

There are a plethora of options for interfacing with input technologies that measure user movements through space, in addition to other discrete and continuous user input interactions. Position trackers, devices that track location and orientation of a user, or at least particular elements of a user like the head and one hand, are of course a key element of producing the physically immersive interface that defines virtual reality, and thus FreeVR can interface with most of these devices. Not all position tracker devices are specifically designed for VR, but even those that are not other are often appropriated for immersive tracking. Typically these "other" systems are motion capture (MoCap) systems.

In some cases, a VR facility may already be using a software system that reads and streams input data through a network protocol. FreeVR can also read the most common VR daemon protocols. Finally, FreeVR can directly interface with most button and valuator inputs including standard game-controllers, plus many pre-cursor computer interface technologies. Of course, FreeVR can indirectly interface with even more devices through the network protocol systems such as VRPN.

Here are examples from each of these categories:


ART Camera TrackersVRPNX-WindowsCyberGlove
InterSense IS-900VRUI VRDDLinux joydevPinchGlove
NaturalPoint OptitrackVisBox DaemonLinux evdevSpaceMouse
Ascension Flock of BirdsANL TrackDStatic SpaceBall
Polhemus Fastrak  SpaceOrb

Many of the modern game controllers and similar devices are handled by the Linux joydev and evdev interfaces. And devices such as the Nintento "wiimote" can be handled either using the VRPN daemon or as an X11 device using the Cwiid daemon. Plus there are more device interfaces under development --- and even some that are not listed because they are no longer relevant.  

Operating System Options

The one area where FreeVR options are a little more limited is in the area of Operating Systems (OSes). There have been some forays into working on MS-Windows systems, and in fact FreeVR does generally work under Cygwin, but for the most part FreeVR is targeted as Unix and Unix-like OSes, in particular Linux, but also the BSD-based OS/X Darwin system.  

Distinctive Features

FreeVR has a number of features that are unique, or more fully implemented than other VR interface systems, of particular note are:
* Flexible and powerful configuration system
To allow FreeVR to work in a variety of systems with a wide selection of input devices, and with different ways to configure rendering outputs and how processes are assigned between each task, a very flexible, and yet well defined configuration parsing system has been developed. In particular, the FreeVR configuration system offers conditional expressions, variables and mathematical operations. See freevrrc(4FV) for details.
* On-screen information displays
FreeVR offers a handful of data overlays that can inform the user of how an application works or how well the system is functioning. For the application user, there is a help-screen overlay which can inform them of how the button and valuator inputs affect the operation of the application. The FreeVR API provides functions that enable the application programmer to specify how each input behaves. There is a statistics overlay that displays the performance of the application in a time-streaming view which is broken down by process, and then sub-divided by activities within the process. This can be very beneficial to the developer looking to improve the realtime nature of their application. Framerate, The most basic statistic, can be independently displayed. The third on-screen display is a live input events overlay, as inputs occur. This can be useful both for troubleshooting a VR system, or when creating an application tutorial to demonstrate to the viewer what inputs are being processed by the application.
* Input stream repeater
FreeVR has the ability to repeat inputs as they are received --- much in the same way a telegraph repeater outputs a message exactly as it was received, FreeVR can output all the inputs it received, packaged as one of the standard VR data stream protocols (ANL's original Tracker Daemon, or the Vrui VRDeviceDaemon). This can be extremely useful both for troubleshooting a VR facility, but also by enabling a VR facility to rely on a single protocol for multiple applications and systems, and use FreeVR as a go-between when there might not otherwise be a direct link from a particular type of input system.
* Live network interaction
FreeVR has a network interface that allows users to connect to a running VR application through a socket interface. The connection can be as simple as using telnet to connect to the FreeVR port (port 3000 by default). Commands include the ability to control stereoscopic rendering, affecting inputs and adjusting the coordinates of screens and input devices. A GUI interface can also be used to interact and even provide live updates to the state of the system --- and one such application is even provided: fvri.tcl (ie. the FreeVr Remote Interface).
* VR tool suite
In addition to the core library, the FreeVR package includes several other tools and utilities that can be especially helpful when establishing and trouble-shooting a VR facility. In particular each FreeVR input type has an associated "test" application that can be used to verify a working connection with the inputs (both for input devices and input daemons). There are also test programs for specific areas of FreeVR operation. In addition there are two tools designed to evaluate serial and socket protocols: serialspy and socketspy respectively. Each tool has its own manpage.
* Thorough documentation
While most virtual reality software systems provide some type of documentation, what makes FreeVR somewhat more distinctive is the availability of several ways to learn how to make use of the API. This includes documentation on the web (, which has a user guide, a guide for configuring the system and other administrative instructions, plus a fairly extensive tutorial on how to develop FreeVR applications. Finally, there are now manpages becoming available, though this is still very much a work in progress.

What FreeVR is Not

FreeVR has many features and capabilities, but it is built within certain design constraints intended to keep it lean and mean. With that in mind, FreeVR is designed to be a VR library and tools for configuring and troubleshooting a VR setup, and that's it. What that means is that FreeVR is not:
* A Scenegraph Library
Beyond providing the perspective matrix on the stack and some functions for billboarding, all the rendering is done by the application. Of course FreeVR has been interfaced with multiple existing scenegraph libraries, and thus by not associating FreeVR with it's own scenegraph, there are more options.
* Physics/Game Engine
As with scenegraphs, FreeVR is also not a game engine or a system that includes any aspects of world physics, including intersection testing or collision detection. Also as with scenegraphs, this allows the application developer to work with a physics/game system with which they are already familiar --- assuming that system will integrate well with FreeVR. For example FreeVR has been interfaced with the OpenDynamicsEngine (ODE) physics engine as well as the Delta3D game engine.
* Widget system
FreeVR also does not include a built-in widget system. This is perhaps more of a hindrance that the other exclusions. Likely because there is no general-purpose 3D widget system that is available, so each application must develop it's own interface.

Documentation and Tutorials

As mentioned above, one of the strengths of FreeVR is the documentation that is available. Specific documents included with the library (and also available on the web page) are:
* User Guide
* Application Development Guide
* Function Reference Manual
* Administrator Guide
* Library Development Guide

These are now being augmented with a collection of man pages. There is still a ways to go before the man page collection is complete, but the pages for many of the command-line utilities have been written.

Especially useful are the suite of tutorials. The primary tutorial provides a series of step-by-step examples that build up to sample applications with widgets, travel, and graspable objects. Two new series of tutorials provide examples for how to interface FreeVR to the OpenDynamicsEngine (ODE) physics engine and the OpenSceneGraph (OSG) scenegraph library.

All of this is collected on the webpage.  


FreeVR has a fairly simple build process. The library is simple enough that it doesn't require complicated build systems like autoconf or CMake. The basic process is this:

% make <architecture>

Of course you need to learn what <architecture> argument to use, and make can be used to provide a list of options:

% make
 Choose an architecture/configuration: (type "make fulllist" for more options)
bsd-glx           Free/Net/OpenBSD     OpenGL and GLX 
cygwin-glx        Win32 w/ Cygwin      OpenGL and GLX 
darwin-X-glx      Darwin XFree (Mac)   OpenGL and GLX 
linux2.6-glx-32   Linux 2.6 (32b arch) OpenGL and GLX 
linux2.6pt-glx-32 Linux 2.6 (32b arch) OpenGL and GLX with pthreads for Multi-proc 
linux2.6-glx-64   Linux 2.6 (64b arch) OpenGL and GLX 
linux2.6pt-glx-64 Linux 2.6 (64b arch) OpenGL and GLX with pthreads for Multi-proc 
solaris-glx       Solaris 2.x          OpenGL and GLX 
solaris-64-glx    Solaris 2.x (64-bit) OpenGL and GLX 
Type 'make <arch>' to build for an architecture listed above.

So, for Linux users on a 64-bit system:

% make linux2.6-glx-64

You'll notice that in addition to choosing an OS, and the memory addressing range (32 or 64 bit), for Linux there is also the "pt" option. This option determines whether the sharing of data between processes is done using pthreads (when "pt" is specified), or using standard shared memory methods. Typically one would use the normal method, but when using FreeVR with systems that handle their own memory allocation, such as OpenSceneGraph (OSG), pthreads are required.

If you use what might be considered a more obscure operating system, and you see that the above list is rather short, you can use the fulllist target for make and you will get a much more complete list of the possible systems for which FreeVR can be compiled. Note however, that FreeVR is infrequently tested on less common systems, so you should report back to the authors the degree to which everything worked under your OS of choice.

ASIDE: Linux version 2.6 has been a fairly stable target that has been in use for quite a long time. Generally this is a good thing, and efforts to perhaps make drastic changes to Linux may be found to be misguided.  


As stated above, FreeVR was designed with as minimal dependence on other software as possible. Really, just the windowing system (presently just X-11), and OpenGL. On Linux there may be some extra packages required for some input device systems.

In general you need to make sure these packages are installed:

* OpenGL
* libXi
* joydev (Linux only)
* evdev (Linux only)


If your system administrator has a properly configured "freevrrc" file then you are in luck and can immediately begin using an application immersively.

If not (and/or you are the system administrator responsible for creating the configuration file), then you have two options.

Run your application in "simulator" mode, which is often a good first step when testing out an application as it is being developed.
Learn how and then configure your immersive system to work with FreeVR. Of course, describing details on the configuration process is too much for this particular man page --- please see the FreeVR Admin Guide for specific details.

Self-documenting Applications

One of the on-screen information displays mentioned above is the ability to display some basic instructions on one of the screens to help a user figure out how to operate the application. This is primarily used to indicate how button presses and valuator inputs will affect the application.

Press the "9/PgUp" key on the numeric keypad to toggle the on-screen help. Note that whichever window has focus is the one on which the display will be toggled.  

Simulator Controls

When operating a FreeVR application in a simulator window, it is generally desirable to generate inputs to the application, and sometimes you will also want to adjust how the simulator renders the world. In fact, inputs and outputs are handled separately. Inputs affect the actual application as though the input had come from an actual position tracker or button or whatever input might be controlled by an immersed user. Whereas the window controls affect only the window with focus when they are activated, and the application will have no knowledge of the change.
* Simulated inputs
FreeVR simulated inputs have distinct input controls based on the style of input --- usually buttons, valuators or position trackers. When we speak of "simulated" inputs, we generally mean one type of physical input substituting for a different input when immersed, so frequently mouse buttons and key presses acting as wand button presses in the VR system, or mouse movements mimicking a joystick. However, for devices such as game controllers, the same device might be used both in the immersive system or when simulating an immersive display.

For position trackers, however, it is far more common that there is some type of simulated interface. In FreeVR the first position tracker is considered the "head" tracker, so is represented as a blocky head. The second tracker is usually the wand, so is represented as an elongated pyramid. All other trackers are represented as small boxes. All the position trackers can be moved around using a combination of key presses and mouse inputs, or possibly joysticks on a game controller.

By default, the simulator configuration of FreeVR uses the three mouse buttons as the first three buttons of input. The joystick is emulated by moving the mouse while holding down the "space bar". Moving around the trackers can be done in multiple ways. In general, the arrow keys can be used to move the "active" simulated tracker (aka "6-sensor") in the X-Z plane (or X-Y plane when the left-shift modifier key is held down). Rotations are with the "right home keys" movements that are familiar to users of the vi editing program (and other programs that have mimicked it's movement) ---

This table summarizes the default input controls:

  Button Input
* Esc --- button 0 (terminate button)
* left mouse --- application button 1
* middle mouse --- application button 2
* right mouse --- application button 3

  Joystick Input
* space --- map mouse location to joystick

  Sensor Translation
* up arrow --- move sensor forward in Z
* down arrow --- move sensor backward in Z
* left arrow --- move sensor left in X
* right arrow --- move sensor right in X
* f --- move sensor up in Y
* v --- move sensor down in Y
* q --- move the sensor in the X-Y plane with the mouse
* a --- move the sensor in the X-Z plane with the mouse
* left-shift --- swap the Y and Z movement controls
* 1 --- toggle between absolute and relative movement
* 2 --- toggle the space restriction on movement

  Sensor Rotation
* h --- rotate left about the Y axis (azimuth)
* j --- rotate down about the X axis (elevation)
* k --- rotate up about the X axis (elevation)
* l --- rotate right about the Y axis (azimuth)
* , --- rotate counterclockwise about the Z axis (roll)
* . --- rotate clockwise about the Z axis (roll)
* left-alt --- map the four arrow keys to azimuth and elevation rotations

  Sensor Selection
* n --- select the next sensor
* s --- select the head (skull) sensor
* w --- select the wand sensor

  Sensor Reset
* r --- reset sensor's location and orientation
* 8 --- reset all sensors' location and orientation

* Altering a simulated view
One option for viewing the virtual world is through a simulated view. A simulated view includes markers that indicate the position of the tracked 6dof sensors moving in the virtual space. By default, the virtual space is marked with translucent surfaces that represent a CAVE-like display of 10 feet cubed. Actual screens from the configuration file may also be represented as rose-colored outlines, if so-configured.

By default, keys on the numeric keypad can be used to alter the view into the virtual world, including options to toggle the simulated objects and the virtual world itself.

This table shows the default view controls:








The highlighted labels indicate controls that are available on all screens, not just simulated views --- and thus they can be displayed on a side wall in a CAVE for example.

NOTE: there are plans to rearrange some of the view controls for FreeVR version 0.6e.

NOTE: these and additional details are covered in the online User Guide:

Interface to Applications

One of the other unique features of FreeVR is the ability to query and change parameters of a running system through a socket interface. When the FreeVR configuration specifies the inclusion of a "telnet" process, then the telnet tool, or indeed any tool capable of communicating via sockets can send commands to any running FreeVR application. As mentioned above, the FreeVR distribution includes an example GUI tool that can be used to interface with application over a socket --- fvri.tcl (ie. the FreeVr Remote Interface).

One use of the socket interface is for debugging FreeVR applications and indeed the FreeVR library itself. However, it can also be used to shift between monoscopic and stereo rendering, or to send input events to an application --- perhaps even the input that causes the application to terminate.

To add a "telnet process" to the currently selected system of a FreeVR configuration, add this line at the end of the configuration process:

system $system += { procs += "default-telnet"; }

NOTE: if there already was a telnet process, this will add a second one.  


As a complex system with many option to configure, the FreeVR configuration system must be robust yet flexible to allow for the myraid ways in which a virtual reality system is put together. Learning how to configure an elaborate system takes effort, and perhaps some experimentation, but the FreeVR distribution includes several sources of information and assistance.  

Configuration Order of Precedence

The first thing to know is the hierarchy of configuration sources. There is an order in which configuration data is read and processed. This order of precedence allows the system to be organized to enable adjustments to be made for individual users, for specific applications, or for specific one-time needs.

The order of configuration parsing (with later sources overriding earlier sources on the list) is:

Built-in default configuration
$FREEVR --- i.e. the string contained in the environment variable
command-line arguments --- if the application passes them to FreeVR
hard-coded arguments --- the application itself can force some options (not recommended)

NOTE: any of these configuration inputs may themselves cause another configuration file to be read through the use of the "readconfig" command.


Sources of Configuration Information

Details of configuration can be more comprehensively documented in manuals where a lengthy description can be presented --- rather than in an overview manpage. FreeVR has a handful of sources one can turn to for details on how to configure a virtual reality facility for use with the FreeVR system.
* The VR Administrator's Guide
The FreeVR Administrator's Guide is an HTML document that describes the FreeVR configuration system, with details about each of the objects that are linked together to assemble a complete system (e.g. windows, input devices, processes), as well as the overall syntax.


* Explicit Backus-Naur specification
The FreeVR configuration is a fully specified grammar described in Extended Backus-Naur form. This description can be found in the file:

  - freevr.bnf

* Sample pre-written configurations
The FreeVR distribution comes with a handful of example configuration files. These files can all be found in the "etc" directory. Example files name in the form "rc_sample_<name>", where "<name>" might be "cave", "6dof, or "joydev". Plus one named "ks, which is the "kitchen-sink" of sample files. The kitchen-sink includes all sorts of examples and tests used to verify the operation of the configuration parsing, and as such does not always exemplify the best way of creating a configuration, but does offer the ability to see what can be done. The other named examples are trimmed to show how to accomplish specific systems.
* Configuration modification via socket commands
The FreeVR telnet/socket live network interaction feature can be used to interact with the configuration as well. The simplest interaction is simply to output the current configuration, which can be done in human or machine readable form:
  FreeVR> print config

This will output details of the running system that go beyond the minimal needs of specifying the configuration, but it can often be used to glean information about the system.

Other options include the ability to tweak the existing configuration when it appears to be nearly correct but just needs some slight adjustments. Currently, these commands are available:    FreeVR> set window[0] nudgex <distance>

  FreeVR> set window[0] nudgey <distance>

  FreeVR> set window[0] nudgez <distance>

Future versions of FreeVR will include additional commands.

* Configuration conversion software
Finally, there is a legacy application that was designed to assist administrators operating an original CAVEtm system to convert thier CAVE configuration files into a FreeVR file:

As the CAVE configuration files were generally simple and involved one-line descriptions of certain aspects of the facility, one could track down the documentation on how to use the legacy system and then convert it to FreeVR style. Of course, probably better to just learn how to create your own configuration.


Testing the system hardware

As part of setting up a new system, it is good practice to verify the operation of each of the components. To this end, the FreeVR distribution includes a suite of test programs to check the operation of some components of the system.

The most useful test programs are those that interface with input devices and daemons. To determine the current list of programs, compiled them with the "devtests" target:

% make devtests
The applications compiled are each designed to interface with a particular system, each with their own connection options. Fortunately, there is a manpage for each device, so look for the "man1 manpages --- they will also be listed in the section "1fv" intro manpage.

Under development, and included in the next version of FreeVR (0.6e), is a new "configurator" application that will enable VR administrators to more easily create a new configuration.  


Details of application building is well beyond the scope of an overview manpage. However, there are some good resources that can be pointed to:

* Sample application in the FreeVR distribution
The FreeVR distribution includes two sample applications:
travel --- the "travel" application is a mostly constant world filled with colorful boxes and pyramids. A single white-pyramid has been placed in the virtual world, and thus allows the user to travel relative to that one object using the joystick. All the other objects are placed in the real-world (and therefore don't actually travel), but are positioned in strategically interesting locations for testing inside a CAVE or other virtual reality display.
inputs --- the "inputs" application, as mentioned elsewhere, simply gives a live presentation of all the inputs received by the configured virtual reality system. This alone has great value, but "inputs" also serves well as an input server/repeater.
* Extensive API reference manual
The FreeVR webpage includes an extensive API reference manual, know as the "Function Reference":

This page has all (or at least all the important) application programmer functions in a categorized list with links to each specific function. Until there are manpages for each function, this is the definitive reference for programming FreeVR. Of course, the HTML documentation is included in the FreeVR distribution.

* OpenGL or Graphics system references
Writing a FreeVR application will require sufficient knowledge of OpenGL, or at least a good high-level scenegraph such as the OpenSceneGraph library, that it will be beneficial to be versed in the usage of the graphical API of choice.

BTW, for refering to coordinate systems, FreeVR uses the native coordinate system of OpenGL, which is Y-up. For the Performer scenegraph this was converted to Z-up, as that is the usage of the Performer library. However, OpenSceneGraph does not operate from a specially modified version of FreeVR, so it too operates in a Y-up coordinate system.

* Extensive tutorials
There are extensive tutorials for writing FreeVR applications using the OpenGL API. There are also a serials of tutorials that were developed for the Performer API, but these are slowly being ported to OpenSceneGraph. There are also tutorials under development for the OpenDynamicsEngine (ODE) physics engine.

The FreeVR webpage includes most of these tutorials as downloadable archives:

* Real applications
There are a handful of FreeVR applications available for download on the web. Two of the most notable are:
vmd --- the "vmd" (Visualization of Molecular Dynamics) application is, as the name implies, a tool for rendering molecules. It is especially good at rendering huge molecules, and rendering them dynamically. It has a FreeVR interface that allows one to view molecules dynamically, with all the powerful options of VMD available on the command line, or through mapped button inputs.
CQ3A --- the "CQ3A" (CAVE Quake III Arena) application uses the Aftershock Quake-III world rendering engine to display those worlds life-size with the ability to walk and fly through them. It does not include game play, so it works mostly as a tool for traversing a game map, including maps created by the Quake community.


As mentioned in the section on the distinctive features of FreeVR, FreeVR, or more specifically really any FreeVR application has the capacity to behave as a server for I/O devices. Naturally, as a virtual reality library, FreeVR can interface with a myriad number of I/O devices, but by including the ability to also be a producer of I/O data streams, a configuration can be created that reads inputs from any number of devices and then streams the data out using one of the available protocols. Presently, those protocols are the Vrui VRDeviceDaemon (for Vrui versions 1.x, 2.x or 3.x), and the shared memory interface of the ANL tracker daemon, also known as TrackD.

Of course, it makes little sense to use a complicated application when the purpose is the side effect of the configuration to act as an input repeater, so the FreeVR package includes an application with a minimal virtual world that is intended to be used as an I/O server --- inputs(1FV). The inputs program simply renders a scene that displays information about the current state of the inputs read by the system.  


When a FreeVR application is executed, there are a handful of environment variables whose values have an effect on how the initial configuration process will take place:

The root directory of the FreeVR installation, and used to read a system-wide configuration file:

The user's home directory, which is used to look for a user-specific configuration file:

Note, the user-specific configuration file is read after the system-wide configuration, and thus can override any of the configuration parameters in a user customizable way.

The FREEVR environment variable can be set to contain a configuration string, which is applied to the configuration settings after the user-specific file is read, and thus can override options the user normally prefers.

By using an environment variable, a user can have a settings that are specific to a particular command shell, and all application run from that shell will have these unique parameters. This can also be a way to provide certain command settings when applications are run from a menuing system --- for controlling stereo rendering for example.

Set level of debugging output that a FreeVR application will generate. Setting this value happens last, and thus none of the other means of reading configuration commands will override this setting --- hence the NO tag.
Set an extra, exact level of debugging output that a FreeVR application will additionally generate, in addition to all messages at or below the general debug-level. Setting this value happens last, and thus none of the other means of reading configuration commands will override this setting --- hence the NO tag. <!-- TODO: add info about "VRSERIAL_DEBUG" and "VRSERIAL_USEC" environment variables. -->


A change in the behaviour of the XOrg implementation of X-Windows after version (which happens to correspond with Fedora 11) occurred. This change has caused the method of simulated position input controls to function abnormally --- only keyboard key releases are recognized (not presses). A work-around has not yet been tracked down.

On some systems when a FreeVR application crashes it may leave behind shared memory segments. Sometimes it may be necessary to clean these up to prevent a deprivation of system resources. To do this, a shell script has been created that will handle this automatically --- ipcrms.  


As with any large application, there is a lengthy list of minor bugs to eradicate and new features to implement that have yet to be handled. FreeVR, of course, is no different.

Some of the major features that are just over the horizon include:

* Provide an application/utility to assist with configuration.
* Create a native MS-Windows version.
* Create a cluster interface.
* Write man pages for all the API functions.


inputs(1FV), travel(1FV), freevrrc(5FV), wiimote(7FV), intro(1FV), intro(3FV)

The FreeVR web site:

Here is the most current citation to use when citing FreeVR:

William R. Sherman, Daniel S. Coming, Simon Su, “FreeVR: Honoring the past, Looking to the future”, In IS&T/SPIE Electronic Imaging. International Society for Optics and Photonics (SPIE), 2013.


Copyright 2013, Bill Sherman, All rights reserved.



Rendering Library Options
Input Options
Operating System Options
Distinctive Features
What FreeVR is Not
Documentation and Tutorials
Self-documenting Applications
Simulator Controls
Interface to Applications
Configuration Order of Precedence
Sources of Configuration Information
Testing the system hardware

This document was created by man2html, using the manual pages.
Time: 05:02:19 GMT, December 13, 2013