VR Juggler

Dan Hiepler wrote:
> I would like to use Vrjuggler DR3 with Chromium 1.1 on Linux Redhat 8.
> 
> I beleive the recommended way is to use a separate viewports for each wall 
> in VrJuggler. For the simulator the file 
> vrjuggler/data/configFiles/sim.c6viewports.mixin.config 
> is recommmended.
> 
> Chromium does not seem to work with the viewports appearing on screen as
> an unfolded cube. In the case of a single tile Chromium appears to require it
> to start at [0,0]. Do I have to arrange the VrJuggler viewports into a 
> rectangle such as 1 row 6 coloumns ?
> 
> I would like to get a 4 wall passive stereo environment working.
> This will use separate left and right stereo channel computers and
> projectors for each wall.  8 computers altogether and 8 projectors.
> 
> Since the chromium tilesort spu maps by screen area how do I configure 
> VrJuggler and Chromium to send each walls left and right projection data
> to separate computers ?
> Do I have to use a different screen area by altering my glViewport for
> left and right channels ?
> 
> Are there any special synchronization issues for this 8 computer 
> 4 wall passive stereo environment ?
> 
> Cluster juggler is another approach but I do not want to replicate my large
> amount of input data.

The tilesort SPU requires that the tiles all be coplanar.  It sounds like 
you've got a CAVE-like system.  There's a facility for warped tiles (see the 
docs) but I believe that applies only to warping within the image plane.

You're not the first person to ask about this and I've suggested extending the 
tilesort SPU to work with non-planer tilings but I don't think anyone's 
tackled it.

I hope I haven't misunderstood what you're doing.

-Brian

Gernot Ziegler wrote:

>Hej !
>
>I'd like to ask: is it already possible to share the keyboard and mouse
>device in ClusterJuggler ?
>
>If not, how could I easily (preferrably in a graphics application) check
>that communication between my two computers that I hook together in a
>cluster works as intended ? I imagined something like sharing the
>acceleration control in two windows on those two PCs ...
>
>My current experimental config file lies on
>http://www.lysator.liu.se/~gz/cl_stand.config
>, if anyone has time to take a look at it :-)
>
>Servus,
>  Gernot
>
>  
>
Yes you can currently share the the keyboard device over a cluster using 
the RemoteInputManagerPlugin of ClusterJuggler. There are a few issues 
with this method though. The screens will stay syncronized if you do not 
use time based navigation.

In order to use time based navigation with ClusterJuggler you must use 
the time delta between the current and past timestamp from a shared 
device. The problem occurs because the keyboard device does not contain 
timestamps. If you are planning on using time based navigation you will 
have to share another device. The way keyboard input gets used in 
VRJuggler is as follows:

Keyboard -> SimPosition   ->  PositionInterface
                 -> SimDigital      -> DigitalInterface

TimeStamps are not present in the Keyboard device, but are in the 
SimPosition and SimDigital devices. So you could share these devices if 
you are in need of time based navigation. In order to get the time delta 
you would insert the following into your navigation code.

static vpr::Interval last_frame;
vpr::Interval current_frame = mHead->getTimeStamp();
vpr::Interval diff(current_frame-last_frame);
last_frame = current_frame;
vpr::Uint64 delta = diff.usecs();

If you want to send me your most recent config file and the output when 
running the application, I will make a few suggestions.

-Aron

Hi,

I am interested to purchase electromagnetic trackers for my VR system. I was
just wondering if anyone has experience with Polhemus and Ascension
Trackers....I was just wondering which is better in tracking body movements?


Steven


----------------------------------------------------------
This email has been scanned for viruses by StarHub e.Scan.

What version of VR Juggler are you using?

  -Patrick

IHSAN DEVRIM GIN wrote:
> Hi, 
> 
> I'm trying to run VRJuggler with Flock of birds on a RedHat 7.3 (smp). I have
> edited the configuration file. However, when I try to run the torus sample that
> came with the package I get an error message that VRJuggler failed to open the
> port I specified for the flock of birds. It works fine with another computer
> and CAVELibs.  Any insight? Thanks in advance,
> Ihsan
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Tablet PC.  
> Does your code think in ink? You could win a Tablet PC. 
> Get a free Tablet PC hat just for playing. What are you waiting for? 
> http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
> _______________________________________________
> vrjuggler-info mailing list
> vrjuggler-info@...
> https://lists.sourceforge.net/lists/listinfo/vrjuggler-info


