RADIANCE Digest Volume 3, Number 1

The release of this digest corresponds with the release of
the next version of Radiance--v. 3.1.1 to be announced in a
subsequent e-mail.


Index of Topics



To: CKEhrlich@lbl.gov

Hi Mr. Ehrlich,

     I have a quick question regarding the "pdfblur" command in 
radiance.  To try the command I typed :

1% rpict -vf myview -x 640 -y 480 -z orig.zbf scene.oct > orig.pic
2% pdfblur 0.5 60 8 orig.pic | pinterp -B -vf myview -x 640 -y 480 
orig.pic orig.zbf > blurry.pic  

Of course, "scene.oct" and "myview" are files already available.

The problem is that after three days of computation on a Indigo2 the 
program was still running!  I had to kill the process thinking something 
was wrong.

I am trying to model the effect of camera Focal Length and aperture for 
various ray traced images.

Thank you for your precious help.



Date: Wed, 28 May 1997 17:50:13 -0700
From: radiance (Radiance Maintenance)
To: valois@cim.mcgill.ca, chas@pink (Charles Ehrlich)
Subject: Re:  pdfblur

Hi J-S,

I just ran pdfblur on a similar problem, and it did take a few minutes,
but it finished and the results were what I expected.  I don't know what
the problem is.  Perhaps you could check to make sure that the output
of pdfblur is a sequence of VIEW= lines.  Which version of Radiance are
you running?



Date: Thu, 29 May 1997 13:21:00 -0400 (EDT)
From: Valois Jean-Sebastien <valois@cim.mcgill.ca>
To: Radiance Maintenance <radiance>
Subject: Re: pdfblur

    I would first like to congratulate you on your new position at SGI. I am
sure your experience in computer graphics will contribute toward better
hardware and software products from SGI.  In that sense it is good new for 
all of us ;) .


   pdfblur for a few minutes ?!?  Mine was running for three days without any
success!  Ok, I guess I don't know how to use it.  Actually, I am combining
pinterp and pdfblur (from Radiance v3.0) to simulate ZOOM.  I
used the example given in the man pages under pdfblur where it says:

rpict -vf myview -x 640 -y ...
pdfblur 0.5 57 8 orig.pic | pinterp -B ...

   Instead of "pinterp -B -vf orig.pic ..."  I used "pinterp -B -vf myview
..."   That must be it!  I just realized the mistake.

   Anyway, I am only using ONE view point (VIEW) to run the simulation,
the same view point that I am using to generate a "pin-hole" type of 



Thank you.

Sincerely yours,
|        Jean-Sebastien Valois B.Eng         | 
| * Email: valois@cim.mcgill.ca              | 
| * Web page (Where and how to reach me):    | 
|          http://www.cim.mcgill.ca/~valois  | 


Date: Sun, 01 Jun 1997 17:13:46 -0400
From: Morgan Larch <mlarch@ix.netcom.com>
To: radiance-discuss
Subject: Naive question regarding -vp and -vd

Hello all, 

I have finally gotten a chance to spend some time
with radiance and am stumped with the relationship
between -vp and -vd and the scenes that I have
been working on. 

I have used torad (which is great) to pull out
several sections from autocad to get a better visual
on light and space. What I need to be able to is
as *simple* as move up and down, front and back, and
so on without incurring fisheye perspective distortions.
I'm sure this is not so simple once you get
into the details, but never mind the the details
for now, I can figure that out as I get going. 

So, how do I use -vp and -vd to move up, down, etc...

Humbled, and hoping for you indulgence,


I think that I am on the list but have not seen
any traffic in the last month or so. If there has
been traffic, please let me know so that I can



The trick to prevent vertical perspective distortion
is to maintain a view direction that is paralell to
the X-Y plane (assuming Z is up), and changing ones
vertical view orientation with the "-vl" view option.

For example, the following two view definitions are
*roughly* similar:

rview -vtv -vp 0 0 0 -vd 1 1 0.000 -vu 0 0 1 -vs 0 -vs 0.2
rview -vtv -vp 0 0 0 -vd 1 1 0.127 -vu 0 0 1 -vs 0 -vs 0

This topic is discussed in more detail in the Radiance
digests which can be found in the doc directory of the
Radiance distribution.  

I double-checked the discussion list, and your e-mail is
on it. 

Charles Ehrlich
Principal Research Associate
Lawrence Berkeley National Laboratory


To: ckehrlich@lbl.gov
Subject: RADIANCE 3.0 
Date: Thu, 29 May 97 16:22:17 +0200

Hi Chas,


For my thesis I had to measure the illuminance value for a road during the 
night. The caracteristics of the luminaire are given by a manufacturer 
(Photometric data for 25 horizontal and 27 vertical angles). I have to 
create the IES file. It is a symetric luminaire for roads lighting.

Actually, the results are very different of results given by a firm 
specialised in lighting.

To obatin the values I use : ximage my.pic | rlux my.oct
or I render the image with the -i option.

Could you tell me if the geometry of the luminous area given in the IES 
is very important to use in RADIANCE ? In my case, the luminaire is an 

