Megahedron—A 3D Graphics Environment

As with any 3D environment, modeling is not enough. Wireframe displays provide a glimpse of what your scene (or animation) will look like, but without extensive shading the model appears rather uninteresting. Megahedron provides a rich set of shading features: ray tracing using reflections, refractions and shadows, and image, bump and procedural mappings to name just a few. A collection of stock shaders such as granite, ridged and cloudy is provided. Targa (TGA) formatted image maps are supported. It's interesting to note that Megahedron maps all image map coordinates from (0,0) to (1,1), with the former being the lower left corner of the map. RenderMan maps (0,0) at the upper left and (1,1) to the lower right. If you're used to using BMRT, it is important to keep this in mind when using Megahedron image maps.

The shading language is closer to the RenderMan shading language than POV-Ray's texturing commands. This can be seen in the examples used in the “Anatomy of a Shader” section of the manual. Here colors are defined through the addition of values computed earlier, such as:

diffuse = (illumination + ambient) * color * .3;
specular = reflect (color * .4);
highlight1 = highlight1 * color;
highlight2 = highlight2 * color;
metallic_color = diffuse + specular + highlight1
        + highlight2;

This method of layering textures is different from POV-Ray's. In POV, an object's final texture is based on a series of textures defined within multiple texture{} statements. In a sense, the two methods are the same computationally, but from a users perspective the blending of layers is more apparent and under greater control in the procedural languages (Megahedron and RenderMan). If you started with POV, as I did, you may find this a bit confusing at first. Once you've learned how layering textures works with Megahedron, however, you'll appreciate the control it provides.

There are a number of predefined shaders provided in the distribution. In the system directory there are some extensions to SMPL (written in SMPL), including some interesting shaders such as “vampires”, which don't show up in mirrors, and “ghosts”, which only show up in mirrors. These shaders look rather interesting, and I have to wonder why the sample images don't appear to make use of them.

One important difference between the BMRT, POV and Megahedron feature sets is that only BMRT supports displacement maps. These are like bump maps except the point on the surface is actually moved instead of just adjusting the normals of the point to make the surface appear bumpy.

I like this aspect of the documentation, but it has some usability problems. First, the tour points to sample directories as smpl/<directory>. This is incorrect—there is no smpl directory. The tour also (unless I missed it) fails to mention that the system specific directories are the top level directories on the CD. Under the system directories is the mhd directory where the examples, code and system files are located. It can be a little confusing to find your way if all you do is read through the Quick Tour—be sure to look through the CD directory structure first.

Another rather interesting omission is that the Quick Tour doesn't mention the name of the program you will be running. After a quick search under the Linux directory on the CD, I found the bin directory and the imhd program.

There were lots of problems running the examples. ideal_gas, sonic_boom and slicer.smpl are all examples that take input from the mouse. At first nothing I did seemed to affect the example; eventually, I found I had to move the mouse slightly for the button presses to be recognized. This might be an X-server issue, but I think the problem is really the hot spot area defined by the SMPL code. It appears that the area that recognizes the button press is smaller than the visible button area.

While writing this review, I often switched desktops (I use FVWM2) between the xterm running my editor and another running Netscape in order to read Megahedron's documentation with the browser. I also ran the sample programs on the same desktop as Netscape. Whenever I switched to my editor desktop and then back to the Netscape desktop, some of the windows for the sample programs didn't get updated. For example, sonic_boom.smpl creates two windows—one that shows an aircraft and “sound waves” moving past it and another that shows controls for setting the thrust of the aircraft along with current speed displays. This second window would not be redrawn when I switched desktops. The ideal_gas example had similar problems, but I found I could get the control window to update if I forced a change to the display by moving the piston up or down. This limits the usefulness of the interactive programs with window managers that support multiple desktops.

Another minor nit is that windows created by the examples are not grouped. As a result, my window manager's AutoRaise feature does not raise all the windows associated with the example. This can be a little annoying, but it's a minor point.