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

More TRANSF, VR Programming

  • Upload
    clem

  • View
    44

  • Download
    0

Embed Size (px)

DESCRIPTION

More TRANSF, VR Programming. Glenn G. Chappell [email protected] 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? - PowerPoint PPT Presentation

Citation preview

Page 1: More TRANSF, VR Programming

More TRANSF, VR Programming

Glenn G. [email protected]

U. of Alaska Fairbanks

CS 481/681 Lecture NotesMonday, February 16, 2004

Page 2: More TRANSF, VR Programming

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.

Page 3: More TRANSF, VR Programming

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.

Page 4: More TRANSF, VR Programming

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

Page 5: More TRANSF, VR Programming

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.

Page 6: More TRANSF, VR Programming

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

Page 7: More TRANSF, VR Programming

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;

Page 8: More TRANSF, VR Programming

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;

Page 9: More TRANSF, VR Programming

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

Page 10: More TRANSF, VR Programming

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.

Page 11: More TRANSF, VR Programming

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);

Page 12: More TRANSF, VR Programming

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);

Page 13: More TRANSF, VR Programming

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.

Page 14: More TRANSF, VR Programming

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.

Page 15: More TRANSF, VR Programming

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.

Page 16: More TRANSF, VR Programming

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).

Page 17: More TRANSF, VR Programming

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!

Page 18: More TRANSF, VR Programming

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.

Page 19: More TRANSF, VR Programming

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.

Page 20: More TRANSF, VR Programming

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

Page 21: More TRANSF, VR Programming

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.