Is the description of the sky important ?

And the important question : Is RADIANCE valid to render with accuracy 
exterior scene ?

Thank you for your rapid reply ( I had to present my thesis the 15th of 

E-mail: duvivier@motelec.fpms.ac.be

Date: Thu, 29 May 1997 14:26:01 -0700
To: duvivier@motelec.fpms.ac.be
Subject: Re:  RADIANCE 3.0

Hello Vincent,

If you have the raw candlepower distribution data, it is more
convenient to simply create a Radiance data file which describes
the output of the luminaire, than to first create an IESNA file
and then translated it into Radiance.  Unfortunately, until
the publication of the Radiance book, this is one of least well
documented features of Radiance.

I recommend that you use a sphere made of material illum rather
than an ellipsoid.  The invisible illum sphere will be just large 
enough to completely enclose the visible geometry of the luminaire.
If glare is important, then this geometry should also contain 
a surface which describes the visible output aperature of the
luminaire, which would be modeled with material glow. 

The intensities of the glow and illum would be inversely proportional
to the projected area (in meters) of each of their respective surfaces.
The projected area of the illum sphere is a circle (of course)
and the projected area of a mesh of polygons would be the sum of
the polygons' areas.  When you have these data available, use the
lampcolor program to compute the R G B intensities for each surface.
There will be no double-counting of the illuminance even though
there is both a glow and an illum because the glow will have a
radius of effect of zero, and any ambient rays that happen to go
reach the illum sphere will be stopped before reaching the glow.

Assuming the data is bi-laterally symmetrical, and since 180 is not
evenly divisible by 24 and 90 is not even divisibly by 26, the data 
file will look something like:


0 0 27 v1 v2 v3 ... v27
0 0 25 h1 h2 h3 ... h25
v1h1 v1h2 v1h3 ... v1h25
v2h1 v2h2 v2h3 ... v2h25
v27h1 v27h2 v27h3 ... v27h25

V1 through v27 and h1 through h25 are the specific vertical and
horizontal angles respectively at which the data is provided, 
and the v1h1 through v27h25 are the actual values at each angluar 
location.  If the data you have is provided in the opposite
order, then simply swap the two lines after the "2" and use the
data as you have it.  What is different about this format than
most data file formats is that the abcisas and ordinates are
not specified on each and every line of data.

Lets assume the above datafile is called lum1.dat.  This data
would then be included into the radiance scene with a brightdata
pattern thusly:


void brightdata illum_sphere_pat
5 corr lum1.dat source.cal src_theta src_phi2
1 .95
# if depreciation factors need to be accounted for
# then change .95 to the corresponding total accumulated
# depreciation allowance.

illum_sphere_pat illum illum_sphere_mat
3 R G B
# intensities as provided by lampcolor

illum_sphere_mat sphere illum_sphere_surf
4 X Y Z R
# location and radius of sphere


There are many other examples of how to do this provided
with the digests in ray/doc/digest.  I recommend that you 
browse them thoroughly to satisfy yourself that you are 
doing this correctly.  You should also make sure that
your luminaire is oriented correctly with respect to the

To calculate illuminance values on the roadway, create
a "plan" view of the road with a view definition like:

rview -vtl -vp 0 0 1 -vd 0 0 -1 -vu 0 1 0 -vh 100 -vv 10

And use the -I parameter of rpict (or rview, or rtrace).
When the final image is then viewed with ximage and the
value of a pixel is queried with "L", then the resulting
value will be in lux.

If this is a nighttime view, the sky is not important.

Radiance is accurate for interior and exterior scene.  The
point of least accuracy in this sort of analysis would be
the material description of the surface of the roadway.  But,
since you are not calculating luminances, this will not
affect your results.  The problem with roadway surfaces is
that there is self-shadowing--something not well treated
by any existing material model.



Subject: RADIANCE 3.0 / luminaire 
Date: Mon, 09 Jun 97 17:11:47 +0200

Hi Chas, 

I am Vincent,

Thank you very much for your reply about modeling luminaires.

I have others questions : 

If the raw candlepower distribution data of the luminaire is in (cd/1000 lm) 
and the total output of the luminaire is 16500 lumens, is it correct to put 
16.5 (or 16500) for 'total lamp lumens' when I use lampcolor and 1 (or 0.001) 
for the multiplier A1 of source.cal ? 

To obtain correct values (compared with measures made by a specialised firm) 
for the illuminance, I had to use 3.5 for the multiplier. Is it normal ? 

Thank you very much for your reply.

email: duvivier@motelec.fpms.ac.be

Date: Sun, 1 Jun 1997 21:44:23 -0400 (EDT)
From: Navid Sadikali <nhsadika@barrow.uwaterloo.ca>
To: "Gregory J. Ward" <greg>
Subject: Re:  Radiance question: Tilting the filmplane? (fwd)

Hi again.  Thanks for your response about tilting the filmplane,
by leveling the view, and then using view lift.  
Now, I am trying to understand exactly how the number given to
view lift corresponds to a movement that in the 3D coordinates...

For example, how much would I lift the view to exactly
simulate the effect of tilting the film plane by a certain 
theta degrees?
By choosing an arbitrary number such as 0.5 I can remove the
convergences, but unless I fiddle I can't get the image centered
in the same spot (ie. centered in the same spot that corresponds to
the center of the non-converged picture).

Maybe I should illustrate:

                         |  building   
           \-- distperp --|
         eye             |_____________

If the non-tilted picture is centered at X, how much do I lift
the film plane, to center the image on X in the tilted picture?
Note:If I lift the view by  (X.vert - eye.vert) I don't get the 
correct image, even though I have set the view direction horizontal.

Thanks every so much,

M.Math Student

>From greg  Wed Jun  4 09:47:36 1997
Date: Wed, 4 Jun 1997 09:47:35 -0700
From: greg (Gregory J. Ward)
To: Navid Sadikali <nhsadika@barrow.uwaterloo.ca>
Subject: Re:  Radiance question: Tilting the filmplane? (fwd)

Hi Navid,

Using your diagram:

                          |  building   
           \-- distperp --|
         eye              |_____________

You need to specify a lift value that is the fractional image height you
want to shift your view.  The image height is in turn determined by your
vertical view angle (-vv parameter).  For example, if the top of your
"unlifted" view just reached your desired view center (marked "X" in the
above illustration), then you would specify a view lift of 0.5, since you want
to move your image center half the frame height.

To put it mathematically, your frame height is twice the tangent of half your
vertical view angle in a relative coordinate system where your view vector
defines the base of a triangle with unit length.  All you have left to
do is figure out what the lift should be using similar triangles:

               (X.vert - eye.vert)/distperp
       lift =  ----------------------------
               2 * tan(vv_ang/2)

If you ever want to use the angle instead of distances, just replace
the numerator with the tangent of your vertical lift angle.  A similar
sort of formula applies for horizontal view shift, if you ever need that.

Hope this helps.

>From chas@pink  Fri Jun 13 13:21:36 1997
Date: Fri, 13 Jun 1997 13:18:37 -0700
From: chas@pink (Charles Ehrlich)
To: MRINALINI D SHARMA <msharma@ced.berkeley.edu>
Subject: Re:  Adeline
Cc: radiance@pink


Date: Fri, 13 Jun 1997 12:00:40 -0700 (PDT)
From: MRINALINI D SHARMA <msharma@ced.berkeley.edu>
To: ckehrlich@lbl.gov
Subject: Adeline

June 13, 1997

Dear Mr. Charles Ehrlich,
I am an assistant a the Environmental Simulation Laboratory, College of
Environmental Design, Berkeley.

I was wondering if ADELINE is capable of coducting a shadow quatification
study. In essence is it able to calculate shadow areas given a lighting

Your prompt reply would be appreciated.

Thankyou for your time.

Mrinalini Devi Sharma 


Dear Mr. Sharma,

Yes.  ADELINE/Radiance can perform a shadow quantification
of an arbitrary lighting and geometry situation.  The way
to perform this is not obvious, however.

First problem: getting the geometry together.  I recommend
using AutoCAD with the torad or radout export utilities.

Second: geting the lighting distribution data from mfgr.

Third: assembling the materials and lighting in the 
Radiance input text files (no graphical user interface for
this task).

Fourth: Define a "plan" view of the area to be quantified.
The view type for the rendering program is "-vtl".  See
the manual pages for rpict for more information.

Fifth: Calculate the image with sufficient resolution and
analyze the results with pvalue.  You would then have to
write a simple script that would count the number of pixels
in the image that have a value less than the ambient value
of your scene (this can be zero with -av 0 0 0).  Or, the 
image file could be converted to some other format (like tiff) 
and analyzed with any other convenient software which can query 
and count pixels.

So, ADELINE/Radiance can do it, but not exactly with ease.

Charles Ehrlich
Principal Research Associate
Lawrence Berkeley National Laboratory


>From urge@shore.net  Tue Jul  1 11:48:54 1997
Date: Tue, 01 Jul 1997 14:46:30 -0700
From: "R.J. Russell" <urge@shore.net>
Organization: Continental Design
To: gregl@asd.sgi.com
Subject: Radiance restriction general question

First, if this not the appropriate place to ask tech questions 
about Radiance, please direct my there.

If you don't mind answering a few general questions I have about
Radiance, I'd appreciate it.

On the web page, under "Restrictions of the Complexity of the
Problem" it says that: 

Although Radiance attempts to account for all significant sources of
illumination, there are a few cases that are not
adequately modeled in the present calculation. The most important of
these is the reflection of intense light from
curved specular surfaces, such as might be found within a heliostat or
parabolic light fixture. Computing light from
such a system requires a ray tracing method that follows light in the
forward direction, starting at the emitters and
working outward. Since Radiance works strictly in the reverse direction,
a separate preprocess is necessary to
compute these output distributions. This hypothetical preprocessor is
not included in the present package. 

I have a client that designs automotive taillamps, and they 
want to be able to see the lit appearance of their lamps
in a rendered image.  The majority of the light transmitting 
through the lens surface is reflected off the curved, basically
parabolic reflector surface behind the bulb (essentially the
same as a flashlight).  

Does the quoted restriction refer to a problem like this?

If so, can you point me to any resources on the web or elsewhere
that may have addressed this?  My client is VERY interested in
doing this, so if it has not been done already they may want me
to develop the mentioned "seperate preprocess". Could you briefly
explain the major issues involved with that, or outline the
basic steps that such a program would have to tackle?

Any info is very appreciated.

R.J. Russell
Continental Design


>From gregl@radiate.asd.sgi.com  Tue Jul  1 12:49:39 1997
From: gregl@radiate.asd.sgi.com (Greg Larson)
To: "R.J. Russell" <urge@shore.net>
Subject: Re:  Radiance restriction general question

Hi R.J.,

Future queries about Radiance should be addressed to "radiance@floyd.lbl.gov".

Indeed, the restriction mentioned does apply to your case.  I cannot offer
much advice on writing a forward ray-tracer, except to say that it is about
a 6 man-month effort for someone who is already an expert in the field.
It is not a task to be tackled lightly.

I can recommend a program that already performs such a function, called ASAP
by Breault Research Organization (http://www.breault.com/).  I suggest that
you check this out.

Radiance assumes that you have some way of measuring or otherwise
characterizing the output of all light sources in a scene.  If you
can measure the output distribution of your tail-lights, then you can
certainly simulate scenes containing them.  If your goal is to predict
the tail-light output, however, you need a program like ASAP.

Best of luck.
Gregory Ward Larson (the computer artist formerly known as Greg Ward)
Silicon Graphics, Inc.                   Computer Science Department
2011 N. Shoreline Blvd., M/S 07U-553     537 Soda Hall, UC Berkeley
Mountain View, CA  94043-1389            Berkeley, CA  94720-1776
(415) 933-4878, -2663 fax                (510) 642-3631, -5775 fax
gregl@sgi.com                            on Tues., Thurs. and Fri.


>From valois@cim.mcgill.ca  Mon Jun 23 08:29:58 1997
Date: Mon, 23 Jun 1997 11:25:43 -0400 (EDT)
From: Valois Jean-Sebastien <valois@cim.mcgill.ca>
To: Radiance Account <radiance>
Subject: Gray Scale Response

Hi Greg,

How are you?  Thanks for your last email.  Here is another (quick) 
question for you.

Is there a command/function that allows to stretch or crop the intensity 
ranges for an image ?  For example, I would like to model the response of 
a camera that can resolve a 10-step (32:1 contrast ratio) under a minimum 
scene illumination of 10 footcandles.  Also, I know that the gray scale 
capability can extend to a 12,000 footcandle scene illumination.

Sincerely yours,

|        Jean-Sebastien Valois B.Eng         | 
| * Email: valois@cim.mcgill.ca              | 
| * WWW  : http://www.cim.mcgill.ca/~valois  | 
| * Tel. : (281) 244-7271                    | 

< or stated another way >

>From valois@cim.mcgill.ca  Tue Jun 24 09:14:53 1997
Date: Tue, 24 Jun 1997 12:10:38 -0400 (EDT)
From: Valois Jean-Sebastien <valois@cim.mcgill.ca>
To: Radiance Account <radiance>
Subject: Dynamic Range

Hi Greg!
        Me again.  
1.  I guess what I was trying to ask yesterday was: "How do I 
change (or simulate) the dynamic range in Radiance ?"  Instead of a 
10^30:1 ratio, I would like to see the effect of a 100:1 ratio for a 
given Exposure.  I guess a special filter would do the job, but which 
one ?  

The way I see it, the dynamic range is related to the resolving power that is 
a function of the Exposure.  Is that right ?

2. Would it be possible to use the function:

  Radiance EXPOSURE = K*T*S/f^2.

   for a CCD camera when, instead of taking S as the film speed (ISO), I 
take the CCD efficiency ?

Thanks for your time.

|        Jean-Sebastien Valois B.Eng         | 
| * Email: valois@cim.mcgill.ca              | 
| * WWW  : http://www.cim.mcgill.ca/~valois  | 
| * Tel. : (281) 244-7271                    | 


>From radiance  Wed Jun 25 12:34:29 1997
Date: Wed, 25 Jun 1997 12:34:28 -0700
From: radiance (Radiance Account)
To: Valois Jean-Sebastien <valois@cim.mcgill.ca>
Subject: Re:  Gray Scale Response
Cc: radiance


The best (quick) answer I can give you is to explore the
use of the "pcomb" program.  It allows you to specify an
arbitrary function on the command line which provides the
functionality to perform pixel-by-pixel operations.   Be
sure to browse the rayinit.cal file for useful functions
to use.  There have also been examples of the use of the
pcomb program in the digests.

Charles Ehrlich
Principal Research Associate
Lawrence Berkeley National Laboratory


>From duvivier@motelec.fpms.ac.be  Thu Jun 12 03:53:14 1997
To: chas (Charles Ehrlich)
Cc: duvivier@motelec.fpms.ac.be
Subject: Re: RADIANCE 3.0 / luminaire  
Date: Thu, 12 Jun 97 12:51:41 +0200

Hi Chas,

I am Vincent

Thank you very much for your rapid reply. Your are great.

I don't know what is my problem with the luminaire.

The scene is an exterior nighttime view. The portion of road is 15m X 4m (origin at 0,0).
The 5 luminaires (GEMA from COMATELEC, ellipsoid, high-pressure sodium Philips SON-T 150W, 
16500 lumens) are placed every 15m (starting at x=-15 m to x=45m) at y=5.5m and z=5m.

1) Simple description of the luminaire
        xxxxxxx             *
      xxxxxxxxxxx  .523m       x = not emitting area
      lllllllllll              l = emitting area
        lllllll             *

      <   .7m   >

2) PROGRAM lampcolor :

       lamp type : HID
       length unit : meter
       lamp geometry : ring
       disk radius : .35
       total lamp lumens : 16500
       lamp color (RGB) = 134.387528 49.117057 1.253024