-- 
Patrick L. Hartling			| Research Assistant, VRAC
patrick@...				| 2274 Howe Hall Room 2624
PGP: http://www.137.org/patrick/pgp.txt	| T: +1.515.294.4916
http://www.137.org/patrick/		| http://www.vrac.iastate.edu/

If you are planning to use only VR Juggler, keep in mind that support 
for Polhemus trackers is quite limited at this time--unless you use the 
support for Trackd (VR Juggler 1.0 and on) or VRPN (VR Juggler 2.0 Alpha 
1) as an intermediary to read data from the hardware.

  -Patrick

Foo Meng & Kay wrote:
> Hi,
> 
> I am interested to purchase electromagnetic trackers for my VR system. I was
> just wondering if anyone has experience with Polhemus and Ascension
> Trackers....I was just wondering which is better in tracking body movements?
> 
> 
> Steven
> 
> 
> ----------------------------------------------------------
> This email has been scanned for viruses by StarHub e.Scan.
> 


-- 
Patrick L. Hartling			| Research Assistant, VRAC
patrick@...				| 2274 Howe Hall Room 2624
PGP: http://www.137.org/patrick/pgp.txt	| T: +1.515.294.4916
http://www.137.org/patrick/		| http://www.vrac.iastate.edu/

Hi,

Sorry for the slightly belated reply.

We spent some time looking at these systems for use in a scientific setting,
and I tested them for a couple of months (using VRPN to interface them under
Linux, along with some kernel modifications to reduce serial latency).

Here is generally what I found (may or may not be correct!):


Polhemus Fastrak (AC system):

Advantages:
- Not very susceptible to active interference (Monitors, mains power,...).
- Reliable. Talking to people they generally seemed to believe the Polhemus
system was more reliable than the Ascension system.

Disadvantages:
- The 120Hz update rate is shared between the sensors connected (max 4 to
one unit). Hence if 4 sensors are attached, each is sampled at 30Hz, and in
a round robin fashion.
- Distorted by fixed metal. Need to calibrate the environment to remove.


Ascension Flock of Birds (DC system):

Advantages:
- Higher update rate (Max 144Hz?)
- Sensors are measured synchronously.
- Not distorted by fixed metal as much (however, it depends on the type of
metal).

Disadvantages:
- Susceptible to active interference. In some environments there is a need
to use a reasonable amount of filtering, which causes higher latency (the
peak delay for the narrow notch filter reaches about 60ms).


It depends on your environment and requirements which system is better. For
our use, it was very important to have low latency and high accuracy. Hence
we went for a Polhemus Fastrak master/slave configuration with 8 sensors,
and are using a calibration frame to remove distortions from the
environment. Neither system was perfect, but for our use the Fastrak system
was the better option.


I can send you a selection of PDF's off list if you wish, looking at
latency, accuracy, and calibration of the two systems.

Regards,
Daniel



----- Original Message -----
From: "Foo Meng & Kay" <mengnkay@...>
To: "IHSAN DEVRIM GIN" <ihsangin@...>;
<vrjuggler-info@...>
Sent: Saturday, March 22, 2003 1:10 AM
Subject: [vrjuggler-info] Polhemus or Ascension Trackers?


> Hi,
>
> I am interested to purchase electromagnetic trackers for my VR system. I
was
> just wondering if anyone has experience with Polhemus and Ascension
> Trackers....I was just wondering which is better in tracking body
movements?
>
>
> Steven
>
>
> ----------------------------------------------------------
> This email has been scanned for viruses by StarHub e.Scan.
>
>

Ihsan D. Gin wrote:
> Hi, 
> 
> I am a bit confused about the requirement of Performer for Linux systems. For
> the Linux package of Version2 alpha1, it is recommended extra package. 
> However, for the source code (same version) it is listed as required. And I
> remember being able to compile it (previous version to be exact) without
> performer on my RedHat8.0 computer at home. Can someone tell me if I really
> need it to be able to compile the source on a RedHat7.3 (smp)? Thanks in
> advance.
> Ihsan

