[Radiance-general] Octree blocks

[Greg Ward]

Kurt Altmann wrote:

> I also spent some time on tests on the export of blocks from AutoCAD to
> instances in Radiance.
> At least it's working in a more or less rough manner (even with nested
> blocks).
> Beside the consistency problems Georg already mentioned, problems arose
> concerning the paths
> (to texture files or IES-data) and the shape of the octree hierarchy.
> Especially thin long Objects, like railings, or flat Objects, like
> leafs, produce the biggest problems.
> I had to reorganize the blocks to get the expected savings in memory and
> file sizes (which could be enormous, of course).
> In other words - I must create the geometry in terms Radiance likes it
> most - which isn't always the most efficient way to build 3D-Modells.
> As I understood, the octree is based on cubes. Looking at a leaf
> parallel to the xy-plane inside a cube, there is a lot of 'emptiness'
> inside this cube. The cubes of other nearby leaves are interconnected
> which often result in an error by oconv.
> As a result I have to reorganize the blocks or increase the n-parameter
> dramatically.
> For these problems it could help a lot, if the 'cage' around objects
> could be handled in a more relaxed way, i.e. in terms of a real bounding
> box.
> Are there any thoughts done already in that direction? Could it be a
> feature for the future?
> Or is it impossible due to the existing octree organization?
> Any comments are welcome.
>
> Kurt
> EMAIL   mail@kurt-altmann.de

It is terribly inefficient to create instances with only a few 
primitives in them.
An octree should have a few hundred geometric primitives to make it
worthwhile in terms of rendering time.  Given such a constraint, it is 
usually
possible to partition geometry so it is roughly cubical in terms of 
volume,
though I agree this is an inconvenience.  The only reason it was done 
this
way is to stick with a strict octree as opposed to a binary partition 
tree,
which is more complicated to code and takes up more space in memory.
One could have an octree with a non-cubical bounding box, but the
efficiency of tracing rays through long, thin subcubes would be awful.

I don't recommend putting individual leaves into instances -- when I have
used instances for trees, I put groups of leaves or needles together into
an instance.  It may be better to put in the entire tree in many cases.
Railings and walls should never go into instances.

As I suggested to Rob, the replmarks program offers the ability to 
generate
xform calls to place raw geometry into the scene, and this is far 
preferable
for long or thin geometry such as you describe.  Instancing should be
reserved for cases where duplicating geometry causes memory problems
during rendering, such as when you are modeling a forest of trees or
a great number of similarly complicated geometric objects.  For simple,
replicated geometry, you will get faster renderings and less hassle if
you just duplicate it throughout your scene, even if it means having
hundreds of identical objects floating around.

Here's a good rule of thumb for when instances might be appropriate:

N_p > 200, and
N_o * N_p > N_t / 5

where:
	N_p = number of geometric primitives in instanced object
	N_o = number of instances
	N_t = total scene size (excluding other instances)

Otherwise, it is better to use xform and just duplicate geometry.

-Greg