RADIANCE Digest Volume 2, Number 5, Part 2
Dear Radiance Users,
Here is the second half of Volume 2, Number 5 of the Radiance Digest.
You should have received the first half already. If you don't get it
in a day or so, write me e-mail and I'll resend it to you.
As always, I ask that you do NOT reply to this letter directly, but
write instead to GJWard@LBL.GOV if you have any questions or comments,
or if you wish to be removed from the mailing list.
These are the topics covered in this mailing:
RPICT PARAMETERS - A couple questions answered re. rpict
EXTENDING RADIANCE - How to add materials/surfaces to Radiance
NEW BRTDFUNC AND NEON - An extended reflectance type and neon lights
LIGHT SOURCE ACCURACY - Near-field accuracy test of light sources
BRIGHTNESS MAPPING - Going from simulation to display
PARALLEL RADIANCE AND ANIMATIONS- New features of 2.3 and animation
AMIGA PORT - Reorganized Amiga port
PVALUE - Getting values from pictures
BACKGROUND COLOR - Setting the background in a scene
DEPTH OF FIELD - Simulating depth of field
A COMPANY CALLED RADIANCE - Not mine -- someone else's!
Hopefully, I won't let a whole year go by before the next posting!
-Greg
=================================================================
RPICT PARAMETERS
Date: Sun, 28 Feb 93 09:33:01 -0500
From: macker@valhalla.cs.wright.edu (Michael L. Acker)
To: greg@hobbes.lbl.gov
Subject: rpict parameters
Greg,
Could you explain the purpose and use of the 'sp' parameter to 'rpict'?
I'm a student who has been using Radiance 2.1 to do some graphics
modeling as part of an independent graphics study. The scene that I am
currently working with has objects as large as 100 feet across and as
small as 1/2-inch wide. With sp at 4 (the default) the 1/2-inch objects
are not completely represented in the image (missing parts I assume from
inadequate sampling). However, when I reduce sp to 1, the 1/2-inch
objects appear more complete (and smoother) though still not completely
represented.
Also, if I increase the ambient bounces (ab) to 1 or greater but leave
all other parameters at their default, rpict produces images with very
'splotchy' surfaces. For example, white walls look as if they have had
buckets of lighter and darker shades of white thrown at them.
The problem appears to lessen if I reduce the surface specularity and
increase the ambient super-samples (as).
Could you give me some insight into the proper parameters to use that
will smooth out the images? Or could you provide some example
rendering statements with the parameter lists? Or do you do some
preprocessing with oconv or postprocessing with other utilities, like
pfilt, to smooth out (improve) the images?
I'd appreciate any information you can offer.
Thanks,
Mike Acker,macker@valhalla.cs.wright.edu
Date: Mon, 1 Mar 93 09:18:59 -0800
From: greg@pink.lbl.gov (Gregory J. Ward)
To: macker@valhalla.cs.wright.edu (Michael L. Acker)
Subject: Re: rpict parameters
Hi Mike,
In version 2.1 of Radiance, the -sp (sample pixel) parameter was changed to
-ps (pixel sample) to make way for new -s? parameters to control specular
highlight sampling. Since the -sp option has disappeared in version 2.1,
you must either be using a previous version or a different option.
At any rate, anti-aliasing in Radiance requires rendering at a higher
resolution than that you eventually hope to display with, then using pfilt
to filter the image down to the proper size. A set of reasonable parameters
to do this might be:
% rpict -x 1536 -y 1536 [other options] scene.oct > scene.raw
% pfilt -x /3 -y /3 -r .65 scene.raw > scene.pic
In this case, the final image size will have x and/or y dimensions of 512,
and even small objects should appear smooth.
As for the ambient bounces, it sounds as if the specular component of your
surfaces may be too high. Non-metallic surfaces generally don't have specular
components above 5%. Check out the document ray/doc/notes/materials for
further guidelines. The splotchiness can be reduced by increasing the -ad
and the -as parameters (as you seem to have discovered).
Let me know if I can be of more help. Sometimes it is easier if you send
me an example file with view parameters, if youre scene's not too big.
-Greg
=========================================================================
EXTENDING RADIANCE
Date: Sun, 7 Mar 93 14:07:26 PST
From: Mark J Young
To: GJWard@lbl.gov
Hello.
Your name came up two days in a row for me. Yesterday I read
your 1992 CG paper, "Measuring and modeling anisotropic
reflection". I really enjoyed it and learned a good deal from
it. I wish there were more graphics papers than had such a
satisfying blend of science and graphics.
Then I was reading a newsgroup posting that indicated that you
have written a rendering package. So I was moved to ask your
advice. Myself and a few colleagues at NYU are looking for
rendering software that could be reasonably modifiable for the
following purposes.
We do psychophysical experiments and modeling of depth cue fusion
(in the sensor fusion sense) in human 3D perception. Some of us
also do modeling and psychophysics concerning color space in human
perception. Those folks are looking towards extending that work to
include reflectance models (of the internal kind). There is a desire
to have graphics software that could generate stimuli for both the
depth and color/reflectance experiments. There would need to be a
variety of rendering pipeline structures, surface models, color models,
and reflectance models employable.
I have written a crude 3D modeler that allows me to independently
manipulate the various 3D cues to a surface's shape in an abstract
geometrical way. I didn't do anything sophisticated about the color
representation or the reflectance model. We are at a point where
I either do alot of work on this package or find a mature package
that can be modified towards our needs. We would obviously like
something that is extremely modular. My package is object-oriented
(C++) and a paradigm like that seems very well suited to the kind of
extensions we need to make.
Do you know of a rendering package that is object-oriented or is of
the flavor that we are looking for? Also, could you tell me where I
can find "Radiance"? Thank you for any help you can give.
Regards,
Mark J. Young
Experimental Psychology Vision Laboratory
New York University NASA Ames Research Center
6 Washington Place Mail Stop 262-2
New York, NY 10003 Moffett Field, CA 94035
(212) 998-7855 (415) 604-1446
mjy@cns.nyu.edu mjy@vision.arc.nasa.gov
Date: Mon, 8 Mar 93 11:10:16 PST
From: greg (Gregory J. Ward)
To: mjy@maxwell.arc.nasa.gov
Subject: human perception modeling
Hi Mark,
Thanks for the compliment on my paper. Yes, I have written a fairly mature
simulation and rendering package called Radiance. You may pick it up by
anonymous ftp from hobbes.lbl.gov (128.3.12.38), along with some test
environments, libraries and so on.
The reflectance model built into Radiance is that presented in the `92
Siggraph paper. Additional hooks are provided for procedural or
data-driven reflectance models, though the resulting simulation will be
less complete as it will not include indirect highlight sampling (ie.
highlights caused not by light sources but by reflections from other
surfaces). The code is fairly modular and extensible, though it was
written in K&R C for maximum portability and speed. (Also, C++ was
not around when I started on the project 8 years ago.)
Adding a surface model requires writing two routines, one to intersect
a ray with the surface, and another to answer whether or not the surface
intersects a specific axis-aligned cube (for octree spatial subdivision).
Adding a reflectance model requires writing a routine to determine the
reflected value based on an incident ray, a list of light sources
(actually a callback routine that computes a coefficient as a function
of source direction and solid angle) and other ray values as required.
The rendering pipeline is very flexible -- too flexible for most people.
It makes it somewhat difficult to learn and to master. There are about
50 programs altogether. Even if you decide to use your own renderer,
you may find some of the programs provided with Radiance useful to your
research.
The one part of Radiance that is currently difficult to change is the
RGB color model. I have been prodded by several people to introduce a
more general spectral model, which is something I had planned to do at
some point but I have been hung up by a lack of data and motivation.
Right now, people can define the three color samples to mean whatever they
want, but to get more samples, multiple rendering runs are necessary.
I look forward to hearing more from you.
-Greg
Date: Tue, 20 Jul 93 13:19:52 MED
From: bojsen@id.dth.dk (Per Bojsen)
To: GJWard@lbl.gov
Subject: Bezier Patches?
Hi Greg,
I was wondering how easy it would be to add support for Bezier patches
as a new primitive in Radiance? What is the status of Radiance and
future development of Radiance? Is it still free or is it going
commercial?
--
Per Bojsen The Design Automation Group Email: bojsen@ithil.id.dth.dk
MoDAG Technical University of Denmark bojsen@id.dth.dk
Date: Tue, 20 Jul 93 09:07:44 PDT
From: greg (Gregory J. Ward)
To: bojsen@id.dth.dk
Subject: Re: Bezier Patches?
Hi Per,
Adding a new surface primitive is easy in principle. Two routines are needed:
one to determine whether or not a surface intersects an axis-aligned cube,
and another to determine the intersection point and surface normal for a
ray with the surface. Neither one is particularly easy or difficult for
Bezier patches, but I have little need for them myself. If ever I do need
such a thing, I use gensurf to create a smoothed, tesselated version for me.
Believe it or not, the Department of Energy STILL has not decided what they
want to do with Radiance, or if they have, they haven't informed me.
-Greg
==================================================================
NEW BRTDFUNC AND NEON
From: phils@Athena.MIT.EDU
Date: Wed, 19 May 1993 18:18:50 -0400
To: greg@hobbes.lbl.gov
Subject: Mirrored glass?
Greg,
Do you have any suggestion for specifying mirrored glass?
Reflective on the outside and low transmission on the inside.
Neither "glass" or "mirror" materials offer enough control of
parameters. I'm not having much luck in using "trans" materials either.
Have any ideas what skyscrapers are made of?
Thanks,
Philip
Date: Wed, 19 May 93 17:36:45 PDT
From: greg (Gregory J. Ward)
To: phils@Athena.MIT.EDU
Subject: Re: Mirrored glass?
Hi Philip,
I really wish I knew more about coated glazings so I could implement at good
material type for them. It's not a difficult problem; I simply don't know
the physics of these materials. The measurements I have access to deal only
with photometric transmittance -- they don't consider color and they don't
look at reflection.
I suppose I could take a hack at it by assuming that reflectance either
doesn't depend on incident angle (wrong) or that it follows Fresnel's law
for a specific dielectric constant (possibly complex). The thing is, I'd
like to do it right the first time, but I need more information.
Let me do a little investigation on my end to see what I can come up with.
I can't think of a good solution with the current material types unless you
use the BRTDfunc and make it sensitive to orientation. I'll get back to you.
-Greg
Date: Thu, 27 May 93 16:18:16 PDT
From: greg (Gregory J. Ward)
To: phils@Athena.MIT.EDU
Subject: Re: Mirrored glass?
Hi Philip,
I haven't forgotten about the glazing problem. In fact, I've spent a good
part of the past week working on it.
As it turns out, no one seems to have a very good handle on the behavior
of coated glazings, including the manufacturers! Our resident window
experts have been using a formula based on reflection function fits to
clear and bronze glazing. I have implemented their formulas in Radiance
via the BRTDfunc type. Unfortunately, I had to modify this type in the
process in order to get it to work, so you'll have to pick up a new
beta release which I've put in xfer/4philip.tar.Z on hobbes.lbl.gov.
The function file ray/lib/glazing.cal is contained therein.
[Don't try to upload this file -- it's already been incorporated in 2.3]
Let me know if you need any help using it.
-Greg
Date: Thu, 30 Sep 93 10:39:05 EST
From: TCVC@ucs.indiana.edu
Subject: Radiance and neon
To: greg@hobbes.lbl.gov
Hello Greg,
1) I have been modelling the effects of neon in the environment.
Where its direct component is irrelevant, I have used instances of
'light' polygons in order to explore the effects of shape and color
in relationship to specular surfaces. This certainly creates a
rapid rendering time.
But now I am also interested in the direct component of neon. It
appears that point sources are arrayed along any "light" or "glow"
emitting surfaces. Unfortunately, I appear to have no control of
their density or spacing, so that uninstanced(sp!?) neon appears
like a string of christmas lights attached to the tube. Are there
parameters I can adjust? I am using 1 unit = 1 foot, sometimes 1
unit = 1 meter. Most views are fairly distant.
A related problem is in my representing the effect of 3 neon tubes
located behind a piece of frosted glass. The glass surface is about
8 feet long and .5 feet wide. I am interested in the direct
component effect onto the surface of a 6 foot diameter pillar
located 1 foot in front of this narrow light box. Rather than
building a model of the neon tubes with 'glow' and then placing a
Translucent surface in front of it, I have tried to simply use a
polygon to represent the glass, and have given it the attributes of
'glow'. The result is the effect of 4 bare lightbulbs lighting the
column. How can I increase this density so that the effect is
smoothed out?
2) Is the intensity of the sun in Gensky in proportion to the
intensity of the output of IES2RAD? I need to merge daylight with
measured electric light sources in a complex environment.
Interreflection will play an important role. Should I create my own
sun using an IES2RAD spotlight with the correct sun intensity at a
great distance?
Please share your thoughts!
-Rob
Date: Sat, 16 Oct 93 22:20:08 PDT
From: greg (Gregory J. Ward)
To: TCVC@ucs.indiana.edu
Subject: Q&A
Hi Rob,
1) "Coving" from extended light sources.
The artifacts you are witnessing are the result of the internal limit
Radiance has in breaking up large light sources. The constant is somewhere
in src/rt/source.h, and I think it's set to 32 or 64 presently. You can
try increasing this value and recompiling, but a better approach is to
set -dj to .5 or .7 and/or break up your long light source into several
shorter ones.
By the way, you can use glow with a distance of zero instead of instancing
"light" polygons if all you want to avoid inclusion in the direct calculation.
In release 2.3 (coming soon, I hope), a negative distance for a glow type
also excludes the materials from indirect contributions, which can be a
problem when -ab is greater than one and the sources are relatively small.
2) Sun from gensky.
Yes, gensky does produce a sun with the proper brightness, using certain
assumptions about the atmospheric conditions. If you wish to adjust the
value up or down, I suggest you modify the gensky output rather than trying
to create the source yourself, since gensky does such a nice job of putting
the sun in the right place.
Gensky in version 2.3 will offer several new options for adjusting solar
and zenith brightness.
-Greg
Date: Sun, 24 Oct 93 20:22:24 EST
From: TCVC@ucs.indiana.edu
Subject: new material type
To: greg@hobbes.lbl.gov
Hi Greg,
Thanks for your note and assistance regarding consortium and
"neon". I have yet to post some images for you to hopefully
enjoy... maybe by Thanksgiving!
There is a "material" which Radiance does not yet support and
which I am finding the need for. It is similar to what is
called "chroma key blue" in TV. The situation is this:
I have a scanned image of a tree without foliage. This was
taken from a painting from the surrealist painter Magritte,
and will be used in an upcoming production of a play titled
SIX CHARACTERS IN SEARCH OF AN AUTHOR by the Italian author
Pirandello. Several instances of this "tree" are to be located
on a platform. The backdrop is a cloud filled sky. The trees
are seen silhouetted against this backdrop. They will actually
be made by stretching a fine black net over a tree shaped
frame, then applying opaque shapes to the surface. Fine branches
will be caulked into the net. The complex shape will be suspended
via fine wires from the pipes above the stage.
My solution was to map the scanned image of the sky onto
a polygon of type plastic. This works well. I then mapped
the trees onto a polygon of type glass ( trees were made black
on a white field in Photoshop). The result is that the trees
are clearly silhouetted in their several locations between the
audience and the backdrop. They cast predictable shadows etc...
BUT the rectangular "glass" polygon surface is still present and
even though it has an RGB value of 1 1 1 , its "presence" can be
seen against the lighted backdrop... and light sources are seen
as reflections on its surface. Any details other than black would
be seen as transparant colors... fine for stained glass BUT I need
them all to be opaque.
I propose an "invisible" surface which only has a visual
presence where elements of an image are mapped onto it. Perhaps
there is an option for rbg = 1 1 1 or rgb = 0 0 0 to be the
invisible component. This is dependent on the nature of the
image. Perhaps the "paint" or image data could take on the
attributes of metal, plastic, trans, mirror, or glass...
making it truely versatile.
Materials that could be modelled this way are not limited to
theatrical objects. Sunscreens made of metal with punched
holes and detailed architectural profiles are but a few of the
objects that could take advantage of this new "material" type.
Maybe I am missing the boat, and this is already a component of this
excellent simulator... if so, please point it out. We have successfully
used "trans" to represent stained glass and theatrical "scrim"... its
the invisible component that's needed.
-Rob
Date: Mon, 25 Oct 93 10:11:21 PDT
From: greg (Gregory J. Ward)
To: TCVC@ucs.indiana.edu
Subject: Re: new material type
Hi Rob,
There is a new material type in the next release that may do what you want.
It's called "BRTDfunc", and it's been modified since release 2.1 to permit
a number of things, including varying diffuse reflectance using a pattern.
I am not quite ready to release 2.3, but you may pick up an advanced copy
I've made for you from hobbes.lbl.gov in /xfer/private/4rob.tar.Z. The
private directory doesn't have read permission, so you won't be able to
run "ls", but you should be able to pick up the file nonetheless.
The only real changes I will make before the official 2.3 release will be
in the documentation, so you probably won't need to recompile when it becomes
official in a week or so.
You can read the new ray/doc/ray.1 manual for an explanation, but what you
want will look something like this:
void colorpict tree_pict
7 clip clip clip tree.pic picture.cal pic_u pic_v
0
0
tree_pict BRTDfunc tree_mat
10
0 0 0
1-CrP 1-CgP 1-CbP
0 0 0
.
0
9
1 1 1
.1 .1 .1
0 0 0
The way I have given it here, you should face your tree polygon towards
the audience, and the back will appear either transparent or fairly dark
(where there are branches).
Let me know if this works!
-Greg
Date: Tue, 26 Oct 93 16:04:48 EST
From: TCVC@ucs.indiana.edu
Subject: Re: new material type
To: greg@hobbes.lbl.gov
Thanks for the fast responce! I can certainly get a lot of mileage
out of the new material you have created.
Your example produced a "cutout" of the image, so I reversed
some parameters, making the scanned image opaque and the polygon
transparent.
void colorpict filigree
9 red green blue robtree2f.pic picture.cal pic_u pic_v -s 7.5
0
0
filigree BRTDfunc net
10
0 0 0
CrP CgP CbP
0 0 0
.
0
9
1 1 1
0 0 0
0 0 0
net polygon tree
0
0
12
0 0 0
6.5 0 0
6.5 13 0
0 13 0
I have yet to explore the properties of the image surface....
wether its like plastic or glass or metal or all.
It works excellently for this application though!
-Rob
======================================================================
LIGHT SOURCE ACCURACY
From: apian@ise.fhg.de
Subject: lightlevels close to lightsources
To: gjward@lbl.gov (Greg Ward)
Date: Thu, 10 Jun 93 17:17:05 MESZ
Dear Greg,
what follows is a uuencoded cpio demo file concerning light intensities
close to lightsources, and a problem.
Given a disc (diameter=1), rtrace calculates irradiance for a point
above the disc center, varying the distance between center and point.
The values are compared with
a) inverse square law, valid for distances >> disc diameter
b) the analytical solution
Problem:
The radiance values are too low for distances in the order of the
diameter and smaller. For very small distances the values are in fact
decreasing.
Hm. Any help, ideas or is my testdemo wrong? (could be... could be..)
The files:
makefile starts the rtrace stuff
rquadrat.rad demo geometry
eins-durch-r-quadrat gnuplot file
If you got gnuplot, simple say "make demo" and tell gnuplot
load "eins-durch-r-quadrat"
The two curves are 1/r^2 and the integrated solution, points are
rtrace output.
For -ds 0 all points lie on the 1/r^2 curve, as expected. Setting
-ds 2 nicely shows the sampling of the disc, but -ds 0.001 results
in a curve too low.
TIA*1e8
Peter
--
----------------------------------------------------------------------
Peter Apian-Bennewitz apian@ise.fhg.de
Fraunhofer Institute for Solar Energy Systems Tel +49-761-4588-123
(W-Germany) D-7800 Freiburg, Oltmannsstrasse 5, Fax +49-761-4588-100
>>> new phonenumber effective after Friday, 11.6.93
>>> new Freiburg postal code: 79100 , effective 1.7.93
----------------------------------------------------------------------
Date: Thu, 10 Jun 93 13:12:39 PDT
From: greg (Gregory J. Ward)
To: apian@ise.fhg.de
Subject: Re: lightlevels close to lightsources
Hi Peter,
Your results, though disappointing, are not terribly surprising. You see,
I don't use an analytical solution for disk sources. In fact, the real
problem is that I don't sample them as disks at all. I assume they are
approximately square, and thus sample points may fall outside the actual
disk at the corners, particularly if -ds is small or -dj is close to 1.
Points that fall outside the disk are not counted, so the resulting
estimate is low.
[But read ahead - there was a mistake in the integral]
Intelligent sampling is difficult (ie. expensive) to do in general, so
I don't usually do it. It would add a lot to the cost of the calculation
because it has to happen everytime a source is examined, which is all the
time in Radiance.
The only case that is handled properly is parallelograms (incl. rectangles).
Thus, if you want a correct result, you'd better start with a rectangular
light source. Fortunately, most sources are approximately rectangular, and
it is cheap to sample them.
Just out of curiousity, why did you decide to test this case? Because you
know the analytical solution, or because you have a real need to calculate
illumination very close to a disk light source? (BTW, you'll find that
spheres are even worse -- I don't substructure them at all in Radiance!)
-Greg
P.S. Here is a bgraph input file to plot the same stuff. You can type:
bgraph comp.plt | x11meta
or
bgraph comp.plt | psmeta | lpr -P PostScript_printer
These programs are distributed with Radiance 2.1. I wrote them ages ago,
before GNU came into being.
::::::::
comp.plt
::::::::
include=function.plt
xmin=.001
xmax=8.5
Alabel=Exact
Blabel=Rtrace
A(x)=PI*2*(1-x/(sqrt(x*x+1)))
Bdata=rtrace.out
From: apian@ise.fhg.de
Subject: Re: lightlevels close to lightsources
To: greg@hobbes.lbl.gov (Gregory J. Ward)
Date: Fri, 11 Jun 93 12:20:25 MESZ
Hi Greg,
thanks for your answer.
> Just out of curiousity, why did you decide to test this case? Because you
Yep. the disc integral is a lot easier to do. The first idea was to
compare the 1/r^2 approxomation with the real thing, to estimate errors
in the measurements I make. Only as second thought came the idea of
comparison with rtrace. Probably more of academic interest.
greetings
Peter
--
From: apian@ise.fhg.de
Subject: nice values in rpict/rtrace
To: gjward@lbl.gov (Greg Ward)
Date: Fri, 11 Jun 93 14:51:38 MESZ
one more suggestion:
The default nice values in rt/Rmakefile are a bit of an xtra. If
you user wants lower priority, normal nice is available, but its
a bit tricky to get rid of the nice once rpict has set it.
This can be nasty in shell scripts and NQS / HP-taskbroker batch
processing.
IMHO, suggestion: as a default, no nice settings in rt/Rmakefile.
(BTW: my integral was a bit wrong, we'll look into this)
Peter
Date: Fri, 11 Jun 93 08:15:14 PDT
From: greg (Gregory J. Ward)
To: apian@ise.fhg.de
Subject: Re: nice values in rpict/rtrace
You know, Rmakefile is there for you hackers to play with. If no other
processes are running on the machine, the nice value has no effect. It's
just there so your time-consuming processes that are not interactive, rtrace
and rpict, don't slow you down too much when you're trying to do something.
It's also there to protect me and my less knowledgeable users from the scorn
of system administrators. I'm one of them, so I know how scornful they can be.
-G
From: apian@ise.fhg.de
Subject: rtrace&integral
To: gjward@lbl.gov (Greg Ward)
Date: Fri, 11 Jun 93 15:05:04 MESZ
ok ok ok ok ok ok ok ,
f(x)=pi*(1-x*x/(x*x+1))
looks a lot better, your disc subdivison is ok.
sorry for all the noise.
--
Peter Apian-Bennewitz apian@ise.fhg.de
Date: Fri, 11 Jun 93 08:24:32 PDT
From: greg (Gregory J. Ward)
To: apian@ise.fhg.de
Subject: Re: rtrace&integral
I'm much relieved to hear it! I can't believe I was willing to just lay down
and admit that my calculation was all wrong without even checking your work.
Oooo! It makes me so mad!
The new plot does look much better, though I notice the value still does
drop precipitously at extremely close range. Using a value of .7 for -dj
changes that drop to noise above and below the correct value, which is better.
The reason it drops is that there is a limit to how far the subdivision will
go, so the calculation doesn't go berzerk next to light sources.
Thanks for following through on this.
-G
====================================================================
BRIGHTNESS MAPPING
To: raydist@hobbes.lbl.gov, raylocal@hobbes.lbl.gov
Subject: Hello
Date: Tue, 15 Jun 93 18:35:47 +0100
From: Kevin Jay marshall
Hello again,
I am not really a new radiance user, but I am not by any means a first
time user. I first have to say that I have found Radiance to be an exceptional
collection of programs and enjoy using them when I get a chance. Lately I
have been really studing Radinace and trying to understand the meat inside
the programs, and have found it a little hard to follow. I think that most
of my problem is lack of experience and knowledge in light technique. I am
hoping that someone out there is able to give me a hand in what I am learning.
I am creating a scene that does not contain much lighting but a couple
of direct sources read in from an ies file format. What I am having a problem
with is the intensity of light after I reset the exposure with pfilt, the
lights are coming out really too bright. I have read the segment that Greg
wrote Jim Callahan on Exposure in the Radiance Digest. So I would like to
ask a couple of questions also. First, is in the letter in the digest it was
stated that the exposure was a more precise way of setting the image color
to look more realist. Would it be safe to say that the use of pfilt would
be more correct than a gamma correction applied to an image? I only ask,
because I am not absolutely 100% sure of the correct answer, but I would guess
the answer is yes. So once I know that answer it will be easier to understand
the next question. I would like to find the correct exposure that suits the
realness of the picture better. Would I be correct if I decided to set the
exposure value based on the ratio of my lights luminous efficiency to that of
white light? Since the lights I am using all have the same luminous efficiency
about 21 lumens/watt as aposed to the 179 lumens/watt white light in Radiance.
Could I use the two pass pfilt averaging of the exposure values and then
multiply the luminous value by 11% which is what 'my light/white light'? Or
on the other had would I just use the 1 pass exposure setting and set the
exposure to that of white light 179 lumens/watt. They both look good to me, but
the first method is brighter than the other. I am just starting in all this
luminous levels and what not so my main question is am I on the right track?
Is one of my solutions better than the other or am I absolutely not
understanding my problem correctly?
Then another question if someone has time. Since I am new to the
lumious/illuminance Engineering, what is the advantage to calculating Radiance
values as apposed to calculating luminous values? I spent the other night
attempting to understand why and what I could understand is that Radiance is
based upon amount of light emitted from a Black body and its measurments
through, and from matterials is wavelength independent. I also looked up the
definition of the candela which is based upon radiance measurements that are
converted to luminous measurements by a max luminous efficiency of
683 lumens/watt is at a wavelength of 545 nm. I realise I am probably asking
questions that will probably better answered in a course, but I figure it never
hurts to ask. Well thanks for the time.
-Sincerly,
Kevin
Date: Tue, 15 Jun 93 13:01:44 PDT
From: greg (Gregory J. Ward)
To: kevin@sigma.hella.de
Subject: exposure, etc.
Hi Kevin,
Luminous efficacy doesn't really have much to do with luminance or the
perception of brightness. Luminous efficacy tells how efficiently a
lamp converts electrical energy into visible light. You can still use
a greater quantity of inefficient fixtures to outshine the more
efficient ones, but as a researcher in energy conservation it is my
job to criticize you if you do.
If I understand you correctly, your basic question is, 'how do I
display my image so as to reproduce the same viewer response as the
actual environment?' I believe this question is still open to debate,
but at least it is starting to attract some of the research attention
from the computer graphics community that it deserves.
One answer has come from Jack Tumblin and Holly Rushmeier. Looking back
to subject studies conducted in the early 1960's, they devised a formula
that maps world luminance values to display luminances in a way designed
to evoke the same viewer response as the actual scene (would). So far,
their paper has appeared only as a technical report (number GIT-GVU-91-13
from the Georgia Institute of Technology, College of Computing,
Atlanta, GA 30332-0280), but an abbreviated version will soon appear in
IEEE Computer Graphics and Applications [Fall 1993 issue]. An implementation
of the Tumblin-Rushmeier display mapping is appended at the end of this
message.
In the meantime, Chiu, Herf, Shirley, Swamy, Wang and Zimmerman have done
some interesting work on mapping brightness adaptively over an image in
their 1993 Graphics Interface paper. They refer also to Tumblin and
Rushmeier's work, which seems to becoming widely accepted as the standard
even before it's been properly published.
The approach I've been working on lately is a simple linear scalefactor,
which can be applied with pfilt, or dynamically with a new version of ximage.
The scalefactor is based on some early 1970's subject studies by Blackwell,
and it attempts to reproduce visible contrast on the display to correspond
to the visible contrast in the environment being simulated.
For a standard color monitor, the formula boils down to:
exposure = .882/(1.219 + L^0.4)^2.5
where the world adaptation luminance, L, is expressed in candelas/m2. To
find this value, it's easiest to use the 'l' command of ximage after selecting
the area at which the viewer is supposedly looking. Let's say that ximage
reports back a value of 25. You could then apply pfilt as follows:
pfilt -1 -e `ev '.882/(1.219+25^.4)^2.5'` orig.pic > adjust.pic
Be sure to use the -1 option, and this must be the first exposure-adjusting
application of pfilt to your picture, otherwise you will not be starting from
the original values and the exposure will be off. Like I said before, the
next version of ximage will have a new command, '@', that performs this
adjustment interactively. The result is a dark display if you're starting
from a dark environment, and a normal display if the environment has good
visibility.
Again, do not confuse luminous efficacy with brightness perception. The
efficacies given in common/color.h are for the visible spectrum only, and
are different from full-spectrum efficacies reported for the sun and electric
light sources. The only reason for using spectral radiance (the physical unit)
instead of luminance is to have the capability of color. The conversion
factor between the two of 179 lumens/watt corresponds to uniform white light
over the visible spectrum. It does not include lamp losses or infrared and
ultraviolet radiation, as do other luminous efficacies, and is purely for
conversion purposes. I could pick almost any value I like, as long as I use
it consistently to go back and forth between radiant and luminous units.
-Greg
----------------------------------------------
{ BEGIN tumblin.cal }
{
Mapping of Luminance to Brightness for CRT display.
Hand this file to pcomb(1) with the -f option.
The picture file should have been run previously through
the automatic exposure procedure of pfilt(1), and
pcomb should also be given -o option. Like so:
pfilt input.pic | pcomb -f tumblin.cal -o - > output.pic
If you are using pcomb from Radiance 1.4, you will have
run without pfilt and set the AL constant manually. If
you are using a pcomb version before 1.4, you will have
to do this plus change all the colons ':' to equals '='
and wait a lot longer for your results.
Formulas adapted from Stevens by Tumblin and Rushmeier.
29 May 1993
}
PI : 3.14159265358979323846; { Hmm, looks familiar... }
LAMBERT : 1e4/PI/179; { Number of watts/sr/m2 in a Lambert }
DL : .027; { Maximum display luminance (Lamberts) }
AL : .5/le(1)*10^.84/LAMBERT; { Adaptation luminance (from exposure) }
sq(x) : x*x;
aa(v) : .4*log10(v) + 2.92;
bb(v) : -.4*sq(log10(v)) + -2.584*log10(v) + 2.0208;
power : aa(AL)/aa(DL);
mult = li(1)^(power-1) * ( LAMBERT^-power/DL * 10^((bb(AL)-bb(DL))/aa(DL)) );
ro = mult*ri(1);
go = mult*gi(1);
bo = mult*bi(1);
{ END tumblin.cal }
[And here is a response from Charles Ehrlich...]
Date: Wed, 31 Dec 69 16:00:00 PST
From: SMTPMcs%DBUMCS02%Servers[CEhrlich.QmsMrMcs%smtpmrmcs]@cts27.cs.pge.com
Subject: Kevin's email
To: greg@hobbes.lbl.gov, greg@hobbes.lbl.gov
Kevin,
You have stumbled on (or rammed into) one of the most sticky issues
related to renderings and visualization. I catagorize it as "How does the
eye measure light?" I would like to share with you my understanding of
the situation.
Radiance is based on the idea of Scientific Visualization...the very
same kind of algolrhythms and techniques used to take measurements
of any other kind of real-world physical data like the density of earth
from sonic echos or cloud coverage from radar imaging, are used to
represent visual data. The only difference is that Radiance happens to
be best at measuring a physical quantity that we all are very familiar
with...light. As a proof of concept, display a radiance image on screen
with ximage, position the cursor somewhere in the image, and press
the "i" key. Notice the bands of color appear. This is a "False-Color"
image, just another way of displaying luminance values different than
the way our eye "measures" luminance values.
2. Very little is known about the way our eyes actually measures light.
Radiance doesn't try to figure this out to the Nth degree. It uses an
approximation technique that is similar to the technique used by the
color photographic process (none in particular.) When you say that
your image appears too bright, this is because, indeed, that is the way
a camera would represent the same scene on a photograph. Really!
I've proven it to myself. Alternatives to the linear, photographic
mapping technique exist, but are not refined (look in the ray/src/cal/cal
directory for tumblin.cal). More work needs to be done that involves
emprical studies of human response. In my opinion, a gamma correction
comes closer to the way the human eye preceives light than a linear
mapping. I've asked greg to build into ximage a way of displaying images
with gamma correction, and to build into pfilt a reversible gamma
correction facility (so that the original, linear values of the image
file can be retreived.) He does not want to do this because indeed, the
eye does not do "gamma correction." I believe that once it is figured
out what the eye does, he'd be happy to implement that algolrhythm. For
the time being, I use Adobe Photoshop to make the image look more realistic, if
I'm less concerned with accuracy or design.
2.a. Radiance image files store many more magnitudes of luminance
values than a photograph or a computer monitor can reproduce. How the
eye processes these out-of-range luminance values is still largely
unknown.
For the lighting designer, or concerned informed architect using Radiance,
what it should tell you when you've created a scene that you judge to
have "light sources that are too bright" is that you need better light
sources...ones with a better cutoff angle and/or higher specularity
grating and/or VDT grade luminaires. You could also try an indirect
lighting solution that makes the ceiling surrounding the light fixtures
bright so that the CONTRAST RATIO between the light fixtures and the
wall is not so great, effectively reducing the perceived brightness of
the light fixtures. You could also try using a brighter colored carpet
so that more light gets reflected onto the ceiling if an indirect (uplighting)
solution does not work for you. Note: changing the brightness of your
carpet from 5% to 10% doubles the amount of reflected light!
I haven't seen the particulars of your scene and I don't know how you're
calculating your images, but make sure you're doing an indirect (-ab>0)
calculation to initially set the -av value if you're using direct fixtures.
If you're using indirect fixtures, then you're whole calculation should
be an indirect one (-ab>=1). To set the -av value, set up a .rif file for
rad to calculate an interactive (rview) image with ambient bounces.
Pick a point in the scene once the image is fairly well refined that you
think represents the average ambient value in the shadows of your scene.
Rview will report something like:
ray hit such_and_such_surface surface_type surface_mat
at point (x.xxxxx, y.yyyyyy, z.zzzzzzz)
with value (r.rrrrrr, g.gggggg, b.bbbbbb).
This last value is the luminance at that point. Write it down and try
a few other places in the scene. Unless you want colored shadows,
average each value with the function (.3*Red+.59*Green+.11*Blue),
which is the function for the eye's (and Radiance's) average brightness
given the three primary colors. Use the resulting value in subsequent
calculations of rview or rpict for all three coordinates of -av.
I believe that, the difference between the luminous efficacy of your
fixtures has little to do with pfilt exposure settings. It has everything
to do with the description of your fixtures from within radiance. I
assume that you're using some kind of low pressure sodium fixture that
has less white in it? I believe that you should be adjusting you're
fixture's intensity such that it matches that of white light using the same
function above (verify this with Greg). Very little work has been done
(to my knowledge) with different colored light sources and what to do
with them once an image has been calculated (how to average them so
that the image "looks" accurate.) Again, this depends upon how the
eye funcitons and I suggest using Adobe Photoshop if you must use colored
light sources. For the most part, unless you're using multiple types of
light source colors (low pressure sodium and incandescent) you should
just assume that the lights are white. If you're talking about the
difference between a good tri-phosphor fluorescent light and daylight,
I'd say you're wasting your time, unless the difference between these
sources is what is important to you. Most people find the orange hue
of daylight film used in incandescently lighted places to be anoying. The
same goes for the bluish tint one finds with tungsten film used in
daylighted spaces. Again, we do not know exactly how the eye responds to
light, especially when it involves great contrasts, and when it involves
multiple colors of light. Even if we did, Radiance uses only three samples
of the spectrum...which is not enough to accurately describe what is
going to happen to the light from a light source with all sorts of spikes
and valleys in its spectrum when it gets mixed together with other
spectrally diverse sources in a scene. And furthermore, I know of n
commercially available computer monitor or photographic film with more
than three colors of phosphors or dyes. But, who knows, maybe there's a
Radiance-16 out there with 16 samples of the spectrum. (don't hold you're
breath.) But then again, even HDTV only has three colors of phosphors.
But, you say, the eye only has three "colors" of receptors. I say that I've
never seen a computer monitor that can display "fluourescent," day-glow
orange, purple or green. Why?
-Chas
chas@hobbes.lbl.gov
Date: Tue, 15 Jun 93 16:35:46 PDT
From: greg (Gregory J. Ward)
To: chas, kevin@sigma.hella.de
Subject: remarks on Chas' remarks
Hi Kevin (and Chas),
I agree with everything Chas had to say (as far as I can remember!).
I did forget to mention gamma correction. Gamma correction is called that
because most CRT-based display systems exhibit a natural response curve
that to reasonable approximation follows a power law, ie:
display_luminance = maximum_luminance * (pixel_value/255)^gamma
The gamma correction done by ximage and the other converters is
designed to compensate for the built in response function of the
display monitor or output device, but it can be used to increase or
decrease contrast if desired as well. For example, your monitor may
have a gamma value of 2.6 (typical). If you want to display an image
with artificially increased contrast (eg. for more vibrant colors), you
can intentionally underrate the gamma with ximage, (eg. ximage -g
1.5). Similarly, you can artificially decrease contrast by overrating
the gamma (eg. ximage -g 3.2).
To find out what the actual gamma of your monitor is, you can look at the
image supplied in ray/lib/lib/gamma.pic like so:
ximage -g 1 -b gamma.pic
Set your monitor to normal brightness and contrast, then match the display
on the left with the grey scale on the right. The corresponding number is
the correct gamma value for this monitor under these settings. Rather than
setting the gamma with the -g option in ximage all the time, you may then
define the environment variable GAMMA to this value, ie:
# In .login file:
setenv GAMMA 2.6
: Or, in .profile:
GAMMA=2.6
export GAMMA
This has the added advantage of setting the gamma value in rview, which
doesn't have a -g option.
If you have an SGI, I should mention that the way they handle gamma correction
is a bit screwy. There is a system-set gamma value that neither indicates
the actual gamma of the graphics display nor does it completely correct for
the natural gamma of the monitor, but leaves the combined system
response somewhere between linear and the natural curve in most cases.
For example, the system gamma is usually set to 1.7. What this means is that
if the monitor's natural response was around 1.7, then the graphics system
has fully compensated for this and the response function is now linear.
In fact, the monitor's gamma is larger than this, and the combined response
ends up being around gamma=1.2, which is to what you should set the GAMMA
environment variable.
Hope this is more help than confusion...
-Greg
To: greg@hobbes.lbl.gov, chas@hobbes.lbl.gov
Subject: Hello
Date: Thu, 24 Jun 93 18:09:48 +0100
From: Kevin Jay marshall
Greg and Chas,
I wanted to write again and thankyou for all your help and to
fill you in on all the results of the test that we made the
other day. What we first did was to measure actual headlights on a car
from one of the employee's here, then what we did was to take a picture
of the car at night of what the car's headlights on the road actually
look like. Then we took that data and simulated the headlights using
Radiance. That was when I had the problem of how to use pfilt
correctly, which I still cannot do. But thanks to the two of you and
some experimenting of my own I understand why it is currently
impossible to get the exact picture I am looking for to be the exact
picture that my boss is looking for and so on. I also have come to
respect the job that is trying to be accomplished by the pfilt
program. But to continue on. So we created some pictures and then
yesterday I had the opportunity to accompany my boss to the light
channel here at Hella to see the actual headlights that were created
from all this theoretical data. The results were excellent. My
picture looked exactly like the real lights shown on the road, except
for the brightness. I think the part my boss likes best is the ability
to compute a rough picture, which is enough to get a clear idea of the
distribution on the street, in about 5 to 10 minutes. Well anyway I
thought you might be interested in the results.
-Kevin
Date: Thu, 24 Jun 93 09:35:09 PDT
From: greg (Gregory J. Ward)
To: kevin@candela.hella.de
Subject: Re: Hello
Cc: chas
Hi Kevin,
I'm glad you got it to (sort of) work. Like we told you, more sophisticated
brightness mappings are possible with pcomb, but you have to know what you
are doing, I think, to get good results.
-G
Date: Wed, 31 Dec 69 16:00:00 PST
From: SMTPMcs%DBUMCS02%Servers[CEhrlich.QmsMrMcs%smtpmrmcs]@cts27.cs.pge.com
Subject: Hella headlight study
To: greg@hobbes.lbl.gov
Kevin,
I'm very encouraged to hear that your simulation worked!! How much
time have you spent learning Radiance all together?
Regarding the fact that the brightness of the image (presumably around
the location of the headlights or where the beam hits the road) did not
match the physical simulation...did you take any luminance measurements
and correlate those with the luminance predicted by Radiance (using
the "L" command within ximage?) I think that doing that might just
convince your boss what Radiance is all about...namely that the
pretty picture you get is just a by-product of the time-consuming,
physically-based calculations going on behind the scenes.
-Chas
=======================================================================
PARALLEL RADIANCE AND ANIMATIONS
From: matgso@gsusgi1.gsu.edu (G. Scott Owen)
Subject: Re: parallel radiance
To: greg@hobbes.lbl.gov (Gregory J. Ward)
Date: Mon, 21 Jun 1993 13:44:35 -0500 (EDT)
Greg,
Has the parallel version of radiance been released yet? We were thinking
of adapting Radiance to the PVM (Parallel Virtual Machine- see article in
latest IEEE Computer)) environment. What do you think of this idea?
Scott Owen
Date: Tue, 22 Jun 93 15:58:01 PDT
From: greg (Gregory J. Ward)
To: matgso@gsusgi1.gsu.edu
Subject: Re: parallel radiance
Hi Scott,
Although I still have not received permission to distribute the next
release, I have made a beta copy of the software for you to test in
the /xfer directory on the anonymous ftp account on hobbes.lbl.gov, in
the file "4owen.tar.Z". Check out the manual page for "rpiece" in
ray/doc/man1. Usage is a little awkward, so don't be shy with your questions.
I picked up a copy of the article from IEEE Computer, but haven't taken
the time to read it through carefully, yet. It seems like a really good
approach.
The approach I have taken is more simple-minded, but shares
the advantage of running in a heterogeneous environment. In fact,
all I require is NFS and the lock manager to coordinate multiple
processes. The host processors may be on one machine, on many machines
distributed over the network, or any combination thereof. Each processor
must either have exclusive access to enough memory to store the entire
scene description, or must share memory with other processors that do.
If you want to do animations, you can run separate frames on the
separate machines, rather than dividing up each frame, which is
technically more difficult. At the end of this letter I have put a
couple of files that might make your animation work easier. Using the
"view" command within rview, you may write out a list of key frames,
one after another, in a walk-through view file, like so:
: v walk.vf -t N
Where "N" is replaced by the number of seconds that you assumed has passed
since the previous keyframe (for the first keyframe, just enter 0). After
you have all the keyframes you want in the view file, simply run the mkspline
command on that file, writing the result to a .cal file:
% mkspline walk.vf > walk.cal
Then, you may use rcalc to compute any frame desired from your animation:
% rcalc -n -f walk.cal -f spline.cal -e 't=10.3' -o view.fmt >10.3.vf
Or, generate the entire sequence:
% cnt 1000 | rcalc -f walk.cal -f spline.cal -e 't=Ttot/999*$1' \
-o view.fmt | rpict -S 1 -vf start.vp -x 1000 -y 1000 \
[more options] -o frame%03d.pic {octree} &
You should also be aware of the pinterp program, which can greatly speed up
renderings of walk-through animations. (Ie. animations where no objects
are in motion.) Since I have never gotten around to making an animation
rendering program, I would strongly recommend that you show me your scripts
before running any long renderings on your machines. I could potentially
save you a lot of compute time with a little appropriate advice.
-Greg
----------------- BEGIN "spline.cal" ------------------
{
Calculation of view parameters for walk-throughs.
Uses Catmull-Rolm spline.
09Feb90 Greg Ward
Define:
T(i) - time between keyframe i and i-1
Input:
t - time
Output:
s(f) - spline value for f at t where f(i) is value at T(i)
}
s(f) = hermite(f(below), f(above),
(f(above)-f(below2))/2, (f(above2)-f(below))/2,
tfrac);
tfrac = (t-sum(T,below))/T(above);
Ttot = sum(T,T(0));
below = above-1;
above = max(upper(0,1),2);
below2 = max(below-1,1);
above2 = min(above+1,T(0));
upper(s,i) = if(or(i-T(0)+.5,s+T(i)-t), i, upper(s+T(i),i+1));
sum(f,n) = if(n-.5, f(n)+sum(f,n-1), 0);
or(a,b) = if(a, a, b);
min(a,b) = if(a-b, b, a);
max(a,b) = if(a-b, a, b);
hermite(p0,p1,r0,r1,t) = p0 * ((2*t-3)*t*t+1) +
p1 * (-2*t+3)*t*t +
r0 * (((t-2)*t+1)*t) +
r1 * ((t-1)*t*t);
--------------- END "spline.cal" --------------------
--------------- BEGIN "mkspline" ----------------------
#!/bin/csh -f
#
# Make a .cal file for use with spline.cal from a set of keyframes
#
if ( $#argv != 1 ) then
echo Usage: $0 viewfile
exit 1
endif
cat <<_EOF_
{
Keyframe file created by $0
from view file "$1"
`date`
}
_EOF_
foreach i ( Px Py Pz Dx Dy Dz Ux Uy Uz H V T )
echo "$i(i) = select(i,"
rcalc -i 'rview -vtv -vp ${Px} ${Py} ${Pz} \\
-vd ${Dx} ${Dy} ${Dz} \\
-vu ${Ux} ${Uy} ${Uz} \\
-vh ${H} \\
-vv ${V} \\
-vs 0 -vl 0 -t ${T}' \
-o ' ${'$i'},' $1 | sed '$s/,$/);/'
end
--------------- END "mkspline" --------------------------
--------------- BEGIN "view.fmt" ------------------------
rview -vtv -vp ${Px} ${Py} ${Pz} \
-vd ${Dx} ${Dy} ${Dz} \
-vu ${Ux} ${Uy} ${Uz} \
-vh ${H} -vv ${V}
--------------- END "view.fmt" ------------------------
=================================================================
AMIGA PORT
Date: Tue, 13 Jul 93 13:09:05 MED
From: bojsen@id.dth.dk (Per Bojsen)
To: GJWard@lbl.gov
Subject: Reorganized hobbes.lbl.gov:/pub/ports/amiga
Hi Greg,
I've reorganized the /pub/ports/amiga directory on hobbes.lbl.gov. I
deleted the old files there and put some new files up instead. I
broke the big archive up into a few pieces and replaced the binaries
with new versions. I hope it's ok with you!
--
Per Bojsen The Design Automation Group Email: bojsen@ithil.id.dth.dk
MoDAG Technical University of Denmark bojsen@id.dth.dk
=======================================================================
PVALUE
Date: Sat, 17 Jul 93 22:42:00 EDT
From: "Yi Han"
To: greg@hobbes.lbl.gov
Subject: question
Hi Greg, I have installed your RADIANCE program. I just have a quick question
for you. Is there a way to find out luminance and radiance on all pixels of
the picture? It is like the function of press and "l" keys in ximage.
But I don't want to do it pixel by pixel.
Thank you very much for your help.
Yi
Date: Mon, 19 Jul 93 09:28:34 PDT
From: greg (Gregory J. Ward)
To: yihan@yellow.Princeton.EDU
Subject: Re: question
Yes, you can use the "pvalue" program to print out the color or gray-level
radiance values. For the spectral radiance values, pvalue by itself or with
the -d option (if you don't want the pixel positions). For the gray-level
radiance values use the -b option (with or without -d). For the luminance
values, take the radiance values and multiply them by 179. You can do this
with rcalc, like so:
% pvalue -h -H -d -b picture | rcalc -e '$1=$1*179' > luminance.dat
-Greg
==============================================================
BACKGROUND COLOR
Date: Mon, 18 Oct 93 20:28:48 -0400
From: David Jones
To: greg@hobbes.lbl.gov
Subject: setting background to something other than black ?
Hi Greg,
I am putting together a rendering of a geometric model
for a presentation and I want the background to be a
dark royal blue, instead of black. That is, whenever the
traced ray goes off to infinity without intersecting a surface,
I want it dark blue.
I know this can be done in an elegant way, but I cannot figure it out.
Can you tell me?
of course the slides need to be ready by tomorrow ....
dj
Date: Tue, 19 Oct 93 09:33:06 PDT
From: greg (Gregory J. Ward)
To: djones@Lightning.McRCIM.McGill.EDU
Subject: Re: setting background to something other than black ?
Just use a glow source, like so:
void glow royal_blue
0
0
4 .01 .01 .3 0
royal_blue source background
0
0
4 0 0 1 360
-Greg
==================================================================
DEPTH OF FIELD
Date: Fri, 29 Oct 93 12:50:40 PDT
From: djones@mellow.berkeley.edu (David G. Jones)
To: gjward@lbl.gov
Subject: optics and radiance
Hi Greg,
I am unsure how accurate RADIANCE can model certain optical effects.
For example, what about blur ?
Can I "build" a simple "camera" inside RADIANCE and "view" the
image plane?
I might build a scene and build a camera in this scene, with a
"thin lens" from "glass" and place an iris of a certain diameter
in the middle and view the "image plane" behind the lens ?
Would this work? Would it give be the appropriate blur for the
iris diameter?
What if I have two "irises" displaced from the optical axis?
This is in fact what I really want to model. Any hope in heck of this
working in RADIANCE?
dj
Date: Fri, 29 Oct 93 14:09:14 PDT
From: greg (Gregory J. Ward)
To: djones@mellow.berkeley.edu
Subject: Re: optics and radiance
Hi David,
Radiance does not directly simulate "depth of field," but it is possible to
approximate this effect through multiple renderings with slightly different
view parameters by summing the resulting pictures.
All you do is pick a number of good sample viewpoints (-vp) on your
aperature (or iris, as the case may be), then set the -vs and -vl view
options like so:
vs = s / (2*d*tan(vh/2))
vl = l / (2*d*tan(vv/2))
where:
d = focal distance (from lens to object in focus)
s = sample shift from center of aperature (in same units as d)
l = sample lift from center of aperature
vh = horizontal view angle (-vh option)
vv = vertical view angle
Then, sum the results together with pcomb, applying the appropriate scalefactor
to get an average image, eg:
pcomb -s .2 samp1.pic -s .2 samp2.pic -s .2 samp3.pic \
-s .2 samp4.pic -s .2 samp5.pic > sum.pic
Let me know if this works or you need further clarification.
-Greg
P.S. You can start with lower resolution images, since this averaging
process should be an adequate substitute for reducing (anti-aliasing) with
pfilt.
==================================================================
A COMPANY CALLED RADIANCE
Date: Tue, 2 Nov 93 16:55:47 PST
From: ravi@kaleida.com (Ravi Raj)
To: GJWard@lbl.gov
Subject: A company called Radiance Software
Greg,
I am a partner in a company called Radiance Software. Radiance was
formed as a partnership in January of this year and the company
develops a low-cost modeling and animation system called Movieola.
The product at the moment runs only on SGIs but is expected to be
ported to Sun, HP and IBM by middle of next year. Version 1.0 of
the product is expected to ship in February next year.
I've heard a lot about your ray tracing product called Radiance.
I haven't really used it yet but am planning on downloading your code
and checking it out on an SGI. Believe it or not, when we formed
a partnership called Radiance Software, it never occurred to
us that there might be a rendering product called Radiance.
We are planning on incorporating Radiance Software soon. Would you or
Lawrence Berkeley Labs mind your product name being used as a company
name by a company that develops a modeling/animation system? We'd
really appreciate hearing from you one way or the other. Please
reply via e-mail or call Lee Seiler at (510) 848-7621.
Many Thanks!
Ravi
Date: Wed, 3 Nov 93 14:55:42 PST
From: greg (Gregory J. Ward)
To: ravi@kaleida.com
Subject: Re: A company called Radiance Software
Hi Ravi,
Well, well. You know there is also a rendering program called "Radiant" and
some other product called "Radiance." Neither one is very popular as far
as I know, but the crowding of names in such a short lexicographical space
is a bit confusing. Radiance (our software) has been around for a good
5 or 6 years, so having a company by the same name could confuse a lot
of people. I appreciate your asking me about it, though.
Since rendering is in some sense complimentary to modeling and
animation, perhaps your company would like to take advantage of this
happenstance by becoming a distributor of our software? We are in the
process of setting up a licensing arrangement to make this possible,
and the fee should be quite reasonable. At any rate, I would appreciate
it if you do check out the Radiance renderer and tell me what you think.
(You might want to wait a few days for me to prepare the next release,
version 2.3.)
-Greg
Back to Top of Digest
Volume 2, Number 5, Part 2
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.