[Radiance-general] Too many questions to fit in the subject

[Kurt Altmann]

Georg Mischler wrote:
> 
> Rob Guglielmetti wrote:
> 

> >   It would be great if
> > there was a way to substitute autocad blocks for
> > instanced rad files!  One could export the blocks as
> > separate rad files, but is there a way to take a series of
> > insertion point coordinates and build a rad file that
> > instances the "block" rad file at those
> > coords/orientations?
> 
> In theory, this sounds easy. In practise, it would open a
> pandora's box of consistency problems, not to mention the
> questions about how to assign materials to subentities within
> such blocks that are placed on different layers. I have been
> pondering those issues for years, and haven't come up with a
> practical solution yet.
> 
> I think there was some talking about doing this for Desktop
> Radiance, but I have no idea if they actually got around to
> implement anything of the kind. Since DR never looks back at the
> Radiance data it has written, but simply overwrites it when you
> change anything within Autocad, it can avoid many (but not all)
> of the consistency questions.
> 
> If you're feeling adventurous and know some Autolisp, then you
> could try to hack my old torad.lsp translator. If you manage to
> come up with a fool proof solution, then I'll immediately
> integrate it into Radout.
> 
Hi all,

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

________________________________________

Kurt Altmann
Sophienstr. 114a
76135 Karlsruhe
Germany
TEL     +49 (0)721 3849730
FAX     +49 (0)721 3849735
EMAIL   mail@kurt-altmann.de