FREEVR

NAME

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

DESCRIPTION

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 can be configured as interfaces.  

Rendering Library Options

Over time FreeVR has been interfaced with a handful of these higher-level graphics APIs. Of these OpenSceneGraph and ANARI have been most currently tested. (The ANARI effort still requires more work. Also, the Delta3D, and Iris Performer libraries are deprecated, and the OpenSG seems like it might be as well.)

Input Options

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 and the Vrui VRDeviceDaemon.

Here are examples from each of these categories:

Many of the modern game controllers and similar devices are handled by the Linux joydev and evdev (aka evio) interfaces. And devices such as the Nintendo "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

Distinctive Features

• 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(5FV) 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. Also, 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: the VRPN protocol, ANL's original Tracker Daemon, the Vrui VRDeviceDaemon, a CSV (comma-separated value) stream, or the remote control interface of the Monado OpenXR runtime. 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: for example, reading Valve/HTC Vive Lighthouse tracking with the VruiDD system to feed the Monado OpenXR runtime.

Output Stream Protocol VRPN VruiDD Monado OpenXR remote ANL TrackD CSV

Another benefit of the output capability of FreeVR is that these can be used to record, and later play-back the inputs that were sent to a VR application. In theory, this play-back can be used to post-analyze what happened during a VR interactive session. Or the movement data can be independently analyzed. How to accomplish recording and play-back is covered in the FreeVR User's Guide.

• 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 of 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.

Under development are a pair of tools to assist with creating a calibrated configuration file for easier creation of optimal configuration parameter settings.

• 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 (www.freevr.org), which has a user's 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 several manpages available, and new ones under development.

What FreeVR is Not

• A Scenegraph Library

Beyond providing the perspective matrix on the stack, the ability to control a distinct matrix for each user's position in the virtual world, 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 available for the developer.

• 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 than 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

• User's Guide
• Application Development Guide
• Function Reference Manual
• Administrator's 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 freevr.org webpage.  

COMPILING

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>

By default, when providing no value for <architecture>, make will simply return a short list of possibilities (same as the "list" target). On modern Linux, the standard target is "linux2.6-glx-64", and indeed there are two synonym targets for that system: "linux", or even "default" will compile that version. Four other shortcut options are "make pt" to compile the pthreads variant, make st to compile the single-thread variant, make macos to compile the darwin-X-glx" version, and "make cygwin" to compile a Cygwin version on MS-windows. For other options, you can get a list of what <architectures> are available with the "make list" command:

% make list
 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 
linux2.6st-glx-64 Linux 2.6 (64b arch) OpenGL and GLX with single threading
------------------------------------------------------
Type 'make <arch>' to build for an architecture listed above.

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

% make linux2.6-glx-64

% make linux

You'll notice that in addition to choosing an OS, and the memory addressing range (32 or 64 bit), for Linux there are also the "pt" and "st" options. When the "pt" option is specified, it determines whether the sharing of data between processes is done using pthreads, versus 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. The "st" option indicates that the library should be compiled for single-threaded operation, which uses no process spawning, nor shared memory. The single-thread variant is typically used for debugging purposes.

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 changes have been sufficiently stable as far as FreeVR's needs are concerned that any version of Linux from 2.6 on will work as the target OS for FreeVR. Thus Linux 3.0 kernels as well as Linux 4.x kernels are fully compatible.  

Dependencies

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)

RUNNING APPLICATIONS

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:

1. Run your application in "simulator" mode, which is often a good first step when testing out an application as it is being developed, or
2. Learn how to 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

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

• 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/controller 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. Usually, all other trackers are represented as small boxes. (During some tests, the inputs(1fv) program will augment the simulator to show two position trackers as pyramids to mimic an HTC Vive setup.) 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/vim editing program (and other programs that have mimicked it's movement) — 'h', 'j', 'k', and 'l'.

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 (center = 0,0)

  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 (the first one)

  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:

Num / * - Lock show FPS zoom window osd in 7/Home 8 9/PgUp + jump rotate stats zoom home down osd out 4 5 6 rotate reset rotate right view left 1/End 2 3/PgDn Enter world rotate input set  objects up osd home 0/Ins ./Del simulator help  objects osd

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. Also, the "show window" flag can be activated on any window, but the results are only visible in a simulated view.

NOTE: these were slightly rearranged for FreeVR version 0.6f.

There are currently three other function keys that can be used to affect the behavior of a running application. These are mostly used for debugging, but are included here for completeness:

F10 F11 F12 reinit continual one jump to gfx user's view user's view

To reinitialize the graphics is to call the startup callback for rendering the world — typically the application will not expect this, but might be helpful in debugging. The F11 and F12 both cause the simulator view to jump to a location where the simulated user's head would be viewing. In the case of F11 this will continue until toggled off again, whereas for F12 it will only happen once per keypress.

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

http://freevr.org/user_guide.html

Interface to Applications

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 these two lines at the end of the configuration process:

if (numberprocsoftype("$system, telnet") == 0)

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

NOTE: the conditional is to ensure that when the configuration already has a telnet process, this will not add an additional one to the system.  

CONFIGURATION

Configuration Order of Precedence

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

1)