3) Assuming that the candlepower distribution file (cd/1000 lm) is correct (vertical angle 0-90 
degrees and horizontal angle 0-355 degrees,), the description of the scene is :

       ### Description of the road

       ### Material : Beton (not important for the illuminance)
       void plastic beton
       5 0.216 0.145 0.106 0.192 0

       ### Geometry
       beton polygon road
               0  0 0
               0  4 0
               15 4 0
               15 0 0

       ### Description of the luminaire

       void brightdata illum_sphere_pat
       5 corr gema.dat source.cal src_theta src_phi2
       1 0.0035 (not 0.001 if I want the correct values)

       illum_sphere_pat illum illum_sphere_mat
       3 134.387528 49.117057 1.253024

       illum_sphere_mat sphere illum_sphere_surf1
       4 -15 5.5 5 .35

       illum_sphere_mat sphere illum_sphere_surf2
       4 0 5.5 5 .35

       illum_sphere_mat sphere illum_sphere_surf3
       4 15 5.5 5 .35

       illum_sphere_mat sphere illum_sphere_surf4
       4 30 5.5 5 .35

       illum_sphere_mat sphere illum_sphere_surf5
       4 45 5.5 5 .35

4) gema150.rif file :
       ZONE= I -16 46 0 6 0 6
       scene= scene.rad
       view= v1 -vtl -vp 7.52404 2.41832 1.48918 -vd 0 0.0099995 -0.99995 \
             -vu 0 0 1 -vh 22.5 -vv 22.5 -vo 0 -va 0 -vs 0 -vl 0
       render= -i -dt 0 -lw 0 -lr 12 -ad 1024 -ab 2 -x 1024 -y 1024

