Upload
gloria-mcdaniel
View
213
Download
1
Embed Size (px)
Citation preview
More TRANSF, VR Programming
Glenn G. [email protected]
U. of Alaska Fairbanks
CS 481/681 Lecture NotesMonday, February 16, 2004
16 Feb 2004 CS 481/681 2
Review:Representing T’formations [1/4] 44 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 2004 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.
16 Feb 2004 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 + uv). 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.
partvector part real
2sin
2cos u
16 Feb 2004 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.
16 Feb 2004 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.
Relative Absolute
vec pos
rot orient
transf frameref
16 Feb 2004 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;
16 Feb 2004 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;
16 Feb 2004 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
16 Feb 2004 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.
16 Feb 2004 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);
16 Feb 2004 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);
16 Feb 2004 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.
16 Feb 2004 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.
16 Feb 2004 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.
16 Feb 2004 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).
16 Feb 2004 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!
16 Feb 2004 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.
16 Feb 2004 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.
16 Feb 2004 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.
preFrame
intraFrame draw
postFrame
draw
Start of Frame
End of Frame
16 Feb 2004 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.