Too many questions to fit in the subject

radiance-general
1

Hello all. Some of you know me, many do not. But I have
been experimenting with Radiance lately. Thanks to Greg
who tipped me off to the power of OS X (and his pre-
compiled binaries for 3.4). I struggled with LINUX many
times, but never got a totally functional system; I was
rpicting all over the place after a week on OS X. =8-)

Anyway, now that I'm getting a feel for how the various
programs work together, I have gone back and am now
reading the old Radiance Digests. This has been helpful.
Those things read like a "Who's Who in the Radiance
Community". And to see many of the gurus, with more
questions than answers, makes me feel like someday I
may get my head around all of this stuff! Of course, many
of those messages are eight years old. Hmmm...

Enough rambling. Questions:

Philip Thompson, way back in '94, inquired about the
ability to show surface normal orientation in rview. Was
this ever developed? My frame of reference is Lightscape,
which has been excellent in this regard. Surface normals
can be interractively viewed, and backfaces are displayed
in a garish green color. Incorrectly oriented surfaces can
be flipped with a click of a button. It was only after my
initial experiments that I learned surface normal
orientation is a non-issue in Radiance (excepting windows
via mkillum).

Failing rview, what other geometry previewers are you
folks using? Ole Lemming's ConRad has a useful
previewer, that operates similarly to the "view setup"
dialog in Lightscape. I really think this would speed
things along for me, the ability to interractively orbit a
scene & check for modeling errors, normal orientation, etc,
and most importantly, SETTING VIEWS. THis is a real
hassle when you have to provide vp, vd as 3D points. Are
there other previewers besides ConRad?

Greg in one of the digests said windows can be modelled
using a single plane of glass. (I'm used to Lightscape's
requirement of two opposite-facing planes, lest you get
refraction errors in a raytrace.) Does this hold true for the
rest of the building? IOW, a simple room can be modelled
with a single genbox? I have been creating an inner
room and an outer "shell". Again, this may be my
Lightscape logic getting in the way of things here. Of
course for detailed renderings you *have* to model the
wall thickness, but for daylighting analysis, would a single
box (with windows of course) suffice? In Lightscape you
would get "light leaks" around the corners of the interior
as sunlight affected the vertices unless you enclosed the
interior with an outer shell.

Re: skies. Gensky (directed by George Mischler's radout)
creates a description of the sky & ground luminance, and
creates two colored hemispheres. I have seen some
special sky textures available for mapping to a sphere for
more realistic environments. How do these work? Are
they transparent placeholders, which merely display a
picture of the sky but allow the sun & sky luminance to
"pass through", or do they actually modulate the sky
luminance as a function of the chromacity of the pixels in
the sky image?

I have been using George Mischler's radout to bring
geometry from AutoCAD to radiance. But there doesn't
seem to be a way to handle blocks. 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? That seems to be the key to being
able to rapidly change scenes, and stay accurate. Anyone
doing this type of thing already?

Along those lines, is there a way to create a grid or really
any series of points in autocad (via nodes, or blocks or
whatever) and then have the coordinates of those points
be fed to rtrace for lighting analysis? I know you can feed
rtrace the points, but I'm interested in a way to have
autocad export the information rather than me figure out
the points manually. I like to draw the stuff and have
CAD keep track of all the math, ya know?

I found a nice collection of materials online (Kevin
Matthews, Design Workshop). Some of the cal files are
missing, but many of the materials are usable. Does
anyone else have material & light libraries they are willing
to share? I'm also really interested in obtaining
definitions of translucent materials, such as one would
find in a light fixture (sandblasted glass, acrylic, etc).

Paul Bourke offers some great tree examples. Again,
does anyone have other blocks they are willing to share
(vegetation, furniture, you name it)?? =8-)

Paul also has a benchmark page:
http://astronomy.swin.edu.au/~pbourke/radiance |
/benchrad/

I tried the first one and my PowerBook G4 550 rendered it
in 582 secs, which is almost exactly three times as long as
the render time for a 1.5 GHz P4 (see the site for more
times). Is it just coincidence, or is there a fairly direct
correlation between CPU speed and render time,
regardless of processor type? Makes Apple's ad copy
about the "Velocity engine" in the G4 seem like a load of
bunk (which I suspected in the first place). Don't get me
wrong, I love this Mac. But it seems that when I finally
am ready to do production work with Radiance I'm gonna
have to learn LINUX once and for all. The cheapest cpu
cycles are with homebuilt PCs, so it seems that's the way
to go. Interestingly, there is a benchmark for a dual 2GHz
PC, which was only 50% faster than the single 1.5 GHz.
I'm interested in parallel processing, but this seems to
make a case against it. What are your experiences out
there in the field?