Built-in default configuration

2)

$FREEVR_HOME/.freevrrc

3)

$HOME/.freevrrc

4)

$FREEVR — i.e. the string contained in the environment variable

5)

command-line arguments — if the application passes them to FreeVR

6)

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

• 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.

  - http://www.freevr.org/vradmin_guide.html

• 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>


   FreeVR> set inputdevice[0] nudget2rwA <x-rot> <y-rot> <z-rot>


   FreeVR> set inputdevice[0] nudget2rwT <x> <y> <z>


   FreeVR> set input <6-sensor name> nudger2eA <x-rot> <y-rot> <z-rot>


   FreeVR> set input <6-sensor name> nudger2eT <x> <y> <z>

• Configuration conversion software

Finally, there is a legacy application that was designed to assist administrators operating an original CAVE™ system to convert thier CAVE configuration files into a FreeVR file:
  % bin/cave2fvr <cave configuration 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

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 this version of FreeVR (0.7), is a new "configurator" application that is being created to enable VR administrators to more easily create a new configuration. However, it is still under development, so is only partially operational at this time.  

BUILDING APPLICATIONS

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 applications 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":
  - http://www.freevr.org/functions.html

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. All 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 referring 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 series 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:
  - http://freevr.org/tutorials.html

• 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 massive 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.

DEVICE SERVER

As mentioned in the section on the distinctive features of FreeVR, FreeVR, or more specifically indeed, 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 VRPN vrpn_server, the Vrui VRDeviceDaemon (for Vrui versions 1.x, 2.x or 3.x), the shared memory interface of the ANL tracker daemon, also known as TrackD, and a stream server that can either output CSV (comma-separated values) or the Monado OpenXR runtime remote control protocol.

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 the aforementioned
 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.  

ENVIRONMENT VARIABLES

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:

FREEVR_HOME

The root directory of the FreeVR installation, and used to read a system-wide configuration file:
  $FREEVR_HOME/.freevrrc

HOME

The user's home directory, which is used to look for a user-specific configuration file:
  $HOME/.freevrrc

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.

FREEVR

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.

FREEVR_DEBUGLEVEL_NO

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 (No Override) tag.

FREEVR_DEBUGLEVEL_NO

Similar to FREEVR_DEBUGLEVEL_NO, this environment variable sets the level of debugging output that a FreeVR application will generate. However, unlike the NO (no override) variable this value is used to set a default debug level at the beginning of the configuration process, so any subsequent settings will take precedence.

FREEVR_DEBUGEXACT_NO

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 (No Override) tag.

FREEVR_DEBUGLEVEL_NO

Similar to FREEVR_DEBUGEXACT_NO, this environment variable sets the extra level of debugging output that a FreeVR application will generate. However, unlike the NO (no override) variable this value is used to set a default debug level at the beginning of the configuration process, so any subsequent settings will take precedence.

BUGS

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.

Occasionally, a FreeVR application may hang during startup. This is intermittent, which means trying to run it again right away should allow the application to run fine, and being intermittent, it has been a difficult bug to eradicate. (Likely there is a race condition during initialization.)  

TODO

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:

• Improve the VRPN output service.

• Improve the ANARI rendering interface.

• Develop HMD lens correcting distortion routines.

• Further develop the configuration assistance utilities.

• Create a native MS-Windows version.

• Create a cluster interface.

• Write man pages for all the API functions.

SEE ALSO

inputs(1fv), travel(1fv), freevrrc(5FV), telnet(7fv), wiimote(7fv), intro(1fv), and intro(3fv).

Web sites of interest:

• FreeVR — http://www.freevr.org

• OpenXR — https://www.khronos.org/openxr

• ANARI — https://www.khronos.org/anari

• VRPN — https://github.com/vrpn/vrpn/wiki

• VRUI — https://web.cs.ucdavis.edu/~okreylos/ResDev/Vrui

• Monado — https://monado.dev

• OpenSceneGraph — https://www.openscenegraph.com

• Coin3D — https://www.coin3d.org

• OpenSG — https://web.archive.org/web/20170806213018/http://www.opensg.org

• Delta3D — http://web.archive.org/web/20160703023414/http://delta3d.org

Here is the preferred 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

Copyright 2024, Bill Sherman, All rights reserved.

Index

NAME

DESCRIPTION

Rendering Library Options

Input Options

Operating System Options

Distinctive Features

What FreeVR is Not

Documentation and Tutorials

COMPILING

Dependencies

RUNNING APPLICATIONS

Self-documenting Applications

Simulator Controls

Interface to Applications

CONFIGURATION

Configuration Order of Precedence

Sources of Configuration Information

Testing the system hardware

BUILDING APPLICATIONS

DEVICE SERVER

ENVIRONMENT VARIABLES

BUGS

TODO

SEE ALSO

COPYRIGHT