Performer is not a requirement for a VR Juggler distribution or for 
compiling from source.  Performer only needs to be installed if you want 
to run Performer-based VR Juggler applications.

There should not be anywhere that says Performer is required.  Wherever 
you saw it listed as a requirement is a bug in the documentation and I 
would really like to correct it.  Can you point me to the exact location 
that you saw Performer listed as a requirment.

Thanks,
Allen

> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by:Crypto Challenge is now open! 
> Get cracking and register here for some mind boggling fun and 
> the chance of winning an Apple iPod:
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
> _______________________________________________
> vrjuggler-info mailing list
> vrjuggler-info@...
> https://lists.sourceforge.net/lists/listinfo/vrjuggler-info

[Note: Please keep the list in the cc: line so that others can provide 
help.  This discussion may also be helpful to someone else having the 
same problems in the future.]

The actual error messages about why it is failing to detect the OpenGL 
libraries are in the file config.log.  Also, what command-line arguments 
are you using when you run configure?

  -Patrick

Ihsan D. Gin wrote:
> Hi Patrick, Thanks alot. Thing finally start to make sense. 
> 
> Below I've pasted everything the configure script prints out. I think that might
> be because of the old OpenGL drivers maybe. I'll try to convince my advisor to
> update the nvidia drivers and alpha version of VRJuggler. Maybe that would
> work.
> Ihsan
> 
> loading cache ./config.cache
> checking for cygpath... no
> checking host system type... i686-pc-linux-gnu
> checking target system type... i686-pc-linux-gnu
> checking build system type... i686-pc-linux-gnu
> checking for gcc... gcc
> checking whether the C compiler (gcc   ) works... yes
> checking whether the C compiler (gcc   ) is a cross-compiler... no
> checking whether we are using GNU C... yes
> checking whether gcc accepts -g... yes
> checking for c++... c++
> checking whether the C++ compiler (c++ -Wall
> -Werror-implicit-function-declaration   ) works... yes
> checking whether the C++ compiler (c++ -Wall
> -Werror-implicit-function-declaration   ) is a cross-compiler... no
> checking whether we are using GNU C++... yes
> checking whether c++ accepts -g... yes
> checking if c++ is egcs 1.1.2 or newer... yes
> checking whether gcc accepts -pthread... yes
> checking for C++ template support... yes
> checking how to run the C preprocessor... gcc -E
> checking how to run the C++ preprocessor... c++ -E
> checking for javac... /home/gin/Java/j2sdk1.4.1_01/bin/javac
> checking for a BSD compatible install... /usr/bin/install -c
> checking for Perl version >= 5.004... /usr/bin/perl
> checking for mtree... ${PERL} ${scriptdir}/mtree.pl
> checking whether make sets ${MAKE}... yes
> checking for ranlib... ranlib
> checking whether ln -s works... yes
> checking for pthread_create in -lpthread... yes
> checking for pthread.h... yes
> checking POSIX threads draft revision... Draft 10
> checking for pthread_attr_setstack... yes
> checking for sem_init... yes
> checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include
> checking for glEnable in -lGL... no
> configure: error:*** OpenGL API will not be used (GL library not found) ***
> 
> 



-- 
Patrick L. Hartling			| Research Assistant, VRAC
patrick@...				| 2274 Howe Hall Room 2624
PGP: http://www.137.org/patrick/pgp.txt	| T: +1.515.294.4916
http://www.137.org/patrick/		| http://www.vrac.iastate.edu/

Hi Patrick, 

The error message from the config.log file is as below:
____________________________________________________
configure:3434: checking for glEnable in -lGL
configure:3453: gcc -o conftest    -L/usr/X11R6/lib  conftest.c -lGL -lX11
-lXext -lm  1>&5
/usr/X11R6/lib/libGL.a(glthread.o): In function `_glthread_InitTSD':
glthread.o(.text+0x1e): undefined reference to `pthread_key_create'
/usr/X11R6/lib/libGL.a(glthread.o): In function `_glthread_GetTSD':
glthread.o(.text+0x76): undefined reference to `pthread_getspecific'
/usr/X11R6/lib/libGL.a(glthread.o): In function `_glthread_SetTSD':
glthread.o(.text+0xbf): undefined reference to `pthread_setspecific'
collect2: ld returned 1 exit status
configure: failed program was:
#line 3442 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error.  */
/* We use char because int might match the return type of a gcc2
    builtin and then its argument prototype would still apply.  */