Woah. That got long in a hurry. I'll leave it at that for
now. More questions to follow hopefully. I'd greatly
appreciate any responses to my inquiries above.

···

====================
Rob Guglielmetti <[email protected]>
    http://home.earthlink.net/~rpg777

2

Rob Guglielmetti wrote:

  I struggled with LINUX many
times, but never got a totally functional system; I was
rpicting all over the place after a week on OS X. =8-)

Hi Rob,

I recommend SuSe as an Linux distribution that is relatively easy
to install and configure. Other people seem to get good results
with Mandrake. Don't even think about RedHat if you're not very
familiar with Linux already.

Philip Thompson, way back in '94, inquired about the
ability to show surface normal orientation in rview. Was
this ever developed?

This may not be exactly what you wanted, but if you use the -bv-
boolean switch, then all faces will become invisible from the
back...

My personal philosophy about this point is (so far anyway), that
this is the task of the modeller you're using. Once you're
running rview (or any similar program), it's really a bit late
to do anything about flipped orientations. The fact that the
orientation doesn't matter at all for most material types in
Radiance has helped me to stick to this position.

Of course, there is the rshow program by Peter, which works on
most unix systems with OpenGL. I don't know if anyone has tried
to port it to OS X though, nor if it can do anything about
surface normals.

Greg in one of the digests said windows can be modelled
using a single plane of glass. (I'm used to Lightscape's
requirement of two opposite-facing planes, lest you get
refraction errors in a raytrace.) Does this hold true for the
rest of the building? IOW, a simple room can be modelled
with a single genbox? I have been creating an inner
room and an outer "shell".

Radiance normally does fine with thin boxes. There *may* be light
leaks in low quality simulations when the ambient density is too
loose. But with tougher settings, you will rarely see this.

  I have seen some
special sky textures available for mapping to a sphere for
more realistic environments. How do these work? Are
they transparent placeholders, which merely display a
picture of the sky but allow the sun & sky luminance to
"pass through", or do they actually modulate the sky
luminance as a function of the chromacity of the pixels in
the sky image?

The latter is the case, as it's a simple colorpict pattern.
You will lose the accountability of the CIE sky model when you
map a picture onto the sky sphere.

Btw: Rayfront has a simple drop-down box in the sky configuration
dialog to select sky maps... :wink:

  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.

Along those lines, is there a way to create a grid or really
any series of points in autocad (via nodes, or blocks or
whatever) and then have the coordinates of those points
be fed to rtrace for lighting analysis? I know you can feed
rtrace the points, but I'm interested in a way to have
autocad export the information rather than me figure out
the points manually. I like to draw the stuff and have
CAD keep track of all the math, ya know?

Both DR and Rayfront can do this for you.

I found a nice collection of materials online (Kevin
Matthews, Design Workshop). Some of the cal files are
missing, but many of the materials are usable. Does
anyone else have material & light libraries they are willing
to share? I'm also really interested in obtaining
definitions of translucent materials, such as one would
find in a light fixture (sandblasted glass, acrylic, etc).

If anyone wants to share their creations, I'd be more than
willing to establish and maintain an online repository.
Of course, if you use materials that others have created and
expect them to be physically meaningful (beyond just looking
nice), then you'll have to run some sanity checks on them
yourself, especially if you're thinking about procedural
definitions.

Paul Bourke offers some great tree examples. Again,
does anyone have other blocks they are willing to share
(vegetation, furniture, you name it)?? =8-)

If you buy DesignWorkshop, then I think you also get a tree
generator program, which produces data that can be exported to
the Radiance scene file format.

I tried the first one and my PowerBook G4 550 rendered it
in 582 secs, which is almost exactly three times as long as
the render time for a 1.5 GHz P4 (see the site for more
times). Is it just coincidence, or is there a fairly direct
correlation between CPU speed and render time,
regardless of processor type?

