1 / 10

Writing VR Juggler Applications

Writing VR Juggler Applications. Glenn G. Chappell CHAPPELLG@member.ams.org U. of Alaska Fairbanks CS 481/681 Lecture Notes Wednesday, February 18, 2004. Review: VR Programming [1/4]. The CAVE

risa
Download Presentation

Writing VR Juggler Applications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related