More TRANSF, VR Programming

1
More TRANSF, VR Programming

• Glenn G. ChappellCHAPPELLG_at_member.ams.org
• U. of Alaska Fairbanks
• CS 481/681 Lecture Notes
• Monday, February 16, 2004

2
ReviewRepresenting Tformations 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.

3
ReviewRepresenting Tformations 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.

4
ReviewRepresenting Tformations 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 uv) (av
  bu u?v).
• We represent a rotation of an angle a about an
  axis u (unit vector) as a quaternion as follows
• With this representation, composition of
  rotations is just multiplication.

5
ReviewRepresenting Tformations 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.

6
ReviewThe 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 includes 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.

7
More TRANSFClasses vec pos 1/2

• Class vec can be thought of as
• An array of three doubles.
• A 3-D vector.
• A translation.
• Class pos
• An array of three doubles.
• 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

8
More TRANSFClasses 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

9
More TRANSFClasses 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

10
More TRANSFClasses 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.

11
More TRANSFTransformations

• 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 vecs, poss, their own
  type, and their own absolute type.
• p2 r1.applyto(p1)

12
More TRANSFExamples

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

13
More TRANSFUsing 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.

14
VR ProgrammingReview 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.

15
VR ProgrammingHardware

• The CAVE
• Developed in the early 1990s 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
VR ProgrammingLibraries

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

17
VR ProgrammingThe 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!

18
VR ProgrammingVR 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.

19
VR ProgrammingVR 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.

20
VR ProgrammingVR 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
21
VR ProgrammingVR 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.