There's something wrong either with your machine, or with the
OS X port of Radiance. There is no direct relation of processing
power and clock speed between different CPU types. In general,
PowerPC CPUs require about half the cycles for the same results
(ie. your 550 MHz G4 is roughly aequivalent to a 1 GHz P4). If
you get only the same performance per cycle on your G4, then
you're probably running into a system bottleneck of some kind
(disk access, RAM size etc.).

Does your HD go to sleep when it isn't accessed for a few
minutes, or do you have any other power saving features turned
on? Were the Radiance binaries compiled with comparable
optimization flags? It may also be that a laptop simply has a
relatively slow HD installed to preserve energy. If you're low on
RAM, then this could stall a Radiance simulation to some degree.

Makes Apple's ad copy
about the "Velocity engine" in the G4 seem like a load of
bunk (which I suspected in the first place).

No, this must have something to do with your specific system.
The G4s *are* faster than most Pentiums out there.

  Interestingly, there is a benchmark for a dual 2GHz
PC, which was only 50% faster than the single 1.5 GHz.
I'm interested in parallel processing, but this seems to
make a case against it. What are your experiences out
there in the field?

Linux isn't optimized for multi-CPU systems yet, although it's
getting better. It is even more difficult to directly equate
clock speed with processing power on multi-CPU system than it
already is with normal boxes. The overall architecture of the
system (both in hardware and software) can influence the result
up to a factor of 50% or more. If the amount and type of your RAM
or the configuration of your HD isn't carefully balanced against
the CPU specifications, then you'll get quite surprising results.

-schorsch

···

--
Georg Mischler -- simulations developer -- schorsch at schorsch.com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/

3

Hi Rob,

Philip Thompson, way back in '94, inquired about the
ability to show surface normal orientation in rview. Was
this ever developed? My frame of reference is Lightscape,
which has been excellent in this regard. Surface normals
can be interractively viewed, and backfaces are displayed
in a garish green color. Incorrectly oriented surfaces can
be flipped with a click of a button. It was only after my
initial experiments that I learned surface normal
orientation is a non-issue in Radiance (excepting windows
via mkillum).

IMHO, the only real non-trivial problem with incorrectly oriented
surfaces happens with solid glass (=dielectric) objects. If the CAD
spills out polygons with quasi-random orientation (AutoCAD 12 caused me
some temporary headaches years back), hand tweaking the orientations is
not an option. Problems with orientation of glow and spotlight surfaces
are typically easier to hand-tweak. All other surfaces, as you know,
don't care for orientation.

Failing rview, what other geometry previewers are you
folks using? Ole Lemming's ConRad has a useful
previewer, that operates similarly to the "view setup"
dialog in Lightscape. I really think this would speed
things along for me, the ability to interractively orbit a
scene & check for modeling errors, normal orientation, etc,
and most importantly, SETTING VIEWS. THis is a real
hassle when you have to provide vp, vd as 3D points. Are
there other previewers besides ConRad?

rshow - shows surface
orientation too (when moving the mouse over surfaces and keeping the
middle (OS-X ??) button down.) come to think of it,- there's no OS-X
version available yet.

...

Along those lines, is there a way to create a grid or really
any series of points in autocad (via nodes, or blocks or
whatever) and then have the coordinates of those points
be fed to rtrace for lighting analysis?

rshow has an option for that too
...

I found a nice collection of materials online (Kevin
Matthews, Design Workshop). Some of the cal files are
missing, but many of the materials are usable. Does
anyone else have material & light libraries they are willing
to share? I'm also really interested in obtaining
definitions of translucent materials, such as one would
find in a light fixture (sandblasted glass, acrylic, etc).

I guess one problem with libraries is the naming. When 4 people find
"Sandblasted" in the list, they have 25 different ideas how that looks
in reality. "Lightly sandblasted" doesn't help either.

...

I tried the first one and my PowerBook G4 550 rendered it
in 582 secs, which is almost exactly three times as long as
the render time for a 1.5 GHz P4 (see the site for more
times). Is it just coincidence, or is there a fairly direct
correlation between CPU speed and render time,
regardless of processor type?

No way. CPU architectures (super-scalar, pipelining, cache coherence)
plus compiler optimizations de-correlate clock speed from rendering
times.

