Radiance Digest Volume 2, Number 8 (Part 1b)
RENDERING PARAMETERS, Continued
Date: Tue, 6 Dec 94 13:31:24 PST
From: greg (Gregory J. Ward)
To: westin@dsg145.nad.ford.com
Subject: Re: Radiance newbie question
Hi Steve,
The speckle effect you're seeing is due to the fact that rpict sends at most
one sample per pixel to the image plane. If you want smooth results, you
have to reduce the image using pfilt with the -x and -y options. I usually
use the "rad" interface to control rendering, and I highly recommend that
you do, too. It controls many of those nasty parameters based on some
more intuitive scene characteristics.
I agree wholeheartedly that the documentation is seriously lacking, which
is why I've started writing a book on Radiance. The many parameters are
confusing, even to me. To see the default settings, type:
rpict -defaults
This also offers a brief reminder of their meaning. I meant at one time to
write a document describing each in gory detail, but decided instead to
write the rad program to insulate users as much as possible. The ultimate
solution is a book explaining the calculation techniques in Radiance and
how the parameters relate to them. In the meantime, you're stuck with the
rpict man page and the notes in ray/doc/notes/rpict.options.
I'd be happy to help explain particular options you're having trouble with.
The -ps option takes an integer, which is why you got the cryptic error
message. I have updated the manual to make this more clear for the next
release.
I've also found it useful to have the Radiance Reference Manual online, and
it is accessible on the Web at "http://radsite.lbl.gov/radiance/HOME.html".
For quicker access, I recommend downloading the desired pages.
Metallic paint is kind of tricky. I haven't worked with this much, myself.
You might try modeling it as plastic, giving the diffuse component the
desired color. I don't think this will produce the sparkle that comes off
of metal flakes, though. What you've got (without anti-aliasing) actually
looks pretty good in that regard, even though it was achieved by improper
means. The ultimate solution may lie in the creative application of the
BRTDfunc type, which takes expressions as its arguments. Nasty, but very
flexible.
I'm flattered that you're working with this. I hope you don't get too
frustrated early on and give up... I'd miss the feedback.
-Greg
=======================================================================
SGI BUG
To: GJWard@lbl.gov
Subject: Radiance.....
Date: Wed, 02 Nov 94 11:37:27 +0000
From: David Hedley
Hello, I am research student in Computer Graphics at the University of
Bristol, England and I recently attended a workshop on Radiance given by
Kevin Lomas and John Mardeljevic at the De Montford University,
Leicester. I was very impressed by the results obtained and I am very
interested in working on (and with) the program. I am, however, having some
difficulty in getting the program to work correctly on my SGI Indigo. The
program renders some of the demo scenes correctly (townhouse, soda, bath),
but it core dumps when trying to render `conf', leaving no indication in
the core file where the error occured. This happens irrespective of the C
compiler used (I have used gcc 2.5.8 and the standard SGI ANSI C compiler),
and is not dependent on any optimisation flags.
My system is as follows:
SGI Indigo (R3000)
32MB Ram
IRIX 5.2
If you can help at all I would be very grateful....
keep up the good work!
David
Date: Wed, 2 Nov 94 09:02:23 PST
From: greg (Gregory J. Ward)
To: hedley@cs.bris.ac.uk
Subject: Re: Radiance.....
Hi David,
There is a bug in the IRIX 5.2 libfastm.a math library which sometimes
causes core dumps on the SGI's. You should recompile (or at least relink)
all of the programs, removing the "MLIB=-lfastm -lm" word from the rmake
script in your Radiance executable directory. Hopefully, this will solve
your problem. (A modified version of makeall is available along with
a few other patches from the /pub/patch directory on the anonymous ftp
account of hobbes.lbl.gov.)
-Greg
=======================================================================
RADIANCE VS. POV AND RENDERMAN
Date: Sat, 12 Nov 1994 13:05:29 -1000
To: greg@hobbes.lbl.gov
From: aersloat@uhunix.uhcc.Hawaii.Edu (Austin Sloat)
Subject: Radiance
Greg,
I was wonderig if you could give me an idea of the benefits/limitations of
Radiance as compared to POV and also Renderman. This is mostly for others.
Thanks,
Austin
Date: Sun, 13 Nov 94 09:58:32 PST
From: greg (Gregory J. Ward)
To: aersloat@uhunix.uhcc.Hawaii.Edu
Subject: Re: Radiance
Hi Austin,
Here is my biased analysis of Renderman and POV compared to Radiance. You'll
have to ask on network news to hear from some neutral party who has used these
for a real evaluation.
Renderman
=========
+ Support of many textures and geometric primitives.
+ General programming interface for shading calculations (local illumination).
+ Links to many commercial geometric modeling packages, particularly on Mac.
+ Can produce beautiful pictures and animations with motion blur.
- Lighting calculation is not physical, and approximations are unreliable.
- No numerical output of light levels, etc.
- Costs money and no source code.
POV
===
+ Easy to read input language.
+ Comes with many canned texture functions and surface primitives.
+ Wide user support base.
+ 3-d modeler available.
- Non-physical lighting calculations that are very difficult to circumvent.
- No numerical output.
- Materials, shading models and textures cannot be modified except in source.
- Slow compared to Radiance for identical rendering tasks.
Hope this helps.
-Greg
=======================================================================
MIRROR ABUSE
From: COURRET Gilles
To: greg@hobbes.lbl.gov
Subject: Radiance problem
Status: RO
Hi greg!
I have a problem with rtrace on a scene composed by a conventional
uniform sky and ground "cou_uni.rad"+"outside.rad" and a building
"indor_shed_mir.rad"+"shed.rad". It is one of my first calculation
with the material:
"void metal gray_paint
0
0
5 1 1 1 1 0"
(see indor_shed_mir.rad)
which is equivalent to:
"void mirror gray_paint
0
0
3 1 1 1"
isn't it? (may be, "metal" takes more time of calculatinon!)
anyway, the rtrace commande produce the following message:
"rtrace: fatal - possible modifier loop for polygon "mur_est"
All the files involved in this problem are available in the tar_file
i put on your server: "xfer/pb221194.tar"
The version i used is:
SOFTWARE= RADIANCE 2.4 official release April 20, 1994
This scene runned before without any trouble with all the same
calculation parameters except -lr that was 50 instead of 5000.
Thus, i suppose a problem (perhaps memory problem) arises because
the specular multireflection iteration goes to far. You can see
in the file "indor_shed_mir.rad" that the 4 walls made of mirror are
parallele two by two!
My purpose is to simulate a building with infinite width and length (or at least
to approche such an asymptotyque situation). That is why i need to let it go so far!
I thank you in advance for your help,
Gilles.
Date: Tue, 22 Nov 94 09:25:31 PST
From: greg (Gregory J. Ward)
To: courret@divsun.unige.ch
Subject: Re: Radiance problem
Hi Gilles,
Using metal is not the same as mirror, since the latter (mirror) reflects
light sources and metal does not.
The failure reported by the program is due to the absurd number of reflections,
which trips a loop detection test. If this test had not tripped, your run
would continue into the next millenium, probably still working on the first
scanline.
I recommend against modeling an infinite room in this way. Always remember
the basic tenet of Radiance, which is "if you can build it and measure it
in the real world, you can model it and simulate it in Radiance." The
converse is also true, i.e. "if you cannot build it and measure it in
the real world, you cannot model it and simulate it in Radiance." In other
words, you should model your "infinite" space as simply a very large space,
not a space with perfect mirrors for walls.
-Greg
=======================================================================
RETROREFLECTIVE SURFACES
From: "Nick C. Bellinger"
Subject: Retro-reflective surfaces in Radiance
To: GJWard@lbl.gov
Date: Mon, 5 Dec 1994 16:31:12 -0500 (EST)
Greg,
It has been suggested by a number of people, that I use Radiance to obtain
simulated images on an optical nondestructive inspection technique which
was developed in Canada. The technique involves the light from a
light source reflecting off an object and this reflective light hitting
a retro-reflective surface. The surface of the object being examined
is treated with a liquid to improve its reflectivity. The light hitting
the retro-reflective surface is reflected back onto the surface which then
reflects light to a camera which is nearly coincident with the light
source. The surface of the object (aluminum) contains small defects,
such as dents.
We are carrying out finite element analysis on lap splices which contain
corrosion products. We are trying to simulate the out-of-plane displacements
which are caused by the corrosion. These FEM results are then transformed
into triangular surfaces and imported into Radiance using tmesh2raw. I did
not include the surface normal vector in this file since I am not quite such
how one gets these values from raw data. This gives the surface of the
object we want to examine. A scene then must be created which includes
a light source (a halogen source is used in the actual technique), a
retro-reflective surface and a camera.
I would like to get your opinion on whether Radiance can model this
situation, particularly the retro-reflective surface. If you
think it can, can use suggest how to go about modeling the surface.
Thanks
Nick Bellinger
National Research Council Canada
e-mail: ncb@m14challenge.iar.nrc.ca
Date: Mon, 5 Dec 94 14:15:46 PST
From: greg (Gregory J. Ward)
To: ncb@m14challenge.iar.nrc.ca
Subject: Re: Retro-reflective surfaces in Radiance
Hi Nick,
I believe that Radiance should be able to model your scene. Others have
used a simple trick to create retroreflective surfaces, which is to use
a reflective metal surface and adjust the surface normal to always point
in the direction opposite the incoming ray. It's a bit of a cheat, but
it does work.
Another alternative available to you in this case is to create the physical
geometry of a retroreflective mirror, which generally consists of many
cube corners.
For the first approach, try:
void texfunc retro-normal
4 -Dx-Nx -Dy-Ny -Dz-Nz .
0
0
retro-normal metal retro-mirror
0
0
5 .95 .95 .95 1 0
retro-mirror polygon retro-reflector
...etc.
Above I am assuming that the retro-mirror has 95% reflectance. I your
situation, you're probably not so concerned about total light flux, so
the actual reflectance value may not be so important.
I hope this helps, and let me know if you have any other questions.
-Greg
=======================================================================
COLOR AND REFLECTANCE
From: sick@ise.fhg.de
Subject:
To: greg@hobbes.lbl.gov (gregory ward)
Date: Tue, 20 Dec 1994 14:15:51 +0100 (MEZ)
Hi Greg,
we interrupted a several day long discussion among several colleagues on
spectral calculation with RADIANCE. I think with one key question answered
by you we can resume discussion after x-mas. Here is it:
What integral radiance value has a RADIANCE light source with
100 50 10 RGB radiance values?
We find only white sources and a confusing statement that for a particular
channel the total watts/sr/m2/spectrum are given, which would indicate
that no colored light sources are possible. However, we would like to
do spectral calculations (even if they are limited to 3 channels) and
even - in general - independent of the color representation on the monitor
(we consider that a separat issue).
Thanks a lot for your advice and we wish you a merry christmas and a healthy
and happy and successful new year!
Best regards,
Fred Sick
--
----------------------------------------------------------------------------
Friedrich Sick MAIL : Fraunhofer Institute for Solar Energy Systems
Oltmannsstr. 5
D-79100 Freiburg
Germany
PHONE: +49-(0)761-4588-133 FAX: +49-(0)761-4588-132
email: sick@ise.fhg.de
----------------------------------------------------------------------------
Date: Wed, 21 Dec 94 11:32:32 PST
From: greg (Gregory J. Ward)
To: sick@ise.fhg.de
Hi Fred,
Color is indeed a confusing subject in Radiance. The RGB system used by
default is non-standard, simply because the only existing standards for RGB
color do not match typical computer monitor phosphors at all. I have
recently modified the color conversion routines in Radiance to allow the
user to redefine the (x,y) chromaticity coordinates corresponding to the
canonical phosphors used, and in this way set the color system.
It is impossible to know what the total radiant energy of a light source
is based on RGB settings, since they say nothing of invisible radiation.
As you know, for most light sources (incandescents especially), much of
the radiated energy is in the infrared and therefore not considered in
the setting of Radiance RGB values.
However, most of the code in Radiance does not hinge on the actual meaning
of the RGB channels -- they can be used to represent whatever wavebands you
decide. You don't even have to modify the code, just go ahead and use
different values. The results will have to recombined or something, for
they won't be displaying true colors on a computer monitor otherwise, but
that's the only real difference. I believe I addressed this problem a number
of times in past digests, which you can peruse at our WWW site:
http://radsite.lbl.gov/radiance/HOME.html
To better answer your question, though, let's assume you have a light source
whose Radiance RGB values are set to "100 50 10". The output of this source
in lumens would then be:
179 lumens/watt * (.265*100 + .670*50 + .065*10)
or 10856 lumens. These coefficients were taken from ray/src/common/color.h,
where all such things are stored.
As I said before, it is not possible to determine the radiant energy from
the source, since we know only about its output in the visible spectrum.
I hope this was more help than confusion. I'm sick, and not thinking too
clearly.
-Greg
From: Peter Apian-Bennewitz
Subject: spec,roughness and rho
To: gjward@lbl.gov (Greg Ward)
Date: Wed, 8 Feb 1995 13:03:08 +0000 (GMT)
Dear Greg,
please pardon if this is FAQ, I haven't paid much attention to the
digest lateley.
Do you have material on the subject of specifying isotropic plastic and
metal parameters (one color channel,spec,roughness) from direct-diffuse
and direct-direct measurements ? Direct-direct could be at normal and
45 degrees incident angle, outgoing at the geometrical reflectance
angle.
The idea is to get these basic Radiance Parameters from some easily
measured quantity. Three radiance parameters - three measurement
values. should work - ? As compared to fitting the curves to full
fledged BRTF measurements - ?
My this-integral-is-easy feeling is not well developed - How follows
direct-diffuse reflection from the isotropic model ? It's easier to ask
before feeding it to mathematica, in case you have it shelved.
Are there more tutorial guidelines available or people rely on your
expertise explaining to them in person ? :-) Don't want to offence you-
Just got a bit sidetracked from writing my thesis together and got
stuck with the reflection model. The key point being to align the
radiance parameters and photometric terms. Obviously they are close.
Just wondering wether I'm rediscovering the wheel here... What do
other people when giving a paint or material to simulate the room with?
As always, thanks for time, help and info
Peter
--
Peter Apian-Bennewitz, apian@ise.fhg.de
Date: Wed, 8 Feb 95 10:00:50 PST
From: greg (Gregory J. Ward)
To: apian@ise.fhg.de
Subject: Re: spec,roughness and rho
I assume you have my 1992 Siggraph paper on reflection already? If not,
I should certainly send you that one. You also didn't ask for my 1994
paper, so I assume you have it or don't know about it. Which is it?
(I can't remember what I've sent to you before.)
Unfortunately, taking a few luminance measurements from a surface under
known lighting conditions is not enough to characterize the reflectance
even in terms of a simple isotropic Gaussian model. I have tried myself
to develop such techniques, only to find that it couldn't be done reliably.
The problem is two-fold. One, spot luminance values from a surface with
a highlight are extremely unstable -- the slightest shift in position causes
a radical change in the value. Two, except for very rough surfaces, it is
impossible to measure the highlight with a normal luminance meter -- the
spot is simply too small.
Direct/diffuse measurements work only if the surface has a perfect diffuse
component and a perfectly smooth specular component. If the specular
highlight is spread out, then one must characterize this spreading, which
is nigh impossible with standard photometric equipment. The best way to
do it aside from measuring the complete BRDF is to do it by eye, believe
it or not. I am currently pursuing this approach with a portable device
and some standard samples. The idea is to match the material in question
to a sample to discover its actual roughness. The concept seems good, but
remains to be proven.
I'm sorry if this didn't answer your question. It's a tough one, all right.
-Greg
From: gerold@ise.fhg.de
Subject: metal and plastic
To: greg@hobbes.lbl.gov
Date: Thu, 23 Mar 1995 11:04:16 +0100 (MEZ)
Dear Greg,
during my work to calculate BRDF data with RADIANCE I had a problem
with "Plastic" and "Metal". That means "Metal" is just fine because
it behaves as I would think but "Plastic" does not. But let me tell
you what I've done:
1. I created a horizontal surface with the following material description:
void plastic spieg
0
0
5 1 1 1 0 0
2. The sun altitude is 45 deg, the azimuth 0 deg.
The view point is along the direct reflected ray from the surface.
The view direction is along this direct reflection.
3. I calculated the radiance with "rtrace", the ambient bounces are set to 1
Result: L = 91 W/m2sr what is totally fine
4. I changed the specularity to 1 (even if this doesn't make sense) and
got a radiance of 6.77e6 W/m2sr what is also absolutely fine.
Changing the specularity again to 0.5 gives me 3.39W/m2sr, that
means exactly half of the forgoing result --> great
5. Then I changed the RGB values to 0.5 without getting any different
results to RGB = 1. The only exception is if the specularity is 0.
6. If I change the material to "Metal" everything is like I would
expect it. The radiance I get depends on the specularity as well
as on the RGB values.
Well, in "The RADIANCE 2.4 Synthetic Imaging System" and in the "Behavior
of Materials in RADIANCE" you mention that plastic is a material with
uncolored highlights, that means independent of the RGB values (except
for the specularity of 0).
So, now there comes my question:
What kinds of materials should be modelled with plastic? The ones
with a specularity less than 0.1? If so the same problem occurs,
there is no dependency on RGB and I have a hard time convincing
my tummy to accept this. For my sense the behaviour of metal is
the more real one so I would prefer it to plastic even if the
specularity is <0.1.
Am I totally wrong with my knowledge of plastic materials or is
the secret in the roughness which was 0 in my cases?
I am sorry to bother you with this and thanks a lot for your answer.
Gerold
--
Gerold Furler MAIL: Fraunhofer Institute for Solar Energy Systems
Oltmannsstr. 5, 79100 Freiburg, Germany
PHONE: +49 (761) 4588 308 FAX: +49 (761) 4588 100
EMAIL: gerold@ise.fhg.de
Date: Thu, 23 Mar 95 09:31:22 PST
From: greg (Gregory J. Ward)
To: gerold@ise.fhg.de
Subject: Re: metal and plastic
Hi Gerold,
The nature of plastic is one where specularly reflected light is not affected
by the color of the material. Specifically, light reflected as part of
the specular component is always white. This is a good model for surfaces
such as plastic, marble, varnished wood, and most painted surfaces. The
physical principle behind this model is that specular reflections happen
at the outer surface, before the light encounters any dye particles. Metal
is different, because the surface itself is a sort of dye.
It is an approximation, but a very good one for most materials.
-Greg
Date: Mon, 27 FEB 95 16:23:36 BST
From: HKM5JACOBSA@CLUSTER.NORTH-LONDON.AC.UK
To: greg
Subject: CIE colour system
Hi, Greg
I am currently using RADIANCE to simulate sportshalls that are to be built in
the near future. The sportscouncil don't know what kind of luminaires are best
suited to match the requirements, which are relatively high especially when the
halls are used for badminton. So I try to help them to make this decision by
rendering computer images using different types of fittings.
My problem now is that I have the colourdata for the walls, floor and roof
paint given in CIE notation.
For example: Silver Grey is defined as
x = 20
y = 10
on page R90B (red plus 90 % blue)
light reflectance factor = 50.22 %
But in RADIANCE I have to specify the materials by means of red, green, and
blue. How can I convert the data into the proper format?
I would be glad if you could help me solving this problem. I could find nothing
on that in the digest.
I am loocking forward to hesring form you.
Thanks a lot!
Axel
Date: Mon, 27 Feb 95 09:08:40 PST
From: greg (Gregory J. Ward)
To: HKM5JACOBSA@CLUSTER.NORTH-LONDON.AC.UK
Subject: Re: CIE colour system
Hi Axel,
It just so happens that I recently finished a conversion routine in .cal
format for RGB <=> XYZ translation. I am enclosing it below. Cut out
this data and put it a file. (I called mine "xyz_rgb.cal".) Then, use
calc or rcalc for your conversions, like so:
% rcalc -f xyz_rgb.cal \
-e '$1=R(Xi,Yi,Zi);$2=G(Xi,Yi,Zi);$3=B(Xi,Yi,Zi)' \
-e 'Yi=$1;Xi=$2/$3*$1;Zi=$1*(1/$3-1)-Xi'
Then, on the standard input, give the Yxy triples (separated by spaces or
tabs). Rcalc will produce the corresponding RGB triples on the output.
(That last rather nasty-looking expression simple converts Yxy to XYZ.)
Let me know if you have any troubles with this.
-Greg
----------------------------------------------------------------------
{
Convert between XYZ and RGB coordinates.
2/17/95
Be sure that CIE_x_r, etc. definitions are consistent with
those in ray/src/common/color.h.
}
{*** The whole calculation is based on the CIE (x,y) chromaticities below ***}
CIE_x_r : 0.640 ; { nominal CRT primaries }
CIE_y_r : 0.330 ;
CIE_x_g : 0.290 ;
CIE_y_g : 0.600 ;
CIE_x_b : 0.150 ;
CIE_y_b : 0.060 ;
CIE_x_w : 1/3 ; { use true white }
CIE_y_w : 1/3 ;
WHTEFFICACY : 179. ; { luminous efficacy of uniform white light }
{ Derived constants }
CIE_D : CIE_x_r*(CIE_y_g - CIE_y_b) +
CIE_x_g*(CIE_y_b - CIE_y_r) +
CIE_x_b*(CIE_y_r - CIE_y_g) ;
CIE_C_rD : (1./CIE_y_w) * ( CIE_x_w*(CIE_y_g - CIE_y_b) -
CIE_y_w*(CIE_x_g - CIE_x_b) +
CIE_x_g*CIE_y_b - CIE_x_b*CIE_y_g ) ;
CIE_C_gD : (1./CIE_y_w) * ( CIE_x_w*(CIE_y_b - CIE_y_r) -
CIE_y_w*(CIE_x_b - CIE_x_r) -
CIE_x_r*CIE_y_b + CIE_x_b*CIE_y_r ) ;
CIE_C_bD : (1./CIE_y_w) * ( CIE_x_w*(CIE_y_r - CIE_y_g) -
CIE_y_w*(CIE_x_r - CIE_x_g) +
CIE_x_r*CIE_y_g - CIE_x_g*CIE_y_r ) ;
{ Convert CIE XYZ coordinates to RGB }
XYZ2RGB(i,j) : select(i*3+j+1,
(CIE_y_g - CIE_y_b - CIE_x_b*CIE_y_g + CIE_y_b*CIE_x_g)/CIE_C_rD,
(CIE_x_b - CIE_x_g - CIE_x_b*CIE_y_g + CIE_x_g*CIE_y_b)/CIE_C_rD,
(CIE_x_g*CIE_y_b - CIE_x_b*CIE_y_g)/CIE_C_rD,
(CIE_y_b - CIE_y_r - CIE_y_b*CIE_x_r + CIE_y_r*CIE_x_b)/CIE_C_gD,
(CIE_x_r - CIE_x_b - CIE_x_r*CIE_y_b + CIE_x_b*CIE_y_r)/CIE_C_gD,
(CIE_x_b*CIE_y_r - CIE_x_r*CIE_y_b)/CIE_C_gD,
(CIE_y_r - CIE_y_g - CIE_y_r*CIE_x_g + CIE_y_g*CIE_x_r)/CIE_C_bD,
(CIE_x_g - CIE_x_r - CIE_x_g*CIE_y_r + CIE_x_r*CIE_y_g)/CIE_C_bD,
(CIE_x_r*CIE_y_g - CIE_x_g*CIE_y_r)/CIE_C_bD
);
noneg(x) : if(x, x, 0);
R(X,Y,Z) : noneg(XYZ2RGB(0,0)*X + XYZ2RGB(0,1)*Y + XYZ2RGB(0,2)*Z);
G(X,Y,Z) : noneg(XYZ2RGB(1,0)*X + XYZ2RGB(1,1)*Y + XYZ2RGB(1,2)*Z);
B(X,Y,Z) : noneg(XYZ2RGB(2,0)*X + XYZ2RGB(2,1)*Y + XYZ2RGB(2,2)*Z);
{ Convert RGB to CIE XYZ coordinates }
RGB2XYZ(i,j) : select(i*3+j+1,
CIE_x_r*CIE_C_rD/CIE_D,CIE_x_g*CIE_C_gD/CIE_D,CIE_x_b*CIE_C_bD/CIE_D,
CIE_y_r*CIE_C_rD/CIE_D,CIE_y_g*CIE_C_gD/CIE_D,CIE_y_b*CIE_C_bD/CIE_D,
(1.-CIE_x_r-CIE_y_r)*CIE_C_rD/CIE_D,
(1.-CIE_x_g-CIE_y_g)*CIE_C_gD/CIE_D,
(1.-CIE_x_b-CIE_y_b)*CIE_C_bD/CIE_D
);
X(R,G,B) : RGB2XYZ(0,0)*R + RGB2XYZ(0,1)*G + RGB2XYZ(0,2)*B;
Y(R,G,B) : RGB2XYZ(1,0)*R + RGB2XYZ(1,1)*G + RGB2XYZ(1,2)*B;
Z(R,G,B) : RGB2XYZ(2,0)*R + RGB2XYZ(2,1)*G + RGB2XYZ(2,2)*B;
{ Convert spectral radiance in watts/sr/m^2 to luminance in cd/m^2 }
luminance(r,g,b) = WHTEFFICACY * Y(r,g,b) ;
Date: Thu, 2 Mar 95 17:05 BST
From: HKM5JACOBSA@CLUSTER.NORTH-LONDON.AC.UK
To: GREG
Subject: Re: CIE colour system
Hi, Greg!
The new command line is working now. Thank's a lot. It is a very useful tool
for my work. Just to make it sure: x and y have to be within the borders of
zero and one, and so should Y, is that right? I have the reflectance given in
per cent (0...100%). So all I need to do is divide this value by 100, is that
correct? The values I got using the formula like this seem to bethe right ones
to me.
Another question I have is a little bit more general. Do you happen to have
information on all the different colour systems (scandinavian, rgb, cmyk, etc.)
and ways of converting them into each other? I couldn't find anything in our
library. Can you name any sources of information such as publications, book,
mags? Where did you get the algorithm you used in the xyz_rgb.cal from??
Thank you for all the help.
Bye, bye!
Axel
Date: Thu, 2 Mar 95 15:27:53 PST
From: greg (Gregory J. Ward)
To: HKM5JACOBSA@CLUSTER.NORTH-LONDON.AC.UK
Subject: Re: CIE colour system
Hi Axel,
Yes, all values input to rcalc in this script should be between 0 and 1.
You will find that highly saturated colors will not convert well, since
it is easy to go out of the smallish, triangular gamut defined by the three
phosphor chromaticities defined in xyz_rgb.cal.
The algorithm in xyz_rgb.cal was taken from the book "Procedural Elements
for Computer Graphics" by David Rodgers (McGraw Hill). The actual phosphor
values used were taken from some other place, and I believe them to be
more or less typical of modern computer workstations.
As far as I know, the only standards defined for RGB conversion are in the
TV broadcasting industry, and they are not representative of computer monitors.
It is best to stick with CIE color systems wherever possible, and actually
measure phosphors on the destination device if you want accurate color
representation.
-Greg
From: Peter Apian-Bennewitz
Subject: brtf files and glow light sources
To: gjward@lbl.gov (Greg Ward)
Date: Sat, 1 Apr 1995 15:27:33 +0000 (GMT)
Dear Greg,
hope you have a nice weekend, and that tube time is not all
weekend long. -
I finally sat down and tried to solidify my views on how brtf functions and
glow work together:
1. It's RTFM, that the brtf functions govern rho-si, not rho-a, so
the ambient calculations don't care about the brtf. This is consistent
with my tests. However rho-a is not zero where I would guess it should be:
void transfunc tf
2 at at.cal
0
6 0 0 1 0 1 1
at.cal: at(lx,ly,lz)=0
When lit with source glow from the backside, a polygon with tf material
is still shining. Why ?
2. When applying mkillum to the above scene, the brtf doesn't seem to be
applied either. Using "#@mkillum l+ d=200 s=100 i=tf m=mk_func c=a b=0".
Am I right at visualizing mkillum shooting rtrace rays into the backside
space - and shouldn't these rays find the glow source? Since I'm not
quite sure wether I missed something here, I take the easy way and ask...
help, as always, is much appreciated,
cheers Peter
--
Peter Apian-Bennewitz, apian@ise.fhg.de
Date: Mon, 3 Apr 95 11:24:05 PDT
From: greg (Gregory J. Ward)
To: apian@ise.fhg.de
Subject: Re: brtf files and glow light sources
Hi Peter,
This is confusing and you will be disappointed to hear that the problem is
a lame BRTF calculation that doesn't know how to sample according to an
arbitrary distribution function.
I was surprised to hear that you were getting some ambient from your purely
specular transfunc material, but once I looked at the code in m_brdf.c,
I remembered that I multiplied the ambient value from the reverse side by
the full transmission quantity rather than just the diffuse quantity, and
the reason was that this light was not accounted for properly in the "specular"
component. You see, I don't know how to efficiently sample an arbitrary
BRTDF, so although Radiance includes the specification for it, it only computes
this component as part of the direct calculation. Only the standard Guassian
reflectance function (plastic, metal, trans, plastic2, metal2 and trans2)
is really a complete calculation, since I have a formula for Monte Carlo
sampling of those distributions.
Others who have sampled arbitrary functions have used a uniform sampling over
the hemisphere and weighted the samples by the BRDF, which is terribly
inefficient. Computing which samples to take is a very hard problem, and
requires large amounts of processing time for each sample or else huge
lookup tables saying where to sample. I hope to be working on this problem
in the next year or two, but with the book and my other projects, it isn't
going to be a top priority.
-Greg
From: apian@ise.fhg.de
Subject: Re: brtf files and glow light sources
To: greg@hobbes.lbl.gov (Gregory J. Ward)
Date: Mon, 3 Apr 1995 22:30:16 +0100 (MESZ)
Hi Greg,
thanks for help -
> This is confusing and you will be disappointed to hear that the problem is
thought so - :-)
How is rtraced used by mkillum ? I guessed that mkillum samples the entry side
by shooting rays with rtrace in random directions and multiplies them with the
BRTF and cosine-whatnot. This would imply that it doesn't matter wether its
a light or glow source. Which in fact does matter and stirs the questions what
the hell happens with rtrace in mkillum ?
> Others who have sampled arbitrary functions have used a uniform sampling over
others with Radiance or other light programs ?
What do people when they want to calculate daylight factors with BRTF
materials ? Setting the sky full of small light sources to average would be
one way, is it the only one ?
Many thanks
Peter
From greg Mon Apr 3 13:46:05 1995
Return-Path:
Date: Mon, 3 Apr 95 13:45:44 PDT
From: greg (Gregory J. Ward)
To: apian@ise.fhg.de
Subject: Re: brtf files and glow light sources
Mkillum does use rtrace to sample the illum surfaces, but does not know about
BRTF's or any of that. Rtrace does everything, returning the radiance
leaving the illum surface (or virtual surface) by the same calculations
as rpict uses.
Light vs. glow makes the same difference therefore to mkillum as it does
to rpict. Mkillum does NOT compute distributions directly from light
sources, since that would constitute overcounting if you then applied
this as an illum in rpict. It uses the -dv- option to rpict to make
light sources appear as blackened areas.
I don't know how others calculate illumination through BTDF windows and
such. My comment about weighting uniform samples according to the scattering
function was related to papers other researchers have published, not even
working programs.
-Greg
Date: Wed, 05 Apr 1995 09:18:08 -0700 (MST)
From: "vivek@asu.edu"
Subject: Modelling glass in Radiance
To: Greg Ward
Hi Greg,
I have a question regarding the way glass is modelled in Radiance.
I am trying to model an Azurlite glass with a Transmittance (visible),
as per the manufacturer catalogue = 0.63.
Should all three values (RGB) be set equal to 0.63 ?
OR - should the value of the B component be set at a higher percentage to
account for the blueish tint of the actuall glass color.
Also, is it a good enough approximation to assume that the ultra voilet
trasmittance of the glass is close to the Blue component and Infra red
transmission close to the Red component of the glass transmittance (since
these are the values usually provided in the maufacturer's product
catalogue) ?
Any sugestions / comments would be greatly appreciated .
Thanks
-Vivek
Date: Wed, 5 Apr 95 10:46:04 PDT
From: greg (Gregory J. Ward)
To: MITTAL@ASU.EDU
Subject: Re: Modelling glass in Radiance
Hi Vivek,
The standard glass material in Radiance takes the transmission at normal
incidence, not the transmittance. The difference is that transmission
doesn't account for external or internal reflections at the interfaces,
thus its range of possible values is exactly 0-1, not 0-something depending
on the index of refraction. I endeavored to make all the ranges of parameters
in Radiance such that the physically valid range was evident. This led to
some rather bizzarre specifications, to wit the "trans" parameter settings.
Borrowing from the reference manual, you can compute the transmission from
the transmittance for standard glass (n = 1.52) with the formula:
tn = (sqrt(.8402528435+.0072522239*Tn*Tn)-.9166530661)/.0036261119/Tn
For your transmittance (Tn) value of 0.63, that comes to a transmission (tn)
of .687. If you have different transmittance values for each of red, green
and blue, you should run this computation once for each component.
All of our window experts are out of town this week, and I'm not personally
familiar with the Azurlite glazing you speak of, nor do I have any advice
regarding how to specify red and blue components from IR and UV values.
This seems like a reasonable thing to do, but glass transparency often
changes dramatically outside the visible range.
Also, I'm not sure if Azurlite is a coated glazing, i.e. has different
reflectance properties from one side as opposed to the other. If so, then
you might be better off using the BRTDfunc type and the specification in
the "glazing.cal" file in the standard Radiance library to model its
properties.
Good luck!
-Greg
Date: Fri, 14 Apr 95 12:52:41 -0600
From: Tarn Burton
To: GJWard@lbl.gov
Subject: BRTDfunc
I do I use BRTDfunc to emulate metal or plastic. I want to switch between the
two based on object color.
Tarn
Date: Fri, 14 Apr 95 18:20:31 PDT
From: greg (Gregory J. Ward)
To: user1417@vis.colostate.edu
Subject: Re: BRTDfunc
Hi Tarn,
You cannot exactly emulate the built in Radiance metal or plastic types
with BRTDfunc, unless the roughness parameter is always zero. This is
because the BRTDfunc type does not sample the rough specular component
the way metal and plastic do. What is your reason for wanting to do this --
could you explain better the effect or process you wish to simulate?
-Greg
From: user1417@VIS.ColoState.EDU (CVL User Tarn Burton)
Subject: Re: BRTDfunc
To: greg@hobbes.lbl.gov (Gregory J. Ward)
Date: Fri, 14 Apr 1995 21:28:38 -0600 (MDT)
I want to simulate an object with an inlaid metal pattern. If the point of intersection is gold colored than use the metal material, otherwise use plastic. Mixfunc occured to me, or mixdata, but they cannot access an existing color. Any suggesting woul
d be great.
Tarn
Date: Sat, 15 Apr 95 08:22:40 PDT
From: greg (Gregory J. Ward)
To: user1417@VIS.ColoState.EDU
Subject: Re: BRTDfunc
You should be able to feed your pattern to mixdata or mixfunc as well as
the materials it refers to. Can you be more specific still -- tell me
what input you are using for the inlays.
-G
From: user1417@VIS.ColoState.EDU (CVL User Tarn Burton)
Subject: Mixed materials
To: greg@hobbes.lbl.gov (Gregory J. Ward)
Date: Sat, 15 Apr 1995 12:56:14 -0600 (MDT)
I'm using colorpict to map an image onto a cylinder. I would like to
avoid creating another image to use as a mask since the one that I am
using is sort of hefty. (20 megs) My initial idea was to use mixfunc
to look at color (CrP,CgP,CbP) and decide wh ich material to used based
on which color the point of intersection was. Since I want to make all
the bronze colored parts use the bronze material.
But mixfunc cannot be based on a material if the modifiers that it is
mixing are materials. I would use mixdata but I don't know how to
convert and image to the data file format. That is why I though of
using BRTDfunc, since it could access the CxP vari ables. I'm not
using any roughness values right now and would be willing to give up
this feature if BRTD is the only way to go.
Sorry about not explaining very well.
Tarn
Date: Mon, 17 Apr 95 13:23:35 PDT
From: greg (Gregory J. Ward)
To: user1417@VIS.ColoState.EDU
Subject: Re: Mixed materials
Hi Tarn,
OK, at last I feel like I understand your predicament. The only real
difference between metal and plastic in Radiance is the specular color,
which you can influence with the BRTDfunc type. However, another usual
difference between metal and plastic is that metal has a higher specular
component relative to diffuse, and the BRTDfunc type does not let you
alter the diffuse coefficient, although you can change the specular one.
To approximate the difference using the BRTDfunc type, your file will
look something like this:
void colorpict mypicture
7 noop noop noop mypicture.pic mypicture.cal u v
0
0
mypicture BRTDfunc mypictmat
10 myred mygreen myblue
0 0 0
0 0 0
mypicture.cal
0
9 .5 .5 .5
.5 .5 .5
0 0 0
Here, I have chosen the value of (.5) for the average diffuse reflectance, but
you can choose whatever you like. (The value will get modified by the
colorpict pattern.) In the file "mypicture.cal" will be
the definitions for u, v, myred, mygreen and myblue. U and v are the
coordinate mappings for the image, which I presume you have worked out
already. Myred, mygreen and myblue will look something like this:
myred = if(ismetal, .4*CrP, .05);
mygreen = if(ismetal, .4*CgP, .05);
myblue = if(ismetal, .4*CbP, .05);
ismetal = {expression greater than zero if pattern is bronze};
The problem here is that the degree of specularity doesn't change properly.
So, using the mixdata type is a better solution, and you can reduce your
original picture down in size and convert to the data type using pfilt
and pvalue (and an editor). For example, you might use:
% pfilt -x /4 -y /4 mypicture.pic \
| pvalue -H -h -d > mypict.dat \
| rcalc -e '$1=.6*$1+.1*$2+.05*$3' > mypict.dat
% vi mypict.dat
The rcalc expression is supposed to compute the "bronzeness" of the pixels,
though I don't know if I picked the best coefficients to do this.
Anyway, you must edit the ASCII file "mypict.dat" so that the first few
lines read:
2
max(yres/xres,1) 0 yres/4
0 max(xres/yres,1) xres/4
Where xres and yres are the original X and Y dimensions of your image.
This makes the (u,v) coordinates of the mixdata exactly match the (u,v)
coordinates of your colorpict pattern. (Note that I want you to work
out these expressions and write in the numbers, not the expressions
themselves!) You can then apply this in a mixdata primitive like so:
void colorpict mypicture
7 noop noop noop mypicture.pic mypicture.cal u v
0
0
mypicture metal bronze_part
0
0
5 .7 .7 .7 .8 0
mypicture plastic wood_part
0
0
5 .7 .7 .7 .04 0
void mixdata my_material
5 bronze_part wood_part coef mypict.dat mypicture.cal u v
0
0
The function "coef" should be defined in mypicture.cal to compute the
coefficient (between 0 and 1) from the data value in your "mypict.dat"
file. I don't know how you want to do this, but you can experiment
with different mappings.
I hope this long-winded answer is of some help.
-Greg
From: "CVL User Tarn Burton"
Date: Tue, 18 Apr 1995 22:15:35 -0600
To: greg@hobbes.lbl.gov
Subject: mixfunc xform
Thanks for the help on mixfunc. I've got the mapping worked out, just the nit
picky details now.
Aside from this, something else has come up. If I use mixfunc in a rad file
that is xformed into a another file multiple times all the previous versions of
the object will use the most recent xform. This seems to apply to mixdata
only, and other materials, such as colorpict seem to work.
I solved this problem for the time being by using instance instead.
Unless I am doing something wrong (which I don't think so since everything else
xforms okay) than this might be a bug.
Thanks again for the help, it wasn't too verbose. Most people hardly even
respond so it is refreshing to get a complete answer to a question.
Tarn
Date: Wed, 19 Apr 95 16:35:47 PDT
From: greg (Gregory J. Ward)
To: user1417@VIS.ColoState.EDU
Subject: Re: mixfunc xform
Hi Tarn,
I actually know about this "bug" but there's not much I can do about it.
The same problem happens with antimatter and it's caused not by the wrong
transform being applied but by the wrong material being looked up. You
see, unlike normal Radiance modifiers, the material or modifier names
given as string arguments are looked up at the time of their application,
i.e. when a pixel is being rendered, rather than as the file is being
read in. Thus, the final definition is the one that always gets
used, whether or not it preceded the referring primitive.
A simple example is given below:
void plastic plas1
0
0
5 .5 .3 .7 .05 .02
void metal met1
0
0
5 .3 .4 .6 .9 .02
void mixfunc mix1
4 plas1 met1 Dz .
0
0
void plastic plas1
0
0
5 .2 .1 .3 .0 .0
mix1 polygon f1
0
0
9
0 0 0
0 1 0
1 0 0
Which definition of "plas1" will apply to the polygon "f1" modified by "mix1"?
The answer is, the last one. If "plas1" had modified a primitive instead of
being referred to in its string arguments, then the first one would have
applied. However, since the modifiers named in the string arguments are
dereferenced during rendering and not before, the final definition of "plas1"
is the one that holds.
I agree that this is a shortcoming, but one that cannot be easily overcome
in the current implementation. It's best just to be aware of it, and name
your modifiers uniquely to avoid the problem. (This is mentioned in the
reference manual under mixfunc.)
Putting things in instances is as you say another way to solve the problem.
Clever of you to think of that -- I didn't!
-Greg
=======================================================================
GEOMETRIC MODELERS
From: Jeremy
Subject: modellor
To: greg@hobbes.lbl.gov
Date: Wed, 22 Mar 95 18:56:07 WST
Hi there Greg,
Sorry to have to annoy you personally, but the situation here is
getting quite desperate!. Firstly, my name is Jeremy and I'm a 3rd year Fine
Arts Student here at CURTIN Uni in Perth Australia. I am no elect. engineer and
have to muddle my way through a lot of things, but..
We have RADIANCE 2.4 installed here and it runs well.
We're running it on 2 HP 9000's. One with 16 and the other 32 RAM. We
have no trouble with the software at all, it's very nice :).
But my problem is I have no modellor complex enough to do
what I'd like, with an easy to use interface.(or at least not completely text
based.) We have Mac's here. And a baby pc, which I don't touch. I have
looked at rendermanCad for Povray and then thought I'd convert objects
into Radiance, but the prog is too simple.
I have shown Simon (crone) the output from Infin-D on the
Mac,
which we have. .. And it's nothing like a true .dxf file. Complete
garble. We can't seem to find a decent modellor for the HP's, which we
would prefer, as they steamroll a Mac, even on a cloudy day. We don't
have any CAD progs for the workstations.
I haven't seen a great deal of organic things done with
RADIANCE,
in fact I haven't seen any. I know it's an architectural modellor, but
it's the software I chose after looking at the range available. I know
I have the ideas..but at the moment, not the means.
As a side note, I also use WAVEFRONT Personal Visualizer
2.11. An
absolute pig of a program, but it has a great scene creation area.
Unfortunately, I can't seem to convert it's output into Radiance
either. It produces .geo files.
So, do you have any ideas at all? Have you heard of, or
used
Visualizer? I'm starting to see .rad files in my sleep. :) Any help
would be appreciated very much.
Jeremy Burton - Graphic Design, I.M.A.G.E. Technology. Dept.
Electronic Engineering, CURTIN University of Technology. Perth
Western Australia, Australia. jeremy@picasso.ece.curtin.edu.au
Date: Wed, 22 Mar 95 18:14:37 PST
From: greg (Gregory J. Ward)
To: jeremy@picasso.ece.curtin.edu.au
Subject: Re: modellor
Hi Jeremy,
For the Mac, there is a free program called Vision3D which you can pick up
from our ftp site (hobbes.lbl.gov) in the /pub/mac directory. It is very
good, though I'm not sure how well you can use it to create free-form shapes.
That's a hard problem, and the one time I did it myself, I used a NURBS
editor written by a friend as a demo for SGI's. I don't know if I could
get a working version of it for you, but I'll try if you ask me nicely.
Can you write out .OBJ files from Wavefront? I recently wrote an obj2rad
converter. It's not very sophisticated, and doesn't know how to handle
parametric surfaces, so you will have to tesselate them beforehand if you
can. There is also a translator for StrataStudio in the /pub/translators
directory on hobbes.
Let me know if any of this is any use to you. I appreciate your efforts,
and wish you luck. It isn't easy, I know. If there is a free or shareware
modeller you really like, you might want to bug the author to add Radiance
support. It really is pretty easy to do.
-Greg
=======================================================================
LENSES
From: Cameron Meadors
Subject: effects of lenses
To: GJWard@lbl.gov
Date: Fri, 24 Mar 1995 13:16:30 -0500 (EST)
Greg Ward,
I have been using Radiance 2.4 compiled on Linux long enough to get
into some pretty intense models. Question: How realistically can lenses be
modeled? I have read the the discussions in comp.graphics.raytracing, but I
haven't found a definite answer. Looking into a lens is fine, but what
about the light refracted through a lens and projected on another surface.
I believe I read one of your posts describing Radiance as using raytracing
and radiosity techniques. Could you explain the limits of lenses and how I
can demonstrate the effects? Thank you in advance.
--
Cameron Meadors Mechanical Engineering '97
cameron@syzygy.res.wpi.edu Worcester Polytechnic Institute, MA
Date: Fri, 24 Mar 95 10:26:12 PST
From: greg (Gregory J. Ward)
To: cameron@syzygy.res.wpi.edu
Subject: Re: effects of lenses
Hi Cameron,
As is true with most light-backwards ray-tracing algorithms, Radiance is not
well-suited to modeling light as passed through lenses onto other surfaces.
To do this effectively, you really need a forward or bidirectional ray-tracing
method. Unfortunately, I know of no ray tracer distributed over the internet
that includes this capability, as it is of limited use in most environments.
Nevertheless, you may be able to see what you're after in Radiance, by
decreasing the -aa value and increasing -ad and -as (with -ab 1 or higher),
and modeling the light source(s) with the glow type with a radius of zero.
This relies on finding the light sources with the "indirect" calculation,
which won't work very well for small light sources. Therefore, your sources
should be reasonably large or you will have to use preposterous settings for
the -ad parameter.
If you just stick with the default Radiance direct calculation, and your
light source is an intermediate size, you will get a shadow effect due
to lens refraction that, although not strictly correct, may be a reasonable
approximation of the illuminated area. This is due to the fact that shadow
rays are refracted through a dielectric medium in Radiance as a cheap,
halfway solution.
Hope this helps.
-Greg
Date: Fri, 24 Mar 95 13:34:02 -0800
From: greg@pink.lbl.gov (Gregory J. Ward)
To: greg@hobbes, cameron@syzygy.res.wpi.edu
Subject: Re: POV: Lenses? - comp.graphics.raytracing #12136
Hi again. Coincidentally, I came across this lucid description of
the problem from Jason Black in comp.graphics.raytracing posted today.
In article <3ksqfp$gc7@nntp3.u.washington.edu>, cloister@u.washington.edu
(cloister bell) writes:
damianf@wpi.edu (Damian Frank) writes:
>Sorry if this is a dead topic around here, but it wasn't in the FAQ. Is it
>possible to model lenses using PoV? I've tried, by shining a point light
>through the intersection of two spheres (to produce a convex lens) but it
>doesn't seem to alter the light at all. This might be because I know
>nothing about lenses, but I expected _something_ to happen. Does anyone
>know about this?
improper treatment of lenses is one of the flaws of backward ray tracing in
general. if you trace rays from the eye out into the world, they will pass
through lenses in the proper way. So as long as you're _looking_ through the
lens it'll be fine.
however, if you're trying to use the lens to focus light from a light source,
backward ray tracing is doomed to fail. what's going on in the real world is
that the lens collects light over its surface and concentrates (or otherwise
redistributes) it onto other surfaces. you can try and model this two ways.
one, you can trace rays forwards from the light sources to see where they land
and then gradually build up an illumination map for the scene that way. The
other method is to try and solve analytically how the lens will redistribute
light into the scene and then treat the lens more or less as a virtual light
source of its own (albeit with some special properties than normal lights).
forward ray tracing, of course, requires you to cast a whole lot more rays than
you need to actually illuminate the part of the scene that you're looking at,
but on the other hand, you only have to do it once. In those respects it's a
lot like radiosity, except that forward ray tracing is stochastic whereas
radiosity is analytic which makes radiosity less computationally expensive than
forward ray tracing.
the analytic solution for general lenses is just plain hard on a mathematical
level. however, progress is being made in this area, so i wouldn't be
surprised to see this sort of feature show up in packages like radiance and
maybe even pov in the next couple of years.
--
+-------------------------------------------------+---------------------------+
|tactical nuclear sdi stealth nsafood signature. | cloister@u.washington.edu |
+-------------------------------------------------+---------------------------+
From: Cameron Meadors
Subject: Re: POV: Lenses? - comp.graphics.raytracing #12136
To: greg@pink.lbl.gov (Gregory J. Ward)
Date: Fri, 24 Mar 1995 19:48:41 -0500 (EST)
>
> Hi again. Coincidentally, I came across this lucid description of
> the problem from Jason Black in comp.graphics.raytracing posted today.
>
> In article <3ksqfp$gc7@nntp3.u.washington.edu>, cloister@u.washington.edu (cloister bell) writes:
> |> damianf@wpi.edu (Damian Frank) writes:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is humorous. This is my roommate. This post is what sparked this whole
discussion :) Thanks anyway.
--
Cameron Meadors Mechanical Engineering '97
cameron@syzygy.res.wpi.edu Worcester Polytechnic Institute, MA
=======================================================================
HERMITE CUBIC FUNCTIONS
From: Cameron Meadors
Subject: Hermite eq's
To: GJWard@lbl.gov
Date: Fri, 31 Mar 1995 14:32:52 -0500 (EST)
Greg,
I have been playing with complex surfaces in Radiance and I noticed
that you use the hermite function frequently. I have not been able to find
anything on hermite polynomials except for a very generic form. Is there
something unique about them that makes them nice for parametric definitions
of surfaces? Can you give me some titles of books that explain them?
Thanks in advance.
--
Cameron Meadors Mechanical Engineering '97
cameron@syzygy.res.wpi.edu Worcester Polytechnic Institute, MA
Date: Fri, 31 Mar 95 13:12:00 PST
From: greg (Gregory J. Ward)
To: cameron@syzygy.res.wpi.edu
Subject: Re: Hermite eq's
Hi Cameron,
I like Hermite cubics myself simply because I understand them. They are
defined by their endpoints and slopes (or "velocities") at the endpoints.
It's relatively easy to build things using Hermite cubics and nothing else.
Any basic computer graphics text, like Foley, van Dam, Feiner and Hughs
(Addison Wesley), will explain this and other cubic forms.
The basic explanation I would give is that a Hermite curve looks like so:
_ r0 _ r1
/| _/|
/ _/
/ /
/ _----__ _-O p1
/ _- --___-
/ _/
/_/
//
O p0
(Excuse my bad ASCII drawing.) The idea is that r0 determines the slope
at p0 and r1 determines the slope at p1. The length of the vectors r0
and r1 also determine how much the curve is "pulled" in the given direction.
A zero length for r1 would mean that the curve just meanders over to p1.
A long length (i.e. a large velocity) means that the curve is really
zinging at p1, so it may cause it to take a larger bend getting there
to smooth out the turn.
I wish I could show you this in animation, but you'll just have to play
with it to see what I mean.
-Greg
=======================================================================
AMBIENT BOUNCES
From: manuel@ise.fhg.de
Subject: Ambient bounces
To: greg@hobbes.lbl.gov
Date: Wed, 19 Apr 1995 16:35:09 +0100 (MESZ)
Hi Greg,
some questions concerning "ambient bounces":
We modelled a simple office room with a window facing WSW.
Walls are plastic .7 .7 .7 .
Sunny sky.
At a point in the center of the room, we started rtrace -I, with several
configurations in the parameters:
def = default rtrace parameter settings
OPT = -ad 256 -as 128 -aa .15 -ar 108 (as in dayfact)
Now, varying the ab parameter, we get (in the R channel)
def OPT
ab 0 0 0
ab 1 0 1.963
ab 2 4.703 5.804
ab 3 7.305 8.361
ab 4 8.708 9.885
ab 5 10.12 10.45
ab 6 10.74 11.09
ab 7 10.08 11.05
ab 8 same as ab 7 -
ab 9 same as ab 7 -
Could you tell me, please, why:
A) ab 6 > ab 7
B) ab 7 = ab 8 = ab 9 (at least in the configuration def)
C) Are A) and B) physics or RADIANCE features?
D) Are these differences (eg, ab_4 nearly 2*ab_2) reasonable?
As I understand the concept of ambient bounces, with every
additional bounce from the walls we get only 70% of the
reflected light ( as the walls are plastic .7 .7 .7).
So, after 4 reflections you get only a fraction of .7^4 = .24
of the initially incoming light.
Does an additional ambient bounce collect so much light that
the weakening of the light intensity (one additional reflection)
is more than counterbalanced by the additional amount of light
collected?
E) (Do you understand question D) ????)
Thank you very much in advance! Manuel
-------------------------------------------------------------------
Manuel Goller
Fraunhofer Institute for Solar Energy Systems
Simulation Group, A608
Oltmannsstr. 5
D - 79100 Freiburg
GERMANY
Phone: ++49 - (0) 761 - 4588 - 296
Fax: ++49 - (0) 761 - 4588 - 132
Email: manuel@ise.fhg.de
-------------------------------------------------------------------
Date: Wed, 19 Apr 95 16:50:33 PDT
From: greg (Gregory J. Ward)
To: manuel@ise.fhg.de
Subject: Re: Ambient bounces
Hi Manuel,
So many questions! I'll try to answer them, but I don't know if I can to
your satisfaction. Here goes:
>Could you tell me, please, why:
>
> A) ab 6 > ab 7
>
I would attribute this to random errors. Different rays are traced on
different runs, and they are distributed using Monte Carlo, so some
noise in the calculation is normal. The reason the values were monotonically
increasing before was that you were accumulating indirect, which you wouldn't
be doing if you had set your -av value correctly. (I.e. not left it as 0.)
Towards the end, the delta changes are getting small, and are overwhelmed by
noise.
> B) ab 7 = ab 8 = ab 9 (at least in the configuration def)
>
Radiance decreases the number of secondary rays at higher reflection levels
by a factor of two. After 7 bounces, the number of rays sent is the -ad
parameter over 2^7, or two in this case. (This gets demoted to 0 because
two is not enough rays to even sample anything.)
> C) Are A) and B) physics or RADIANCE features?
>
They are Radiance "features".
> D) Are these differences (eg, ab_4 nearly 2*ab_2) reasonable?
> As I understand the concept of ambient bounces, with every
> additional bounce from the walls we get only 70% of the
> reflected light ( as the walls are plastic .7 .7 .7).
> So, after 4 reflections you get only a fraction of .7^4 = .24
> of the initially incoming light.
>
> Does an additional ambient bounce collect so much light that
> the weakening of the light intensity (one additional reflection)
> is more than counterbalanced by the additional amount of light
> collected?
>
I'm a bit puzzled myself why you get a value of 0 for the default parameters
and 1 ambient bounce. This would seem to indicate that 128 samples is not
enough to even find the window, which means that the subsequent default
calculations are not even worth looking at.
Your crude zonal approximation does not account for the distribution of
light in the space. You have to think about light coming from the sky,
as well as direct light landing on the floor, bouncing then bouncing again
off the ceiling before finally reaching your illuminance point. Then,
I can sort of see how it might make sense.
> E) (Do you understand question D) ????)
>
I don't know, did I answer it?
-Greg
=======================================================================
BUMP MAPS
From: "CVL User Tarn Burton"
Date: Wed, 19 Apr 1995 21:01:31 -0600
To: greg@hobbes.lbl.gov
Subject: Bump Map
Is there a program that I can use to convert a data file (or picture) that
represents a displacement map to the three bump map files that I need for
texdata?
The displacement map is just an array of heights in the Z vector. With X and Y
being represented by the position in the array.
Thanks, Tarn
Sorry to bug you so much.
Date: Wed, 19 Apr 95 20:39:44 PDT
From: greg (Gregory J. Ward)
To: user1417@VIS.ColoState.EDU
Subject: Re: Bump Map
Hi Tarn,
Unfortunately, an array of heights does not a Radiance texture make. In fact,
there is no natural way to relate surface heights to surface normals, and it's
a mystery to me how other rendering systems do it. I suppose they use some
sort of fitting function and take its slope, but the choice of function
wholly determines the slope, and the choice is completely arbitrary!
I'm sorry that I can't answer your question in this case, but I simply don't
know a good answer. Your guess is as good as mine.
-Greg
From: "CVL User Tarn Burton"
Date: Fri, 21 Apr 1995 11:19:27 -0600
To: greg@hobbes.lbl.gov
Subject: Bump map
Here is a program to do the bump map conversion. It's pretty primitive and I
will probably work on it some more in the future, but maybe you can get
something out of it now.
It takes an array of heights from stdin and four args on the command line, the
first being the array width the the others being the names of X, Y, and Z data
files to write to.
As for how it does the actual calculations, it really is fairly simple. For
each point it fits a spline function onto the points in the vertical direction
and the horizontial direction. The derivitive of the these functions
represents dY and dZ since the array is oriented so the heights point in the
positive X direction. The cross product of these two vectors results in the
surface normal.
The program doesn't do any scaling or other fancy things, maybe I'll add this
later, right now I just wanted a quick fix.
Tarn
---------------------------------
#include < stdio.h>
#include < stdlib.h>
#include < math.h>
FILE *Xfile,*Yfile,*Zfile;
void Cross(double dY,double dZ) {
double divisor=sqrt(dY*dY+dZ*dZ+1.0);
fprintf(Xfile,"%g\n",1.0/divisor);
fprintf(Yfile,"%g\n",-dY/divisor);
fprintf(Zfile,"%g\n",-dZ/divisor); }
static double coeff[4][4]=
{{-4.0,9.5,-8.0,2.5},
{-0.5,0.0,0.5,0.0},
{0.0,-0.5,0.0,0.5},
{-2.5,8.0,-9.5,4.0}};
double Spline(int i,double x0,double x1,double x2,double x3) {
return (coeff[i][0]*x0+coeff[i][1]*x1+coeff[i][2]*x2+coeff[i][3]*x3); }
int Width;
double *X[4];
void CalcRow(int i) {
int j;
Cross(Spline(i,X[0][0],X[1][0],X[2][0],X[3][0]),Spline(0,X[i][0],X[i][1],X[i][2],X[i][3]));
for (j=3;j< Width;j++) Cross(Spline(i,X[0][j-2],X[1][j-2],X[2][j-2],X[3][j-2]),Spline(1,X[i][j-3],X[i][j-2],X[i][j-1],X[i][j]));
Cross(Spline(i,X[0][Width-2],X[1][Width-2],X[2][Width-2],X[3][Width-2]),Spline(2,X[i][Width-4],X[i][Width-3],X[i][Width-2],X[i][Width-1]));
Cross(Spline(i,X[0][Width-1],X[1][Width-1],X[2][Width-1],X[3][Width-1]),Spline(3,X[i][Width-4],X[i][Width-3],X[i][Width-2],X[i][Width-1])); }
void main(int argc,char *argv[]) {
int AtEnd,i,j;
double *swap,temp;
if (argc!=5) {
fprintf(stderr,"\nIncorrect number of parameters!");
return; };
Width=atoi(argv[1]);
Xfile=fopen(argv[2],"w+");
Yfile=fopen(argv[3],"w+");
Zfile=fopen(argv[4],"w+");
for (i=0;i< 4;i++) {
X[i]=(double*)calloc((size_t)Width,sizeof(double));
for (j=0;j< Width;j++) if (scanf("%g\n",&X[i][j])==EOF) {
fprintf(stderr,"\nIncomplete data!");
return; }; };
CalcRow(0);
do {
CalcRow(1);
if (!(AtEnd=(scanf("%g\n",&temp)==EOF))) {
swap=X[0];
X[0]=X[1];
X[1]=X[2];
X[2]=X[3];
X[3]=swap;
X[3][0]=temp;
for (j=1;j< Width;j++) if ((AtEnd=(scanf("%g\n",&X[3][j])==EOF))&&(j!=0)) {
fprintf(stderr,"\nIncomplete data!");
return; }; }; } while (!AtEnd);
CalcRow(2);
CalcRow(3);
fclose(Xfile);
fclose(Yfile);
fclose(Zfile);
for (i=0;i< 4;i++) free(X[i]); }
---------------------------------
Date: Fri, 21 Apr 95 10:34:26 PDT
From: greg (Gregory J. Ward)
To: user1417@VIS.ColoState.EDU
Subject: Re: Bump map
Hi Tarn,
Thanks for the code, but I don't know quite what to do with it. I don't have
any personal use for such things, though I know others have asked for this.
I suggest you put this together with a short man page or other documentation
and drop a tar file in the /xfer directory of hobbes.lbl.gov. Let me know
when it's ready, and I'll transfer it into the /pub/programs directory and
add an appropriate line to the README file there.
In the meantime, I've been recording our correspondence in the Radiance Digest,
which I should be sending out shortly. (As soon as I can get around to it!)
-Greg
Return to beginning of digest
Back to Top of Digest
Volume 2, Number 8, Part 1b
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.