~sRadiance Digest, v2n3 Dear Radiance Users, Here is the latest culling of mail messages from users with questions about Radiance. The topics are as follows: CYLINDER SOURCES What kind of cylinder may be a light source? GETTING STARTED Documentation and modeling without CAD NUMERICAL OUTPUT Calculating point illuminances PCOMPOS Overcoming pcompos input limits USER INTERFACE Advice on creating a user interface OCONV SET OVERFLOW What causes "set overflow" error in oconv? HEIGHT FIELDS How to use gensurf to create height fields COMPILATION QUESTIONS Problems compiling on NeXT and with GNU-C ANIMATION SPLINES Using Catmull-Rolm splines for camer animation RA_PICT Transferring output of ra_pict to Macintosh LIGHT SOURCES Problems with light sources HARTMANN CONSTANT What is it? SPOTLIGHTS Questions about spotlight type I hope you find the information useful. -Greg ============================================= CYLINDER SOURCES Date: Tue, 2 Jun 92 14:46:48 NZT From: pdbourke@ccu1.aukuni.ac.nz Subject: cylinders & lights To: GJWard@lbl.gov In section 2.1.2 of the Radiance manual in the section on materials and the light material you say... "..., cylinders (provided they are long enough),...can act as light sources. What exactly (or inexactly) does "long enough" mean? ------------------------------ Paul D. Bourke School of Architecture pdbourke@ccu1.aukuni.ac.nz Auckland University Date: Tue, 2 Jun 92 12:36:38 PDT From: greg (Gregory J. Ward) To: pdbourke@ccu1.aukuni.ac.nz Subject: Re: cylinders & lights Well, it's not a fatal error if the cylinder is too short, but cylinders in general are imperfect as light sources because I send a ray to the center of the object, and if it comes in axially, then it can pass right through the source. You will get warnings if your cylindrical sources are too short. I recommend a ratio of length to diameter of 4 or more. -Greg ========================================================= GETTING STARTED Date: Wed, 3 Jun 92 04:19:06 PDT From: logan%cs@hub.ucsb.edu (Bruns) To: GJWard@lbl.gov Subject: The "Radience Reference Manual" I printed out the Mac document files in which there are many references to said manual. Where could I obtain this from? Or do I already have it and don't know it? Also, I would appreciate any advice for people who do not have access to CAD. Currently I plan to write short C rountines which would create objects in various positions based upon input parameters. (for example I might have a program which would generate a flexible desk lamp and would accept parameters to determine relative positions of its pieces.) However, I am new to this and would appreciate any advice you could give me. Sincerely yours, Logan O'Sullivan Bruns Date: Wed, 3 Jun 92 14:16:09 PDT From: greg (Gregory J. Ward) To: logan%cs@hub.ucsb.edu Subject: Re: The "Radience Reference Manual" Hi Logan, The "Radiance Reference Manual" is distributed in the form of a troff document in the ray/doc directory. It is the file "ray.1" in that directory. There is also a short tutorial, called "tutorial.1". You should at least have nroff on your system, and you can print out these files like so: % nroff -ms ray.1 | lpr % nroff -ms tutorial.1 | lpr Most sytems also have a more sophisticated text formatter, such as ditroff or psroff or troff or some such. Ask your system administrator about how to get decent troff output. I wish I could offer some helpful insights to you about modeling without CAD. I have done it for many years myself, and it's not all that easy. You can get some distance using the Radiance generators (genbox, genrev, gensurf, genprism, etc) in conjunction with the scene transformer, xform. The Mac user's manual does a pretty good job describing how this is done. Best of luck! -Greg ============================================================== NUMERICAL OUTPUT [The following is in response to some faxed questions from Xabier Gorritxategi (good thing this isn't voice-mail) about using Radiance to compute values.] Date: Fri, 5 Jun 92 09:38:43 PDT From: greg (Gregory J. Ward) FAXnumber: 01134943796944 FAXto: "Xabier Gorritxategi, IKERLAN" Status: R Dear Xabier, I am glad that you have been using Radiance so successfully in your work. You can use the program "rtrace" to get numerical output, such as luminance and illuminance values, from numerical input such as point locations. Since Radiance uses radiometric units, such as radiance and irradiance, conversion is necessary if you want to get results in photometric units. This is: photometric unit = (.3*r + .59*g + .11*b) * 179 lumens/watt The value of 179 is the luminous efficacy of uniform white light, which is the default value used by programs that take photometric units and produce Radiance source descriptions (such as ies2rad and gensky). The three coefficients, .3, .59 and .11 are the relative contributions of the standard red, green and blue to luminance. (There is actually a slightly more accurate conversion stored in ray/src/common/color.h, but this more common approximation is good enough for most applications.) As an example of producing illuminance values at regularly spaced points on a 4x5 workplane, you might use the following command: % cnt 3 4 | rcalc -e '$1=$1+.5;$2=$2+.5;$3=1;$4=0;$5=0;$6=1' \ | rtrace -h -I [options] octree \ | rcalc -e '$1=179*(.3*$1+.59*$2+.11*$3)' > outfile Note that rcalc was used to massage both the input and the output to rtrace. Rcalc is a standard program distributed with Radiance, and it has quite a number of mathematical functions not found in the standard UNIX program "awk", plus it is easier to use. (I think.) Note that the output file will not contain the point locations. If you want them, you can add them with a post-process like so: % cnt 3 4 | rcalc -e '$1=$1+.5;$2=$2+.5' | lam - outfile > values Lam is another program distributed with Radiance, and it merely concatenates lines from multiple files (one of which is the standard input in this example). I hope that this helps you with some of the more esoteric features of Radiance. I want to make these sorts of calculations more straightforward for designers, if I can only get the funding from Washington, D.C. -Greg ========================================================= PCOMPOS Date: Thu, 11 Jun 92 9:16:29 NZT From: pdbourke@ccu1.aukuni.ac.nz Subject: question To: GJWard@lbl.gov Before I start pawing over the code can you give me an idea of how hard it might be to increase the maximum frames for pcompos from 32 to a larger number. I am creating 64x64 renderings as tests for animation flightpaths and it would be useful to be able to pcompos larger matrices, for example 10x10. ------------------------------ Paul D. Bourke School of Architecture pdbourke@ccu1.aukuni.ac.nz Auckland University Date: Thu, 11 Jun 92 12:18:03 PDT From: greg (Gregory J. Ward) To: pdbourke@ccu1.aukuni.ac.nz Subject: Re: question There is a macro called MAXFILE near the top of pcompos.c that you can easily change to be whatever you want. You may have another problem though if you run into the system limit on the number of open files a process can have. Another way to construct large matrices of images is of course to create several small matrices and put them all together with pcompos at the end. -Greg ================================================================ USER INTERFACE Date: Wed, 10 Jun 92 19:18:49 -0400 From: Jim Callahan To: GJWard@lbl.gov Subject: Radiance as a tool for Architecture I just recently acquired the 2.0 version of Radiance and was *very* impressed with it. I am interested in using this program to render some of my designs for school and thought you might have some experience with this sort of thing. Have you or others developed any generator programs which are specific to architectural design? Texture functions? Objects? If so, where can I find them? Also, I am in the process of developing a Graphic User Interface (GUI) to the oconv, rpict, pcompos, and pfilt programs using the InterViews C++ library written by Mark Linton of Stanford (it is available via anonymous at interviews.stanford.edu). Like you, he has developed a very powerful program and is willing to share it for free. We all owe you for your generosity. If you are willing, I'd like to distribute my interface at your site as soon as it is up and running (and bug free I hope). I may soon be purchasing a SGI machine if I can scrape up the money and my next project will be to write a 3d interactive "front end" for designing scenes. It would allow the user to design in 3d enviroment rather than using clumsy 2d orthagonal views and allow the construction of agregate object libraries. Radiance seems to be the best "free" tool for producing the final images I have seen. Could you suggest features/options that you would like to see in something like this. I would be willing to distribute this software for no charge. I believe that the best software is written by people who need a solution to a problem NOT by money hungry programmers. These kind of tools should be shared so that we can build on each others work (but I guess you don't need to be told all this). Once again, GREAT JOB! Thanks for the program and the help. - Jim Date: Sat, 13 Jun 92 09:48:35 PDT From: greg (Gregory J. Ward) To: jmc@ugrad.ee.ufl.edu Subject: Re: Radiance as a tool for Architecture Dear Jim, Thank you for your nice letter, and for your interest in our software. I have wanted for some while to work on a user interface for Radiance, but have had neither the time nor the funds to pursue it. Of course, I would be delighted if you would work on a GUI and make it available to people. The thing that I have found to be most important in distributing software is to make sure that there is a common base. In my case, that means UNIX and K&R C (boring as that may be). I have not played with the library you mentioned, partly because I don't get around the network much so I hadn't heard of it, and partly because I don't have and cannot afford a C++ compiler. (Actually, maybe the compiler's not so expensive, but I would have to buy a new machine to run it on!) There is much work to be done before Radiance is truly useful as a design tool, I think. The main problem is that it is too general a lighting simulation, and doesn't know a thing about architecture or architectural design. Radiance has no notion of human scale or what a door is or a window or a space. It only knows geometry and materials, placing all the burden of description and interpretation on the user. This may be all right for the user with time on his hands, but it's unacceptable for the practicing designer, who needs to talk to a design tool in his or her own language. That is what a user interface is all about. I need to get to work talking to practicing architects and designers so I can start to bridge this gap between design and simulation. I may not get to the graphical part of the user interface for some time. Most of my work will entail writing programs and scripts to perform particular design evaluation tasks and take some of the burden of description and interpretation off of the user. I'm not sure I'm even the best person to work on the final graphical user interface, so I am quite open to working with someone else on that part of it. I, too, have a lot of respect for people who work long and hard on a program for little or no money, then make it available for free to others. Many would even cast such people in the role of heroes, though I might not go that far. But I'm not one of those people. I was paid well for my efforts by the Department of Energy, and have been very lucky to work on something I enjoy and get money for it besides. The reason Radiance is "free" is because it has already been paid for by government taxes! I agree with you that programs are best developed by those who are very familiar with the task involved. I wish I knew more about lighting design and architecture for that reason. My hope is to get people like you to do the real work of user interface design for me, but I don't expect you to do it for nothing. You should expect some sort of compensation for your efforts. Don't devalue yourself. Programmers doing interesting work rarely make much money -- there's no reason for the MicroSofts and IBMs of the world to take it all with our consent. Even if you're not a money-grubbing bastard, you've still got to eat. The only models and programs that I have are on the hobbes.lbl.gov ftp server in the pub subdirectories. Help yourself, and please do add to our little collection if you can. -Greg P.S. Hobbes address is 128.3.12.38. Also note that Radiance is now in release 2.1. Where is everyone getting these outdated copies?! ======================================================= OCONV SET OVERFLOW From: phils@Athena.MIT.EDU Date: Mon, 15 Jun 92 11:59:43 -0400 To: greg@hobbes.lbl.gov Subject: overflow problem. Hi Greg, We're trying to trace a BIG model are getting the following error: <79> oconv -w sky.rad plot.rad > plot.oct oconv: internal - set overflow in addobject (poly12914) This is the Washington D.C. monumental core (about 21,000) polygons. But this is a BIG Vax 9000 with 500 meg. RAM so memory should not be a problem. Any ideas? Thanks, Philip Date: Mon, 15 Jun 92 09:34:06 PDT From: greg (Gregory J. Ward) To: phils@Athena.MIT.EDU Subject: Re: overflow problem. Hi Phil, The cause of this error is either many overlapping surfaces (ie. coincident), which would probably mean an error in the model, or that the enclosing global cube is too large with respect to the detail in the model. Check out the manual page for oconv. You can try increasing the octree resolution with the -r option. Set it to the maximum overall dimension of your scene divided by the size of a relatively small surface, and you should be OK. -Greg ====================================================================== HEIGHT FIELDS To: greg@hobbes.lbl.gov Subject: Gensurf file in Radiance Date: Wed, 17 Jun 92 09:45:31 EDT From: Gilbert Leung Hi, We are running your program Radiance and want to use the gensurf command. But there is little, if any then unclear, information about the coordinate files that gensurf reads. Can you send us some more details about this or at least point us to the right direction? A/some sample file(s) that gensurf reads will be great. Sincerely yours, Gilbert Leung To: greg@hobbes.lbl.gov Subject: freadscan vs freadcolr Date: Wed, 17 Jun 92 18:29:54 EDT From: Philip Thompson Hi, I'm trying to update my ra_xim code and have noticed that you now use freadcolr a lot more often. Is freadscan now obsolete? Also, we're trying to get DEMs (Digital Elevation Maps) into radiance. Do you have an example of a height field in action? or sample input to gensurf? Thanks, Philip Date: Wed, 17 Jun 92 15:52:16 PDT From: greg (Gregory J. Ward) To: gleung@Athena.MIT.EDU, phils@Athena.MIT.EDU Subject: Re: gensurf height functions Dear Gilbert and Philip, Here is a simple example of gensurf using height information from a file: gensurf dirty ground '40*s' '30*t' height.data 4 3 -s Where height.data contains the following: 10.35 15.78 13.33 12.15 10.72 11.77 14.55 14.15 13.37 12.20 12.21 14.31 14.93 13.75 13.71 11.35 14.05 14.75 12.91 13.35 The formatting of the data file is irrelevant, but the number and ordering of points matters. Since I have specified 20 points, which is (4+1)*(3+1), gensurf will interpret these as vertex heights rather than centroid heights. If I had given anything other than 12 or 20 points, gensurf would have reported an error. The -s option performs surface normal interpolation for smoothing the data, but in any case 12 polygons would have been produced. If I wanted to take x and y coordinates from a data file as well, I would have used a command like: gensurf ugly object object.data object.data object.data 4 3 The file "object.data" should contain either 12 or 24 triplets (ie. 36 or 72 floating point values) corresponding either to the centroid or vertex locations of each surface, respectively. The triplets would appear as: x0 y0 z0 x1 y1 z1 x2 y2 z2 ... in the input file. The repetition of the file name, although awkward, was done that way to avoid more compilcated argument specification and so that I could without too much trouble allow for separate coordinate input files if someone needed that in the future. In response to Philip's question about freadcolrs(), it is much faster than freadscan(), and when combined with setcolrgam() and colrs_gambs(), can do gamma correction as well on 24-bit pixels. You can look at ra_skel.c in the src/px directory to see how this is done. -Greg ============================================================= COMPILATION QUESTIONS From: desilva@ced.berkeley.edu Subject: compile To: greg@hobbes.lbl.gov Date: Thu, 18 Jun 92 21:12:52 PDT Hello again, I'm trying compile the new version on Irix 4.0 and I can't get ximage to work. The error message I'm receiving is: X Error of filed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 1 (X_CreateWindow) Serial number of failed request: 4 Current serial number in output stream: 18 Rview appears to working just fine. Do any of the X app-defaults need to be set? All of our irises have at least 16 megs of ram and a few have more than 24 megs. Should answer yes or no the "more than 24 megs?" question. We also just got one of the new SGI Crimsons with the 64bit R4000 CPU. I was using the Crimson to compile Radiance on it. I'm still in the process of setting it up and installing Irix 4.04 on all the other machines. Deanan Date: Fri, 19 Jun 92 08:45:21 PDT From: greg (Gregory J. Ward) To: desilva@ced.berkeley.edu Subject: Re: compile Hi Deanan, You should pick up the revised files in the pub/patch directory to get rview and ximage to work better with the SGIs. I would answer "yes" to the question about "more than 24 megs". The only difference between version 3.x and 4.x of IRIX is the compiler switch to get K&R C and the fact that 3.x doesn't fully support X11. -Greg Date: Fri, 19 Jun 92 13:37:15 +0200 From: pralong@gismo.cnet-pab.fr (Frederic PRALONG) To: greg@hobbes.lbl.gov Subject: Solicitation from a Radiance user on NeXTStation Hi greg, Do you know someone who have compile radiance2R1 on a NextStation ? Thanks FReD Date: Fri, 19 Jun 92 08:48:24 PDT From: greg (Gregory J. Ward) To: pralong@gismo.cnet-pab.fr Subject: Re: Solicitation from a Radiance user on NeXTStation Hello Fred, Yes, I just recently exchange e-mail with someone struggling with Radiance 2.1 on a NeXT. There are a few bugaboos in the NeXT C compiler. Following is my response: >From greg Mon Jun 15 16:25:44 1992 Return-Path: Date: Mon, 15 Jun 92 16:25:41 PDT From: greg (Gregory J. Ward) To: linde@physics.Stanford.edu Subject: NeXT compilation Status: RO Well, what can I say? The NeXT is not a very standard compiler. I'm still amazed that it cannot manage to accept redefined library functions. This runs counter to the very spirit of the C language. Anyway, you can just add a -lrt to all the Rmakefile lines that resulted in the ld: Zstrcmp undef. errors. The only other serious errors were the -n: unknown option problems, which can be resolved by removing -n from the corresponding lines in Rmakefile. The rest is just bitching you can ignore. By the way, it seems that you do not have X11 installed on your NeXT machine. You need to read the instructions in noX11.help and follow them to avoid compiling the programs that won't work without it. Date: Wed, 1 Jul 1992 13:18:27 -0500 From: guy@guy.b30.ingr.com (Guy Streeter) To: greg@hobbes.lbl.gov (Gregory J. Ward) Subject: Re: how was textures.pic generated? Gregory J. Ward writes: > Hello Guy, > > Indeed, anything that reports a consistency error is highly suspicious. > In theory, you should never get such an error, and it indicates an internal > bug in the program. What machine was your version of Radiance compiled on? I'm running Radiance on an Intergraph InterPro 2020, which is a RISC architecture (Intergraph Clipper C300 processor: 32-bit integer, 64-bit float) SYSV R3 system. I compiled it with GNU C v2.2. Although the system libraries are compiled with a different compiler, I've never encountered a compatibility problem. rmake looks like: #!/bin/sh exec make "SPECIAL=" \ "CC=gcc -mc300 -fwritable-strings" \ "OPT=-O -s" \ "MACH= -DALIGN=double" \ ARCH= "COMPAT=bmalloc.o erf.o" \ INSTDIR=/usr/local/bin \ LIBDIR=/usr/local/lib/ray "$@" -f Rmakefile The only part of this I'm unsure of is the COMPAT definition. I don't know what those modules are supposed to do. I haven't changed any of the definitions (-DSMLFLT, etc.) so there couldn't be any internal compatibility problems there. I tried it again with the updated commandline you sent. The results were the same. Among the peculiarities of my system, one that strikes me as a possible problem is the way subroutine arguments are passed. The compiler always puts the first two integer or pointer arguments and the first two floating-point arguments into registers, and passes the rest on the stack. This means that variable argument lists can only be handled by the varargs (or stdarg) facility. Date: Wed, 1 Jul 92 13:42:10 PDT From: greg (Gregory J. Ward) To: guy@guy.b30.ingr.com Subject: Re: how was textures.pic generated? Hmmm. I'm starting to suspect the GNU C compiler now. The other fellow who was having troubles was also using GNU C. I have never managed to compile anything using GNU C, so I gave up trying. It's too nonstandard for my taste. Do you have an alternative compiler available? The argument list strangeness shouldn't trip up Radiance, though I'll have to check and make sure. The only time I ever play with the number of function arguments is when there are optional arguments at the end of the list. They are always declared but only accessed under some conditions, when they must be passed by the caller. This basic mechanism is described in K&R, so it is supported by all C compilers I've used. What happens when you pass fewer arguments than are declared in a GNU-compiled program? -Greg Date: Wed, 1 Jul 1992 16:09:20 -0500 From: guy@guy.b30.ingr.com (Guy Streeter) To: greg@hobbes.lbl.gov (Gregory J. Ward) Subject: Re: how was textures.pic generated? I believe I've discovered my problem. There are a number of places in the Rmakefiles where an explicit command is used to compile a source file. In those commands, 'cc' is used instead of '$(CC)', so my definition of 'CC' in rmake didn't matter. A different compiler was used for those source files. I don't know if there is something broken in that compiler, or a compatibility problem with other modules compiled with GNU C, but I changed all the Rmakefiles and rebuilt everything, making sure that all files were compiled with GNU. I'm rerunning 'texture' right now, and it's at: 2163454 rays, 18.33% done after 1.0092 hours which is better than twice as far as it got before. So, unless you hear from me again you can assume the problem is fixed. thanks, Guy Streeter Date: Wed, 1 Jul 92 14:56:28 PDT From: greg (Gregory J. Ward) To: guy@guy.b30.ingr.com Subject: Re: how was textures.pic generated? Great! I should have thought of this myself, I suppose, but I'm glad that someone did! I will go through my Rmakefile's and make sure they all reference $(CC) instead of cc, so future users don't have the same troubles. -Greg ============================================================= ANIMATION SPLINES To: greg@hobbes.lbl.gov (Gregory J. Ward) Subject: animations w/ splines Date: Tue, 30 Jun 92 15:37:02 EDT From: Philip Thompson Hi Greg, We're trying to borrow your spline animation technique from the cabin, and have figured out everything but the time parameter T(). In our first example we're just trying to fly through 4 points. My question is, if T is the time between keyframe i and i-1 why are there an equal number as there are frames? Second, if we want the speed to be fairly constant, should this time be proportional to the distance? When we set T() equal to the distance between points the animation started in the middle of the path, went to one end and doubled back. Anyway here is what we are trying in keys.cal now - but it seems awfully hit or miss. Px(i) = select(i, -6130, -4390, -2800, -2430); Py(i) = select(i, 1440, 740, 100, -40); Pz(i) = select(i, 500, 500, 500, 500); Dx(i) = select(i, 0.4, 0.4, 0.4, 0.4); Dy(i) = select(i, 0.9, 0.9, 0.9, 0.9); Dz(i) = select(i, -0.5, -0.5, -0.5, -0.5); Ux(i) = select(i, 0, 0, 0, 0); Uy(i) = select(i, 0, 0, 0, 0); Uz(i) = select(i, 1, 1, 1, 1); E(i) = select(i, 50, 50, 50, 50); T(i) = select(i, 0, 2, 2, 0); Thanks, Phil ps. I also noticed that in the cabin keys file you have "rview .... -t .35" where -t .35 seems to correspond to the T() values. How did you get these? Date: Tue, 30 Jun 92 16:34:14 PDT From: greg (Gregory J. Ward) To: phils@Athena.MIT.EDU Subject: Re: animations w/ splines Hi Phil, Yes, why indeed does T() have the same number of points as keyframes? Because, the first one doesn't count! I did it this way for convenience, I think. A zero value is appropriate there. Yes, the value for each frame should be proportional to the distance, though I would slow down a bit when making turns if you don't want to get sick. The viewfiles I created with the "view" command of rview, which allows you to tack whatever you like after the end of the view file name and it will be appended to the view line in the file. This is merely for the convenience of annotating multiple views (eg. keyframes) written out to a single file. The -t option is just what I decided to use for time. Within rview, when I had found a view I thought would work for the next keyframe, I typed: : view keyframes -t SECS where SECS was the decimal number of seconds I thought would work between the last view and this one. You're right, it's a bit of a hit and miss process. I usually do an extremely low resolution (both in time and image size) animation before starting the real thing just to check that I haven't done anything stupid. Good luck! -Greg ========================================================== RA_PICT Date: Wed, 8 Jul 92 18:45:14 -0400 From: Jim Callahan To: greg@hobbes.lbl.gov Subject: PIC to PICT problems... Greg- I think you mentioned that you use a Mac, so I thought you might know what I'm doing wrong. I am trying to view some images produced by Radiance on a Mac II-fx. These are the steps I took: 1> in UNIX: "ra_pict test.pic test.pict" 2> Moved the PICT file via ftp (in bin mode) to the Mac 3> Tried to view with many different viewers... It seem that the Mac thinks "test.pict" is a document and refuses to load it. Am I overlooking a step here? Do I need some program which will make the OS realize it is a PICT? Thanks for the help... Anyway, I am going to send my GUI (based on InterViews) for Radiance to a number of beta testers this weekend. Would you like to see it? It allows the user to set all command line options for OCONV, RVIEW, and RPICT with sliders and other widgets. In addition, it provides detailed control of image division and remote shelling over a network. I hope it will make using Radiance easier, especially for new users. Are you going to attend SIGGRAPH'92 later this month? It looks like a real "disney world" experience for the computer graphics addict... -Jim (jmc@ugrad.ee.ufl.edu) Date: Wed, 8 Jul 92 18:06:55 PDT From: greg (Gregory J. Ward) To: jmc@ugrad.ee.ufl.edu Subject: Re: PIC to PICT problems... Hi Jim, Yes, you need to modify the creator and type of the file before any tools will load it directly. The desk accessory called "disktop" allows you to make such changes. The type should be PICT and a good creator is 8BIM (used by Photoshop, I think). If you have Photoshop, you can always use the "Open as..." dialog box to load the file, even without setting the type beforehand. I would like to see your interface. Do you have a compiled version for a Sun or Silicon Graphics? I don't have Interviews or C++, so it would be difficult for me to do the compilation. -Greg P.S. Yes, I will be at Siggraph. I'll be staying with Paul Heckbert at the Hyatt if you want to get together. [Note that Siggraph will be in Orlando, home of Disney World, in '93...] ========================================================= LIGHT SOURCES From: chauvine@dingo.imag.fr (ROOT) Date: Mon, 6 Jul 92 10:32:52 MET DST Organization: IMAG Institute, University of Grenoble To: greg@hobbes.lbl.gov Subject: Radiance again Bonjour greg, Thank you for your fast reply from your bed, we hope that your are in better shape now. We have done all that you have said, and it's working (light was !). We knew your warning but understood it in a wrong way. We have a lot of things to ask you, but if you have no time, or if you are tired of us, don't hesitate to throw some of then. 1- we don't understand why when we have two light sources with the same power, the largest one in size gives more light in the scene? 2- we don't understand why there is a lost of rays when rendering a scene from 100 unit or more (we want to say that some objects appear with holes in them instead of be plain)? 3- Can you tell us how many sources of light are allowed at maximum. Remark: We have many black holes on object with plastic material, and that whatever is the size of the object. Last : We have a great interest with anisotropic reflection, and we shall be very pleased if ther is a mean to get a copy of your SIGGRAPH'92 article. Many thanks from a sunny Grenoble, laurent & jacques. -- ------------------------------------------------------------- - Chauvineau Laurent - Magistere Informatique - - - Ecole Univ. Info. - UJF - - Laboratoire ARTEMIS - - Projet Image de Synthese - - - - e_mail: chauvine@dingo.imag.fr - ------------------------------------------------------------- Date: Mon, 6 Jul 92 18:02:09 PDT From: greg (Gregory J. Ward) To: chauvine@dingo.imag.fr Subject: Re: Radiance again Hello Laurent and Jacques, I was better, but then my brother visited this weekend and now I am sick again! Oh, well. You're questions are not too difficult, so I will try to answer them. 1- we don't understand why when we have two light sources with the same power, the largest one in size gives more light in the scene? The total output of a light source is (as you have noticed) the product of the source area and the output radiance. Since radiance (the unit, not the software) is in watts/sr/m^2, you must multiply this by square area and solid angle to obtain power. Look at it this way: if you had a light filament that was as bright as the surface of the sun (as is a common quartz-halogen filament), it would have the same radiance as the sun but not the same output as has only about 10^-23 as much radiating area. Thus, radiance is related to the visible brightness of an infinitesimal fraction of the surface. 2- we don't understand why there is a lost of rays when rendering a scene from 100 unit or more (we want to say that some objects appear with holes in them instead of be plain)? What version of Radiance are you running? Version 2.0 has some problems with the -DSMLFLT option. This compile switch is used if you answer yes to a certain question in makeall about rendering very large models. You should be able to see it in the resulting rmake command placed in your Radiance bin directory. If you have version 2.0, you should remove this rmake command and run "makeall clean" followed by "makeall install", this time answer "no" to the question about large models. If you have version 2.1 and are experiencing this problem, then I would like to know about it. 3- Can you tell us how many sources of light are allowed at maximum. There is no maximum to the number of light sources, although you will find that the calculation slows down more the more light sources you add. It is best to represent your scene with as few light source surfaces as possible to obtain the fastest renderings. Last : We have a great interest with anisotropic reflection, and we shall be very pleased if ther is a mean to get a copy of your SIGGRAPH'92 article. I will send you a preprint of this article when I get back to the office. -Greg From: chauvine@dingo.imag.fr (ROOT) Date: Thu, 9 Jul 92 10:24:46 MET DST To: greg@hobbes.lbl.gov Subject: Radiance version Hello greg, We are using version 2.1 and we still have this probleme. Your new manual is very usefull and well made. Thank you for accepting to send us the preprint. laurent & jacques. Date: Thu, 9 Jul 92 15:39:36 PDT From: greg (Gregory J. Ward) To: chauvine@dingo.imag.fr Subject: Re: Radiance version Were you using the -DSMLFLT option? I just tried it on my machine, and I ran into similar problems, so I tried decreasing the value of FTINY further. You should try modifying the FTINY value in common/fvect.h so it matches the following: /* Copyright (c) 1988 Regents of the University of California */ /* SCCSid "@(#)fvect.h 2.3 7/9/92 LBL" */ #ifdef SMLFLT #define FLOAT float #define FTINY (1e-3) #else #define FLOAT double #define FTINY (1e-6) #endif #define FHUGE (1e10) /* and so on... */ ------------ Then, try cleaning and recompiling everything and see if you still have troubles. I noticed some small problems, but there's really no getting away from errors with short floating point numbers. -Greg ======================================================= HARTMANN CONSTANT From: bcurrey@neumann.une.oz.au (The Ray) Subject: Radiance - bits and pieces To: GJWard@lbl.gov Date: Wed, 5 Aug 92 13:45:30 EST Hi Greg, I have recently got your Radiance program through FTP and have successfully compiled to run on our DEC's here at Uni. I will say right now that the program is very comprehensive, and I wich I had more time o get to know it better. Anyway, I have two questions: - One, where can I get some values for the Hartmann constant you refer to in the manual regarding dielectrics. The Physics department here was stumped when I asked them for data (in fact they had never even heard of such a constant!) - Two, since I have to keep this in a temp directory on this system (because of the programs size) what files do I really need for the program to run. I'm trying to cut down on disc usage as much as possible. Any help would be greatly appreciated. Boyd bcurrey@neumann.une.oz.au Date: Wed, 5 Aug 92 09:17:23 PDT From: greg (Gregory J. Ward) To: bcurrey@neumann.une.oz.au Subject: Re: Radiance - bits and pieces Hi Boyd, The Hartmann constant can be found in the handbook of Chemistry and Physics, or fitted manually based on a list of (wavelength,refractive_index) pairs. Basically, the final index of refraction is computed by: n = n0 + Hartmann_constant/wavelength where wavelength is given in nanometers. Note that this constant ONLY has effect for light scattered from light sources, and is normally irrelevant to the calculation. That is why it is usually left as zero, ignoring the wavelength dependence of the index of refraction. As for your second question, only the binaries, the library directory (ray/lib in the distribution) and any models you want to use need be kept around. The source code and the rest can be removed once the programs have been successfully compiled. -Greg ========================================================== SPOTLIGHTS Sender: MAILER%PLWRTU11.BITNET Date: Thu, 27 Aug 92 15:43:19 CET From: SJK%PLWRTU11.BITNET@Csa3.lbl.gov To: greg@hobbes.lbl.gov Subject: Spotlights in RADIANCE; antimatter Hello Greg, recently we (with Karol Myszkowski) spent some time experimenting with RADIANCE. Our goal is to compare accuracy/speed of RADIANCE with TBT using similar scenes. Actually Karol is absent (short holidays) so I continue investigations alone. I am a novice in RADIANCE, so I apologize for asking about probably well known topics. I encountered some difficulties when I try to model directed light sources by means of spotlight (with RADIANCE 2.1) and I have not find answers to my questions neither in the manual nor in digest files. 1. What focal distance means? I am unable to see any difference between spotlights with the same angles but different lengths of orientation vectors. 2. Visibility of spotlight. I noticed that the spotlight is visible even when the observer is located at a point not illuminated by this light (see the picture below). Is it correct? 3. Secondary spotlights. The picture shows that a secondary spotlight acts as if it is undirected. The top face of the golden cube is illuminated only partly, however the illuminated area on the wall is produced by the whole square. Below is the source file (tc.rad): ------------------------------------ void spotlight dir_source 0 0 7 10000 10000 10000 90 0 0 -1 void plastic white 0 0 5 .7 .7 .7 0 0 void mirror polished_gold 0 0 3 .45 .25 .02 !genbox white room 10 10 10 -i !genbox polished_gold gold_box 3 3 3.5 | xform -t 0 4 0 # Light source dir_source ring light 0 0 8 5 3 9 0 0 -1 0 0.1 ----------------------------- I have used the command rpict -vf $(name).vf -x 300 -dr 1 -ab 1 -av 0.05 0.05 0.05 -t 10 \ $(name).oct >$(name).pic with tc.vf containing: rview -vtv -vp 9 9 5 -vd -1 -1 0 -vu 0 0 1 -vh 90 -vv 90 -vs 0 -vl 0 -------------------------- 4. Are goniometric diagrams possible in RADIANCE? In view of very general mechanism to specify reflectance and transmittance (BRTDfunc) I was surprised not found something like ULEDfunc (Unidirectional Light Emitting Distribution) to specify a dependency of power of a light source on emitting direction. Is it possible to specify such dependency in some way? If not, maybe it is worth to include such possibility in future version? 5. Antimatter remark. The method to produce a hole with different surface material that You suggested in v2n2, lines 251--271 (ANTIMATTER, answer to David Jones, 17 Jan 92) do not work (I tried to make sphere hole in cubical object instead of cylinder). It do work (in my example) after the following changes of AMAT2 definition: void antimatter AMAT2 2 MAT2 MAT1 0 0 # The order of MAT2 MAT1 is significant! With best regards, Andrei Khodulev: sjk@plwrtu11.bitnet Date: Thu, 27 Aug 92 18:13:36 PDT From: greg (Gregory J. Ward) To: SJK%PLWRTU11.BITNET@Csa3.lbl.gov Hello Andrei, Thank you for your excellent questions. I'm afraid that I will not be able to give you a complete answer right away. Briefly, 1. The focal length produces only a subtle difference as it shifts the effective position of the source behind the actual emitting surface. A real spotlight has the effect of changing its falloff to being something less than r^-2 (where r is the distance to the emitter) in this way. The actual falloff is closer to (r+e)^-2, where e is the focal length of the spotlight's optics. It is a minor concern, I admit. 2. This is the way the spotlight material behaves. The spotlight type is primarily to make a more efficient calculation by ignoring that portion of a light's output that is insignificant. It is usually used in conjunction with a light source pattern, described briefly in the answer to your question 4 (below). 3. Since I won't be able to run your file right away, I will have to answer this question later. 4. Yes, light source emissions are specified using the more general pattern types brightfunc or brightdata. (Colorfunc and colordata may also be used if you wish to give your light source a color-dependent distribution.) A simple example is as follows: void brightfunc cos3dist 2 cos(Dz)^3 . 0 0 cos3dist light con_light 0 0 3 100 100 100 con_light ring con_lamp 0 0 8 5 8 3 0 0 -1 0 .06 You should look at the files in the ray/lib/source/ies directory for examples of the brightdata primitive and its application to light sources. 5. I'll have to go back and look at the question to which you refer. Yes, order does matter. The first material given is the one used at the antimatter boundary. -Greg