QVR 4.1.0
A library to build Virtual Reality applications
|
QVR provides the base class QVRApp for Virtual Reality applications. An application implements the subset of QVRApp functions that it needs. See QVRApp for function descriptions.
To run a QVR application, the main() function creates and initializes a QVRManager instances and then calls QApplication::exec() as usual. See QVRManager for a minimal code example.
The QVRManager manages three basic types of objects: observers, processes, and windows:
All QVR applications support a set of command line options. The most important option lets the user choose a configuration file. See QVRManager::QVRManager(). The same application binary can run on different Virtual Reality display setups by specifying different configuration files.
To get started, see the main descriptions of QVRManager and QVRApp, and then look at the source code of an example application to understand how it is implemented.
A configuration file defines the observers, processes, and windows that the QVRManager will manage.
Each observer, process, and window definition is mapped directly to the QVRObserverConfig, QVRProcessConfig, or QVRWindowConfig classes.
A configuration file starts with a list of observers and their properties.
After that, the list of processes starts. There is always at least one process: the main process. The main process is connected to the display that Qt initially uses by default; if a different display is configured, the main process will be relaunched automatically to take this into account. Child processes typcially connect to different displays. Optionally, a launcher command can be specified, e.g. to run a child process on a different host using ssh.
Each process definition contains a list of windows for that process. Since windows provide views into the virtual world, the geometry of the screen wall represented by a window must be known. This geometry is either given by screen wall center coordinates, or by coordinates for three of its corners.
Please see the configuration file examples distributed with QVR to understand how typical configurations look like.
Device definition (see QVRDevice and QVRDeviceConfig):
device <id>
tracking <none|static|oculus|openvr|vprn>
none
.buttons <none|static|gamepad|vprn|oculus|openvr>
none
.analogs <none|static|gamepad|vrpn|oculus|openvr>
none
.Observer definition (see QVRObserver and QVRObserverConfig):
observer <id>
navigation <stationary|vrpn|wasdqe|custom> [parameters...]
stationary
.navigation_position <x> <y> <z>
0 0 0
.navigation_forward <x> <y> <z>
0 0 -1
.navigation_up <x> <y> <z>
0 1 0
.tracking <stationary|vrpn|oculus|custom> [parameters...]
stationary
.eye_distance <meters>
0.064
.tracking_position <x> <y> <z>
0 0 0
.tracking_forward <x> <y> <z>
0 0 -1
.tracking_up <x> <y> <z>
0 1 0
.Process definition (see QVRProcess and QVRProcessConfig):
process <id>
ipc <tcp-socket|local-socket|shared-memory|auto>
auto
.address <ip-address>
launcher <prg-and-args>
display <name>
sync_to_vblank <true|false>
true
.decoupled_rendering <true|false>
false
.Window definition (see QVRWindow and QVRWindowConfig):
window <id>
observer <id>
output <center|left|right|stereo|red_cyan|green_magenta|amber_blue|oculus|openvr|googlevr>
center
.display_screen <screen>
-1
(which means the default screen).fullscreen <true|false>
Whether to show the window in fullscreen mode. Default: false
.position <x> <y>
-1 -1
(which means automatic positioning).size <w> <h>
800 600
.screen_is_fixed_to_observer <true|false>
true
.screen_is_given_by_center <true|false>
true
.screen_center <x> <y> <z>
0 0 -0.5
.screen_wall <blx> <bly> <blz> <brx> <bry> <brz> <tlx> <tly> <tlz>
0 0 0 0 0 0 0 0 0
.render_resolution_factor <factor>
1.0
.The QVRManager creates an invisible main OpenGL context for each process. This context is used for all calls to QVRApp application functions: the application only has to deal with this one context. The rendering results are directed into a set of textures that cover all the windows of the process.
When all window textures have been rendered, they are put on screen by the actual visible windows who all have access to the textures from the main window. The windows themselves render in separate rendering threads. On buffer swap, only these rendering threads block. The main thread fills the waiting time with CPU work such as processing events and calling the QVRApp::update() function of the application.
The process initially started by the user is the main process. QVRManager launch child processes as required by the configuration file, and it will handle all necessary synchronization and data exchange with these child processes.