Comp 600.460: Virtual Worlds

Homework Help Page

Students - if you think of something that should be on this page but isn't, let me know.

AC3D Information and Tips

Paths

You can now find the ac3d and povray executables in:

/home/projects/CS600.460/bin

Rendering with Povray

The default preference for rendering with povray writes the input file for povray in /tmp. The file permissions will probably be such that the next person who comes along and tries to write to the same file name will not be able to overwrite it. So, you should modify the preference for povray execution command.

The default command (bad) is:

ac3d write_POV /tmp/ac3dpovfile.pov ; ac3d execute {povray +D +I/tmp/ac3dpovfile.pov &}

You should change it to use a path under your home directory rather than /tmp.

Also, if you do not have /home/projects/CS600.460/bin in your path, you will need to use that full path in the above "povray" command (i.e. /home/projects/CS600.460/bin/povray).

Running AC3D at Both Nurbs Seats

AC3D apparently locks some port while it is running. When two people sit down at the two seats on nurbs, they cannot both run AC3D, because the first one to run gets the port, and the second cannot use it. If you encounter this situation, you must manually edit your .ac3dprefs file (not using the interface within AC3D). You can then change the "tcl_socket_port" value to a different number. I'm not sure what the valid range of numbers is, so just increment it or decrement it some small amount.

If you don't have your own .ac3dprefs yet from running the program previously, you can copy mine at ~cohen/.ac3dprefs.

Useful Links

AC3D manual

AC3D modeler home page

AC3D author (Andy Coulbourne)

OpenGL and GLUT Stuff

OpenGL and GLUT are available from undergraduate, research, and graphics accounts. The undergraduate and research accounts only have access to the Mesa OpenGL-like API, which is a software only version, so it is naturally much slower than on the SGIs.

Useful Links

cube.c: a very simple OpenGL/GLUT application - link with:

    cc -I/usr/local/include -L/home/projects/CS600.460/lib/sgi_irix.n32 -o cube cube.c -lglut -lGLU -lGL -lXmu -lX11 -lm

OpenGL Specification (Version 1.1)

OpenGL Reference Manual (the blue book)

GLUT API documentation

GLUT home page

OpenGL Survival Kit Tutorial

SGI's OpenGL Site: pointers to tutorials and all sorts of interesting stuff

OpenGL.org Site: more tutorials, coding techniques, etc.

Paula Womack's Performance Techniques lecture

Dan Aliaga's SGI Infinite Reality performance tips and Performance Table (doesn't show well in our ghostview, but prints okay)

Care and Use of the HMD

First - please treat the HMD with care. Don't leave it on the floor or in an otherwise precarious position. When you are done using the HMD, please turn off its power using the push button on the black video box (the black cable from the HMD goes into it, and it makes some fan noise when turned on).

The video input to the HMD comes from the SGI, nameless. In its current configuration, nameless has its display set for 1280x1024 resolution. The top 1280x480 block is sent to the HMD as well as the main screen. Each eye gets a 640x480 block. You can set your application to bring up its graphics window in this exact location. You can even set up your window manager to bring up windows with a particular name string without any "decorations" or "borders" so that all you see is the image pixels. We may eventually rearrange this display configuration. If this happens, I'll post the new configuration.

The knobs on the top and back of the HMD allow you to tighten the HMD after you put it on and loosen it to remove it. You probably want it to fit fairly snugly on your head. You can adjust the field-of-view overlap with the two little knobs on the sides. Also, it's okay to wear the HMD while wearing glasses; they won't be scratched (but do not test this by making the HMD as absolutely tight as possible).

Again, turn off the power button when the HMD is not in use.

Care and Use of the Tracker

Unlike the HMD, it is not necessary to power down the tracker when it is not in use. Feel free to leave it running.

Sensor #0 is currently screwed onto the top of the HMD, and it will probably stay that way. Some time soon we will be attaching sensor #1 to the joystick device. It will probably be easily removable (using velcro or some such attachment) so you can possibly attach it to the custom device of your choice. (Getting buttons attached to a random device may be another matter entirely, but it simply depends on how resourceful you are.)

At present, the magnetic field appears to be extremely distorted, so things look reasonable when you are standing directly under the tracker, but things quickly begin to tip and scale in an odd way as you step away from it. This may be due to the metal brackets the tracking source is mounted to. Things work well enough for you to do your homeworks, and they will hopefully be improved before you get too far into your term projects.

Using VRPN

In short, VRPN is a client-server library for dealing with peripheral devices, such as the tracker and joystick buttons you will be using in your programs. You must run a server process on the machine physically connected to the device, then your VR application program may act as a client, communicating with the machine over the network (unless the client and server reside on the same machine).

Please peruse the VRPN documentation. Some of the high-level description is quite useful, though much of the documentation is just key exerpts from the header files.

Server Info

You will probably not need to write your own server program. You can run the generic server on nameless (which is connected to the tracker) as:vrpn

/home/projects/CS600.460/bin/vrpn_server -f /home/projects/CS600.460/config/vrpn.cfg

Only one person may be connected to the server at a time (and I believe only one server may be running at a time). As soon as one client program dies, the next may connect to the same server process. (I think I modified the server last semester to always exit after the client dies because we were getting hung server processes that no one could connect to or kill.)

