Rob Guglielmetti's response about the overture calculation used by rad is correct except for the reason why. It is not merely to speed up the final rendering calculation -- the time spent in the overture calculation is greater than the time saved in the final one. The real reason rad does this is to minimize interpolation artifacts as explained at the top of page 551 in the "Rendering with Radiance" chapter 12 on the indirect calculation.
Date: Tue, 20 Aug 2002 17:31:37 -0400
From: Thomas Seebohm <email@example.com>
Organization: University of Waterloo
Subject: [Radiance-general] oconv
A little while ago I wrote about using the i option to combine smaller
octrees into a larger one. This is described in chapter 8 of the Radiance
text, section 8.5 on large data sets. Page 467 give the following example:
oconv -f fl.lgt st.lgt cl.lgt -i e_twr.oct -i w_shr.oct ... > bridge.oct
Omigosh. I don't know how this one slipped by the editor -- no one ever pointed it out to me before, but it must have been pretty late at night when Rob typed it in... Quoting the oconv man page:
oconv [ -i octree | -b xmin ymin zmin size ][ -n objlim ][
-r maxres ][ -f ][ -w ][ - ] [ input .. ]
This is meant to indicate that the options must preceed the scene input files. The man page doesn't explicitly state that only one octree may be added to, but it should. The reason for this is because the starting (-i) octree defines the boundaries of the scene, which may not be changed when adding new objects. If you were to attempt to combine two octrees, their different boundaries would make them impossible to reconcile -- you might as well start fresh from the objects, themselves. The only reason for building octrees incrementally is if oconv runs out of space building the whole octree at once, or you are trying to save time in an animation where only a few objects are changing in an otherwise static environment.