Last edited 17dec09 by Justin Kopinsky


Cubability and Compilation


VPython consists of a 3D graphics module, Visual, built using OpenGL (written in C++) on top of the programming language Python. It is a free, open source, compiled library of graphics methods with a relatively shallow learning curve. As Python itself is a very easy language to learn, it is no surprise that VPython is the graphics language of choice for many new programmers. As such, it would be ideal to allow RTICAs written in VPython access to the cube (the University of Illinois walk-in virtual reality environment). Unfortunately, that is not currently possible due to some of the subtle interactions of OpenGL with Syzygy, the engine used to manage the clusters in the cube. We would like to locate and patch these issues into a modified, cube-ready version of VPython, but unfortunately, even recompiling Visual is a difficult endeavor. As such, the majority of this project focuses on the process needed to complete this recompilation (which is unfortunately still in progress due to missing packages). Since this project was done entirely on Linux machines (with attempts made on both Red Hat and Fedora), these notes will apply only to Linux. A slightly more concise version of these notes is available as a PDF here.

Obtaining the Source

The first thing that needs to be done is to obtain the source. As of this writing, the current stable version of Visual is Visual 3, although it appears that Visual 5 has been released. For this, and the next several steps, we follow these notes. Additionally, we use the source available on that page, direct download link here. Once the source is downloaded, it can be perused at leisure, although of course it must be recompiled in order to make changes.

Source Notes

Every drawable object in Visual has its own class (e.g. cone.cpp) located in the /src/ folder of Visual. All of these extend the class Primitive, which has members for basic essentials like as position, orientation, and color. Each drawable object also defines a method called glRender which, as the name implies, calls the necessary OpenGL commands to render the object. Strangely, glInit does not seem to be called anywhere in Visual (at least according to grep), which could be potentially problematic when trying to port into the cube.

Installation Procedures

Visual helpfully contains an INSTALL.txt file which contains detailed instructions on how to install, but unfortunately contains few troubleshooting pointers. The first thing to do is to run the configure script included in the visual package. If all required packages are present, this should complete sucessfully, in which case make can be run and again, if successful, Visual will be installed. Unfortunately, it is likely that configure will not complete successfully. The most probable cause of this is missing packages, an issue encountered on every machine for which this was attempted, specifically gtkglarea on EWS and certain python header files in the math department Linux machines. Presumably, installing all these packages will fix this issue, but this is as yet untested.

Next Steps

The next step in these attempts will be to contact the system admins for these machines (most likely the math department ones) and try to get the necessary packages installed. Hopefully this will allow us to at least recompile Visual.

Unsuccessful Ideas

Even though the intent is to install Visual into a home directory, so as not to upset the stable version already on the machines, it appears that installing needed packages into home directories is either not sufficient, or requires a lot of tinkering with flags in order to work (enough that it is beyond the scope of this project). As such, it is presumed that packages need to be installed in /usr/bin or in other root directories where they belong.