Megahedron—A 3D Graphics Environment

Megahedron is feature-rich. The section of the documentation titled “What is Megahedron?” gives a detailed list of features, including:

This is not the complete list, of course, but it should give you an idea of the range of capabilities available.

SMPL is the programming language for Megahedron, and it looks a little like Basic. It's fairly intuitive if you are familiar with tools like POV-Ray or BMRT and with vectors, object primitives and transformations. If you are not, there are plenty of simple examples to get you started and the glossary and indices in the manual will help you find the way through the source code.

An SMPL program has the following general format:

do task2, task3;
<include files>
integer a;
procedure task1 is
        <declarations>
        <statements>
end;
procedure task2 is
        <declarations>
        <statements>
end;
procedure task3 is
        <declarations>
        <statements>
        task1;
end;

Declarations include data, type and subprogram declarations. Statements include object declarations and instances, transformations and so forth.

The data types supported by the language are fairly intuitive, but are slightly different in syntax from RenderMan and POV. In the RenderMan RIB file format, a string type is a String, whereas Megahedron uses char. As you can see, the data type is obvious. RenderMan uses point to specify a set of 3 points in space, each of which is a float value. Megahedron uses the type vector for the same thing. POV, on the other hand, doesn't really have data types. All variables have declared values that get preprocessed before the code is processed, substituting the declared value for the name of the variable. Which method is better depends on the user's preference. I like defined data types because type checking can be done up front. Megahedron's use of the const statement allows for enumerated values, a nice addition that doesn't appear possible in a RIB file. (Although if you use the RenderMan API, you're writing C code, so enumerated types are not a problem.)

Subroutines are supported with the use of the procedure statement. Scoping of variables is much like C scoping, with variables accessible locally or globally, but not across procedures. Procedures are delimited with the procedure and end statements. There is support for static variables in procedures as well as multidimensional arrays.

The language has one annoying aspect: it uses curly braces for comments. I've used quite a number of languages over the past 10 years and can't remember any that used curly braces for comments. The traditional C and C++ comment markers of #, /**/ and // would, in my opinion, have been better.

One weakness in the documentation is the description of the file I/O routines. Although file I/O is possible, it's not clear how to output model information to a file. A few examples for outputting model information would have been a nice addition. After all, since I prefer using BMRT's renderer over Megahedron's, I need a way to output RIB files in order to use SMPL for modeling. Rendered images can be saved in RAW or TGA (Targa) formats. I found this information in the section on “Display Controls”, not in the section on “File I/O” as I expected. While perusing one of the system files, smpl_prims, I found that support is implied for the JPEG format as well, but I didn't find confirmation of this elsewhere.

As with RenderMan's RIB and with POV-Ray, an SMPL file is a collection of sections describing a 3D scene. In SMPL you have sections for defining the camera and rendering options (similar to the sections outside the WorldBegin/WorldEnd statements in RenderMan), object declarations, still frames and animation. Still frames are really the guts of the scene, where objects are instanced, textured, transformed and so forth. The proceduralism of SMPL allows for declaring objects once and instancing them many times throughout a frame. For example, a single ball might be defined as a sphere with holes cut out of it that can be used to instance 100 spheres in various states of unrest for a single frame.

An important part of any 3D rendering system is its ability to do transformations. Transformations allow an object (a sphere, box or more complex figure) to be moved to its location in 3D space prior to the actual rendering of the image, or to be sized or modified in shape (stretched or skewed, for example). Megahedron allows objects to be transformed relative to their current size and position or absolutely. Absolute transformations specify the exact size or position without regard to the current size or position.

Transformations are specified using the with clause for objects, as follows:

<object name>
                with
                        <transformations>
        end;

Transformations can be nested, and the relative transformation is based on a transformation stack, much like RenderMan or POV-Ray. Instancing an object gives it the current transformation state, and new transformations are made within the instance that apply only to that particular instance or any instances created below it. In other words, it's a hierarchical model. If you're familiar with POV or BMRT, you should have no problems learning the syntax and use of transformations in Megahedron.

One difference between RenderMan and Megahedron is how camera transforms are done. In the latter, the camera is actually moved. This is similar to the way POV handles camera transforms, but different from the way RenderMan handles it. It's important to understand what is being moved when using transformations in any 3D package.

Lighting primitives supported include distant point lights, spot lights and ambient lighting. These are the same lighting types supported by POV and RenderMan. Each type has its own parameters, such as brightness (known as “intensity” in RenderMan) and color. Lighting in RenderMan is handled through the use of shaders, so it's possible to create all manner of lights for use with BMRT. Megahedron appears to offer similar functionality, although I didn't delve into this area much.

One of the nicest features is the live animation capability. Wireframe displays, which can include hidden surface removal, can be run interactively. Interactive displays can also make use of mouse and keyboard input to control the display. There are examples provided that show exactly how this is done.