to go. Interestingly, there is a benchmark for a dual 2GHz
PC, which was only 50% faster than the single 1.5 GHz.
I'm interested in parallel processing, but this seems to
make a case against it. What are your experiences out
there in the field?

I've got no experience with 2Ghz (AMD ?) dual boards, although all other
duals (PII 200MHz- PIII 1Ghz) worked as expected so far. Mem speed, disk
times (if needed, typically not so much for Radiance during rendering,
rpict does heavy I/O only at startup while reading the scene) and cache
size may slow down overall throughput.
btw: With rpict, -PP allows sharing the geometry between two rpict
programs on the same machine. Useful for large scenes.

-Peter

···

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

4

Hi Rob,

I recommend SuSe as an Linux distribution that is relatively
easy to install and configure. Other people seem to get good
results with Mandrake. Don't even think about RedHat if
you're not very familiar with Linux already.

Hi Georg, how ya doin'? Did you get a chance to see that
movie "Pi" I was telling you about?

Yes, I heeded your advice about SuSE a number of years
ago, and that was indeed the closest I got to really doing
something with Radiance on the PC. That was the first
distro that I got installed and was able to compile
Radiance. There were some utilities not working correctly
though, and I never got a chance to troubleshoot them,
because about a week after my first radiance compile
success, a fire broke out in my apartment building. The
good news was the fire did not destroy my apartment;
the bad news was, mine was was on the top floor and
the fire department cut a cole in my ceiling to vent the
smoke. They cut a 4'x4' hole in the ceiling. Guess what
was under it -- my computer!! Grrr. Yes, I had countless
problems with Red Hat, and no, I'm not familiar with it. I
expect that soon I will need to go out & buy the latest
SuSE and try installing it on my PC at home. The Mac has
been a good jump-starter for me though.

This may not be exactly what you wanted, but if you use the
-bv- boolean switch, then all faces will become invisible
from the back...

Interesting. Well, since you have confirmed that normals
don't matter (except for mkillum), I guess I shouldn't
worry about it. I can use that switch to confirm that
mkillum polygons are correct though. Thanks.

My personal philosophy about this point is (so far anyway),
that this is the task of the modeller you're using. Once
you're running rview (or any similar program), it's really a
bit late to do anything about flipped orientations. The fact
that the orientation doesn't matter at all for most material
types in Radiance has helped me to stick to this position.

I agree with you. It is a bit late in the game to fix it at the
rview stage. You wouldn't happen to know the name of
the lisp utility that comes with DR, that shows normals? I
suppose I could use that too...

Of course, there is the rshow program by Peter, which works
on most unix systems with OpenGL. I don't know if anyone has
tried to port it to OS X though, nor if it can do anything
about surface normals.

Yes, I have heard of rshow and it looks good. But as
soon as I saw that it was OGL, I assumed I'd need Mesa,
and compiling, and well you know my experience is not
quite up to that yet. Maybe that's a good challenge for
me though, since Greg already took care of compiling Rad
for us OS X users.

Radiance normally does fine with thin boxes. There *may* be
light leaks in low quality simulations when the ambient
density is too loose. But with tougher settings, you will
rarely see this.

OK then, my modelling chores are getting easier!

> I have seen some
> special sky textures available for mapping to a sphere for
> more realistic environments. How do these work?

The latter is the case, as it's a simple colorpict pattern.
You will lose the accountability of the CIE sky model when
you map a picture onto the sky sphere.

Btw: Rayfront has a simple drop-down box in the sky
configuration dialog to select sky maps... :wink:

OK, so validity goes out the window when you map the
pretty pictures. For serious daylighting analysys I should
stick to the gensky primitives.

Yeah, maybe I need to have a look at your demo. Since I
don't have a Linux system running (yet), what will I be
missing by using the NT version? See, the whole reason
I'm trying to learn Radiance from the Unix side is because
I'm amazed by all the scripting possibilities (the time of
day image sequence in "Rendering With Radiance" for
example) it affords. Just wondering if there are things
that just aren't possible on the NT side.

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.

Hmmm. I was thinking of only using it for importing
luminaire layouts and lighting analysis points. In fact, I do
this all the time in Lightscape, using their block
substitution routine. How do you get your luminaires
from AutoCAD into Radiance scene descriptions?

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.

I know very little AutoLISP. But maybe I'll have a look.

