~s Radiance Digest, v2n8 (Part 1) Dear Radiance Users, Here is a long-overdue digest of mail between myself and some of you, dating back to October of last year. Because I've been so derelict in my moderator's duties, I had to break this into two parts since one part exceeded the 100K limit on many mailers. The second part, however, consists of just one discussion, which is rather long-winded and highly speculative. I figured there would be only a few people interested in that one, so I put it in a separate, ready-to-delete message. As usual, the digest is broken into easily searched topics. This message contains discussions on the following topics: DAYLIGHT CALCULATIONS - Daylight and sky simulation RADIANCE PORTS - Ports to the Amiga and Macintosh RENDERING PARAMETERS - Q&A on rpict and rad parameters SGI BUG - Core dumps on IRIX 5.x RADIANCE VS. POV AND RENDERMAN - Crude analysis of program diff's MIRROR ABUSE - What happens in a perfect funhouse? RETROREFLECTIVE SURFACES - Modeling retroreflection COLOR AND REFLECTANCE - CIE -> RGB and reflectance models GEOMETRIC MODELERS - What to use with Radiance? LENSES - Correct modeling of caustics HERMITE CUBIC FUNCTIONS - How to specify Hermite curves AMBIENT BOUNCES - Sorting out some test results BUMP MAPS - Converting height-field to texdata Enjoy! -Greg ======================================================================= DAYLIGHT CALCULATIONS From: kathrin schwarz Subject: radiance To: greg@hobbes.lbl.gov Date: Fri, 7 Oct 94 10:35:58 MEZ Dr. Ward, we have a short and simple question: How do we get the direct irradiance and diffuse irradiance in W/m/m in Radiance 2.3 ? Thanks Kathrin and Christof Date: Fri, 7 Oct 94 09:07:29 PDT From: greg (Gregory J. Ward) To: kathrin@prehp.physik.uni-oldenburg.de Subject: Re: radiance Radiance computes only total irradiance, using the -I or -i options of rtrace. If you wish to separate "direct and diffuse" for daylight calculation purposes, you must perform two calculations using different executions of gensky. For direct only, you must remove the sky source description and/or turn the interreflection calculation in rtrace off by setting -ab 0 -av 0 0 0. For diffuse only, you can use the -s option of gensky to remove the sun source, or simply do a full calculation and subtract the direct component computed above. I hope this makes some sense. I realize that it is confusing. The chief difference between Radiance and other lighting programs is that Radiance will not calculate anything that cannot be measured. Direct only and diffuse only portions can only be approximately measured by shading the photosensor from the solar direct. You can do this in Radiance also by creating a small shield in front of the sun source, if you like. -Greg Date: Sun, 19 Feb 95 15:22:41 CST From: sabol@zen.wes.army.mil (Bruce Sabol) To: greg@hobbes.lbl.gov Subject: Generating sky in RADIANCE Greg: I'm involved in a forestry remote sensing project in which we're trying to use RADIANCE to generate false color scenes of a natural forest in LANDSAT Thematic Mapper Bands (#2:0.52-0.62um {mapped to blue}, #3:0.63-0.69um {mapped to green}, and #4:0.75- 0.88um {mapped to red}). I need to better understand how GENSKY functions in order to set the direct solar flux and diffuse skylight in these bands. To assist in determining direct and diffuse irradiance values in these bands I'm using the atmospheric model LOWTRAN7. Below is an example .RAD file output from GENSKY, with some added documentation comments, followed by some questions. ------------------------------------------------ # Howland Maine 9/8/90 11 AM clear sky # gensky 9 8 11 +s -a 45.2 -o 68.75 -m 75 # Solar altitude and azimuth: 49.7 -12.8 # Ground ambient level: 18.3 # turbidity set at default value of 2.75 void light solar 0 0 3 6.88e+06 6.88e+06 6.88e+06 # (watts/rad sq/sq m) solar source sun 0 0 4 0.142792 -0.630758 0.762728 0.5 void brightfunc skyfunc 2 skybr skybright.cal 0 7 1 1.33e+01 2.37e+01 6.53e-01 0.142792 -0.630758 0.762728 # end GENSKY output, begin my add-ons skyfunc glow skyglow 0 0 4 0.03 0.4 1.0 0.0 # rgb radiance (w/rad^2/m^2), max radius # values set to look right - no physical basis for selection skyglow source sky 0 0 4 0 0 1 180 -------------------------------------------------------- Questions: 1. Direct Solar Flux. Turbidity was systematically manipulated from 1 to 10. Zenith brightness (variable A2 in skybright.cal) and ground plane brightness (variable A3) both increase with turbidity as expected. However, the RGB solar values were constant (at 6.88e+06) for all bands for all turbidity values. This was unexpected - as aerosol turbidity increases diffuse irradiance increases and direct solar flux decreases. Where does the value 6.88e+06 come from and why is it the same across all 3 bands and for all turbidity values? This is considerably higher than the red green or blue direct irradiance estimates from LOWTRAN7, although it is very close to the broadband visible radiance (0.4-0.7 um) value predicted by LOWTRAN7. Where should I be substituting in estimates of direct spectral flux in other bands? 2. Diffuse Irradiance. How is A2 (1.33e+01 in example above) computed and what does it represent? It appears very close to zenith sky irradiance in the visible band (0.4-0.7um) predicted by LOWTRAN. How does (or should) it relate to RGB values in skyglow? Should the spectral irradiances (RGB) be summed to equal A2? Any help you can give me on these questions would be greatly appreciated. Regards Bruce Sabol U.S. Army Waterways Experiment Station Environmental Laboratory 3909 Halls Ferry Rd. Vicksburg, MS 39180 sabol@zen.wes.army.mil Date: Tue, 21 Feb 95 12:20:05 PST From: greg (Gregory J. Ward) To: sabol@zen.wes.army.mil Subject: Re: Generating sky in RADIANCE Hi Bruce, In order to better understand the ouput of gensky and its meaning, you should refer to the file "skybright.cal" in the src/gen directory, which should be duplicated also in your Radiance library directory (wherever that is). I assume you have done this already, based on the questions you posed. Let me start by saying that I have little confidence in the sky or solar luminance calculations of gensky. They are based on some simple rule-of-thumb calculations and mean sky measurements taken years ago. If you are serious about your sky model (and it appears that you are), you should insert your own values for sky and solar luminance via the -b and -r (or -B and -R) options to gensky. This will override the turbidity calculation for zenith luminance, which as you noted, does not affect solar luminance as it ought. If you have access to LOWTRAN, I would recommend that you stick with its calculations for the relevant luminances. You will find even that the CIE- recommended model for clear and overcast skies is not very accurate. It is used more as a standard for calculation than anything else. There are better sky models floating about, but no official groups have yet gotten together and put their stamp of approval on them. Luminance can be computed from spectral radiance in Radiance with the approximate formula: cd/m^2 = 179 lumens/watt * (.265*R + .670*G + .065*B) Note that the default output of gensky is achromatic. This is simply so that renderings come out white-balanced. Since most people are after a picture rather than 4 digit accuracy, this is the default. The meaning of red, green and blue in Radiance is somewhat vague, and this is intentional. You can in fact define these to be whatever you want. If you wish that they represent integrated spectral power from lambda1 to lambda2, then that's what they represent. Of course, you have to figure out what to do with the pictures produced, as well as how to set the material reflectances appropriately, but the calculation is the same. Let me know if I can be of any more assistance. You might also try looking through the back issues of the Radiance digest, available by anonymous ftp from hobbes.lbl.gov in the /pub/digest directory, or conveniently indexed from our WWW site: http://radsite.lbl.gov/radiance/HOME.html -Greg Date: Mon, 27 Mar 1995 13:26:25 +0200 (MET DST) From: Maus Sender: Maus Subject: green-house questions To: greg@hobbes.lbl.gov Hi Greg, I'm trying your Radiance package to measure light efficiency in greenhouses under cloudy sky conditions. I'm specifically interested in the ratio between the light measured in a point just above the greenhouse and the light measured in a number of points 2 meters above the ground inside the greenhouse. I have some questions considering these simulations. Plants respond to the same portion of the spectrum as the human eye. But the human eye reponds best to green-yellow light while plants respond best to red-orange light. Furthermore,the response curve of the human eye is more or less a Gaussian curve while the responsecurve of a plant follows a saw-tooth. Am I right to say that I should not measure luminance like (.3*r + .59*g + .11*b) {watts} * 470 {lumens/watt} but substitute the rgb multipliers by other values to measure the light plants like best? How, thereupon, should I measure this specific light in points two meters above the ground? What exactly is the use of specifying a groundglow in addition to a skyglow. Is it to simulate reflection of light by air molecules? I read once that for glass, the 8% difference between 96% (transmission through the medium itself) and 88% (transmissivity) is due to reflection, and it varies with incident angle. Does this mean the 88% is a mean percentage for all possible angles of incidence, in other words, is it the percentage of light coming through the glass under diffuse lighting conditions ? (the conditions I'm interested in). Regards, Maurice Bierhuizen. Date: Mon, 27 Mar 95 09:26:14 PST From: greg (Gregory J. Ward) To: M.F.A.Bierhuizen@TWI.TUDelft.NL Subject: Re: green-house questions Hi Maurice, You are correct that you should not use photometric units (luminance or illuminance) to gauge the amount of plant-food light in a space. I don't know what factors you should use. However, it really doesn't matter unless your glass is tinted, because light is transmitted evenly over the visible spectrum for clear glazing. The 88% transmittance value is at normal (i.e. perpendicular) incidence, and the amount transmitted will decrease at higher incident angles. Radiance accounts for this variation, and asks that the user specify the transmission (amount of light not absorbed in one pass through the material) at normal incidence and (optionally) the index of refraction for the glass type. The ground glow accounts for light reflected from the ground towards the horizon, assuming that you have some local geometry for the ground in the vicinity of your model. It is not advisable in Radiance to specify the entire Earth as local geometry, as the difference between the largest and smallest object is then too great for the octree structure to manage. I hope this helps, and I wish you luck with your investigation. I assume you are using rtrace in your calculations. -Greg [P.S. I have been having a long discussion with Tony Yuricich about an advanced sky model he's been working on, and hopefully he will provide some code for us all in the coming months. I didn't include that conversation here because it was very specific and went on and on.] ======================================================================= RADIANCE PORTS Date: Thu, 20 Oct 1994 03:32:28 -0400 From: DWEINREBER@aol.com To: greg@hobbes.lbl.gov Subject: Disk space for Radiance I am a lighting designer in Nashville. I spoke with you on the phone a few months ago about Radiance. I am considering installing A/UX on my Centris 650 to run Radiance but I'm concerned about disk space. How much disk space is needed for Radiance? Are there any quirks or problems with running it under A/UX? Any plans on a PowerPC version? Thanks Dan Weinreber DWEINREBER@aol.com Date: Thu, 20 Oct 94 09:18:50 PDT From: greg (Gregory J. Ward) To: DWEINREBER@aol.com Subject: Re: Disk space for Radiance Hi Dan, A/UX itself requires about 120 Megs of disk space, and you should have at least 20 Megs of RAM installed to be comfortable. Radiance uses about 40 Megs of disk space on top of this, and I operate A/UX comfortably on a 160 Mbyte external drive. You can buy one from Apple with A/UX already installed, and it will save you some hassle (at the expense of a rather steep price per megabyte.) There are no quirks that I know of running Radiance under A/UX. Unfortunately, Apple does not plan to carry their A/UX product to the PowerPC platform, which to my mind is really ideally suited to it. Instead, they're going to let their former enemy, IBM, service the PowerMac with their persnickity AIX product. Radiance will run in this environment, but compiling it is a bit tricky because the compiler is so cranky. Also, AIX offers no access to your Macintosh applications, a key benefit of A/UX. I have no plans myself to port Radiance to the native Macintosh OS, though I just spoke yesterday with someone who might. It may happen, but not right away. -Greg Date: Sun, 30 Oct 94 00:35:30 +0100 From: Harald Backert To: greg@hobbes.lbl.gov Subject: Amiga port of Radiance 2.4 Hi Greg, maybe you remember me. I was the the one who wanted to port Radiance to the Amiga half a year ago. While my first attempt did not work as I expected (I was too busy trying to convert Radiance' K&R-C into ANSI-C, my fault). Then I concacted Per Bojsen in Denmark who made the first port and he told me that he will port a newer version of Radiance later. Well...half a year went by and nothing happened. So I started to compile Radiance again. And guess what: I now have a running and stable Radiance :-) I am going to upload my Amiga version to hobbes.lbl.gov including the slightly modified sources. I had to make small changes like inserting a '#include ' and the like. Now my question: I would like to upload a complete package of Radiance ready-to-run for Amigas. This includes the standard Radiance files, binaries and ASCII docs translated with 'nroff -man *.1'. And two support packages for pipes. May I? greetings, Harald Date: Sun, 30 Oct 94 07:40:16 PST From: greg (Gregory J. Ward) To: Harald.Backert@rz.uni-regensburg.de Subject: Re: Amiga port of Radiance 2.4 Hello Harald, Thank you for writing, and thank you for porting Radiance to the Amiga! In answer to your first question, please feel free to upload your complete Radiance package for the Amiga to the /pub/ports/amiga directory on hobbes.lbl.gov with a suitable title. I haven't checked write permissions on that directory, but if you have any trouble you can always upload it to the /xfer directory and tell me to move it. -Greg ======================================================================= RENDERING PARAMETERS Date: Wed, 2 Nov 1994 16:41:12 +0200 (METDST) From: Shaul Baruch To: Ward greg Hi Greg, I dont forward this to the discussion groupe because I dont think its so intersting to that forum. I have changed 2 parameters in my rpict bat file, in order to get a "cleaner" picture (more round contor lines of falsecolor). my old parameters were : -lr 8 -lw 0.005 -as 1024 -ad 512 -ar 4 -aa .1 -ab 4 -st .01 -ps 1 -dj .75 -pt .001 my new parameters are the same except for -aa .05 & -ab 6. With the old parameters together with a uniform cloudy sky and a 4x3 room with a skylight window (not using illum function), it took about 10 hours to generate a picture. With the new parameters it took 48 hours to complete 94.68 % of the picture but then I got a message: system out of memory in doambient, Radiance stub failed. Can you tell me why this happened and if there is any way to check such thing in advance? What would be your advise , in order to get a better (but realistic) contour lines? by the way my PC has 16mB ram (12.5mB extended ram) best regards Shaul Date: Wed, 2 Nov 94 09:14:46 PST From: greg (Gregory J. Ward) To: novebaru@inet.uni-c.dk Hi Shaul, You ran out of memory because you are storing so many values. You should probably increase -ad to 1024 and reduce -as to 512, use -ab 3 instead of 6 and set -aa to .1. Unfortunately, there's no way to know in advance how long a rendering is going to take or how much memory it will use. You just have to learn from experience with your particular problems. It varies quite a lot from one scene to the next. I would also recommend that you set the -av parameter to something non-zero, for more accurate results. You can use a zonal cavity approximation to do this in most cases. It's a bit difficult to do this for daylighting situations, unfortunately, but the formula I recommend is: ambient_value = (Sum_i PHI_i)/(pi * A_total) * /(1 - ) where: Sum_i PHI_i = sum of all source output flux (in watts) A_total = total surface area of all surfaces = area-weighted average of surface reflectance -Greg [The following was culled from the discussion group list:] Date: Fri, 2 Dec 94 11:01:50 PST From: greg (Gregory J. Ward) To: crones@puffin.curtin.edu.au, radiance-discuss Subject: Re: Radiance farming. Hey folks, I don't know why your renderings are taking so long, but somehow I feel that I'm to blame. (Now why is that?) I've been doing a bunch of renderings myself, lately, and they do take a while but I don't think I'd ever wait 400+ hours for a single picture! The last high-quality 1000x700 (or so) picture I generated took about 10 hours on my SGI Indigo R4000, and it was a fairly complex space. Since I want to encourage people to use rad (and the new GUI trad), I feel I should give some appropriate hints on minimizing rendering time or at least understanding why a particular rendering is taking so darned long. As most of you know already, the indirect calculation in Radiance is what makes it special and also what can make it especially slow if you're not careful about how you apply it. Using rad, most of the so-called "ambient" parameters (-a*) are derived from the following variables. I have arranged their values in order of least to most costly in calculation time: QUALITY= Low Medium High INDIRECT= 0 1 2 3 ... VARIABILITY= Low Medium High DETAIL= Low Medium High In addition to the above rad variables, the PENUMBRAS variable if set to "True" will significantly slow down most renderings. The RESOLUTION setting also has some effect, though not as much as you would suppose. Also, setting the AMBFILE variable is generally a good idea, since it improves the results noticeably without increasing rendering time by much. In fact, for multiple renderings of the same scene, rad will proceed much faster with an ambient file. Now, let me explain a bit how the above variables affect calculation time. The QUALITY variable has the greatest effect on rendering time, which is why I listed it first. A low quality rendering NEVER uses the indirect calculation, regardless of the setting of the INDIRECT variable, unless overridden by the render options variable. (We'll discuss when you might want to do this a little later.) A medium quality rendering uses as many bounces as indicated by the INDIRECT setting, and a high quality rendering uses INDIRECT+1 bounces in its calculation. Even more significant is how the QUALITY variable changes all the other rendering parameters that affect accuracy. Since these changes are too numerous to list exhaustively, suffice it to say that there's a BIG difference between the times and results for different settings of the QUALITY variable. The next most important variable after INDIRECT, which controls the number of bounces in the calculation (along with the QUALITY setting as described above), is the VARIABILITY variable. This tells rad just how hard it is to compute the indirect component at any given point in the scene. If the variability is low, then we don't have to send as many samples around to figure out the indirect contribution. If VARIABILITY is set to medium, then we send about three times as many samples, and space our calculations more closely. If VARIABILITY is set to high (something I don't recommend unless you have direct sun penetrating your space), then about 1500 samples will be sent out at each calculation point, and there will be roughly 4 times as many of these points as there would be with a low setting. Therefore, all else being equal, you should expect a VARIABILITY=High calculation to take roughly 25 times as long as a VARIABILITY=Low calculation -- something to think about! Finally, the DETAIL variable has a modest effect on the calculation time, as it controls the "ambient resolution" calculation parameter, which determines the minimum spacing between indirect calculation points. A low detail sene means we can afford to limit our indirect value density to a modest level compared to a medium or high detail scene. The precise effect this will have depends on the geometry of the particular scene, but it generally doesn't have more than a 10 times effect moving from a low to a high setting. Unfortunately, the above information is not enough to predict how long a given rendering will take to complete. (The best indicator still is the time elapsed so far and how much has finished, as given by rpict's reporting facility.) However, there are some important scene-related factors that we should consider. The most important scene characteristic that affects rendering time is geometric detail. (Note that this would seem to contradict my placement of the DETAIL variable as the least important setting. While it is true that the setting of this variable has a minor effect, the ACTUAL scene detail has a rather major one. In other words, changing the DETAIL variable from "medium" to "high" might double the rendering time, but increasing the actual scene complexity will have a much greater effect.) This is because Radiance adjusts the calculation of indirect illumination to the local scene complexity, unlike most radiosity rendering algorithms. (Thus Radiance maintains accuracy with the minimum effort.) Increasing the number of do-dads and knick-knacks therefore increases the number of indirect calculation points required to maintain accuracy. A worst-case scenario for Radiance is something like a packed forest, where every pine needle is participating in the indirect calculation. In scenes of such complexity, a different approach is required, and that's when we bring in the render variable to override some of the settings determined by rad. In the worst-case of a forest given above, we would probably want to turn off the indirect value storage and interpolation altogether, and greatly reduce the number of sample rays sent out, i.e: render= -ab 1 -aa 0 -ad 10 -as 0 Here we are forcing a 1-bounce calculation (more than that would be painful), set -aa to 0 to turn off interpolation, and using just 10 samples over the hemisphere at each point. The resulting picture will be somewhat noisy, but a forest is not a visually quiet place, so chances are no one will notice. (And if a tree falls, no one will hear it.) The second, more common case encountered is one where most of the geometry is fairly plain, consisting of walls, furniture and the like, but parts of the scene are incredibly detailed, like rows and rows of books in an enormous bookcase. We want to use our indirect interpolation technique to get the smoothest possible results over most of the scene, but if we apply it also to the bookcase, our rendering will never finish. What you should do in such a case is employ the "ambient selection" options, -ae and -aE to explicitly exclude materials from the indirect calculation, or -ai and -aI to include them. (You can use only one set or the other.) Thus, you "remove" the offending objects from consideration (giving them the default -av ambient value), speeding the overall calculation. Since the objects removed have a large amount of geometric detail, the loss in illumination detail will probably go unnoticed. I use this technique all the time in my own renderings, and it is one of the chief tricks that make high-quality renderings tractable. (Ultimately, a better solution would be automatic geometric simplification, but the problems involved are nasty, nasty and nasty.) For example, let's say we had venetian blinds on the window that were slowing down our nighttime calculation. The material used for the blind slats is called "slat_mat". We would then add the following setting to our render variable: render= -ae slat_mat If there were other materials involved, we could list them in additional -ae options, or use an -aE "file" option, where the file contains a list of the appropriate materials. I hope this helps to shed some light on a very murky subject. -Greg P.S. In answer to Simon Crone's question about running rpiece more elegantly, I usually use the OPTFILE variable of rad to create a rendering options file, then apply that to rpiece, like so: % rad -n -s scene.rif OPTFILE=scene.opt % rpiece @scene.opt [other options] scene.oct & Date: Tue, 6 Dec 94 15:41:24 -0500 From: westin@dsg145.nad.ford.com (Stephen H. Westin) To: greg@hobbes.lbl.gov Subject: Radiance newbie question Greg, I'm finally trying to make some real pictures with Radiance. I'm struggling, though. My images are very speckly in what seems the specular component of a rough surface. Direct lighting is fine, but the (diffuse) reflection of the environment is extremely noisy. Which of the ninety-'leven parameters to "rpict" should I tweak? I have tried -pt, -st, -ab, and a couple of others I've forgotten. "-ps .2" gives the message rpict: fatal - command line error at '-ps' so I can't use that. I'll E-mail you a uuencoded image file; I'm sure it's something simple. The material I'm using is void metal CHAMPAGNE 0 0 5 0.7 0.641 0.58 1 .4 and yes, I know that you don't recommend a roughness greater than 0.2, but it doesn't seem to make a lot of difference. I'm trying to create some approximation of metallic paint, which gets its main color from metal and pigment particles suspended in the binder, but includes a clear coat that reflects in an ideal specular fashion. I haven't dug into this deeply enough to see if I can do this directly in Radiance; I would like a "metal" with a "plastic" or "glass" overlayed. By the way, it would be helpful if your documentation could be expanded; at least tell me what the default value is for each parameter, so I have some idea whether I've tweaked it or not. Any further elucidation as to the function of each would also help. -Steve 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 #include #include 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