[Radiance-general] Re: Instances + octrees

[Charles Ehrlich]

Lars O. Grobe wrote:

Hi,

while I am still not sure if I am on a secure path with my model's 
structure, setting oconv's resolution to 256 fixed the problem for 
now...

CU Lars.


A more efficient approach *might* be to create a set of nested instances.  Each super-instance would include eight sub-instances (-n 8), and each of the eight sub-instance further instances until the entire scene is enclosed in one bounding box.  If there are 8 or fewer "objects" per octree (instance) then oconv does not bother to futher subdivide, thereby allowing oconv to do its job. Greg would know how many times you can nest instances, but if I remember correctly, it is not infinite.  An instance counts as a single object, of course.

It is debateable as to whether this approach will result in a "better" octree.  The maxres (-r 256) approach could introduce errors in the intersection calculation in very large scenes with very small pieces, but increasing the object limit (-n >7) slows down the ray-intersection calculation because it has more objects to deal with (a higher-order equation to solve for the zeroes). In my experience, you can double the object limit with only a small increase in rendering time, sometimes not even noticeable.

However, when it comes to render the scene, each ray that goes between one instance and another must go through a ray transformation operation to align it with the "object space" of the next instance. The transformation ops are applied to *every* ray including ambient, shadow, etc.   All other things being equal, the resulting octree will not render as quickly as one generated without instances.  For a given maxres, the optimum solution would be a balance between the object count per instance (-n N) and the total number of sub-instances.

And, be sure the boundaries of each of the instances are world-axis aligned.  If there is any structure to the underlying geometry, be sure to align the octree boundaries with the "structure" of the underlying geometry (the other way around, actually.)  For example, a digital elevation model is made up of a uniform pattern of triangles forming a square when projected onto a plane.  It is much easier to oconv when the "grid" of the DEM is world axis-aligned.  For non-converging scenes it is better to oconv the object and then rotate and transform it into the appropriate location in the scene as an instance rather than the other way around.

The DEM scene also is a good example of carefully selecting the maxobj parameter.  A cubic "chuck" of such a scene can either contain 2, 8, or 32 triangles.  Eight is the best value for -n because it is closest to Radiance's optimum value of 7.

Obviously, if oconv simply will never converge on a solution (so to speak) then you *must* use the nested instance approach.  But, the success of this approach depends upon the modeler's ability to divide up the scene into nice, semi-cubic, non-overlapping chunks.  Some scenes simply do not allow this to happen easily.  In one case, I used something akin to a fancy "sed" script to arbitrarily divide the scene into separate pieces which were then oconv'd, instanced, and assembled into a coherent scene.  With Desktop Radiance, if you create an AutoCAD "block" out of some surfaces and then "insert" it into the drawing, that object will be treated as an instance.  (I had to get a plug in there somewhere.)

I apologize if this is old news.  I do not keep up with this list as much as I'd like.

-Chas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://radiance-online.org/pipermail/radiance-general/attachments/20040706/262e99e8/attachment.htm