> Along those lines, is there a way to create a grid or
> really any series of points in autocad (via nodes, or
> blocks or whatever) and then have the coordinates of those
> points be fed to rtrace for lighting analysis?

Both DR and Rayfront can do this for you.

I figured, I was just wondering if there was a way to
script it with the basic package.
  

If you buy DesignWorkshop, then I think you also get a tree
generator program, which produces data that can be exported
to the Radiance scene file format.

Yes, I saw on their website that there is a tree generator -
- you sort-of build your own tree by selecting from a menu
of choices, and then you download a DW file, which can
then be exported to Radiance format from DW. I had DW
at my old office but found it very buggy, crash-prone.

There's something wrong either with your machine, or with
the OS X port of Radiance. There is no direct relation of
processing power and clock speed between different CPU
types.

Does your HD go to sleep when it isn't accessed for a few
minutes, or do you have any other power saving features
turned on? Were the Radiance binaries compiled with
comparable optimization flags? It may also be that a laptop
simply has a relatively slow HD installed to preserve
energy. If you're low on RAM, then this could stall a
Radiance simulation to some degree.

Hmmm. I ran it while on battery, and figured the CPU was
ramping down to conserve juice and that that was the
cause, but I plugged it in and re ran it, and the first three
checkpoints were all identical (i.e. same percentage
complete). It's a small scene and the laptop has 512MB
of RAM, so I didn't think it could be paging/disk access.
I'm still not up on all the tweaks one can do in unix to give
jobs priority; perhaps that's the problem. Dunno. That's
why I didn't bother to send the timing to Paul Bourke,
because I suspect it's inaccurate (or unfair).

···

On 9 May 2002, at 14:16, Georg Mischler wrote:

         ====================
Rob Guglielmetti <[email protected]>
    http://home.earthlink.net/~rpg777

5

Hey Rob:

One way to check normal orientation by hand with Radiance is to assign a
temporary material using a glow material to the geometry in questions.
The "front" side will be the color of the glow while the "back" side
will be black. Rather than looking at all the geometry in question you
can use objview to look at the specific geometry of interest.

Regards,

-Jack de Valpine

···

--
# John E. de Valpine
# president
#
# visarc incorporated
# http://www.visarc.com
#
# channeling technology for superior design and construction

6

Hi Rob,

Georg and Peter have already done a really good job answering these, but I wanted to add my two cents, anyway....

Failing rview, what other geometry previewers are you
folks using? Ole Lemming's ConRad has a useful
previewer, that operates similarly to the "view setup"
dialog in Lightscape. I really think this would speed
things along for me, the ability to interractively orbit a
scene & check for modeling errors, normal orientation, etc,
and most importantly, SETTING VIEWS. THis is a real
hassle when you have to provide vp, vd as 3D points. Are
there other previewers besides ConRad?

Check out the "glrad" program that comes with Radiance 3.4. It works on my version of X11 for OS X, which is the same as yours, as you told me how to install it! Also, take a look at the rholo program and see if you can figure out how to work it. This gives you a more flexible way to move around your scene than rview.

I have been using George Mischler's radout to bring
geometry from AutoCAD to radiance. But there doesn't
seem to be a way to handle blocks. 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? That seems to be the key to being
able to rapidly change scenes, and stay accurate. Anyone
doing this type of thing already?

I'm way out of my depth, here, but have you looked at the replmarks program that comes with Radiance? I would think Georg would have mentioned it in his reply unless he had a reason not to, so maybe it's irrelevant. Anyway, replmarks replaces triangular placeholders with Radiance instances or objects, and it shouldn't be too difficult to adapt this to work with AutoCAD blocks, though I admit that I'm not sure what these are.

-Greg

7

Rob Guglielmetti wrote:

Yes, I have heard of rshow and it looks good. But as
soon as I saw that it was OGL, I assumed I'd need Mesa,
and compiling,

MESA is one Open-GL implementation running on top of X11 with no
hardware acceleration.
If a system is configured with other Open-GL libraries, typically using
direct hardware rendering in conjuntion with kernel and X11 server,
rshow, as other Open-GL programs, will use that, since it uses the
shared libraries installed on the system. It is known to run on
I386-architecture SUSE7.3 on a machine which had been configured to use
HW accel.
-P.

···

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

8

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