Lab 5: 2D Hierarchical Modeling System

In this lab exercise, we added hierarchical modeling to our graphics engine. Hierarchical modeling provides a convenient framework for assembling conglomerate entities out of simpler, reusable components. Once designed, a module can be duplicated, transformed, and extended with minimal additional code.

Procedure

Our graphics environment continues to follow Prof. Maxwell's Graphics Environment Specification.

We store a module as a linked list of element structures. Each element structure is associated with a type. Line, Point, Polyline, and Polygon elements contain drawable items. Identity, Matrix, and Color types modify the drawing state. The Module type introduces a nested module. As required by the API, we provide routines to create, destroy, and construct modules.

We also provide the routine Module_draw, which traverses a module and renders it into an image. In addition to module and image pointers, Module_draw receives global and view transformation matrices and an initial pen color from the caller. It traverses the elements in the module. Color elements contain a new pen color, which it adopts; Identity elements prompt it to clear a local transformation matrix; Matrix elements are multiplied onto the LTM from the left. A drawable item is transformed by the LTM, then the GTM, and finally the VTM before being drawn into the image in the present pen color. A Module item prompts a recursive call of Module_draw on the nested module, with the product GTM*LTM passed in as the GTM.

Results

Group Images

The following animation of warplanes of some sort was generated using Prof. Maxwell's test code. The hierarchically-modelled planes are easily duplicated and transformed independently.

Image 1. A two-plane fly-by, with one plane spinning.

We developed the following images by defining a Fleet module containing Fish modules, and a Scene module containing Fleet modules.

Image 2. An aquarium. (graph of the hierarchical model)

Conclusions and Future Work

The hierarchical modeling abstraction mostly frees our user from thinking about pixels: instead of drawing shapes on a screen, he may design objects in a space. It enables him to place independent mutations of the object in a scene with a few tidy lines of code where previously a tedious copy-and-paste effort was required. It eliminates the messy transformation process discussed in our Lab 4 writeup.

We have not discovered any bugs in our implementation. If the programmer properly destroys the objects he creates, it leaks no memory.

Appendices

Our code is available with AES256 encryption. The passphrase is only available to Dr. Maxwell.

The libraries were mostly pair-programmed, although David put in a few independent hours of segfault-hunting and other debugging. Allison developed the fish image. David wrote this writeup.