5) rad gema150.rif
   ximage gema150_V1.pic

The values are obtained from interactive clicks (L) on the picture.

This was the process to evaluate the illuminance.
Could you tell me if it seems correct ? 
Thank you very much.

Rue Trieu des Dames, 24
5190 Jemeppe-sur-Sambre

email: duvivier@motelec.fpms.ac.be (until july of 1997)



I appologize for my late reply. I've been way over-worked lately.

I started to look at your scene and realized that I don't
have your data file.  If you e-mail it to me, I'll be able to
reproduce your results.

Meanwhile, you can try two changes to your scene while you
wait for my reply.

1. In scene.rad change:

void brightdata illum_sphere_pat
5 corr gema.dat source.cal src_theta src_phi2
1 0.0035


void brightdata illum_sphere_pat
5 flatcorr gema.dat source.cal src_theta src_phi2
1 0.001 

Flatcorr is the correct correction function for planar
surfaces such as rings.  Corr is used for spheres and
surfaces which can be simplified as infinitely distance 
like the "source" surface.

2. In the rif file change:

render= -i -dt 0 -lw 0 -lr 12 -ad 1024 -ab 2 -x 1024 -y 1024


render= -i 
RESOLUTION= 1024 1024
OPTFILE= scene.opt
OCTREE= scene.oct