char glEnable();

int main() {
glEnable()
; return 0; }
________________________________________________________________


On Fri, 21 Mar 2003 10:14:55, Patrick Hartling wrote:

> Also, what command-line arguments 
> are you using when you run configure?
> 

First, I haven't used any command line arguments, then I tried to run it with
<--with-oglroot = > but it did not work either. However, because of the flock
of birds problem I think I'd better have the alpha2 release, and try again with
that one.

Hmm, I have seen this before, but I don't remember where.  To fix it, 
-pthread needs to be added to the command line that does the linking.  My 
guess is that this is happening because VR Juggler 1.0.6 was released a 
few months before Red Hat Linux 8.0.  The easiest way to fix this is to 
edit line 1212 of configure.in to look like this:

LIBS="$LIBS -l${MESA}GL -pthread"

The -pthread option would probably also have to be added to the list of 
libraries on line 1276.

After making these changes, run autoconf to regenerate configure and try 
running the configure script again.

  -Patrick

Ihsan D. Gin wrote:
> Hi Patrick, 
> 
> The error message from the config.log file is as below:
> ____________________________________________________
> configure:3434: checking for glEnable in -lGL
> configure:3453: gcc -o conftest    -L/usr/X11R6/lib  conftest.c -lGL -lX11
> -lXext -lm  1>&5
> /usr/X11R6/lib/libGL.a(glthread.o): In function `_glthread_InitTSD':
> glthread.o(.text+0x1e): undefined reference to `pthread_key_create'
> /usr/X11R6/lib/libGL.a(glthread.o): In function `_glthread_GetTSD':
> glthread.o(.text+0x76): undefined reference to `pthread_getspecific'
> /usr/X11R6/lib/libGL.a(glthread.o): In function `_glthread_SetTSD':
> glthread.o(.text+0xbf): undefined reference to `pthread_setspecific'
> collect2: ld returned 1 exit status
> configure: failed program was:
> #line 3442 "configure"
> #include "confdefs.h"
> /* Override any gcc2 internal prototype to avoid an error.  */
> /* We use char because int might match the return type of a gcc2
>     builtin and then its argument prototype would still apply.  */
> char glEnable();
> 
> int main() {
> glEnable()
> ; return 0; }
> ________________________________________________________________
> 
> 
> On Fri, 21 Mar 2003 10:14:55, Patrick Hartling wrote:
> 
> 
>>Also, what command-line arguments 
>>are you using when you run configure?
>>
> 
> 
> First, I haven't used any command line arguments, then I tried to run it with
> <--with-oglroot = > but it did not work either. However, because of the flock
> of birds problem I think I'd better have the alpha2 release, and try again with
> that one. 
> 
> 
> 



-- 
Patrick L. Hartling			| Research Assistant, VRAC
patrick@...				| 2274 Howe Hall Room 2624
PGP: http://www.137.org/patrick/pgp.txt	| T: +1.515.294.4916
http://www.137.org/patrick/		| http://www.vrac.iastate.edu/

For Red Hat 8.0, you need to install the e2fsprogs-devel RPM to get 
libuuid.so.  This page has more details:

    http://www.vrjuggler.org/twiki_public/bin/view/Juggler/SystemSetup

Unfortunately, when I built the release for Red Hat, I forgot about that 
detail.  I'll add something to the download page to make that requirement 
more apparent.

  -Patrick

