More TRANSF, VR Programming Glenn G. Chappell U. of Alaska Fairbanks CS 481/681 Lecture Notes Monday, February 16, 2004

16 Feb 2004CS 481/6812 Review: Representing T’formations [1/4] 44 Matrices Very general. Good for a pipeline! Too general? Tough to retrieve info about “the rotation” when you cannot even be sure it is a rotation. 16 numbers. Angle-Axis Nice way to specify rotations. A bit nasty for computation involving rotations (composition, etc.) Euler Angles (roll, pitch, yaw) (also: x rotation, y rotation, z rotation) Ick! Ick, ick, ick, ick! Quaternions Great for computation. Compact. Easy to convert to other forms. Best (IMHO) all-around representation, if you only need to represent rotations.

16 Feb 2004CS 481/6813 Review: Representing T’formations [2/4] The quaternions are a generalization of complex numbers. Three square roots of –1: i, j, k. Quaternions are of the form a + bi + cj + dk, for a, b, c, d real numbers. Addition, subtraction are as usual (component-wise). For multiplication: i 2 = j 2 = k 2 = –1. ij = k; jk = i; ki = j. ji = –k; kj = –i; ik = –j.

16 Feb 2004CS 481/6814 Review: Representing T’formations [3/4] We can think of the i, j, k part of a quaternion as a 3-D vector. So a quaternion is a real number plus a vector: a + u. a is the real part. u is the vector part or pure part. Addition: (a + u) + (b + v) = (a + b) + (u + v). Multiplication: (a + u)(b + v) = (ab – u·v) + (av + bu + uv). We represent a rotation of an angle α about an axis u (unit vector) as a quaternion as follows: With this representation, composition of rotations is just multiplication.

16 Feb 2004CS 481/6815 Review: Representing T’formations [4/4] A transformation of a rigid 3-D body can be modeled as: A rotation about a line through the origin … Followed by a translation. Putting these together, we can represent anything a rigid body can do: Any translation. Any rotation. Corkscrew motions as well.

16 Feb 2004CS 481/6816 Review: The TRANSF Package TRANSF defines 6 classes, organized as follows: TRANSF has two source files: vecpos.h Defines and implements classes vec & pos. transf.h Defines and implements classes rot, orient, transf, frameref. Also #include ’s vecpos.h. All classes and global functions are placed in namespace tf. There is also a file tfogl.h. This is an experimental OpenGL interface. RelativeAbsolute vecpos rotorient transfframeref

16 Feb 2004CS 481/6817 More TRANSF: Classes vec & pos [1/2] Class vec can be thought of as: An array of three double ’s. A 3-D vector. A translation. Class pos : An array of three double ’s. A point in 3-D space. We can do the usual operations: vec v1, v2, v3; pos p1, p2; double d; d = dot(v1, v2); v3 = cross(v1, v2); p2 = p1 + v1; v3 = v1 + v2; v3 = 3. * v1; v3 = p1 – p2;

16 Feb 2004CS 481/6818 More TRANSF: Classes vec & pos [2/2] Certain operations are not defined. These allow you to catch bugs during compilation. vec v1, v2; pos p1, p2; double d; // Each of the following lines results in an error: dot(p1, p2); cross(p1, p2); 3. * p1; v1 – p1; p1 + p2; d + v1; v1 = p1;

16 Feb 2004CS 481/6819 More TRANSF: Classes rot & orient Class rot represents a rotation. rot r(30, vec(1,1,0)); // r is a rotation of 30 degrees about the line // through the origin and the point (1,1,0) Just as pos is an “absolute” version of vec, orient is an absolute version of rot. orient x(30, vec(1,1,0)); // The orientation resulting from applying the // above rotation to the standard orientation

16 Feb 2004CS 481/68110 More TRANSF: Classes transf & frameref Class transf represents a rigid 3-D transformation. It is specified as a rotation ( rot ) followed by a translation ( vec ). rot r; vec v; … transf t(r, v); Class frameref is an absolute version of class transf.

16 Feb 2004CS 481/68111 More TRANSF: Transformations There are three transformation classes: vec, rot, transf. They can be composed: v3 = compose(v1, v2); r3 = compose(r1, r2); t3 = compose(t1, t2); They can be inverted: v2 = v1.inverse(); They can be applied to vec ’s, pos ’s, their own type, and their own absolute type. p2 = r1.applyto(p1);

16 Feb 2004CS 481/68112 More TRANSF: Examples This method of dealing with transformations makes certain operations very easy. Recall (from 381) the problem of determining where the viewer is. The viewer lies at the location that model/view puts at the origin. So we need to apply the inverse of model/view to the origin. Now we can just do it: transf mv; // Holds model/view transformation … const pos origin(0.,0.,0.); pos whereami = mv.inverse().applyto(origin); In which direction is the viewer looking? const vec negz(0., 0., -1.); vec lookdir = mv.inverse().rotpart().applyto(negz);

16 Feb 2004CS 481/68113 More TRANSF: Using with OpenGL To use TRANSF with OpenGL, try tfogl.h. Comments on this file are very welcome! Examples: pos p; vec n, v; rot r; transf t; glNormal(n); glVertex(p); glTranslate(v); glRotate(r); glTransform(t); // Hopefully it is obvious what this // should do.

16 Feb 2004CS 481/68114 VR Programming: Review from 381 Recall (from CS 381): In Virtual Reality, we want to give users the sense that they are inside a computer-generated 3-D world. This is called the sense of presence. We accomplish this using: 3-D display Head tracking For proper perspective, etc. Some kind of 3-D input device An environment that surrounds the user, and which the user can walk around in (literally). VR hardware comes in two categories: Head-mounted. Theater-style.

16 Feb 2004CS 481/68115 VR Programming: Hardware 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.

16 Feb 2004CS 481/68116 VR Programming: Libraries 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).

16 Feb 2004CS 481/68117 VR Programming: The CAVE Library The CAVE team developed a VR library: the CAVE Library. Now a commercial product: CAVELIB, sold by VRCO. Written in “C”, and similar to GLUT in many ways. Works with varying hardware and CG libraries (including OpenGL). For each frame, a display callback is called twice for each wall. Or once per wall, if in mono. Multiple processes: Computation Runs main program. Unlike with GLUT, application maintains overall control. Tracking Manages input devices. Does not execute user code. Display There may be several of these (one for each wall?). Executes display callback. Processes communicate via shared memory, read & write locks. Input-device data gotten via function calls, not callbacks. No events!

16 Feb 2004CS 481/68118 VR Programming: VR Juggler — Introduction 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.

16 Feb 2004CS 481/68119 VR Programming: VR Juggler — Coding Programmer writes an object called a “VR Juggler Application”. Member functions are callbacks. Everything is done via callbacks. As with GLUT, application gives up overall control. Display threads all execute draw. Main/computation thread is synchronized with display, executes preFrame, intraFrame, postFrame. Input-device management is synchronized also. Devices are read once per frame. Data is available via function calls.

16 Feb 2004CS 481/68120 VR Programming: VR Juggler — Frame Execution 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. preFrame intraFramedraw postFrame draw Start of Frame End of Frame

16 Feb 2004CS 481/68121 VR Programming: VR Juggler — Our Addition We have written a C++ class to aid with input-device interfacing in VR Juggler: jugglerUser. Written by Don Bahls and (theoretically) myself. Includes functions for getting info from various input devices. Returns TRANSF types.