The -x and -y params were taken out because this causes
problems when you try an interactive viewing with rview.
RESOLUTION takes care of that.  QUALITY=MEDIUM makes the
resolution render at twice the specified RESOLUTION value
to reduce the jaggies, and takes care of the other necessary

To do an interactive view:

rad -o x11 file.rif

Use the "t" command to trace a ray into the scene.  Press
return a few times and it will show the average value,
which will be illuminance because of the "-i" in the 
render= line.  Read the rview manual for more commands.

If you have no other surfaces in your scene except the
ground and the light, you don't need any ambient bounces,
so you could make -ab = 0.

I added the -I option so that you could use the scene.opt
options file with rtrace for a more rigorous analysis with
rtrace.  Same goes for the OCTREE= definition.

rtrace @scene.opt -dv- -h- -x 1 scene.oct < scene.pts \
       | rcalc -e '$1=47.4*$1+120*$2+11.6*$3' \
       > illum.val

scene.pts contains:

0 0 1 0 0 1
1 0 1 0 0 1
1 1 1 0 0 1
0 1 1 0 0 1

for a simple four-point analysis.  First three digits are
the "sensor" location x y z, and the next three are the "sensor"
orientation x y z.  Scene.val will contain four values corresponding 
in sequence to the four locations above.  Rcalc with its options
takes the average of the R G B calculated values.



