FAQ

You sort-of could if, at the time BuildOctree() was called, you knew you were going to render the volume. But you don't. The result of BuildOctree() may be used for purposes other than ray tracing, such as printing via PrintOctree(); for such operations, MaxDepth is not defined during BuildOctree(), so it cannot be used therein.

Of course, all operations define MaxDepth prior to calling octree functions that use this global variable. Also, they reserve the right to modify MaxDepth over time. As a result, MaxDepth is not guaranteed to be a constant over the lifetime of an octree produced by BuildOctree(), and hence the octree built should not be tailored to a specific MaxDepth.

You may do so, if you wish. There is a tradeoff, though...

To distinguish between different node types, you will need a one bit flag. In practice, this flag will consume much more than one bit since the operating system may require that memory is allocated in multiples of four bytes, or in powers of two. So, you will be adding memory overhead for all internal nodes, while saving memory at the leaves (which will not have any child pointers).

Here are two other alternatives that work better:

1. Use a different kind of node only for those leaves that are at the maximum depth, i.e. for nodes associated with voxels of the smallest possible size. This way, you don't need a flag: the depth of a node determines its type.
2. Store child pointers using a two-level scheme. Instead of always storing an array of eight pointers at every node, store only one pointer per node: a leaf node contains zero for this pointer, while an internal node sets this pointer to an array of eight nodes.

In essence, you reverse-engineer the file reader in vrender.cc, which is really easy:

1. Create a binary file whose contents, in byte order, are:
   • 50 bytes whose values are ignored, and can hence be anything you wish ("junk bytes");
   • 3 unsigned shorts (using 2 bytes each), whose values are all equal to the volume size L;
   • 6 more junk bytes;
   • the contents of the Opacity array, numbering L³ bytes, in the same order as will be stored in memory (see vrender.h).
2. Run gzip on the file you created.

1. Make sure that the new file resides in the current directory.
2. Its name contains the value of L, right before the mandatory .vol.gz extension. For example, if L is 64, then acceptable file names are foo64.vol.gz, or foo064.vol.gz, while foo or 64foo.vol.gz are unacceptable.
3. In response to any Volume: prompt of do, type the name of the volume preceded by the two characters ./, and omit the trailing .vol.gz extension. For example, enter ./myvolume64 for the volume whose file is named myvolume64.vol.gz.

No, you are not. The whole project should consist only of your own code - after all, you only need to write a total of 150 to 200 lines of code or so...