Client Info

By instantiating a vrpn_Tracker_Remote object with the string "Tracker0@nameless.cs.jhu.edu", you can read the tracking data from both sensors (one for the head/HMD, the other for the hand/joystick).

The joystick device plugs into the PC, which is running Windows NT. To read the button values of the joystick, you must run the button server on the PC. Log in to the PC using our class account. Click on the button server icon on the desktop to run the server.

Your client program can then read the button values by instantiating a vrpn_Button_Remote object with the string "Button0@cube.cs.jhu.edu". There are four readable buttons. You probably want to make sure the "turbo" switch on the joystick is turned off. When it is on, holding a button makes it toggle on and off repeatedly as long as you are holding. With it turned off (probably the way you want to use it), pushing a button triggers an event, as does releasing a button. Your registered callback function handles these events.

My sample application is available at:

http://www.cs.jhu.edu/~cohen/VW2000/Misc/hw2sample.tar.gz

Canned Tracker

By saving the data from a vrpn_Tracker_Remote object to a file, you can later use this data as a "canned" tracker. (Note: there is currently no way to save the button data, just the sensors).

First, collect create the tracking data file by running the vrpn_server program (on nameless) as usual, followed by the vrpn_recorder program. vrpn_recorder is a vrpn client application which reads the tracking sensor and write the results to a file called tracker.dat. You can quit recording by pressing &LTControl>-C. After quitting, you should probably rename the data file so you don't record over it later.

This file can now act as your tracker. Your application simply opens a different named tracker device to access this recorded data instead of the real tracker.

First, create your own config file with an entry as follows:

vrpn_Tracker_Canned   Tracker0@machinename   datafilename

Now, modify your application to instantiate the tracker using vrpn_Tracker_Remote("Tracker0@machinename").

(I haven't tried this yet, but you you may be able to set machinename to "localhost" so you can use it on various machines without changing your code or the config file).

When you are ready to run, run the vrpn_server program on your local machine (the one specified as "machinename"), using your new config file rather than the installed config file. Then run your client.

The client and server are now both running on your local machine, and the tracking data is read from the pre-recorded data file.

Because the vrpn_recorder program is not part of your application, you can't see your model or any sort of hand icon while you are recording. If you want to see what you are doing while you record, you will have to build the data recording into your own application instead of using the vrpn_recorder program. This is actually pretty easy. Check out vrpn_recorder.C to see how this is done.

Quatlib Tips

Quatlib is a C library for dealing with quaternions and related transformations. It has types for dealing with quaternions, vectors, and matrices. There is some meager documentation in the header file. If you want/need to see the source code, it's located at:

/home/projects/CS600.460/src/quat

In my sample application, I used primarily the q_xyz_quat_type. This structure is just a quaternion plus a translation vector. I compose a bunch of these, and finally convert to an OpenGL-style matrix (qogl_matrix_type) before putting it onto the matrix stack. Note that the xyz_quat type limits you to rotations and translations. If you need to store other sorts of rotations, you'll probably have to go with a matrix rotation for that portion of the transformation hierarchy.

Recall that if we construct a transformation from coordinate system B to coordinate system A, the transformation, A_from_B, is actually designed such that it would move the coordinate axes of system A to align with those of system B, not vice versa. This can be a bit confusing, so be careful. (Have you read the Robinett and Holloway paper yet?)

Also, the quaternion library thinks of the OpenGL matrix type as a matrix for multiplying column vectors, because that is the order is stored in memory. So if you plan to compose these matrices together with the q_ogl_matrix_mult() command, you have to multiply in the reverse order:

A_to_C = A_to_B * A_to_C,   rather than    C_from_A = C_from_B * B_from_A.

You could probably maintain the C_from_A notation by adding a new macro function as follows:

#define qogl_matrix_compose( A_from_C, A_from_B, B_from_C )  \

             qogl_matrix_mult( (A_from_C), (B_from_C), (A_from_B) )

Are you confused yet?

I tended to use the q_make() function to construct quaternions in my application. You specify an axis, and a rotation angle about an axis. It's possible to express any change in orientation this way. I actually ended up composing two quaternions about the coordinate axes so I was sure to get it right, but if I knew the correct axis of rotation, I could have constructed the correct quaternion directly. Of course, by looking at the quaternion resulting from my composition, I could determine the axis pretty easily. Quatlib also allows you to specify a quaternion by providing two vectors. The resulting rotation will be the one which aligns the first vector with the second and rotates about an axis perpendicular to both. This occasionally comes in handy.

Given two orientations specified as quaternions, quatlib allows you to perform a spherical linear interpolation between them. That is to say, it allows you to animate the rotation (interpolate between the two extremes) by rotating along the shortest path between the two quaternions. You provide the two quaternions and a parameter between 0 and 1, and the routine returns the resulting quaternion. It probably allows you to do extrapolation as well (by giving parameters outside the [0-1] range.

The standard quaternion reference is:

Shoemake, Ken. "Animating Rotation with Quaternion Curves". Proceedings of SIGGRAPH 85. pp. 245-254.

Links

Quaternions: a tutorial by Ken Shoemake

Using Quaternions to Represent Rotation

quat.h

February 15, 2000