Radiance Digest Volume 2, Number 8 (Part 1b)

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

Return to beginning of digest

Back to Top of Digest Volume 2, Number 8, Part 1b
Return to RADIANCE Home Page
Return to RADIANCE Digests Overview

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