Writing VR Juggler Applications

1. Writing VR Juggler Applications Glenn G. ChappellCHAPPELLG@member.ams.org U. of Alaska Fairbanks CS 481/681 Lecture Notes Wednesday, February 18, 2004

2. Review:VR Programming [1/4] • The CAVE • Developed in the early 1990’s at the Electronic Visualization Laboratory at the U. of Illinois at Chicago. • Theater-style, roughly cubical. • Multiple flat, rectangular screens (“walls”). • 3-D input is a mouse-like “wand”. • Stereo done using shutter glasses. • Our main VR display is a Mechdyne MD Flex, which is based on the CAVE. CS 481/681

3. Review:VR Programming [2/4] • VR programming usually involves a specialized VR library. • The VR library plays a role similar to that of GLUT. • We still use OpenGL for frame rendering. • We do not use GLUT (except possibly glutSolidTorus, etc.). • VR libraries generally handle: • Creation & sizing of windows, viewports, OpenGL contexts. • Interfacing with VR input devices. • Setting projection & model/view matrices for the user’s viewpoint. • Creation & management of multiple processes or threads. • Including inter-process communication, shared data spaces, etc. • Callback registration and execution. • Or some other way of getting the display code executed when necessary. • Dealing with varying display hardware. • E.g., we can change the number of screens without recompilation. • Handling stereo. • Networking of some sort (sometimes). CS 481/681

4. Review:VR Programming [3/4] • We will be using a VR library called VR Juggler. • Development team led by Carolina Cruz-Neira, formerly of CAVE team at EVL, now at the VR Applications Center, Iowa State. • Under active development. • Open-source. • Written in C++. • Works with varying hardware and CG libraries (including OpenGL). • Uses threads, not processes. • Computation & display, as with CAVELIB. CS 481/681

5. Review:VR Programming [4/4] • VR Juggler execution is based on the idea of a frame. • Each frame, the major callbacks are called once. • The draw callback is called once per wall-eye. • Because of this synchronization: • Locks are unnecessary. • Make sure that neither draw nor intraFrame accesses a variable that the other writes to. • Synchronization of computation with drawing is very easy. • It is automatic, in fact. • Long computations spanning many rendering cycles are tricky. • With CAVELIB, on the other hand, this is very easy. Start of Frame preFrame intraFrame draw draw postFrame End of Frame CS 481/681

6. Writing VR Juggler Applications:Introduction • Now we discuss how to write a VR Juggler program. • We are using: • VR Juggler (“VRJ”) 2.0. • This is the latest version. • Our primary environment is SGI Irix. • This is what igie (the computer that drives the Discovery Lab) runs. • But VRJ runs everywhere. You are welcome to run it elsewhere. • You might want to see Don Bahls <bahls@arsc.edu> for help. • We have found VRJ to be: • Robust  • It works fine. Crashes are generally our code, not theirs. • General  • It is supposed to work with just about any sort of platform, input devices, display, etc. This promise appears to be a reality. • Somewhat Complex to Program With  • Our sample applications separate out the complexity into other files that need only minimal changes (or sometimes no changes). • Quite Difficult to Set Up  • However, we have done most of the hard work for you (on Irix …). CS 481/681

7. Writing VR Juggler Applications:VRJ Application • When we program with VRJ, we write a “VR Juggler Application”. • A VRJ Application (“app”) is a C++ object. • Member functions are callbacks. • We start VRJ independently of the app. • To launch an app, pass an instance of it to VRJ. • This is usually done in main. • So the “main program” isn’t much. • We can stop an app and launch another one without stopping VRJ. • I’ve never done this, though … CS 481/681

8. Writing VR Juggler Applications:simpleApp— Structure • Now we look at simpleApp, a small VRJ app class. • This is intended as a starting point for VRJ app’s. • Files • TRANSF headers: vecpos.h, transf.h • These are required. • User class: jugglerUser.h, jugglerUser.cpp • Provides simplified interface to VR input devices. • Uses TRANSF. • App code: simpleApp.h, simpleApp.cpp • These files define the simpleApp class. • An instance of this class is a VR Juggler application. • This (especially simpleApp.cpp) is the interesting stuff. • Main program: main.cpp • Some boring code that starts up VRJ and launches an instance of simpleApp. CS 481/681

9. Writing VR Juggler Applications:simpleApp— Code • Now we look at the code for simpleApp. • In class we went over the code in the various files. CS 481/681

10. Writing VR Juggler Applications:Files & Changes • Here are the changes to make to simpleApp when writing your own app: • No Changes • TRANSF headers: vecpos.h, transf.h • User-class files: jugglerUser.h, jugglerUser.cpp • Very Minimal Changes • “Main program”: main.cpp • Include your app header (filename) and launch your app (class name). • Make file: Makefile • Change filenames so your app is compiled. • Small Changes • App header: simpleApp.h • Copy to a file with a different name. • Change class name to name of your app class. • Prototype only those functions you define. • BIG Changes • App source: simpleApp.cpp • Copy to a file with a different name. • Change class name to name of your app class. • Include your app header. • Write code for your app! CS 481/681