Mikkel Steffensen wrote:
> Hi,
> 
> I downloaded the new 2.0 Alpha 1-1
> (vrjuggler-2.0-alpha1-1.linux-rh80.tar.bz2) of VR Juggler.
> Trying to compile the OGL SimpleApp example and for that matter
> the OpenSG OpenSGNav example produces the following error:
> 
> ***************************
> [ms@... SimpleApp]$ make
> g++    -I.    -I/usr/X11R6/include -fexceptions
> -I/usr/local/vrjuggler-2.0-alpha1-1.linux-rh80/include
> -I/home/vr/Juggler/2.0/vrjuggler-2.0-alpha1.src/external/GMTL -g
>  -g -D_DEBUG  -o simpleApp.o -c simpleApp.cpp
> g++    -I.    -I/usr/X11R6/include -fexceptions
> -I/usr/local/vrjuggler-2.0-alpha1-1.linux-rh80/include
> -I/home/vr/Juggler/2.0/vrjuggler-2.0-alpha1.src/external/GMTL -g
>  -g -D_DEBUG  -o main.o -c main.cpp
> g++    -g  -o simpleApp ./simpleApp.o ./main.o
> -L/usr/local/vrjuggler-2.0-alpha1-1.linux-rh80/lib  -lJuggler
> -L/usr/local/vrjuggler-2.0-alpha1-1.linux-rh80/lib 
> -lJuggler_ogl -L/usr/local/vrjuggler-2.0-alpha1-1.linux-rh80/lib
> -L/usr/X11R6/lib -Wl,-Bdynamic -lsonix -Wl,--export-dynamic
> -lgadget -ljccl -lvpr -lm -Wl,-Bdynamic -lX11 -lXext
> -Wl,-Bdynamic -luuid -ldl -pthread -L/usr/X11R6/lib
> -Wl,-Bdynamic -lGLU -lGL -Wl,-Bdynamic -lX11 -lXext
> -Wl,-Bdynamic -luuid -ldl -pthread
> /usr/bin/ld: cannot find -luuid
> collect2: ld returned 1 exit status
> make: *** [simpleApp] Error 1
> *****************************
> 
> Does anybody got ideas to what the cause might be?
> 
> 
> Regards,
> Mikkel
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Tablet PC.  
> Does your code think in ink? You could win a Tablet PC. 
> Get a free Tablet PC hat just for playing. What are you waiting for? 
> http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
> _______________________________________________
> vrjuggler-info mailing list
> vrjuggler-info@...
> https://lists.sourceforge.net/lists/listinfo/vrjuggler-info



-- 
Patrick L. Hartling			| Research Assistant, VRAC
patrick@...				| 2274 Howe Hall Room 2624
PGP: http://www.137.org/patrick/pgp.txt	| T: +1.515.294.4916
http://www.137.org/patrick/		| http://www.vrac.iastate.edu/

Hej !

> I can respond to a few specific points here, but I am not the "cluster
> guy," so I don't have a lot of information to offer.
Ah, ok ! Who is that usually ? ;)

> > First of all: how is the cooperation between the two PCs supposed to work
> > ? How do they know who is the master and who is the slave ?
> > Do I simply have to start applicationdata on both PCs with the same
> > configuration file ?
Someone else in this list who has played with that ? *begging look in the
eyes* :)

> > VRJConfig: Entry modifications over MultipleChoice lists offer Choices
> > from all open files ... not too good if you don't want to intertwine the files ;)
>
> Good point.  You may want to enter a bug on SourceForge about this so
> that there will be a reminder to fix it.
done !

BTW: You need to add a new group "2.0" in the Bug tracker ...

> > http://www.vrjuggler.org/gadgeteer/0.3/clusterjuggler.guide/clusterjuggler.guide.html
> >
> > has a broken link:
> > You don't have permission to access
> > /gadgeteer/0.3/clusterjuggler.guide/ptah.cluster.config on this server.
>
> I cut off access to documentation for VR Juggler 1.1 DR1 since I didn't
> think anyone was using it.  I don't know what version you are using, but
> I suspect you want the documentation for either Gadgeteer 0.3 (shipped
> with VR Juggler 1.1 DR2 and DR3) or Gadgeteer 0.8 (shipped with VR
> Juggler 2.0 Alpha 1).
The only thing is that the link below was referred to from the link above
(which is still accessible)

But the Gadgeteer 0.8 docs are not available yet, or are they ?
*checking* oh, there is one - but it still states "Version 1.1 DR2", ok.

> > There is no doc for VRJConfig yet, and I didn't read it first because I
> > thought it wasn't valid anymore ... but it seems to be quite up to date
> > still - maybe you can put a kind of short note in the VRJ2.0 part, stating
> > that one should read the VRJConfig above ? :-)
>
> I'm not sure what you mean.  The VRJConfig Guide is not online yet, and
Oh sorry - I meant there is no _new_ doc for VRJConfig yet, and I
didn't read the _old_ one because I thought it wasn't valid anymore.