>From paul@bourke.gen.nz  Wed Jul  2 16:02:15 1997
Date: Thu, 3 Jul 1997 09:00:52 +1000
To: greg (Gregory W. Larson)
From: Paul Bourke <paul@bourke.gen.nz>
Subject: Re:  ArchiCAD2rad

>We looked and looked, and could not find the archicad to Radiance translator.
>I guess it's time to ask Paul Bourke if he still has it, or knows where it is.
>His e-mail address is "pdb@mhri.edu.au" -- and please include me in your

It can be found at
I've sent the URL off to Henry.

How are things anyway? I never actually heard what you were doing at
SGI? As it turns out I'm using SGI gear all the time now, we have
Indigo-2 Max Impacts for workstations and a lovely 12 processor power
challenge as our CPU server. Even better when you consider there are
only 3 of us using it! I'm involved almost exclusively in scientific
visualisation and still find lots of uses for Radiance. I think I asked
earlier whether you'll be at Siggraph, if so, I might see you there.

Paul Bourke                                           pdb@mhri.edu.au
Brain Dynamics Research Unit                  http://www.mhri.edu.au/
Mental Health Research Institute                   Ph: 61 3 9389 2602
Locked Bag 11, Parkville                          Fax: 61 3 9387 5061
Victoria 3052, Australia


>From mlarch@ix.netcom.com  Wed Jul  2 06:59:16 1997
Date: Wed, 02 Jul 1997 09:53:09 -0400
From: Morgan Larch <mlarch@ix.netcom.com>
To: radiance-discuss
Subject: first colorfunc's and the disappear'd prmitives

This may well be yet another silly question, but ...

My first try at colorfunc's has resluted in the 
disappearance of my primitives. I built a .cal
file, s.cal, with the fallowing:

       red = Px*A1;
       green = Py*A2;
       blue = Pz*A3;

and a rad file, c.rad, with the fallowing:

       void plastic white
       5 1 1 1 0.01 0.01

       void colorfunc hat
       4 red green blue s.cal
       3 1 1 1

       void light bright_white
       3 20 20 20

       bright_white sphere l1
       4 0 0 20 4
       hat sphere s1
       4 0 0 0 2

       hat polygon floor
               -10 -10  0
               -10  10  0
                10  10  0
                10 -10  0

After oconv c.rad > c.oct, rivew ( with -vp 0 -20 10 
-vd .30 .95 -.34 -av .2 .2 .2) shows me nothing. If 
I replace hat with the plastic material white, I can 
see what I'd expect, a polygon intersecting a sphere. 

I read through the usman1.rtf and usman2.doc and looked
over several example files and thought I had connected
all the dots. But I guess not. What am I not getting ?



>From radiance  Sun Jul  6 23:48:40 1997
Date: Sun, 6 Jul 1997 23:48:39 -0700
From: radiance (Radiance Account)
To: Morgan Larch <mlarch@ix.netcom.com>
Subject: Re:  first colorfunc's and the disappear'd prmitives


You're almost there!  The only concept of the Radiance
input language that you overlooked was that a pattern
by itself is not sufficient to describe the surface
material properties of an object.  The pattern must
"modify" a material like plastic.  So the colorfunc
pattern must appear before the white plastic, and
the white plastic must be modified by the "identifyier"
of the colorfunc (hat).  In this way, the white plastic
"inherits" the properties of the previous modifier(s).

        void colorfunc hat
        4 red green blue s.cal
        3 1 1 1

        hat plastic white
        5 1 1 1 0.01 0.01

        void light bright_white
        3 20 20 20

        bright_white sphere l1
        4 0 0 20 4

        hat sphere s1
        4 0 0 0 2

        hat polygon floor
                -10 -10  0
                -10  10  0
                 10  10  0
                 10 -10  0

That should do it.

>From mlarch@ix.netcom.com  Mon Jul  7 10:45:30 1997
Date: Mon, 07 Jul 1997 13:40:29 -0400
From: Morgan Larch <mlarch@ix.netcom.com>
To: Radiance Account <radiance>
Subject: Eureka ! Re: first colorfunc's and the disappear'd prmitives, thanks

Thanks Chas, now that I stop and look at it, it makes
quite a lot of sense and a whole lot of difference!



>From haico.schepers@arup.com  Tue Jul  8 16:17:53 1997
Date: Tue, 08 Jul 1997 22:53:08 +0000
From: Haico Schepers <haico.schepers@arup.com>
To: chas
Subject: Glare Uuugh


