Standard Procedural Databases

by Eric Haines et al.

balls gears mount rings teapot tetra tree
click on an image to see a full size rendering
(rendered with POV-Ray 3.1)

This is the code described in:

Eric Haines, "A Proposal for Standard Graphics Environments," IEEE Computer Graphics and Applications, 7(11), Nov. 1987, p. 3-5.

You can download the latest version of the SPD (currently 3.14), and also view the original IEEE CG&A article from Nov. 1987. The code is on Github.

This software package is not copyrighted and can be used freely. All source is in K&R vanilla C (though ANSI headers can be enabled) and has been used on many systems.

For a newer set of more realistic environments for benchmarking ray tracers (or renderers in general), see BART: A Benchmark for Animated Ray Tracing. The focus is software that generates an animated set of frames for a ray tracer to render. These scenes use an NFF-like language (AFF), and the authors provide a number of tools for parsing and visualization.

This software is meant to act as a set of basic test images for ray tracing algorithms. The programs generate databases of objects which are fairly familiar and "standard" to the graphics community, such as the teapot, a fractal mountain, a tree, a recursively built tetrahedral structure, etc. I originally created them for my own testing of ray tracing efficiency schemes. Since their first release other researchers have used them to test new algorithms. In this way, research on algorithmic improvements can be compared in a more standardized fashion. If one researcher ray-traces a car, another a tree, the question arises, "How many cars to the tree?" With these databases we may be comparing oranges and apples, but it's better than comparing oranges and orangutans. Using these statistics along with the same scenes allows us to compare results in a more meaningful way.

Another interesting use for the SPD has been noted: debugging. By comparing the images and the statistics with the output of your own ray tracer, you can detect program errors. For example, "mount" is useful for checking if refraction rays are generated correctly, and "balls" (a.k.a. "sphereflake") can check for the correctness of eye and reflection rays.

The images for these databases and other information about them can be found in A Proposal for Standard Graphics Environments, IEEE Computer Graphics and Applications, vol. 7, no. 11, November 1987, pp. 3-5. See IEEE CG&A, vol. 8, no. 1, January 1988, p. 18 for the correct image of the tree database (the only difference is that the sky is blue, not orange). The teapot database was added later.

The Neutral File Format (NFF) is the default output format from SPD programs. This format is trivial to parse (if you can use sscanf, you can parse it), and each type of object is defined in human terms (e.g. a cone is defined by two endpoints and radii). The basic shapes supported are polygon and polygon patch (normal per vertex), cylinder, cone, and sphere. Note that there are primitives supported within the SPD which are not part of NFF, e.g. heightfield, NURBS, and torus, so more elaborate programs can be written. If a format does not support a given primitive, the primitive is tessellated and output as polygons.

Ares Lagae has written libnff, a modern C++ library for parsing NFF that also supports conversion to Wavefront OBJ.

I converted the sphereflake demo to a more modern form, for RTX hardware. The code is in the DXR-Sphereflake directory in this code base (which now won't run, because Falcor has changed). My blog post is here, gallery here, and longer NVIDIA post here.

Other output formats are supported:

Alexander Enzmann receives most of the credit for creating the various file format output routines, along with many others who contributed.

There are also reader programs for the various formats. Currently the following formats can be read and converted:

This makes the NFF format a nice, simple language for quickly creating models (whether by hand or by program), as any NFF file can be converted to many different formats. Warnings:

The Graphics Gems V code distribution has a simple z-buffer renderer by Raghu Karinthi, using NFF as the input language.

On hashing: a sore point in mount.c, the fractal mountain generator, has been its hashing function. Mark VandeWettering has provided a great hashing function by Bob Jenkins. To show what a difference it makes, check out images of models made with the original hash function with a large size factor, replacement hash function I wrote (still no cigar), and Jenkins' hash function.

For more information on the SPD, see the README.txt file included in the distribution.

Compatibility Notes

Linux

On some (all?) versions of gcc on Linux, the following correction to the code is necessary:

libinf.c, line 33:

FILE *gOutfile = stdout;
change to
FILE *gOutfile = NULL;

Research Works using SPD

Timing comparisons for the various scenes using a wide variety of free software ray tracers are summarized in The Ray Tracing News, 3(1) (many), 6(2), 6(3), 8(3), and 10(3). Here are some research works which have used the SPD to benchmark their ray tracers (please let me know of others; you can always search Google Scholar for more):

Eric Haines

Last change: May 30, 2021