Terra: Full Heightfield

One of the homework assignments for our Graphics course was to implement a terrain renderer using a quadtree structure. After reading up on it a bit, I attempted to implement the method described by Ulrich’s article (although I won’t lie: the working demo code given in the article helped a good deal with that part). The image above is the end result of the terrain renderer, along with the quaternion-based camera library I implemented for the previous assignment.

Terra: Wireframe Heightfield

The random terrain in this example was created by generating a 1024×1024 image in GIMP using the Solid Noise filter and saving it as a PNG, which Terra uses to generate the heightmap. The image used to texture the terrain was created by applying a gradient map to the grayscale heightmap, and adding an embossed version of the grayscale heightmap on top of the gradient mapped heightmap to give the illusion of a directional light source.

The inset image is the same scene as the first image in this post, but rendered in wireframe mode. If one looks closely, one can see how the adaptive quadtree algorithm uses more triangles for high-detail parts of the heightmap, and less (”bigger”) triangles for less detailed parts.

Finally, the last image below is also the same scene as the other two images, but with a detail factor 2¼ times higher than the first two images, also rendered in wireframe, highlighting the increased number of triangles.

Terra: High Detail Heightfield

Running the detector with the -O2 optimisation flags yielded the following statistics:

pcronje@gecko modelchecker $ mpirun -H localhost ./deadlock -q -q
[0] Resource usage statistics:
 * Store memory (bytes) : 192000
 * User time   (work)   : 2.568160
 * User time   (total)  : 2.652165
 * System time (total)  : 0.008000
 * Page faults/reclaims : 0/1461

Switching over to -O3 yielded:

pcronje@gecko modelchecker $ mpirun -H localhost ./deadlock -q -q
[0] Resource usage statistics:
 * Store memory (bytes) : 192000
 * User time   (work)   : 1.520095
 * User time   (total)  : 1.604100
 * System time (total)  : 0.016001
 * Page faults/reclaims : 0/1463

Not bad. Force of habit running a Gentoo system makes me go -O2 by default when optimising.

Interestingly enough, running the deadlock detector across two systems yielded the following statistics (the number in square brackets indicate the process ID of the printing process):

pcronje@gecko modelchecker $ mpirun -H localhost,localhost ./deadlock -q -q
[1] Resource usage statistics:
 * Store memory (bytes) : 96000
 * User time   (work)   : 0.872055
 * User time   (total)  : 0.948059
 * System time (total)  : 0.028001
 * Page faults/reclaims : 3/1628
[0] Resource usage statistics:
 * Store memory (bytes) : 96000
 * User time   (work)   : 0.880055
 * User time   (total)  : 0.972060
 * System time (total)  : 0.008000
 * Page faults/reclaims : 7/1623

Obviously, the memory usage is neatly halved (since that’s just how the state generator I’m using to test this sucker works), but the interesting thing is the decrease in runtime. I would’ve thought that the communications overhead involved in throwing work items around between processes would’ve made the whole thing about as fast as swimming in tar. I guess the smaller memory footprint is making the difference when the analyser reads through the work item store or something. It’s something I’ll look at once I start properly evaluating the project.