[Radiance-general] Re: rad and oconv questions

Thu, 22 Aug 2002 19:03:30 -0700

Hi Thomas,

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 protected]>
> Organization: University of Waterloo
> To: [email protected]
> Subject: [Radiance-general] oconv
> Reply-To: [email protected]
>
> 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:

> SYNOPSIS
>        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.