Octree blocks

radiance-general
1

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 [email protected]

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

2

Greg Ward wrote:

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.

Geometry exported from CAD is often complex and uses Radiance primitives
not very efficiently, e.g. everything is tesselated into polygons, even
if the surface could be described as sphere, cone etc. Mostly
hierarchical structures are left intact, e.g. a line of complex carved
posts is known to the exporting routine as "instances" of the same
element.
Then, IMHO, there's no generaly sound way to reorganize geometry to fill
RADIANCE instances with cube like geometry.

One could have an octree with a non-cubical bounding box, but the
efficiency of tracing rays through long, thin subcubes would be awful.

If I get this right, the penalty for non-cubical bounding boxes with
non-thin geometry distribution would be nil, with the advantage that it
would allow placing "thinny" instances next to another without
overlapping bounding cubes.
Code for checking ray intersections with non-cubical boxes would be as
efficient as checking cubical boxes ? If not, would that be
counterweight by the speedup as rays close to the bounding box miss the
non-cubical box completely whereas they hit (and trigger at least one
octree lookup) a cubical now ?

As always, any insights very much welcome
-Peter

···

--
pab-opto, Freiburg, Germany, www.pab-opto.de

3

Hi Peter,

From: Peter Apian-Bennewitz <[email protected]>

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.

Geometry exported from CAD is often complex and uses Radiance primitives
not very efficiently, e.g. everything is tesselated into polygons, even
if the surface could be described as sphere, cone etc. Mostly
hierarchical structures are left intact, e.g. a line of complex carved
posts is known to the exporting routine as "instances" of the same
element.
Then, IMHO, there's no generaly sound way to reorganize geometry to fill
RADIANCE instances with cube like geometry.

Then use "xform" rather than instances.

One could have an octree with a non-cubical bounding box, but the
efficiency of tracing rays through long, thin subcubes would be awful.

If I get this right, the penalty for non-cubical bounding boxes with
non-thin geometry distribution would be nil, with the advantage that it
would allow placing "thinny" instances next to another without
overlapping bounding cubes.
Code for checking ray intersections with non-cubical boxes would be as
efficient as checking cubical boxes ? If not, would that be
counterweight by the speedup as rays close to the bounding box miss the
non-cubical box completely whereas they hit (and trigger at least one
octree lookup) a cubical now ?

I shouldn't have said "subcubes" when I meant "sub-boxes." Ray
intersection tests in long, thin sub-boxes would be inefficient, and
the only way to make it efficient again is using a kd-tree, which
is more complicated to code. I originally implemented cubical
octrees because they were simpler and just as fast as kd-trees
according to other people's research on the subject, and when
I added instances later, I was too lazy to reimplement everything
just so I could have non-cubical bounding boxes for instances.
I barely got it to work properly as it was -- you wouldn't believe
how much stuff is going on "behind the scenes" to make instancing
work right. (Well, maybe you would.)

I wouldn't trust the octree code with long, thin boxes. It's too likely
to run into floating point inaccuracies in extreme cases. A lot of
the design of Radiance is based on my intuition of what will work
and what won't, and you're welcome to try things out
and prove me wrong. I really don't mind, or take it personally.

-Greg