[Radiance-general] rtrace

[Thomas Bleicher]

Morning Jia.

On Wed, Jul 14, 2010 at 3:28 AM, Jia Hu <hujia06 at gmail.com> wrote:
> Dear Radiance experts:
>
> I plan to calculate illuminance of an office model by using multiprocessing
> (6 processors). I saw some posts discussing about this
> problems (e.g.
> http://www.rumblestrip.org/interests/light/rtrace-multiprocessing-option-initial-test-results/).
>
> (1) I have some questions about the usage of rtrace.
> There are two options "i", "I" (one lower i and one upper i).
> I checked the manual page but I am still confused with their difference.

First think about what rtrace really does: It calculates the
brightness of a point on a surface seen from the origin with a given
view direction (the six coords per line you feed into it). The result
is a separate value for the red, green and blue colour component. If
you do number of calculation each with a slightly different angle you
can compose an image out of these r,g,b values. This is what rpict
does.

The brightness of the spot depends obviously on the colour of the wall
and the amount of light that falls onto it. A dark wall will reflect
less of the incident light than a white wall. You can use rcalc to
convert these into to the photopic average ie. how "bright" this spot
appears to the human eye.

So far so good, but in daylight simulation we are traditionally less
interested in the brightness of a surface than in the light that falls
onto it. Therefore rpict and rtrace offer the "-i" (lower case) switch
which will ignore the surface colour on the last bounce and report the
amount of light that falls on a given spot instead of the light that
is reflected off it. An image calculated with this option can be
converted with falsecolor to a colour map or in a contour line image
which shows the Lux levels on any given surface.

What now if you want to calculate the incident light on a surface when
there is no physical surface that would show in an image (like a
theoretical workplane)? This is what the "-I" (upper case) option
accomplishes: In addition to reporting the irradiance/illuminance it
also adds a virtual plane at the point of your origin and flips around
the origin and direction.

Take for example an origin of (0,0,0.75) and a direction of (0,0,1)
for up which calculates the horizontal illuminance at 750mm. With "-i"
rtrace would look from (0,0,0.75)  straight up to the ceiling and
calculate the light falling onto the spot at (0,0) on the ceiling.
With "-I" rtrace creates a virtual surface at 750mm with a surface
normal of (0,0,1) (=horizontal). Then it places the origin at
(0,0,0.75+1) and looks down onto this surface (new view
direction=(0,0-1)). The result is the irradiance on a horizontal
surface calculated at (0,0,0.75). Just what we need for daylight
factors etc.

> (2) What is the option "-h" (in rtrace) used for? I run several times but do
> not see any header information.

As I mentioned above you can created images pixel by pixel using
rtrace. However, a valid Radiance picture needs a header containing
the resolution and other information. By default rtrace prints this
header before it prints the results of the calculations. (I assume
there are historical reasons for that. I'd expect that most uses of
rtrace switch the header of with "-h".)

You probably have never seen the header because your output is piped
through rcalc which converts it into a bit of number garbage. Just try
the following commands on your bash prompt:

echo "0 0 1 0 0 1" | rtrace scene.oct
echo "0 0 1 0 0 1" | rtrace -h scene.oct
echo "0 0 1 0 0 1" | rtrace -h -w scene.oct

Substitute "scene.oct" with any octree you have around. The difference
between the first two should be obvious. The last command uses "-w" to
switch of the warning about "no light sources found", too. That will
only be printed if you have no sun in your scene, though.

> (3) There are interior blinds installed. If I first use mkillum to make the
> window as a secondary light source, and then run rtrace, in this case the
> program runs twice to get the illuminance value. Does this way make running
> faster than directly using rtrace (only once)?  I input the model from
> Revit and thus the window object is connected in the .rad file and therefore
> It is not easy to use mkillum (To use mkillum requires either (1) not
> to import window from revit and to generate window in Radiance or (2) cut
> and paste the window .rad to a separate .rad file?)

mkillum can help you saving time by splitting the calculation in one
part for the exterior (until the light reaches the window) and one for
the interior. If your exterior is fairly simple there is little gain
from this extra step.

You will also find it difficult to extract the window glass geometry
from your *.rad file if it is produced by Revit. The normals might be
the wrong way around and you may have multiple surfaces instead of
only one as mkillum requires. I think you're better of not to use
mkillum at his point. If you have doubts about the accuracy of your
calculations increase "-ab" by 1 or 2.

> (4) For mutiprocessing, besides the option "-n",  is there any other
> options I should pay attention to? I use Python script, and should I set
> other options related to Python itself?

There are no options for Python that would affect Radiance. From Rob's
page you should know that you need to specify an ambient file ("-af"
option) to benefit of the "-n" parallel processing. If you have a
number of options for your geometry you can also just run one rtrace
process for each scene in a separate shell. Then you don't have to
worry about parallel processing options.

Cheers,
Thomas