1 / 21

More TRANSF, VR Programming

More TRANSF, VR Programming. Glenn G. Chappell CHAPPELLG@member.ams.org U. of Alaska Fairbanks CS 481/681 Lecture Notes Monday, February 16, 2004. Review: Representing T’formations [1/4]. 4  4 Matrices Very general. Good for a pipeline! Too general?

clem
Télécharger la présentation

More TRANSF, VR Programming

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. More TRANSF, VR Programming Glenn G. ChappellCHAPPELLG@member.ams.org U. of Alaska Fairbanks CS 481/681 Lecture Notes Monday, February 16, 2004

  2. 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. CS 481/681

  3. 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: • i2 = j2 = k2 = –1. • ij = k; jk = i; ki = j. • ji = –k; kj = –i; ik = –j. CS 481/681

  4. 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. CS 481/681

  5. 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. CS 481/681

  6. 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. CS 481/681

  7. 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; CS 481/681

  8. 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; CS 481/681

  9. 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 CS 481/681

  10. 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. CS 481/681

  11. 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); CS 481/681

  12. 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); CS 481/681

  13. 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. CS 481/681

  14. 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. CS 481/681

  15. 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. CS 481/681

  16. 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). CS 481/681

  17. 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! CS 481/681

  18. 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. CS 481/681

  19. 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. CS 481/681

  20. 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. Start of Frame preFrame intraFrame draw draw postFrame End of Frame CS 481/681

  21. 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. CS 481/681

More Related