I seem to be able to get some numeretical results now that rayinit is
located in the same directory as Glare.exe.  Just some additional
questions to those in the last email;
1/ I can't find xglaresrc to run the visualization program for Glare
2/ How important is the warning that I am missing 80% of samples to the
reliablity of the results
3/ I am working on Daylighting glare with large sources, has the program
been evaluated for this?

If there is anyone else that can help me on these questions please
forward their email accounts.

Thanks for your help

>From greg  Wed Jul  9 10:23:43 1997
Date: Wed, 9 Jul 1997 10:23:42 -0700
From: greg (Gregory W. Larson)
To: chas
Subject: Re:  Can you help with this one?
Cc: haico.schepers@arup.com


> 1/ I can't find xglaresrc to run the visualization program for Glare

Doesn't exist in ADELINE, since it's tied to X11.

> 2/ How important is the warning that I am missing 80% of samples to the
> reliablity of the results

Shouldn't be a big deal.  What it means is that there is information on
the border of your sample space that is unaccounted for.  If you're concerned
that the borders contain important glare information, then you should run
findglare with the rtrace option, though I'm not sure if this is supported
in ADELINE.  The other thing you could do is render a wider angle view to
give to findglare.

> 3/ I am working on Daylighting glare with large sources, has the program
> been evaluated for this?

There has been some work on this done by the folks at the LESO in Switzerland,
but I don't think it's been integrated back into ADELINE.  In general, the
glare indices provided are appropriate for small sources, though they have
been applied by people to other cases.  I'm just not sure how valid they are.

Gregory Ward Larson (the computer artist formerly known as Greg Ward)
Silicon Graphics, Inc.                   Computer Science Department
2011 N. Shoreline Blvd., M/S 07U-553     537 Soda Hall, UC Berkeley
Mountain View, CA  94043-1389            Berkeley, CA  94720-1776
(415) 933-4878, -2663 fax                (510) 642-3631, -5775 fax
gregl@sgi.com                            on Tues., Thurs. and Fri.

>From jbi@saturn.dmu.ac.uk  Thu Jul 10 01:35:33 1997
Date: Thu, 10 Jul 1997 09:35:37 +0100
From: jbi@dmu.ac.uk (Joven Ignacio)
To: rogerc@indigo.ie
Subject: Re: Radiance/Linux (Red Hat)

Dear Roger

If you still haven't sorted out the problem with Radiance installation on
the Linux (RedHat) version, the solution is as follows.