> there will be an announcement when it is available.  Unfortunately, the
> author has been on two out-of-state trips in the last three weeks, so I
> don't expect too much progress has been made recently.
Oki - don't stress, I just wanted to make sure I didn't miss any
manual I was supposed to read :-)

Servus,
  Gernot

-- 
T----------------------------W-E-L-C-O-M-E------------------------------T
|                 The Austria <=> Sweden connection.....                H
O                Homepage: http://www.lysator.liu.se/~gz                E
\------------------------------F-U-T-U-R-E------------------------------/

Gernot Ziegler wrote:
> Hej !
> 
> 
>>I can respond to a few specific points here, but I am not the "cluster
>>guy," so I don't have a lot of information to offer.
> 
> Ah, ok ! Who is that usually ? ;)

Aron Bierbaum has been writing nearly all of the cluster code since the 
original author graduated in May 2002.  Aron is presently away on a 
spring break vacation.

>>>First of all: how is the cooperation between the two PCs supposed to work
>>>? How do they know who is the master and who is the slave ?
>>>Do I simply have to start applicationdata on both PCs with the same
>>>configuration file ?
> 
> Someone else in this list who has played with that ? *begging look in the
> eyes* :)
> 
> 
>>>VRJConfig: Entry modifications over MultipleChoice lists offer Choices
>>>from all open files ... not too good if you don't want to intertwine the files ;)
>>
>>Good point.  You may want to enter a bug on SourceForge about this so
>>that there will be a reminder to fix it.
> 
> done !
> 
> BTW: You need to add a new group "2.0" in the Bug tracker ...

We will add the 2.0 group when 2.0 is released.  At this stage, we are 
still technically at VR Juggler 1.1.

>>>http://www.vrjuggler.org/gadgeteer/0.3/clusterjuggler.guide/clusterjuggler.guide.html
>>>
>>>has a broken link:
>>>You don't have permission to access
>>>/gadgeteer/0.3/clusterjuggler.guide/ptah.cluster.config on this server.
>>
>>I cut off access to documentation for VR Juggler 1.1 DR1 since I didn't
>>think anyone was using it.  I don't know what version you are using, but
>>I suspect you want the documentation for either Gadgeteer 0.3 (shipped
>>with VR Juggler 1.1 DR2 and DR3) or Gadgeteer 0.8 (shipped with VR
>>Juggler 2.0 Alpha 1).
> 
> The only thing is that the link below was referred to from the link above
> (which is still accessible)
> 
> But the Gadgeteer 0.8 docs are not available yet, or are they ?
> *checking* oh, there is one - but it still states "Version 1.1 DR2", ok.

Ah, I see where you are confused.  Our versioning scheme for the 
documentation has never been formalized, so those of us who have written 
documentation haven't been careful about using the right version number. 
  It appears that the version for the Clutser Juggler Guide was copied 
from some VR Juggler documentation.  Someone should correct that, and we 
should probably decide how to version the documentation.

  -Patrick

>>>There is no doc for VRJConfig yet, and I didn't read it first because I
>>>thought it wasn't valid anymore ... but it seems to be quite up to date
>>>still - maybe you can put a kind of short note in the VRJ2.0 part, stating
>>>that one should read the VRJConfig above ? :-)
>>
>>I'm not sure what you mean.  The VRJConfig Guide is not online yet, and
> 
> Oh sorry - I meant there is no _new_ doc for VRJConfig yet, and I
> didn't read the _old_ one because I thought it wasn't valid anymore.
> 
> 
>>there will be an announcement when it is available.  Unfortunately, the
>>author has been on two out-of-state trips in the last three weeks, so I
>>don't expect too much progress has been made recently.
> 
> Oki - don't stress, I just wanted to make sure I didn't miss any
> manual I was supposed to read :-)
> 
> Servus,
>   Gernot
> 


-- 
Patrick L. Hartling			| Research Assistant, VRAC
patrick@...				| 2274 Howe Hall Room 2624
PGP: http://www.137.org/patrick/pgp.txt	| T: +1.515.294.4916
http://www.137.org/patrick/		| http://www.vrac.iastate.edu/