|
|
Guide to Porting a Desktop Application to Cluster VR
|
|
|
This document is intended to be a rough guide to porting a desktop
application that uses OpenGL to a virtual reality application operable
on either an SMP machine or a cluster using a toolkit such as VR Juggler
2.0.
|
|
|
The End Goal
|
|
|
The end product of this guide is a VR-Juggler based application that is
capable of running in a commodity cluster. The goal is also to have GUI
input to the VR application from a network-connected desktop PC.
|
|
|
Step 1: Examine Your Application
|
|
|
There are a few key features that make an application easily portable to
VR:
|
|
|
1. Is the GUI separable from
the OpenGL viewport(s)?
|
|
If the application can run without a GUI, it is already part of the way
to a working VR product. If not, then the GUI must be separated from
the OpenGL drawing code. No data that needs to be drawn should be
stored in widgets, nor should the draw loop check for the state of a
widget.
|
|
|
2. Is the draw loop read-only?
|
|
When applications are written with a single OpenGL window in mind, it is
easy to fall in the habit of changing data from within the draw loop.
For example, a counter may be incremented within your draw loop. This
practice does not play well with VR rendering because the draw function
may be called multiple times from multiple threads within a given frame
of execution.
|
|
|
3. Is there a command
interface (i.e. a scripting language) that operates on the scene?
|
|
Some applications issue commands straight from GUI callback functions
. Others go through a text-based command interface, where the GUI
issues a command to the core application, which then executes the
command. This question is an extension of the "is the GUI separable"
question that is asked above. If no such command interface exists, it
is recommended to create one to make the transition to VR go smoothly.
|
|
|
4. Does the application
require mouse interaction with the OpenGL window?
|
|
This is a more subjective question. However, it is one that is worth
some consideration. Basically, the question is what will be shown on
the remote PC for input? If we show just the GUI widgets, the end
product may be a little simpler. If we need the OpenGL viewport as well
, there will be an extra step in the implementation. If the application
requires interaction with the OpenGL window, we may need to port
selection methods that make use of the window dimensions to a more
portable 3-D version (e.g. ray-cast through a scene).
|
|
|
Step 2: Implementation
|
|
|
Assuming the answers to questions 1, 2, and 3 above are all "yes", then
the application sounds like a good candidate for porting to VR.
|
|
|
Now, here is a rough step-by-step guide to implementation:
|
|
|
1. Port the Event Loop to
VR Juggler
|
|
This step involves creating a VR Juggler application class and filling
in the functions with the appropriate code for the application. VR
Juggler will call the functions at run-time, so we don't have to worry
about setting up an event loop; we just have to play by Juggler's rules
. VR Juggler has a predefined set of functions where events should
happen. For example, the preFrame function is called once per execution
frame before any viewports are drawn. This is a good function for
putting in wand-based interaction and command processing code. The
draw function is called once per viewport, and this is where all the
OpenGL code should go. Avoid changing any data in the draw function
because doing so can result in strange behavior.
|
|
|
2. Make the command processing
cluster-friendly
|
|
VR Juggler's clustering capability provides an ApplicationData object to
share data other than tracking and button input, which is automatically
shared. This object should be used to distribute commands from a master
node to the other nodes on a cluster.
|
|
|
3. Network-enable the command
interface
|
|
If your application isn't going to have an OpenGL window as part of the
GUI component, then disregard this step. Instead, you can make the GUI
run in a separate thread on your master node and set the display back
to an X-Windows host somewhere on your network. You could do this
anyway, but performance of the GUI would suffer.
|
|
|
Conclusion
|
|
|
Porting an application to VR does not have to be too difficult,
especially if the application already has some key features to make the
transition easier. The above process gives good performance on a
commodity cluster, and it is a process that can be applied to a wide
range of 3-D applications.
|
|
top of page
|
|