You have to specify where your include and library files are located
under the X11R6 directory (RedHat's latest version for X11).

When you install Radiance, you will have to change the settings on the 
makeall script, see below:

<... cut ...>

Current rmake command is:
exec make "SPECIAL=" \
       "OPT=-O2" \
       "MACH=-DBSD -DSPEED=40 -DDCL_ATOF -Dqsort=_quicksort -DBIGMEM" \
       ARCH=IBMPC "COMPAT=malloc.o erf.o getpagesize.o" \
       INSTDIR=/usr/home/bin \
       LIBDIR=/usr/home/lib \
       CC=gcc "$@" -f Rmakefile

... cut ...


To correct the error, use the following.

exec make "SPECIAL=" \
       "OPT=-O2" \
       "MACH=-DBSD I-DSPEED=40 -DDCL_ATOF -Dqsort=_quicksort -DBIGMEM  -L/usr/X11R6/lib -I/usr/X11R6/include" \
       ARCH=IBMPC "COMPAT=malloc.o erf.o getpagesize.o" \
       INSTDIR=/usr/home/bin \
       LIBDIR=/usr/home/lib \
       CC=gcc "$@" -f Rmakefile


It's because RedHat has both an X11 and an X11R6 directory and radiance just
gets confused with the two directories.

problem solved on my end.


Jose (Joven) Ignacio                                         
The Institute of Energy & Sustainable Dev't.
The Gateway - DeMontfort University, Leicester - LE1 9BH UK 
Email:    jbi@dmu.ac.uk
Phone:    +44 116 250-6124
FAX:      +44 116 257-7449
URL:      http://www.iesd.dmu.ac.uk/~jbi/


>From haldane@MIT.EDU  Thu Jul 17 12:29:59 1997
To: greg@floyd
Subject: some questions
Date: Thu, 17 Jul 1997 15:28:29 EDT

hi greg,

i had some questions concerning radiance. 

the first question is concerning smoothing in radiance.  i have a model of a
person that i've created in "poser" on the macintosh and i'm trying to render
it in radiance.  the program exports dxf and i translate that into a rad file
using radout.  is there anyway to smooth the surfaces of the model?

the second question is concerning the use of instances.  i had a file that had
100 instances and it created an oct tree that was about 57mb.  does that sound
right?  the oct file was simply a column with some cylindrical mapping.

here's a sample of the instances....

## row 1
## --------------------------------------------------------------------
void instance bcolumns
5 Oct/bcolumns.oct -t 10.9530 25.0780 0.0000

void instance bcolumns
5 Oct/bcolumns.oct -t 13.1249 25.0780 0.0000

void instance bcolumns
5 Oct/bcolumns.oct -t 15.2968 25.0780 0.0000

void instance bcolumns
5 Oct/bcolumns.oct -t 17.4687 25.0780 0.000

void instance bcolumns
5 Oct/bcolumns.oct -t 19.6406 25.0780 0.0000

void instance bcolumns
5 Oct/bcolumns.oct -t 21.8125 25.0780 0.0000

void instance bcolumns
5 Oct/bcolumns.oct -t 23.9844 25.0780 0.0000

void instance bcolumns
5 Oct/bcolumns.oct -t 26.1563 25.0780 0.0000

void instance bcolumns
5 Oct/bcolumns.oct -t 28.3282 25.0780 0.0000

void instance bcolumns
5 Oct/bcolumns.oct -t 30.5001 25.0780 0.0000

## row 2
## --------------------------------------------------------------------
void instance bcolumns
5 Oct/bcolumns.oct -t 10.9530 27.2499 0.0000

etc...  am i doing it correctly?  there's also one other very peculiar aspect
to this whole thing.  if i use 11 instances, the final octree gets generated
almost instantly.  if use 12 instances, the octree takes up to 5 minutes to
generate.  do you know what might be the cause for this? 

and that's it.  thanx for all your time and assistance.



>From greg  Thu Jul 17 13:23:37 1997
Date: Thu, 17 Jul 1997 13:23:37 -0700
To: haldane@MIT.EDU
Subject: Re:  some questions

Hi Haldane,

Unfortunately, there's no automatic smoothing method in Radiance.  If you
have surface points on a rectangular grid, you can give them to the gensurf
program and have it smooth them using the -s option, or if you have the
surface normals, you can pass them through tmesh2rad or mgf2rad to get
smoothed triangles out, but those are the only options.

Instances are a bit strange the way they work in oconv.  Since they are
volumes as opposed to surfaces, oconv cannot separate them very well,
and you can get "clumpings" that take it a long time to sort out.
Keep in mind that the extent of an octree is actually a cube, so your
columns do not fit well into an instance, as all their dimensions will
equal their longest one.  If you can find a way to group roughly cubical
geometry together for your instances, you combined octree will be much
smaller and will generate much more quickly.



>From radiance  Fri Jul 18 10:04:51 1997
Date: Fri, 18 Jul 1997 10:04:50 -0700
From: radiance (Radiance Account)
To: haldane@MIT.EDU
Subject: Re: some questions
Cc: radiance, greg

Hi Haldane,

I would like to add a few words regarding the use of instances
and octrees.  The "clumping" Greg mentions is the cause of your
problems with oconv...why it is taking so long, and also possibly the
reason why the octree is so large.  The reason lies with the
cubical form of the bounding boxes, as Greg mentions. 

Another way to get around this is to tell oconv to not bother
with trying to sort out the instances' bounding boxes from each
other.  This is done by specifying a larger set size on the
command line.  Since you have twelve "surfaces", i.e., instances
in your scene, you can use:

      oconv -n 12 columns.rad > columns.oct

I would recommend that you then create another instance out of
this gathering of columns before you include it into the main
scene octree.  If done in this way, there will only be a very small 
impact on rendering speed because only one voxel of the entire
scene has more than 5 (the optimum) sub-voxels.

Unfortunately, I have no suggestions for how to smooth the surfaces
of your columns in the DXF file, unless you have a means of creating 
instead a Wavefront ".obj" file with vertex normals included for 
smoothing.  Using obj2rad -s  will cause the resulting radiance file 
to have surfaces smoothed.  There's no way you're going get smoothing 
from DXF.



Subject: Star patterns in pfilt
Date: Wed, 16 Jul 97 10:51:17 -0500
From: <robert@audile.com>
To: <raydisc>

Does anyone have any advice in making the star pattern options (-n, -s, 
-h) work noticeably with pfilt in Radiance?  I have not been able to hit 
on any combinations that show visible effects.

Thanks for any help,



Date: Fri, 18 Jul 1997 10:54:37 -0500 (EST)
From: "robert a. shakespeare" <tcvc@indiana.edu>
To: robert@audile.com
cc: raydisc
Subject: Re: Star patterns in pfilt

Hi Robert,

       Try something like the following to achieve subtle star effects. 
Of course, it is dependent on luminance of objects within the scene.

%pfilt -2 -h 5 -n 6 -s .00001  input.pic  > output.pic

You must use the -2 option instructing pfilt to make two passes
over the picture data.

Change the -h value to control the luminance level at which
the star pattern will begin to be exhibited.

Set the number of points with the -n value.

The -s value sets the "spread" of the effect, ie, the value it has at the 
edges of the picture. The default is .0001

Hope this helps!

-Rob Shakespeare
 Theatre Computer Visualization Center
 Indiana University

Back to Top of Digest Volume 3, Number1
Return to RADIANCE Home Page
Return to RADIANCE Digests Overview

All trademarks and product names mentioned herein are the property of their registered owners.
All written material is the property of its respective contributor.
Neither the contributors nor their employers are responsible for consequences arising from any use or misuse of this information.
We make no guarantee that any of this information is correct.