From ph@miro.Berkeley.EDU Mon Aug 13 14:11:25 1990 Return-Path: Received: from miro.Berkeley.EDU by hobbes.lbl.gov (3.2/SMI-3.2) id AA06897; Mon, 13 Aug 90 14:05:43 PDT Received: by miro.Berkeley.EDU (4.1/1.41) id AA14542; Mon, 13 Aug 90 13:42:27 PDT Date: Mon, 13 Aug 90 13:42:27 PDT From: ph@miro.Berkeley.EDU (Paul Heckbert) Message-Id: <9008132042.AA14542@miro.Berkeley.EDU> To: arvo@apollo.hp.com, asensio@dmi.ens.fr, atc@cs.utexas.edu, buckalew@polyslo.calpoly.edu, chense@apple.com, drb@sgi.com, dwg@squid.graphics.cornell.edu, eloisec@fai.com, erich@eye.com, fussell@cs.utexas.edu, fxs@squid.graphics.cornell.edu, greene@apple.com, greg@hobbes.lbl.gov, hr3@hydra.gatech.edu, johnw@eye.com, lalonde@cs.dal.ca, m-cohen@cs.utah.edu, ph@miro.Berkeley.EDU, puech@dmi.ens.fr, shirley@iuvax.cs.indiana.edu, turner@apple.com Status: RO Contents: minutes of Dallas meeting, globillum mailing list ----- Minutes of Global Illumination Meeting in Dallas, 8/10/90 meeting organizer & pizza rustler: Greg Ward secretary: Paul Heckbert present: Jim Arvo, Frederic Asensio, Dan Baum, Chris Buckalew, Jim Bullis, A. T. Campbell III, Eric Chen, Michael Cohen, Don Fussell, David George, Ned Greene, Eric Haines, Paul Heckbert, Paul Lalonde, Claude Puech, Holly Rushmeier, Pete Shirley, Francois Sillion, Doug Turner, Greg Ward Heckbert: What are the unsolved problems of global illumination that keep you up at night? ADAPTIVE SAMPLING OF RADIOSITY Heckbert: For me, it's adaptive sampling of light directions and radiosity sample locations on surfaces. Chen: We should separate shading from geometry. George: We're doing something like radiosity textures; we have samples on each surface. Heckbert: Why hasn't the adaptive substructuring described in Cohen's 1986 CG&A paper been used more? Baum: it's too slow; the convergence is poor. George: we're doing something like it. Our method is cheaper than Campbell's [siggraph '90]. In our CG&A paper last month we included some pictures made with adaptive sampling (though the method is not described there). DIVIDE AND CONQUER Sillion: How do you divide the global illumination problem into smaller, simpler problems? For example, how do you decompose the problem for an entire building into room-sized problems? Baum: see the paper by John Airey (sp?) of UNC at the Snowbird conference. ERROR METRICS Arvo: I'd like to have bounded error, so that I know the difference between the discrete (radiosity) solution and the continuous solution is bounded. I'd like the discrete solution to be within a percentage of the correct solution for all scenes. Baum: we did that [referring to Baum-Rushmeier-Winget89?] Chen: Is anybody making real [physical] models? Sillion: We're going to build a specular/diffuse box test scene. Heckbert: It would be nice to have simple test scenes for which we can construct both analytic and empirical (physical) solutions. We could all compare our results against these standards. George: RMS error is a poor error measure. If your answer is consistently darker, or is off by a pixel, this metric will report an error larger than you want. Rushmeier: As shown by this morning's paper by Takagi et al, it's important to define your criteria for success explicitly. Ward: To create better error metrics you need to take the human visual response -- what really matters -- into account. First, you'd register the two images, then do comparison. Ward: We need a test suite that includes a matrix of combinations of various geometry from simple to complex, and various surface types, including diffuse, specular, and rough specular. All: where's our pizza? LIGHT SOURCE DATA Baum: Does anybody have light source data? Ward: I've got some. Manufacturers often supply such information. You can get it in IES format. I've got a converter. Ward: We should have a common floating point picture format. CONTROL OF APPEARANCE Turner: I did animation using both ray tracing and radiosity ["The Audition", the piece with bulldog, worm, and cannon in the film show] and found that there was a tradeoff between realism and the control that you'd want as an animator. Realistic rendering often means poor control of visual appearance. Cohen: It would be nice to point to a pixel or surface point and get a list of its strongest illuminators. Heckbert: Greg Ward's ray tracer will do that; you can point with the mouse and it will print the ray tree, with object names. PREVIOUS METHODS Chen: Most solutions are either good locally, or good globally, but not both. For instance, the radiosity solution finds the global solution but assumes that the local behavior (the BRDF) is purely diffuse. On the other hand, if a more sophisticated local illumination model [such as Torrance-Sparrow] is used, you can't find a global solution. Heckbert: I'm passing around a table of comparisons between the assumptions made by classic ray tracing and classic radiosity. Classic ray tracing assumes, for the diffuse term, that illumination is a sum of delta functions, and assumes, for the specular term, that reflectance (BRDF) is a sum of delta functions. Classic radiosity assumes that there is no specular component. I'm also passing around a rough draft of a table characterizing published global illumination schemes by the effects they simulate and the data structures they use to store radiosity values. DATA/SOFTWARE AVAILABLE Ward: I've got BRDF data that I can share. Arvo: I worked on a program that can use arbitrary BRDF data. Ward: If anybody wants a free ray tracer that does diffuse interreflection, send me a blank tape. Anon: and he might even send it back. ----- # GLOBAL ILLUMINATION MAILING LIST, 8/13/90 # append the following to your .mailrc file # # send corrections/additions to Paul Heckbert alias globillum arvo asensio baum buckalew campbell carlton chen \ cohen fussell george greene haines heckbert lalonde puech \ rushmeier shirley sillion turner wallace ward # Jim Arvo, Apollo / Yale alias arvo arvo@apollo.hp.com alias arvo2 arvo@yale.edu # Frederic Asensio, LIENS alias asensio asensio@ens.ens.fr # Dan Baum, Silicon Graphics alias baum drb@sgi.com # Chris Buckalew, Cal Poly alias buckalew buckalew@polyslo.calpoly.edu # Jim Bullis, Dicomed -- not on net # A. T. Campbell III, U of Texas, Austin alias campbell atc@cs.utexas.edu # Eloise Carlton, Fujitsu America alias carlton eloisec@fai.com # Eric Chen, Apple alias chen chense@apple.com # Michael Cohen, U of Utah alias cohen m-cohen@cs.utah.edu # Don Fussell, U of Texas, Austin alias fussell fussell@cs.utexas.edu # David George, Cornell U alias george dwg@squid.graphics.cornell.edu # Ned Greene, Apple / U of California, Santa Cruz alias greene greene@apple.com # Eric Haines, 3D/Eye alias haines erich@eye.com # Paul Heckbert, U of California, Berkeley alias heckbert ph@miro.berkeley.edu # Paul Lalonde, Queen's U alias lalonde lalonde@cs.dal.ca # Claude Puech, LIENS / Stanford alias puech puech@ens.ens.fr # Holly Rushmeier, Georgia Tech alias rushmeier hr3@hydra.gatech.edu # Pete Shirley, Indiana U alias shirley shirley@iuvax.cs.indiana.edu # Francois Sillion, Cornell U alias sillion fxs@squid.graphics.cornell.edu # Doug Turner, Apple alias turner turner@apple.com # John Wallace, 3D/Eye alias wallace johnw@eye.com # Greg Ward, Lawrence Berkeley Lab alias ward greg@hobbes.lbl.gov From shirley@iuvax.cs.indiana.edu Thu Aug 16 11:56:59 1990 Return-Path: Received: from iuvax.cs.indiana.edu (129.79.254.192) by hobbes.lbl.gov (3.2/SMI-3.2) id AA10198; Thu, 16 Aug 90 11:56:46 PDT Message-Id: <9008161856.AA10198@hobbes.lbl.gov> Received: by iuvax.cs.indiana.edu Date: Thu, 16 Aug 90 13:48:07 -0500 From: peter shirley To: arvo@apollo.hp.com, asensio@dmi.ens.fr, atc@cs.utexas.edu, buckalew@polyslo.calpoly.edu, chense@apple.com, drb@sgi.com, dwg@squid.graphics.cornell.edu, eloisec@fai.com, erich@eye.com, fussell@cs.utexas.edu, fxs@squid.graphics.cornell.edu, greene@apple.com, greg@hobbes.lbl.gov, hr3@hydra.gatech.edu, johnw@eye.com, lalonde@cs.dal.ca, m-cohen@cs.utah.edu, ph@miro.berkeley.edu, puech@dmi.ens.fr, shirley@iuvax.cs.indiana.edu, turner@apple.com Subject: misc for globillum Status: RO It was nice to meet you all (sorry-- y'all) in Dallas. Much thanks to Greg Ward for the pizza organization (the hardest problem discussed) and to Paul Heckbert for setting up the list. I will try to get the ball rolling... Francois Sillion mentioned solving partial systems and then combining these for a full solution. This seems like a great idea (though I have no ideas on how to execute it). I've seen this discussed in two papers: @inproceedings{kn:xu89, Author = {Hau Xu and Qun-Sheng Peng and You-Dong Liang}, Title = {Accelerating Radiosity Method for Complex Scenes}, Booktitle = {Eurographics '89}, Year = 1989, Pages = {51-61}, Annote = {Partions object space for solutions in subdomains. } } @Article{kn:neum89, Author ={Laszlo Neuman and Attila Neumann}, Title = {Photosimulation: Interreflection with Arbitrary Reflectance Models and Illumination}, Journal= {Computer Graphics Forum}, Year = 1989, Volume = 8, Pages = {21-34} } I don't really understand the methods in these papers... if anyone here does, please let me know. Second, I have some thoughts on standard environments. There is a class of diffuse environments with analytical solutions that are quite artificial but do allow for complex geometry. Let every surface in the closed environment have emitted radiance E and reflectivity R (for a given wavelength). The outgoing radiance of a surface at point x in direction psi is: L_out(x, psi) = E(x, psi) + INT BRDF(x, psi, psi') L_in(x, psi') cos(theta) dw where the integral is taken over all incoming directions psi (Immel's equation) Since all surefaces are diffuse with equal characteristics we get: L_out(x) = E + INT R/pi L_in(x, psi') cos(theta) dw We know that L_in(x,psi') is L_out(x', psi') where x' is the point seen in direction -psi' standing at point x. Now we can expand the intergal equation: L_out(x) = E + INT R/pi E cos(theta) dw + ( INT R/pi E cos(theta) dw ) ** 2 + ( INT R/pi E cos(theta) dw ) ** 3 + ... Since INT cos(theta)dw = pi we get, for all x: L_out(x) = E + RE + R**2 E + R**3 E + ... = E / (1 - R) The good news is that any closed geometry can be used. The bad news is that no interesting light sources can be used (it's a flourescent nightmare). Still, I think that it is not a bad approximation to INDIRECT lighting. It has nothing to say about direct lighting. Any comments or corrections? Pete Shirley From hr3@prism.gatech.edu Thu Aug 16 11:58:31 1990 Return-Path: Received: from hydra.gatech.edu (128.61.6.11) by hobbes.lbl.gov (3.2/SMI-3.2) id AA10205; Thu, 16 Aug 90 11:58:24 PDT Received: by hydra.gatech.edu (5.61/3.1) id AA12228; Thu, 16 Aug 90 13:33:45 -0400 Date: Thu, 16 Aug 90 13:33:45 -0400 From: hr3@prism.gatech.edu (RUSHMEIER,HOLLY E) Message-Id: <9008161733.AA12228@prism.gatech.edu> To: arvo@apollo.hp.com, asensio@ens.ens.fr, atc@cs.utexas.edu, buckalew@polyslo.calpoly.edu, chense@apple.com, drb@sgi.com, dwg@squid.graphics.cornell.edu, eloisec@fai.com, erich@eye.com, fussell@cs.utexas.edu, fxs@squid.graphics.cornell.edu, greene@apple.com, greg@hobbes.lbl.gov, hr3@prism.gatech.edu, johnw@eye.com, lalonde@cs.dal.ca, m-cohen@cs.utah.edu, ph@miro.berkeley.edu, puech@ens.ens.fr, shirley@iuvax.cs.indiana.edu, turner@apple.com Subject: non-diffuse help Status: RO I am trying to finish up a paper that my student wrote about non-diffuse reflections. There are two papers on this subject which I can't find in our library. If you have a copy and would be willing to send it to me could you send me email? Chen and Wu "An Adapted Solution of Progressive Radiosity and Ray Tracing Methods for Nondiffuse Environments", Proceedings of CGI'90, June 26-30,1990. Shao,P.P., Peng, Q. S. and Liang Y. D., "Formfactors for General Environments", Proc. Eurographics'88, pp. 499-510. Also, just by the by, I noticed in the 1989 annual report from the CMU Robotics institute there is a paper called "An Experiment in Perfectly Realistic Graphics" by Thibadeau, Hsiung, Thuel, Chow and Siegel (M. W. not Robert). Generally its a discussion of their ray tracer. The unique aspect of their work is including the time element in ray tracing and taking into account relativistic effects so that you can do stuff like make images of how things would look if you were travelling towards them at the speed of light. -- Holly Rushmeier hr3@hydra.gatech.edu From greg Thu Aug 16 14:37:32 1990 Return-Path: Received: by hobbes.lbl.gov (3.2/SMI-3.2) id AA10564; Thu, 16 Aug 90 14:36:34 PDT Date: Thu, 16 Aug 90 14:36:34 PDT From: greg (Gregory J. Ward) Message-Id: <9008162136.AA10564@hobbes.lbl.gov> To: arvo@apollo.hp.com, asensio@dmi.ens.fr, atc@cs.utexas.edu, buckalew@polyslo.calpoly.edu, chense@apple.com, drb@sgi.com, dwg@squid.graphics.cornell.edu, eloisec@fai.com, erich@eye.com, fussell@cs.utexas.edu, fxs@squid.graphics.cornell.edu, greene@apple.com, greg@hobbes.lbl.gov, hr3@hydra.gatech.edu, johnw@eye.com, lalonde@cs.dal.ca, m-cohen@cs.utah.edu, ph@miro.berkeley.edu, puech@dmi.ens.fr, shirley@iuvax.cs.indiana.edu, turner@apple.com Subject: Re: misc for globillum Status: RO Hi everyone, I think Peter has discovered invisibility! A glowing room with absolutely no contrast anywhere! Actually, this seems like a nice starting point to check that a diffuse simulation is working properly. It should also be possible to add any number of perfectly reflective mirrors and still have the same solution, E/(1-R), for all the diffuse surfaces. If you are interested, I worked out a solution for one interreflection on a diffuse sphere sitting on an infinite diffuse plane illuminated by parallel light from above. It took all my strength to do the algebra, so if you want the equations you will have to give me a fax number. As we consider more sophisticated (and realistic) environments, I think we will find it very difficult to come up with analytical solutions. Therefore, I suggest that we use a converged Monte Carlo approximation as the reference standard. This method is slow, but is the only one that guarantees its results (with a statistical uncertainty of course). I suggest that we create a table of environments with increasing complexity in geometry and reflectance like so: | Geometry Reflectance |----------------------------------------------- | Empty room | Room w/ boxes | 1000+ polygons ================================================================ Diffuse | ED | BD | CD ---------------------------------------------------------------- Mirror specular | EM | BM | CM ---------------------------------------------------------------- Rough specular | ER | BR | CR ---------------------------------------------------------------- We can put one person in charge of selecting the geometries, and one person in charge of the reflectance models. I volunteer for the reflectance models. (It pays to be first.) Does anyone want to create the scenes to go with them? -Greg (GJWard@lbl.gov) From shirley@iuvax.cs.indiana.edu Sat Aug 18 09:24:32 1990 Return-Path: Received: from iuvax.cs.indiana.edu (129.79.254.192) by hobbes.lbl.gov (3.2/SMI-3.2) id AA12786; Sat, 18 Aug 90 09:16:26 PDT Message-Id: <9008181616.AA12786@hobbes.lbl.gov> Received: by iuvax.cs.indiana.edu Date: Sat, 18 Aug 90 10:02:48 -0500 From: peter shirley To: arvo@apollo.hp.com, asensio@ens.ens.fr, atc@cs.utexas.edu, buckalew@polyslo.calpoly.edu, chense@apple.com, drb@sgi.com, dwg@squid.graphics.cornell.edu, eloisec@fai.com, erich@eye.com, fussell@cs.utexas.edu, fxs@squid.graphics.cornell.edu, greene@apple.com, greg@hobbes.lbl.gov, hr3@hydra.gatech.edu, johnw@eye.com, lalonde@cs.dal.ca, m-cohen@cs.utah.edu, ph@miro.berkeley.edu, puech@ens.ens.fr, shirley@iuvax.cs.indiana.edu, turner@apple.com Subject: standard scenes Cc: hanrahan@cs.princeton.edu Status: RO I think Greg's approach to standard scenes is a good idea. Before we go to far, I wonder what geometric primatives should be used... just polygons? Also, perhaps the test images should have pretty full spectral solutions, so that different color models could also be tested. Finally, I have a nit-picking question for everyone-- we have diffuse and (specular or mirror or perfect specular or mirror specular) and in between these we have (rough specular or imperfect specular or specular or glossy). What do you think is the preferred terminology? As far as I can tell, the Europeans usually use `specular' to mean `not diffuse'. This would be consistent with the perfect/mirror specular-> rough specular-> diffuse terminology. Also, does rough specular include reflectance that is just barely not diffuse? I don't really think it matters what terms are used, as long as we all use the same terms. pete From ph@miro.berkeley.edu Mon Aug 20 16:08:27 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA15214; Mon, 20 Aug 90 16:08:23 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Mon, 20 Aug 90 16:08:16 PDT Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA12876; Mon, 20 Aug 90 16:09:03 PDT Received: by miro.Berkeley.EDU (4.1/1.41) id AA04801; Mon, 20 Aug 90 16:06:47 PDT Date: Mon, 20 Aug 90 16:06:47 PDT From: ph@miro.berkeley.edu (Paul Heckbert) Message-Id: <9008202306.AA04801@miro.Berkeley.EDU> To: globillum@miro.berkeley.edu Subject: How to use globillum mailing list Status: RO I've set things up so that you can now send mail to globillum@miro.berkeley.edu in order to send mail to everyone on the global illumination mailing list. This way there will be one master copy of the mailing list, and we can avoid the update problem that would occur if we all kept separate copies. Here's an updated version of the .mailrc file, with corrections (Greg Ward, 'globillum' alias) and additions (Don Greenberg, Pat Hanrahan) to the list. ---- # GLOBAL ILLUMINATION MAILING LIST, 8/20/90 # append the following to your .mailrc file # # send corrections/additions to Paul Heckbert # note: preferred way to send mail to everyone on list is to mail to # globillum (aliased below), where a master copy of list is being maintained. alias globillum globillum@miro.berkeley.edu alias globillum_explicit \ amanatides arvo asensio baum buckalew \ campbell carlton chen mcohen \ fussell george greenberg greene haines \ hanrahan heckbert lalonde dmitchell puech \ rushmeier shirley sillion turner jwallace ward # John Amanatides, York U, Toronto alias amanatides amana@yetti.yorku.ca # Jim Arvo, Apollo / Yale alias arvo arvo@apollo.hp.com alias arvo2 arvo@yale.edu # Frederic Asensio, LIENS alias asensio asensio@ens.ens.fr # Dan Baum, Silicon Graphics alias baum drb@sgi.com # Chris Buckalew, Cal Poly alias buckalew buckalew@polyslo.calpoly.edu # Jim Bullis, Dicomed -- not on net # A. T. Campbell III, U of Texas, Austin alias campbell atc@cs.utexas.edu # Eloise Carlton, Fujitsu America alias carlton eloisec@fai.com # Eric Chen, Apple alias chen chense@apple.com # Michael Cohen, U of Utah alias mcohen m-cohen@cs.utah.edu # Don Fussell, U of Texas, Austin alias fussell fussell@cs.utexas.edu # David George, Cornell U alias george dwg@squid.graphics.cornell.edu # Don Greenberg c/o Fran Brown, Cornell U alias greenberg fbm@squid.graphics.cornell.edu # Ned Greene, Apple / U of California, Santa Cruz alias greene greene@apple.com # Eric Haines, 3D/Eye alias haines erich@eye.com # Pat Hanrahan, Princeton U alias hanrahan pmh@princeton.edu # Paul Heckbert, U of California, Berkeley alias heckbert ph@miro.berkeley.edu # Paul Lalonde, Queen's U alias lalonde lalonde@cs.dal.ca # Don Mitchell, Bell Labs, Murray Hill NJ alias dmitchell don@research.att.com # Claude Puech, LIENS / Stanford alias puech puech@ens.ens.fr # Holly Rushmeier, Georgia Tech alias rushmeier hr3@hydra.gatech.edu # Pete Shirley, Indiana U alias shirley shirley@iuvax.cs.indiana.edu # Francois Sillion, Cornell U alias sillion fxs@squid.graphics.cornell.edu # Doug Turner, Apple alias turner turner@apple.com # John Wallace, 3D/Eye alias jwallace johnw@eye.com # Greg Ward, Lawrence Berkeley Lab alias ward gjward@lbl.gov # END OF GLOBAL ILLUMINATION MAILING LIST From eye!erich@uu.psi.com Tue Aug 21 08:18:44 1990 Return-Path: Received: from uu.psi.com (136.161.128.3) by hobbes.lbl.gov (3.2/SMI-3.2) id AA15687; Tue, 21 Aug 90 08:18:39 PDT Received: from eye.UUCP by uu.psi.com (5.61/3.1.081490-Performance Systems International-Albany) id AA14178; Tue, 21 Aug 90 11:15:11 -0400 Received: from juniper by eye with SMTP (15.11/15.6) id AA06907; Mon, 20 Aug 90 14:29:00 edt Received: by juniper (15.11/15.6) id AA02193; Mon, 20 Aug 90 14:28:56 edt Date: Mon, 20 Aug 90 14:28:56 edt From: Eric Haines Message-Id: <9008201828.AA02193@juniper> To: arvo@apollo.hp.com, asensio@dmi.ens.fr, atc@cs.utexas.edu, buckalew@polyslo.calpoly.edu, chense@apple.com, drb@sgi.com, dwg@squid.graphics.cornell.edu, eloisec@fai.com, fussell@cs.utexas.edu, fxs@squid.graphics.cornell.edu, greene@apple.com, greg@hobbes.lbl.gov, hr3@hydra.gatech.edu, johnw@eye.com, lalonde@cs.dal.ca, m-cohen@cs.utah.edu, ph@miro.berkeley.edu, puech@dmi.ens.fr, shirley@iuvax.cs.indiana.edu, turner@apple.com Subject: bibliography, etc Cc: erich@juniper Status: RO Dear global illuminator, I've compiled a radiosity bibliography which seems to be pretty complete. An early version of this bibliography appeared on comp.graphics some weeks ago, and I've received some additions since that time. In a few weeks I'll put this bibliography on some FTP-able site and will announce it here. If you want it earlier, write and ask me for a copy (I'm in the 2400 baud modem boondocks, so am trying to avoid sending it out en masse). Before I do so, I want to make sure that the list is as complete as possible. So, if you know of any references (including thesis titles) that are missing from the below, please send them on to me. Incidentally, the term "radiosity bibliography" is not quite right. I considered "global illumination bibliography", but this is also incorrect (and too wordy). Ray tracing is a global illumination technique, and I don't bother to include most ray tracing references - these references are already in a separate list compiled by Paul Heckbert and myself (write me for the latest version). The references I've included here are primarily concerned with radiosity per se, but is actually a collection of articles covering secondary global illumination effects not simulated by classical ray tracing. For example, Kajiya's "Rendering Equation" paper is included in the list. So, here's the list of titles. I have not added all the Eurographics workshop '90 articles on radiosity yet (I need to borrow this proceedings from John Wallace), so don't bother sending these to me. Note that some of the titles have been cut short (i.e. whatever didn't fit on one line) - I generated this list using "grep", "vi", and "sort", so it's nothing fancy. A Catalog of Radiation Configuration Factors A General Two-Pass Method Integrating Specular and Diffuse Reflection A Hardware Solution to the Two-Pass Approach for Rendering of Artificial A Model for the Interaction of Light Between Diffuse Surfaces A New Radiosity Approach by Procedural Refinements for Realistic Image A New and Simpler Formulation for Radiative Angle Factors A Progressive Radiosity Method and its Implementation in a Distributed A Progressive Refinement Approach to Fast Radiosity Image Generation A Radiosity Method for Non-Diffuse Environments A Radiosity Method for the Realistic Image Synthesis of Complex Diffuse A Ray Tracing Algorithm for Progressive Radiosity A Ray Tracing Method for Illumination Calculation in Diffuse-Specular Scenes A Ray Tracing Solution for Diffuse Interreflection A Shading Method for Computer Generated images A Shading Model for Atmospheric Scattering Considering Luminous Intensity A Two-Pass Solution to the Rendering Equation: A Synthesis of Ray Tracing A VLSI System Architecture for High-Speed Radiative Transfer 3D Image Accelerated Radiosity Method for Complex Environments Accelerating the Hemi-Cube Algorithm for Calculating Radiation Form Factors Acceleration Techniques for Progressive Refinement Radiosity Adaptive Mesh Generation for Global Diffuse Illumination Adaptive Radiosity Textures for Bidirectional Ray Tracing Algorithms for Calculating Radiation View Factors Between Plane Convex An Analysis and Modification of Shao's Radiosity Method An Efficient Radiosity Approach for Realistic Image Synthesis An Efficient Radiosity Solution for Bump Texture Generation An Experimental Evaluation of Computer Graphics Imagery Atmospheric Illumination and Shadows Backward Ray Tracing Bi-directional Ray Tracing Calculations of the Radiation Configuration Factor Using Ray Casting Caustics and Specular Reflection Models for Spherical Objects and Lenses Continuous Tone Representation of Three-Dimensional Objects Illuminated by Continuous Tone Representation of Three-Dimensional Objects Taking Account Determination of Configuration Factors of Irregular Shapes Distributed Ray Tracing Engineering Radiation Heat Transfer Extending the Radiosity Method to Include Specularly Reflecting and Extending the Radiosity Method to Transmitting and Specularly Reflecting Fundamentals of Three-Dimensional Computer Graphics Image Synthesis Image Synthesis Using Radiosity Methods Image and Intervisibility Coherence in Rendering Improved Techniques for Progressive Refinement Radiosity Improving Interaction with Radiosity-based Lighting Simulation Programs Improving Radiosity Solutions Through the Use of Analytically Determined Incorporating the BRDF into an Infrared Scene Generation System Incremental Radiosity: An Extension of Progressive Radiosity to an Interactive Computer Graphics: Functional, Procedural, Light-Water Interaction using Backward Beam Tracing Modelling the Interaction of Light Between Diffuse Surfaces Octant Priority for Radiosity Image Rendering Particle Transport and Image Synthesis Photosimulation: Interreflection with Arbitrary Reflectance Models and Practical Aspects of Distributed Ray Tracing Radiant Interchange in an Enclosure with Specular Surfaces and Enclosures Radiation Heat Transfer Radiative Heat Exchange Between Surfaces with Specular Reflection Radiative Transfer Radiative Transfer Radiosity Radiosity Redistribution for Dynamic Environments Radiosity: A Method for Computing Global Illumination Ray Tracing Volume Densities Real Time Radiosity Through Parallel Processing and Hardware Acceleration Realistic Image Synthesis for Scenes with Radiatively Participating Media Stochastic Sampling in Computer Graphics The Back-Buffer Algorithm: An Extension of the Radiosity Method to Dynamic The Hemi-Cube: A Radiosity Solution for Complex Environments The Radiosity Model The Rendering Equation The Zonal Method for Calculating Light Intensities in the Presence of a Thermal Radiation Heat Transfer Towards Image Realism with Interactive Update Rates in Complex Virtual Two Adaptive Techniques Let Progressive Radiosity Outperform the Traditional That's it - anything I missed? Eric Haines, 3D/Eye Inc erich@eye.com From greg@hobbes.lbl.gov Wed Aug 29 16:07:19 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA09750; Wed, 29 Aug 90 16:07:16 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Wed, 29 Aug 90 16:07:13 PDT Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA13901; Wed, 29 Aug 90 16:08:10 PDT Received: from lbl.gov by miro.Berkeley.EDU (4.1/1.41) id AA01857; Wed, 29 Aug 90 16:00:54 PDT Received: from hobbes.lbl.gov by lbl.gov (4.1/1.39) id AA13874; Wed, 29 Aug 90 16:02:07 PDT Received: by hobbes.lbl.gov (3.2/SMI-3.2) id AA09731; Wed, 29 Aug 90 16:01:01 PDT Date: Wed, 29 Aug 90 16:01:01 PDT From: greg@hobbes.lbl.gov (Gregory J. Ward) Message-Id: <9008292301.AA09731@hobbes.lbl.gov> To: globillum@miro.berkeley.edu Subject: standard models Status: RO Hi everyone, I was talking with Peter Shirley again about the standard models for comparing simulations. Here is what Pete wrote to me about my program: Radiance's input files made me think that getting standard scenes for global illumination may be a pain... "true" radiosity code will need polygonal connectivity info, while radiance-like codes will not, etc. Also, there doesn't seem to be boiling interest in generating standard scenes (just using them!)... I don't think Eric Haines will do such public service again. Also, solid procedural textures seem to be getting pretty wide acceptance. Should your "complex" scene have these? If so, we may need to supply a deterministic random number generator. Perhaps we could start just with that Cornell box. Pete And my response: I think we are such a distance from good simulations of general scenes that if we start with simple stuff and try to do it right, by the time we get somewhere we'll have figured the rest of it out. Creating the basic models shouldn't be too much trouble. I'd even do it myself but I need some feedback from the other folks who would be using it. A text description of the scene with a few coordinate values would probably suffice for the basic stuff -- let people enter whatever info. their software needs when they run it. As far as the complex geometries go, I think that the sky could be the limit. If the simulation doesn't support all the stuff that's required, it's all part of the approximation. I think we do need to set an agenda of what people think is interesting to simulate. For example, we will certainly want to model architectural spaces, but maybe we don't care about how light travels through the ocean. (Then again, maybe someone does...) As I mentioned before, I think the real difficulty is not in deciding what to model, but in deciding how to compare simulations. Let's get some chatter from the rest of you folks. What do you want to simulate and how should we evaluate the results? -Greg From hr3@prism.gatech.edu Thu Aug 30 07:50:03 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA10811; Thu, 30 Aug 90 07:49:59 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Thu, 30 Aug 90 07:49:53 PDT Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA15374; Thu, 30 Aug 90 07:50:51 PDT Received: from hydra.gatech.edu by miro.Berkeley.EDU (4.1/1.41) id AA14779; Thu, 30 Aug 90 07:42:37 PDT Received: by hydra.gatech.edu (5.61/3.1) id AA08613; Thu, 30 Aug 90 10:42:50 -0400 Date: Thu, 30 Aug 90 10:42:50 -0400 From: hr3@prism.gatech.edu (RUSHMEIER,HOLLY E) Message-Id: <9008301442.AA08613@prism.gatech.edu> To: globillum@miro.berkeley.edu Subject: standards chatter Status: RO In response to what Greg had to say about standards, I think we ought to begin with really simple test cases. I have been experimenting with the sort of results I would be able to produce, and I found that to get a solution within 5% or +-5 (out of 255) at each pixel, it took me nearly 14 hours to get a 40 x 200 image of a relatively low reflectivity scene of 18 planar surfaces with one diffuse light source. This brings up a couple of points -- even though my program is really inefficient and I'm just using a personal Iris, these standards are going to take serious lengths of time. The second issue is I expect most of you would like to know why I think I am coming up with an exact solution and why I think I can make any statements about its accuracy. I think at least a couple of different people are going to have to produce the same standard images independently for anyone to have confidence in them. Addressing the problem of comparing simulations, I don't think we can come up with a consensus on how to do that -- but as a group perhaps we could create a library of environment descriptions and images that people are willing to contribute so that we could compare our methods against one another and begin a discussion of what differences appear, and which difference are important and which aren't. -- Holly From eye!erich@uu.psi.com Thu Aug 30 08:45:11 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA10843; Thu, 30 Aug 90 08:45:07 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Thu, 30 Aug 90 08:45:05 PDT Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA15571; Thu, 30 Aug 90 08:45:53 PDT Received: from uu.psi.com by miro.Berkeley.EDU (4.1/1.41) id AA15383; Thu, 30 Aug 90 08:37:27 PDT Received: from eye.UUCP by uu.psi.com (5.61/3.1.082190-Performance Systems International-Albany) id AA19598; Thu, 30 Aug 90 11:34:08 -0400 Received: from juniper by eye with SMTP (15.11/15.6) id AA03900; Thu, 30 Aug 90 10:44:19 edt Received: by juniper (15.11/15.6) id AA00530; Thu, 30 Aug 90 10:44:16 edt Date: Thu, 30 Aug 90 10:44:16 edt From: eye!erich@uu.psi.com Message-Id: <9008301444.AA00530@juniper> To: globillum@miro.berkeley.edu Subject: Databases Cc: cornell!hp-pcd!uoregon!gary%uu.psi.com@Csa1.lbl.gov, cornell!wisdom.graphics.cornell.edu!roy%uu.psi.com@Csa1.lbl.gov, erich@juniper.berkeley.edu Status: RO I just received Greg's mail about his dialogue with Pete Shirley. Some things come to mind which I thought I'd pass on: - Any radiosity databases which get distributed will be much different from the SPD (Standard Procedural Databases - sphereflake, the tetra, etc) package I made. SPD tested efficiency, not shading quality, so there's not even an ability to set lighting intensity. Also, the procedural element is not as important to radiosity testing (though it wouldn't hurt - we'll want more complicated models as time goes on). There certainly doesn't seem to be a point to a procedural Cornell cube (except perhaps meshing). - Pete brings up connectivity specification. Is this truly necessary? As someone in the commercial world who is usually handed a bunch of separate polygons and told to render them using radiosity techniques, I think of connectivity as the programmer's task. Greg's "Radiance" software certainly does not need it, nor does HP's radiosity software (though it helps). Our goal is to give a minimal but complete description of the lighting and shading characteristics of an environment. Researchers could provide derived descriptions (or better yet, code to generate these descriptions), such as connectivity, meshing, etc, but these would not be a part of the scene; rather, they would be useful additional structures. - So, how can we minimally specify shading? Seems like someone like Greg Ward (hint, hint) or Gary Meyer or Roy Hall would be well-qualified for this task. One thing that should probably be allowed is simplification and conversion from the original description. For example, the database could actually provide spectral curves to some resolution (say, sampled every 10 wavelengths), though in practice most researchers might simply derive an RGB triplet from this data. My question is, how far should a surface's description be taken? Should we give descriptions of two input functions like Cook & Torrance's reflectance function, which is a function of wavelength and angle of incidence? Most people won't use it, but for a more realistic result you need it. Researchers should describe their simplifications (or extensions) of the shading data. - Lighting is also an interesting question. Are point lights "legal" in any sense? There's also very few true "area" lights: rather, there is some volume which is excited and emits photons, which then hit some diffusing media (the light bulb surface, or the translucent panel in from of the fluorescent lights, etc). How far do we take this description? - The question of comparison is certainly interesting. The least common denominator seems to be some rendering at some resolution (as opposed to providing RGB/vertex polygons, or somesuch). This makes for bulky comparisons - you certainly don't want to mail them to people not on the Internet or without lots of free disk space. As far as comparison goes, taking some measure of the variance between your results and the "true" images seems reasonable. - I see the "true" benchmark images as being a little tricky - when do you call it quits? The problem is that whatever image we agree is "the most physically-based" is then the image to beat. The assumptions made for that image can be improved upon by the next implementor, who may then claim his image is more realistic. Comparisons of images is also not a one dimensional task: one may use a more realistic shading model, while the other uses a superior sampling and filtering technique. All this makes me feel eminently unqualified to try to come up with some reasonable test models. The relatively easy part is the gross geometry - it's the shading (possibly including microgeometry or texturing) and lighting specification that's the challenge. Probably the best thing to do at this point is to start with something simple (like the Cornell cube) and start comparing results and see where we diverge (e.g. "Hmmm, so you use a gamma correction of 2.2, but I use 2.4"). The idiot version of the Cornell cube would be (from Goral84): left face (red) rho = 1.0, 0.0, 0.0 right face (blue) rho = 0.0, 0.0, 1.0 top face rho = 0.84, 0.84, 0.84 center face rho = 0.84, 0.84, 0.84 bottom face rho = 0.54, 0.54, 0.54 back face (light source) rho = 0.8, 0.8, 0.8 and emissivity = 1.27, 1.27, 1.27 A fairly simple kind of thing: what would you like expanded upon (or simplified, if that's possible)? Eric Haines, erich@eye.com From atc@cs.utexas.edu Thu Aug 30 11:37:02 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA11216; Thu, 30 Aug 90 11:36:57 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Thu, 30 Aug 90 11:36:51 PDT Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA16259; Thu, 30 Aug 90 11:37:49 PDT Received: from cs.utexas.edu by miro.Berkeley.EDU (4.1/1.41) id AA18486; Thu, 30 Aug 90 11:26:42 PDT Posted-Date: Thu, 30 Aug 90 13:26:48 CDT Message-Id: <9008301826.AA06761@cs.utexas.edu> Received: by cs.utexas.edu (5.64/1.76) From: atc@cs.utexas.edu (Alvin T. Campbell III) Date: Thu, 30 Aug 90 13:26:48 CDT X-Mailer: Mail User's Shell (6.5.6 6/30/89) To: globillum@miro.berkeley.edu Subject: scene specification standards Cc: atc@cs.utexas.edu Status: RO Fellow global illuminators, I am impressed by everyone's spirit of cooperation in this discussion of standard scenes and standard scene description formats. While I appreciate the ambitious goals of some people to create a very flexible, extensible format, now does not seem to be the time for such an effort. There are several reasons. First, most people are only working with simple lighting models (pure diffuse, classical Phong specular/diffuse combination, and possibly texture mapping) and geometric primitives (generally only polygons). It would be terrible to waste time adding features no one would use. Second, we still have a lot of work to do before we have generally acceptable solutions that work for these cases. Thus it would be a long time before we get to move to these advanced features. Finally, we are doing research in rendering, not user interfaces or programming language design, so spending much time on this takes away from our real research efforts. We need to decide what essential elements to put in the description, and leave it at that for now. Consider the scene geometry. For now, I suggest that our only primitives be planar convex polygons. Other geometric items can be added easily later, but this should meet most people's needs. We should use the minimal number of polygons to describe the scene, with no patch/element subdivision specified. This would allow people doing research in mesh generation, such as myself, to have unlimited freedom in dividing up the surfaces as we, and our algorithms, see fit. Also, this eliminates the need for polygon connectivity/neighborhood information in the format. As far as I can tell, most people are currently using uniform subdivision and restricting their scenes to to rectangular polygons. This type of subdivision is straightforward to implement, so if people want to experiment with identical meshes, it would be sufficient to associate an element size with each polygon in the scene. The subdivision would be deferred until program execution, so those of us who want to explore our own meshing schemes could simply ignore the element size information. Moving beyond geometry, we have camera descriptions. Anything unambiguous is fine with me. I think the type of information in Eric Haines's NFF format (eye position, lookat position, up vector) is sufficient. Next we need to come up with a color model. As much as I hate to admit it, RGB triples seem to be the most common thing going, so we should probably just use these. Light source colors, as well as reflection spectra, should be described by three floating point values. I am unsure whether we should put any limitations on the ranges of these values. One one hand, it seems a good idea to limit emittances to being nonzero and reflectances to being in the range [0,1). On the other hand, I know people who use "negative light" and other such abstractions, so these people may feel restricted by such a format. Now, we need to describe light sources. I believe that we can get away with a few standard types of emission. For area light sources, we can simply instance a light source in an optional field of the polygon descriptions, as shown below. light diffuse 100. 100. 100. I am inclined to stop with area light sources, but if others want to include point or infinite sources, I can be pursuaded. Next, we come to reflection. I think that a very few standard reflectance models should be used (diffuse and Phong should suffice). For colors, either an RGB triple or a texture should be used. The reflectance and color could be specified as shown below. # R G B shading diffuse color .9 .9 .9 # Kd Ks Exponent shading phong .6 .4 12 texture "mandrill" There are a few issues that remain. First is image resolution. This can be easily specified in the file. Next is image file format, both for textures and final images. We probably need to pick some existing format (UTAH RLE, GIF, TIFF, ...) and stick with it. I hope that we can get this standardization effort over as soon as possible. I can't wait to start start sharing models. Then we can spend our time generating images, timings, analyses, and all those other things we do in our pursuit of scientific research. A. T. Campbell From shirley@iuvax.cs.indiana.edu Thu Aug 30 12:20:15 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA11316; Thu, 30 Aug 90 12:20:10 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Thu, 30 Aug 90 12:20:08 PDT Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA16501; Thu, 30 Aug 90 12:21:06 PDT Received: from iuvax.cs.indiana.edu by miro.Berkeley.EDU (4.1/1.41) id AA19475; Thu, 30 Aug 90 12:14:34 PDT Message-Id: <9008301914.AA19475@miro.Berkeley.EDU> Received: by iuvax.cs.indiana.edu Date: Thu, 30 Aug 90 14:14:45 -0500 From: shirley@iuvax.cs.indiana.edu To: globillum@miro.berkeley.edu Subject: standards Status: RO I think A.T.'s desire to keep things simple makes sense (especially leaving mesh generation up in the air. I hadn't thought of that). Perhaps somebody could donate a default subdivision code? I don't like the idea of RGB though. I use a spectral model and converting from RGB to spectral is a one-to-many mapping. I'd rather have spectral descriptions and a simple filter for spectral-to-RGB. Not as big an issue to me is the lighting model, but I'd prefer a specification of material constants that is more physically based (index of refraction and extinction coefficient for metals for example), but if I am in a minority here I'll adapt. I also have some rather brute force radiosity code that could generate a "correct" result. It would be great to compare that with other brute force methods to see if we could have a reliable "real solution". We could run a feasibility study on that Cornell box. I can send out mine, but the exact dimensions are probably off. Does anybody have access to "the real thing"? pete PS-- I would LOVE it if we all had a standard image format. Somebody at the lunch mentioned a 4-byte format (per pixel, 1 exponent byte) that sounded sensible. Anybody have more inf on that? From arvo@apollo.com Thu Aug 30 14:01:40 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA11422; Thu, 30 Aug 90 14:01:36 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Thu, 30 Aug 90 14:01:30 PDT Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA16948; Thu, 30 Aug 90 14:02:18 PDT Received: from amway.apollo.com (amway.ch.apollo.hp.com) by miro.Berkeley.EDU (4.1/1.41) id AA21231; Thu, 30 Aug 90 13:54:20 PDT Received: from xuucp.ch.apollo.hp.com by amway.apollo.com id Thu, 30 Aug 90 16:52:47 EDT Received: by xuucp.ch.apollo.com id ; Thu, 30 Aug 90 16:40:05 EDT Message-Id: <9008302040.AA10842@xuucp.ch.apollo.com> Received: by daphne.ch.apollo.hp.com id AA17976; Thu, 30 Aug 90 16:50:08 EDT From: arvo@apollo.com Date: Thu, 30 Aug 90 16:05:24 EDT Subject: some syntax To: globillum@miro.berkeley.edu Status: RO People seem to be in favor of keeping the scene description simple and forging ahead as soon as possible (I count myself among them). So, here are some specific suggestions for syntax. Maybe we can iterate to something which is at least tolerable to everyone very quickly so we can start making pictures and debating about who's pixels are right! I agree with Eric's point that polygon connectivity is the "programmer's job", but then it would also be nice to make the information easy to get at. For instance we could use the "connection-list" format for polygons, which would be somewhat compact (if there are a lot of shared vertices), and would be very simple to extract polygon connectivity information from. vertex 1 x y z vertex 2 x y z vertex 3 x y z vertex 4 x y z . . polygon 1 2 3 polygon 8 9 13 14 90 . . . As for the camera specification, I agree with A.T. that anything unambiguous is fine, so here is his suggestion (originally from Eric Haines) with a couple more pieces of information to make it complete. (Eric, how did you specify the window, etc., or did you use "field of view"?) eye position x y z lookat position x y z up vector x y z viewplane distance d viewplane window left right bottom top image resolution nx ny Where "viewplane distance" is the distance from "eye position" to the viewplane, and "viewplane window" specifies the aperture rectangle on the viewplane. We will want to include comments in these files, for instance to describe what the scene is, what a certain sub-componenet is, etc. So, we should agree on a syntax for comments: /* Allow c-style comments? */ % Maybe everything after a "%" is ignored to the end of the line? There seems to be a call for spectral definitions of colors. Can someone toss out a possible syntax for this? I think that if the definition is long (i.e. lots of numbers) we will want to define symbolic names for them, such as define spectral color APPLE_RED ......lots of data....... This is a little farther out, and I'd like to not impede progress toward a simple and useable scheme, but... I would like to be able to include the exact mathematical expressions for the reflectance functions used. This will be more relevant to scenes with non-ideal specular & duffuse surfaces, but it's something to think about. -- Jim From arvo@apollo.com Thu Aug 30 14:48:15 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA11486; Thu, 30 Aug 90 14:48:10 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Thu, 30 Aug 90 14:48:03 PDT Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA17170; Thu, 30 Aug 90 14:49:00 PDT Received: from amway.apollo.com (amway.ch.apollo.hp.com) by miro.Berkeley.EDU (4.1/1.41) id AA22192; Thu, 30 Aug 90 14:40:19 PDT Received: from xuucp.ch.apollo.hp.com by amway.apollo.com id Thu, 30 Aug 90 17:38:47 EDT Received: by xuucp.ch.apollo.com id ; Thu, 30 Aug 90 17:26:03 EDT Message-Id: <9008302126.AA11134@xuucp.ch.apollo.com> Received: by daphne.ch.apollo.hp.com id AA18462; Thu, 30 Aug 90 17:30:22 EDT From: arvo@apollo.com Date: Thu, 30 Aug 90 16:48:25 EDT Subject: confidence! To: globillum@miro.berkeley.edu Status: RO This may be putting the cart somewhat before the horse, but I'd like to address the very good point which Holly raised. How can we have confidence in someone else's solution? Reflecting on this for a while, I can only think of two ways: 1) Different algorithms implemented by independent researchers produce the same results (+-epsilon) when run on the same test scenes. 2) The source code for the solver is made public as part of the solution. Presumably the first one is what we'd like to accomplish by defining a collection of standarized test environments. But it will take time for a consensus to emerge (I would guess) and differences to be explained (as Holly pointed out). The second option would be effective in raising confidence in the solution ONLY if the code can be "verified by inspection". (I don't mean verification in any strict sense -- just informally verified.) If it consists of 10,000 lines of obscure APL (for instance), having and running the code will only serve to verify that the same results can be obtained on different machines. This is not entirely without merit, but it doesn't address the bigger issue. If, on the other hand, the algorithm is easy enough to discern and verify as being physically correct, though perhaps unbearably inefficient, then we have something. It's the same idea as writing a good proof. It must be clear or it fails to be convincing, and if it's not convincing, it fails to be a proof (at least not a good proof). Now, is it possible to come up with such an algorithmic "proof"? Well, as Greg Ward has already suggested, Monte Carlo is a possibility. Here are some of the advantages and disadvantages of using Monte Carlo as a means of generating solutions for the sandard test scenes. Advantages of Monte Carlo Simple to write and (potentially) easy to verify by inspection. Very amenable to complex environments & BRDFs Therefore: source code could be small, easy to understand, and usable as a solver for almost any scene. Disadvantages of Monte Carlo Slow convergence Noisy solutions The advantages make it a good candidate for a verifiable solver, especially if it uses a strictly "naive" Monte Carlo (i.e. no variance reduction through stratification, importance sampling, etc. unless these can be done in an utterly transparent fashion and proven to be unbiased). But what about the disadvantages? Slow convergence isn't such an awful problem for the following reasons 1) The solver could be run to high precision by anyone who has lots of spare cycles on a fast machine, perhaps letting it run for a week. (I have an Apollo DN10000 sitting in my office which I wouldn't hesitate to use for such a purpose.) 2) The solution needn't be high resolution (maybe some will disagree with me on this). If we had "exact" solutions at a sparse collection of points (maybe 16x16) on the image plane of a standard view, then that would be amenable to publishing as a table, which might be the most useful means of making the information known and available. But what about the second problem: noisy solutions. While it is true that Monte Carlo will produce answers with statistical variation, that variation can be made resonably small and can be estimated (via the sample variance) and supplied as part of the solution. Once we've agreed upon a scene description, I volunteer to take a stab at supplying a "verifiable-by-inspection" Monte Carlo solver and enough CPU cycles to produce good answers. Is anyone else interested in this aspect of the problem (i.e. algorithmic "verifiability")? -- Jim P.S. The whole issue of verifiability hinges on having agreed upon the underlying mathematical model, of course. I'm assuming that this won't be much of an issue until we get into more complex things such as arbitrary BRDFs, texture mapping, etc. Maybe I'm overly optimistic :-) From atc@cs.utexas.edu Thu Aug 30 16:57:50 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA11683; Thu, 30 Aug 90 16:57:46 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Thu, 30 Aug 90 16:56:40 PDT Received: from cs.utexas.edu by lbl.gov (4.1/1.39) id AA17772; Thu, 30 Aug 90 16:57:31 PDT Posted-Date: Thu, 30 Aug 90 18:40:45 CDT Message-Id: <9008302340.AA05301@cs.utexas.edu> Received: by cs.utexas.edu (5.64/1.76) From: atc@cs.utexas.edu (Alvin T. Campbell III) Date: Thu, 30 Aug 90 18:40:45 CDT X-Mailer: Mail User's Shell (6.5.6 6/30/89) To: amana%yetti.cs.yorku.ca%cs.utexas.edu@Csa1.lbl.gov, arvo@apollo.hp.com, asensio@dmi.ens.fr, drb@sgi.com, buckalew@polyslo.calpoly.edu, atc@cs.utexas.edu, eloisec@fai.com, chense@apple.com, m-cohen@cs.utah.edu, fussell@cs.utexas.edu, dwg@squid.graphics.cornell.edu, fbm@squid.graphics.cornell.edu, greene@apple.com, erich@eye.com, pmh@princeton.edu, ph@miro.berkeley.edu, lalonde%cs.dal.ca%cs.utexas.edu@Csa1.lbl.gov, don@research.att.com, puech@dmi.ens.fr, hr3@hydra.gatech.edu, shirley@iuvax.cs.indiana.edu, fxs@squid.graphics.cornell.edu, turner@apple.com, johnw@eye.com, gjward@Csa1.lbl.gov Subject: more on standards Cc: atc@cs.utexas.edu Status: RO Global Illuminators, I like a lot of the specific suggestions that have been tossed out today. Jim's proposal of the connection list structure for polygon vertices sounds fine. However, there is a point that we must address very early in the specification process. Should a scene specification be completely contained in one file, or should the geometry, emittance, relectance, and other types of data be in separate files? I have tried both approaches, and generally find it much easier to keep everything in one file. But I know several formats (DEC's OFF, for instance) which keeps things separate. Jim's example gives me the feeling that he may use this approach. What do most people want to use? My preference for comments within the file is to have a special comment character ('%', '#', or '!' seem likely), after which the rest of the line is ignored. This is easy to parse, works well, and allows easy commenting-out of parts of the database. With C-style comments, there are the added problems of commenting out sections already containing comments. Spectral definitions of colors pose an interesting problem. Basically, we want to specify the shape of a reflectance curve over a range of wavelengths. This can be done with wavelength/reflectance pairs, together with a specified interpolation function. Thus we would have something like color apple_red wavelengths 300 400 500 600 700 800 reflectance .1 .4 .7 .8 .2 .6 interpolant linear color black wavelengths 0 800 reflectance 0 0 interpolant linear color weird wavelengths 0 100 200 220 225 300 301 500 800 reflectance .1 .99 .1 .23 .1 .8 .7 .2 .9 interpolant cubic_spline To perform our shading calculations, we should specify the wavelengths of interest. Then each of colors could be sampled at these wavelengths using the interpolants, and we will have a consistent number of color samples for each surface and light source in the scene. The specification of sampling can be done like the following. sample wavelengths 100 200 700 800 % (nm) Of course, we must then have a mapping from the spectral values to our ultimate RGB result. I have used a complicated procedure described in Roy Hall's book, which requires a lot of information about the destination monitor, among other things. If we do this, we must decide on common monitor specifications to compare RGB's directly. Is this what most people want to do? I like Jim's and Pete's desires to specify arbitrary reflectance functions, but I worry that much effort in that direction could get out of hand. In the extreme, we could re-invent RenderMan. It would be much easier to simply predefine a set of reflectance functions, and then add to them as needed. Please let me know what you think. I would like to see us develop something good. A. T. From greg@hobbes.lbl.gov Thu Aug 30 23:18:34 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA12021; Thu, 30 Aug 90 23:18:31 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Thu, 30 Aug 90 23:18:30 PDT Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA18336; Thu, 30 Aug 90 23:19:30 PDT Received: from lbl.gov by miro.Berkeley.EDU (4.1/1.41) id AA29760; Thu, 30 Aug 90 23:10:52 PDT Received: from hobbes.lbl.gov by lbl.gov (4.1/1.39) id AA18321; Thu, 30 Aug 90 23:12:02 PDT Received: by hobbes.lbl.gov (3.2/SMI-3.2) id AA11997; Thu, 30 Aug 90 23:10:54 PDT Date: Thu, 30 Aug 90 23:10:54 PDT From: greg@hobbes.lbl.gov (Gregory J. Ward) Message-Id: <9008310610.AA11997@hobbes.lbl.gov> To: globillum@miro.berkeley.edu Subject: That's more like it! Status: RO Good chatter out there, team! I'm glad to see so many good suggestions on scene specification. It's an education just hearing what other people have been using. Let's not get too bogged down in the details of syntax and so on. (I vote for '#' preceding comments...) We're all programmers, so as long as the information is there, I think we can all figure out how to use it. It's impossible to avoid evolution in file formats so there's little use in trying to standardize it beforehand. Nevertheless, I'd like to throw in my two cents to the discussion on scene information. As I see it, there are four basic areas that demand our attention: Surface geometry, Surface reflectance, Light sources and Atmospherics. I want to talk more generally about these areas before getting to back a reasonable starting point for a model. Surface geometry: I think Jim's suggestion for polygons that refer to a vertex list is an excellent least common denominator. An important addition to this would be an interpolating (or texturing) function to determine the surface normal. This becomes very important for specular reflectance models. In the long run, I would like to see us use implicit surfaces and/or parametric specifications. I haven't got any code for tessellating implicit surfaces, but I will gladly make my program for turning parametric surfaces into normal-interpolated polygons available (you may have a better one of your own). Most people would break functional surfaces into such simpler primitives, while the ambitious among us attacked the higher order models directly. Surface reflectance: General surface reflectance is nasty. At a point, reflectance is a function of at least 5 variables: incoming theta and phi, outgoing theta and phi, and wavelength. Reflectance also tends to vary macroscopically, which is why patterns and textures are relied on so heavily in computer graphics. That makes reflectance a function of 7 or 8 variables, depending on whether you use a surface or a solid texture. Here again, I think we should use procedural models, such as the one suggested by A.T. for spectral reflectance. (As in the case of parametric surfaces, the procedures are usually data-driven -- they only serve to interpolate points in a smooth and unambiguous fashion.) I have been involved in the development of a device for measuring the spatial distribution of reflectance (BRDF), and will make data available to those who want it. Light sources: As I mentioned at our lunch meeting, this is a very important area (or point?) that has been ignored by most simulators. Namely, we have all been using diffuse emitters. Wrong, wrong, wrong. I have yet to see a light source that even approaches this ideal. Most luminaires have highly directional distributions by design, and even sources that are meant to be diffuse have lop-sided outputs. Obviously, this has a huge effect on the light distribution in the scene. We must treat light output as dependent on direction, and may even want to consider its variation over the emitting surface. Again, I volunteer to supply some real data (from a luminaire manufacturer) to get people started in the right direction. Volumetrics: We need to consider what happens within volumes. In general, there is scattering, absorption and emission (just like surfaces). I think many of us can simulate absorption, but we need to consider the other effects in the long run. Again, I think interpolated data points is the way to go in the specification. Whoa, hold on, wait just a dad-burned minute! This is all way too complicated to act as a starting point for comparing simulations. This is for later, when we figure out better what we're doing. I just couldn't resist the opportunity to get on my favorite soap box and blow some bubbles. Let's start with the basics. How about an empty rectangular box with diffuse surfaces and a single diffuse (area) light source? If someone would kindly compute a solution, we could all get started. (Who cares if it's right -- that's what we want to argue about, isn't it?) I think we should give a prize to the first person who offers a simple scene specification and a solution. (Pete -- your invisible box counts as the first dataless simulation.) Let's use gray surfaces to make things simple and give the results as point irradiance values (watts/meter^2). An image is more or less irrelevant with diffuse surfaces anyway. The First person to stick their neck out gets to order the pizza next year. (I'll still run for it.) Finally, a couple people mentioned standards for image data. I have been using a 4-byte float format (red,green,blue,exponent) in my image files for some years. This has the advantage of storing the full dynamic range of a simulation, which is going to be important for making comparisons. Rather than describing my file format in gory detail, I thought I would just mail out the code for reading and writing run-length encoded scanlines. There are also some routines in there for converting from spectral data to CIE (XYZ) coordinates and NTSC (RGB). I have been using NTSC for my image files, but the format can store triplets from any color system. As for sharing images over the net, I think we will have to set up ftp sites to get the data across reliably. Compression helps, too. -Greg P.S. Sorry this was so long-winded! From greg@hobbes.lbl.gov Thu Aug 30 23:17:35 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA12015; Thu, 30 Aug 90 23:17:31 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Thu, 30 Aug 90 23:17:28 PDT Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA18333; Thu, 30 Aug 90 23:18:27 PDT Received: from lbl.gov by miro.Berkeley.EDU (4.1/1.41) id AA29763; Thu, 30 Aug 90 23:11:02 PDT Received: from hobbes.lbl.gov by lbl.gov (4.1/1.39) id AA18324; Thu, 30 Aug 90 23:12:13 PDT Received: by hobbes.lbl.gov (3.2/SMI-3.2) id AA12002; Thu, 30 Aug 90 23:11:05 PDT Date: Thu, 30 Aug 90 23:11:05 PDT From: greg@hobbes.lbl.gov (Gregory J. Ward) Message-Id: <9008310611.AA12002@hobbes.lbl.gov> To: globillum@miro.berkeley.edu Subject: scanline code Status: RO Hello again, What follows are routines for reading and writing images in a reasonably compact 4-byte per pixel floating point format. I also have programs available for displaying these images under X10 and X11, and converting to and from some commercial image formats. Also, the Radiance distribution includes programs to do cut and paste, filtering, sizing, and pixel math, among other things. I need to explain what goes at the top of a correct Radiance file to make the picture complete. A few lines of header information, generally ignored by the software acting on the images, is followed by a single empty line (ie. "\n\n" marks the end of header). This in turn is followed by the image dimensions and orientation. In a vain effort to be general, I thought I would allow for any scanline ordering, though I never use anything other than English scanning (left to right, top to bottom). Thus, a typical header might look like this: rview -vp 0.05 0.5 0.5 -vd 1 0 0 -vu 0 0 1 -vh 100 -vv 100 -x 800 -y 800$ EXPOSURE=3.022424e-01$ pfilt -x 512 -y 512 -1 -r 1 $ $ -Y 512 +X 400$ {IMAGE DATA ...} (I put in the dollar signs to show the end of each line.) The header information contains the commands used to create the files, which I often need to figure out where "ugly.pic" came from. The EXPOSURE variable indicates that the pixel values have been scaled. The data is sized and ordered according to the line "-Y 512 +X 400", which means that the y dimension is 512 pixels, and is the major sort in decreasing order. Because the x dimension is given second, it is the minor sort and is increasing. By convention, the x and y coordinate system starts at the lower left corner with x horizontal and y vertical. Your comments are welcome. -Greg [here are the id's of the files I sent in a shar archive] /* SCCSid "@(#)color.h 1.6 1/9/90 LBL" */ static char SCCSid[] = "@(#)color.c 1.11 8/30/90 LBL"; From hr3@prism.gatech.edu Fri Aug 31 07:33:18 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA12237; Fri, 31 Aug 90 07:33:14 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Fri, 31 Aug 90 07:33:13 PDT Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA19117; Fri, 31 Aug 90 07:34:13 PDT Received: from hydra.gatech.edu by miro.Berkeley.EDU (4.1/1.41) id AA05155; Fri, 31 Aug 90 07:27:31 PDT Received: by hydra.gatech.edu (5.61/3.1) id AA23018; Fri, 31 Aug 90 10:27:41 -0400 Date: Fri, 31 Aug 90 10:27:41 -0400 From: hr3@prism.gatech.edu (RUSHMEIER,HOLLY E) Message-Id: <9008311427.AA23018@prism.gatech.edu> To: globillum@miro.berkeley.edu Subject: verifiability Status: RO I am definitely interested in the verifiability issue Jim discussed. I compute my "exact" solutions with a naive Monte Carlo solver, and I don't think we should have a problem agreeing on one even for complicated bidirectional reflectance functions -- either samples from the hemisphere could just be weighted by the function, or for more efficiency a suitable (and verifyable) cdf could be provided with the reflectance function in the specification. I think that giving a small array of radiance values for a small number of pixel centers for one wavelength, accompanied by an array of the sample variances is a good way to start. This avoids complications of wavelength sampling and pixel sampling and would let us compare the results of the interreflection calculations directly. Most of my Monte Carlo code is reading in data and doing ray intersections -- the actual algorithm is pretty short. My code is really a mess and not terribly efficient at doing ray intersections -- I think the best thing to do would be for someone (Jim?) to alter an existing ray tracer (maybe Radiance?) I wrote up my ideas about a naive Monte Carlo solver (which I called the "exclusively Monte Carlo method) in my thesis in chapters 4 and 5, including the treatment of participating media. If anybody has questions about it I would be willing to send them a copy of the appropriate sections. Also I would be willing to review the code whoever comes up with and run it against mine for some simple cases as a check. -- Holly From eye!erich@uu.psi.com Fri Aug 31 08:45:07 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA12297; Fri, 31 Aug 90 08:45:02 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Fri, 31 Aug 90 08:44:57 PDT Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA19426; Fri, 31 Aug 90 08:45:56 PDT Received: from uu.psi.com by miro.Berkeley.EDU (4.1/1.41) id AA05919; Fri, 31 Aug 90 08:38:14 PDT Received: from eye.UUCP by uu.psi.com (5.61/3.1.082190-Performance Systems International-Albany) id AA21644; Fri, 31 Aug 90 11:34:55 -0400 Received: from juniper by eye with SMTP (15.11/15.6) id AA06836; Fri, 31 Aug 90 10:22:54 edt Received: by juniper (15.11/15.6) id AA01539; Fri, 31 Aug 90 10:22:51 edt Message-Id: <9008311422.AA01539@juniper> From: eye!erich@uu.psi.com ( Eric Haines) Date: Fri, 31 Aug 1990 10:22:49 EDT X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: globillum@miro.berkeley.edu Subject: Format Cc: kolb@yale.edu Status: RO Jim Arvo writes: > As for the camera specification, I agree with A.T. that anything unambiguous > is fine, so here is his suggestion (originally from Eric Haines) with a > couple more pieces of information to make it complete. (Eric, how did you > specify the window, etc., or did you use "field of view"?) I used field of view. Since we don't seem to be going much beyond the NFF (Neutral File Format) used in the SPD (Standard Procedural Databases) (got all those acronyms straight?), it might be a good starting point because it already exists and people have already written software or translators for it: at least 10 ray tracers can use it, including Craig Kolb's public domain RayShade and Mark VandeWettering's ray tracer. An even better choice would be Craig Kolb's language definition: it has many more primitives defined, has procedural textures, has modeling matrices, has some primitive area lights, etc. See his RayShade package on weedeater.math.yale.edu [130.132.23.17] for info, doc/rayshade.1 is the man page. There are a lot of other goodies at weedeater, including the latest, much improved Utah Raster Toolkit - I highly recommend this format as the best for 24 bit picture storage and manipulation (and the toolkit has converters to GIF, TIFF, and many other formats). Anyone opposed? > There seems to be a call for spectral definitions of colors. Can someone > toss out a possible syntax for this? I think that if the definition > is long (i.e. lots of numbers) we will want to define symbolic names for > them, such as > > > define spectral color APPLE_RED ......lots of data....... How about something simple like: spectrum APPLE_RED 450 0 460 1.0 470 1.0 471 0.1 510 0 with wavelength and amplitude (0.0 to 1.0), and we linearly interpolate between the closest two wavelengths to get other samples. It's up to the parser to figure out that we're done with data. Worked fine at Cornell. > This is a little farther out, and I'd like to not impede progress toward > a simple and useable scheme, but... I would like to be able to include the > exact mathematical expressions for the reflectance functions used. This > will be more relevant to scenes with non-ideal specular & duffuse surfaces, > but it's something to think about. I'm all for it - anyone have a nice way to do this? > I agree with Eric's point that polygon connectivity is the "programmer's > job", but then it would also be nice to make the information easy to get > at. For instance we could use the "connection-list" format for polygons, > which would be somewhat compact (if there are a lot of shared vertices), > and would be very simple to extract polygon connectivity information from. > > vertex 1 x y z > vertex 2 x y z > vertex 3 x y z > vertex 4 x y z > . > . > > polygon 1 2 3 > polygon 8 9 13 14 90 > . > . > . Sounds great, let's use it - fits in just fine with Kolb's format, I think. --Eric Haines Attached is some relevant documentation from Kolb's RayShade, which I would recommend as a good starting point for an input language (let's not reinvent the wheel): But first, a sample file: /* * generate wood texture on screen */ maxdepth 3 eyep 0 0 1 lookp 0 0 0 up 0 1 0 fov 45 screen 1280 1024 background 0.078 0.361 0.753 surface s1 0.15 0.1 0.045 1. 0.75 0.33 0. 0. 0. 0. 0. 0. 0. plane s1 0 0 1 0 0 0 texture wood scale 1. 1. 1. light 1 point 0 0 1 Here's some of the rayshade.1 document: eyep x y z Specifies the eye's position in space. The default is (0, 20, 0). lookp x y z Specifies the point at which the eye is looking. The default is (0, 0, 0). up x y z Specifies the direction which should be considered "up" from the eye's position. Note that this vector need not be perpendicular to the vector between the look point and the eye's position. The default is (0, 0, 1.). fov horizontal_field_of_view [vertical_field_of_view] The horizontal field of view specifies the angle, in degrees, between the left-most and right-most columns of pixels present, the vertical field of view specifies the angle between the center of the top-most and bottom-most row of pixels. not present, the vertical field of view is calculated using the screen resolution and the assumption that pixels are square. The default horizontal field-of-view is 45 degrees, while the default vertical field-of-view is calculated as described above. screen x_resolution y_resolution Specifies the horizontal and vertical resolution of the image to be rendered. This command may be overridden through use of the -R option. The default resolution is 512 by 512 pixels. background red green blue Specifies the color that should be assigned to rays which do not strike any object in the scene. The default is black (0, 0, 0). Three types of light sources are supported: point, extended (area), and directional. Point sources are specified by a location in world space and produce shadows with sharp edges. Extended sources are specified by a location and a radius. They produce shadows with "fuzzy" edges (penumbrae), but increase ray tracing time considerably. Directional sources are specified by a direction. A maximum of 10 light sources may be defined. In the definitions below, brightness specifies the intensity of the light source. If a single floating-point number is given, the light source emits a "white" light of the indicated normalized intensity. If three floating-point numbers are given, they are interpreted as the normalized red, green and blue components of the light source's color. Lights are defined as follows: light brightness point x y z Creates a point source located at ( x, y, z ). light brightness extended x y z radius Creates an extended source centered at ( x, y, z ) with the indicated radius. The images produced using extended sources are usually superior to those produced using point sources, but ray-tracing time is increased substantially. Rather than tracing one shadow ray to a light source, multiple rays are traced to various points on the extended source. The extended source is approximated by sampling a square grid of light sources. See SAMPLING for more details on the sampling of extended light sources. light brightness directional x y z Creates a directional light source whose direction vector from each point in world space is defined as ( x, y, z ). This vector need not be normalized. Every primitive object has a surface associated with it. The surface specifies the color, reflectivity, and transparency of an object. A surface may be defined anywhere in the input file, provided it is defined before it is used. Surfaces are defined once, and may be associated with any number of primitive objects. A surface definition is given by: index [translu stcoef] surface surf_name ar ag ab dr dg db sr sg sb coef refl transp Surf_name is the name associated with the surface. This name must be unique for each surface. Ar, ag and ab are used to specify the red, green, and blue components of the surface's ambient color. This color is always applied to a ray striking the surface. Dr, dg and db specify the diffuse color of the surface. This color, the brightness component of each light source whose light strikes the surface, and dot product of the incident ray and the surface normal at the point of intersection determine the color which is added to the color of the incident ray. Sr, sg and sb are used to specify the specular color of the surface. The application of this color is controlled by the coef parameter, a floating-point number which indicates the power to which the dot product of the surface's normal vector at the point of intersection and the vector to each light source should be raised. This number is then used to scale the specular color of the surface, which is then added to the color of the ray striking the surface. This model (Phong lighting) simulates specular reflections of light sources on the surface of the object. The larger coef is, the smaller highlights will be. [We could add a "Lr, lg and lb" which are used to specify a light intensity for a surface, so that we can define area lights - Eric] Refl is a floating-point number between 0 and 1 which indicates the reflectivity of the object. If non-zero, a ray striking the surface will spawn a reflection ray. The color assigned to that ray will be scaled by refl and added to the color of the incident ray. Transp is a floating-point number between 0 and 1 which indicates the transparency of the object. If non-zero, a ray striking the surface will spawn a ray which is transmitted through the object. The resulting color of this transmitted ray is scaled by transp and added to the color of the incident ray. The direction of the transmitted ray is controlled by the index parameter, which indicates the index of refraction of the surface. The optional parameters translu and stcoef may be used to give a surface a translucent appearance. Translu is the translucency of the surface. If non-zero and a light source illuminates the side of the surface opposite that being rendered, diffuse lighting calculations are performed with respect to the side of the surface facing the light, and the result is scaled by translu and added to the color of the incident ray. Thus, translu accounts for diffuse transmission of light through the primitive. Stcoef is similar to coef, but it applies to the specular transmission of highlights. Note that in both cases the index of refraction of the surface is ignored. By default, surfaces have zero translucency. ... triangle surface x1 y1 z1 x2 y2 z2 x3 y3 z3 Creates a triangle with vertices ( x1, y1, z1 ), ( x2, y2, z2 ) and ( x3, y3, z3 ). Vertices should be given in a counter-clockwise order as one is looking at the 'top' face of the triangle. triangle surface p1x p1y p1z n1x n1y n1z p2x p2y p2z n2x n2y n2z p3x p3y p3z n3x n3y n3z Defines a Phong-shaded triangle. Here, the first three floating-point numbers specify the first vertex, the second three specify the normal at that vertex, and so on. Again, vertices should be specified in counter- clockwise order. Vertex normals need not be normalized. poly surface x1 y1 z1 x2 y2 z2 x3 y3 z3 [x4 y4 z4 ...] Creates a polygon with the specified vertices. The vertices should be given in a counter-clockwise order as one faces the "top" of the polygon. The polygon may be non-convex, but non-planar polygons will not be rendered correctly. The number of vertices defining a polygon is limited only by available memory. From drb%studmuffin.asd.sgi.com@sgi.com Fri Aug 31 13:00:43 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA12837; Fri, 31 Aug 90 13:00:40 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Fri, 31 Aug 90 13:00:38 PDT Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA20705; Fri, 31 Aug 90 13:01:38 PDT Received: from SGI.COM by miro.Berkeley.EDU (4.1/1.41) id AA09429; Fri, 31 Aug 90 12:53:26 PDT Received: from giraffe.asd.sgi.com by SGI.COM via SMTP (5.64-bind 1.5+ida/900410.SGI) for globillum@miro.berkeley.edu id AA17129; Fri, 31 Aug 90 12:53:38 -0700 Received: from studmuffin.asd.sgi.com by giraffe.asd.sgi.com (5.52/900721.SGI) for sgi.sgi.com!miro.berkeley.edu!globillum id AA23292; Fri, 31 Aug 90 12:53:35 PDT Received: by studmuffin.asd.sgi.com (5.52/891101.SGI) for @giraffe.asd.sgi.com:globillum@miro.berkeley.edu id AA12004; Fri, 31 Aug 90 12:53:34 PDT Date: Fri, 31 Aug 90 12:53:34 PDT From: drb%studmuffin.asd.sgi.com@sgi.com (Dan Baum) Message-Id: <9008311953.AA12004@studmuffin.asd.sgi.com> To: globillum@miro.berkeley.edu Subject: more stuff about comparisons Status: RO Well there has been a lot of discussion on reference geometry and scene description. I agree with greg etc. to keep things simple at first. I think we can start off with the empty room and the room/stick model that Holly has (we have already started doing radiosity/monte carlo comparisons on this model). As far as scene description, it would be nice to use an existing format if possible. We use Berkeley Unigrafix (with some extensions to specify normals, materials, etc.). I think this format would handle most of the issues (what do you think Paul H.?). Since we are talking about using view dependent monte carlo methods as a reference, we may need to work out a standardized method in mapping geometric solutions (i.e. radiosity) to image solutions. It may sound trivial to just display the radiosity solution with the specified view parameters, but I'll bet you our hardware gouraud shades different than your hardware :-)! Hopefully, the differences in scan-conversion will be small but it might be nice to characterize it. dan From eye!johnw@uu.psi.com Fri Aug 31 15:44:51 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA13076; Fri, 31 Aug 90 15:44:45 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Fri, 31 Aug 90 15:44:36 PDT Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA21522; Fri, 31 Aug 90 15:45:34 PDT Received: from uu.psi.com by miro.Berkeley.EDU (4.1/1.41) id AA11793; Fri, 31 Aug 90 15:36:38 PDT Received: from eye.UUCP by uu.psi.com (5.61/3.1.082190-Performance Systems International-Albany) id AA02232; Fri, 31 Aug 90 18:33:20 -0400 Received: from cedar by eye with SMTP (15.11/15.6) id AA08047; Fri, 31 Aug 90 17:10:01 edt Received: by cedar (15.11/15.6) id AA03260; Fri, 31 Aug 90 17:09:57 edt Date: Fri, 31 Aug 90 17:09:57 edt From: eye!johnw@uu.psi.com Message-Id: <9008312109.AA03260@cedar> To: globillum@miro.berkeley.edu Subject: standard image row Status: RO I would like to follow up on Jim Arvo's observation: > 2) The solution needn't be high resolution (maybe some will > disagree with me on this). If we had "exact" solutions at > a sparse collection of points (maybe 16x16) on the image > plane of a standard view, then that would be amenable to > publishing as a table, which might be the most useful means > of making the information known and available. I imagine we'll always be drawn at some point to compute full resolution images for visual comparison. However, there are other ways of comparing solutions that may be enlightening in different ways and at less cost (which can be very high, as Holly pointed out). For example, how about a standard row of pixels from a standard image? The values at such a standard row (say 512 pixels long) could be stored in a table, as suggested by Jim. To compare an algorithm to the standard you would compute the same row. A useful way of presenting the result would be to then plot both the standard and the new data on a 2D graph of intensity vs. pixel location. The results from a number of algorithms could be plotted on one graph, making the relative strengths and weaknesses of each fairly clear. This would be a practical way of presenting comparisons for publication. The advantage of computing an entire row rather than a few selected points is that some algorithms produce characteristic artifacts that are not obvious for a sparse collection of points, but are quite evident over an ordered set of closely spaced points. For example, pixel values for radiosity images are typically computed by Gouraud interpolation. The errors introduced by Gouraud interpolation will be systematic and obvious as you move across a high resolution image row. This would also be true for noisy results. If there is noise in a particular region of the row (e.g., where there is illumination due to a caustic) this will be immediately evident. I've plotted a few rows like this in the past and it's been very useful. It can also be very enlightening, because it eliminates the image processing step provided by our brains. Regions of the image that may have looked like fairly flat fields are revealed to be slowly varying. Effects like color bleeding are more obvious. Etc. That's all for now. --John From shirley@iuvax.cs.indiana.edu Tue Sep 4 07:43:57 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA15723; Tue, 4 Sep 90 07:43:52 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Tue, 4 Sep 90 07:43:47 PDT Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA01219; Tue, 4 Sep 90 07:44:50 PDT Received: from iuvax.cs.indiana.edu by miro.Berkeley.EDU (4.1/1.41) id AA28284; Tue, 4 Sep 90 07:34:20 PDT Message-Id: <9009041434.AA28284@miro.Berkeley.EDU> Received: by iuvax.cs.indiana.edu Date: Tue, 4 Sep 90 09:34:29 -0500 From: shirley@iuvax.cs.indiana.edu To: globillum@miro.berkeley.edu Status: RO I have the proceedings from the Simulation for Graphics workshop that was in France in June. A couple of you have asked me for copies of papers. If a lot of people want it, I will look into bulk copying. Otherwise I'll just copy the requested papers. Note that this will eventually be out as a SV book ($$$ though I'd guess). Let me know if you want anything on this list. Pete TRENDS IN RADIOSITY FOR IMAGE SYNTHESIS by Wallace (3D Eye) Invited overview paper. The most interesting prediction in the paper is that as scenes become more complex, it may be worth it to descretize the environment for each new viewpoint. This will lower the N for radiosiy calculations, but they will no longer be view independent. INCREMENTAL RAY TRACING by Murakami and Hirota (Fujitsu) A extension of Parameterized ray tracing that allowed moving some scene objects in addition to changing material properties. Used tables of changed voxels to determine if a ray's interaction with geometry has changed. Included implementation on multiple CPUs. Also includes reference to a paper in Japanese by Matsumoto on Octree ray tracing in 1983! PARAMETRIC SURFACES AND RAY TRACING by Luc Biard (IMAG, France) Like most parametric patch papers, this one went over my head, but it seems to be an interesting paper, and includes some implementation results. THEORETICAL ANALYSIS OF GLOBAL ILLUMINATION MODELS by Bouville et al. (France) Fairly rigorous statement of governing equations of energy transport. Also includes some discussion of solving equations for 'subsystems' (rooms) and then linking these equations. PHYSICALLY BASED LIGHTING CALCULATIONS FOR CG : A MODERN PERSPECTIVE by me Review of past rendering techniques with the benefit of hindsight and a proposed (no pictures!) extension to general BRDF environments. EFFICIENT RADIOSITY METHODS FOR NON-SEPERABLE REFLECTANCE MODELS by Neumann and Neumann (Budapest) A radiosity proposal for BRDFs that aren't expressable as sums of diffuse and specular. Their math is too heavy for me, so I can't evaluate the work. A PROGRESSIVE RAY TRACING BASED RADIOSITY WITH GENERAL REFLECTANCE FUNCTIONS by Le Saec and Schlick (France) A proposal for general BRDF radiosity (very similar to what I propose in the paper above). Also includes method for interactive display-- display only non mirrors until viewer stops, then ray trace (UNC style). A TWO-PASS RADIOSITY METHOS FOR BEZIER PATCHES by Kok et al. (Netherlands) A radiosity approach with no polygonalization. THE HEMISPHERE RADIOSITY METHOD : A TALE OF TWO ALGORITHMS by Spencer (OSU) FF calculation by projecting on: (1) the hemisphere, (2) the base circle of the hemisphere. This method is more intuitive than Hemicube and is faster IF YOU DON'T HAVE A HW ZBUFFER (because you have one projection instead of 5 I believe-- isn't compared with one plane zbuffer projection). Good for people with sparcstations, crays, etc. EXPLOITING COHERENCE FOR CLIPPING AND VIEW TRANSFORMATION IN RADIOSITY ALGORITHMS by Vilaplana and Puyeo (Spain) Uses coherence properties of hemicubes. Unclear whether rotation of hemicubes to reduce aliasing messes things up. A RAPID HIERARCHICAL RADIOSITY ALG FOR UNOCCLUDED ENVIRONMENTS by Hanrahan and Salzman (Princeton) Very interesting paper on using techniques of gravitational systems for radiosity (rad is similar to gravity because of N^2 interactions and inverse square falloff in influence. Is complicated by occlusion and cosine term). Basic idea (I think) is a generaization of patches and elements. Assign the algorithm a goal error bound in radiance. Let each of K patches be divided hierarchically into N elements. When calculating the influence of one patch on another, the elements might be used for close patches or for far away patches little work is done. This is done in an 'intelligent' manner so that the error bound is respected. John Wallace comments that when K is large, then N should be 1 (no subdivision), so there are some domains where this approach may not be viable. Still, I expect to see this paper with occlusion and some nice pictures one or two years down the road. The paper was presented by Salzman abd he said corrected copies of the paper can be obtained by contacting him at salzman@princeton.edu. FAST RADIOSITY BY PARALLELIZATION by Purgathofer and Zeiller (Austria) Discussion of FF computation in parallel on different architectures is discussed. NEWTON'S COLORS : SIMULATING INTERFERENCE PHENOMINA IN REALISTIC IMAGE SYNTHESIS by Smits and Meyer (U of Oregon) Excellent paper on interference effects. Include first (to my knowledge) physically modelled oil slick and soap bubble. Includes discussion of how to display out-of-gamut colors which come up because of the pure colors produced by interference. Presented by Gary Meyer in GREAT fashion. LIGHT SOURCES IN A RAY TRACING ENVIRONMENT by Roelens et al. (France) A method for showing 'cone of light' effect when there is not very dense participating media in a room (primary scattering only). METHODS FOR EFFICIENT SAMPLING OF ARBITRARILY DISTRIBUTED VOLUME DENSITIES by Hass and Sakas (FRG) Methods of sampling a volume density along a ray. From eye!erich@uu.psi.com Wed Sep 5 07:22:23 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA17184; Wed, 5 Sep 90 07:22:19 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Wed, 5 Sep 90 07:22:15 PDT Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA05414; Wed, 5 Sep 90 07:23:18 PDT Received: from uu.psi.com by miro.Berkeley.EDU (4.1/1.41) id AA17511; Wed, 5 Sep 90 07:12:06 PDT Received: from eye.UUCP by uu.psi.com (5.61/3.1.082190-Performance Systems International-Albany) id AA04012; Wed, 5 Sep 90 10:08:47 -0400 Received: from juniper by eye with SMTP (15.11/15.6) id AA14438; Wed, 5 Sep 90 09:37:55 edt Received: by juniper (15.11/15.6) id AA03385; Wed, 5 Sep 90 09:37:52 edt Date: Wed, 5 Sep 90 09:37:52 edt From: eye!erich@uu.psi.com Message-Id: <9009051337.AA03385@juniper> To: globillum@miro.berkeley.edu Subject: one lacuna left Status: RO The radiosity "refer" format bibliography is almost ready to send out. I'm missing just one little piece of info: from which department did Jim Bullis get his Master's thesis? I know this: %A James M. Bullis %T Models and Algorithms for Computing Realistic Images Containing Diffuse Reflections %R Master's thesis %I University of Minnesota %D Aug. 1989 %K global illumination %Z as of 8/90, order from James Bullis, 3306 Richmond Ave, St Paul MN 55126 Worst comes to worst, I'll write him, but I was hoping someone out there could save me the trouble. Eric Haines, eye@erich.com From eye!erich@uu.psi.com Fri Sep 7 09:53:50 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA21132; Fri, 7 Sep 90 09:53:42 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Fri, 7 Sep 90 09:53:43 PDT Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA13961; Fri, 7 Sep 90 09:54:43 PDT Received: from uu.psi.com by miro.Berkeley.EDU (4.1/1.41) id AA01599; Fri, 7 Sep 90 09:38:37 PDT Received: from eye.UUCP by uu.psi.com (5.61/3.1.090690-Performance Systems International-Albany) id AA15046; Fri, 7 Sep 90 12:35:15 -0400 Received: from juniper by eye with SMTP (15.11/15.6) id AA05601; Fri, 7 Sep 90 11:35:34 edt Received: by juniper (15.11/15.6) id AA01677; Fri, 7 Sep 90 11:35:28 edt Date: Fri, 7 Sep 90 11:35:28 edt From: eye!erich@uu.psi.com Message-Id: <9009071535.AA01677@juniper> To: globillum@miro.berkeley.edu Subject: at long last, the rad bibliography Status: RO So, Francois Sillion lent me his Eurographics workshop proceedings, and I just got the last tidbit of info from Jim Bullis, so attached is the Radiosity bibliography, complete to the best of my knowledge. Note that there is also a ray tracing bibliography that Paul & I made, so most basic ray tracing papers are not included here. Rather, I've put in only those papers dealing with extensions to classical ray tracing illumination effects (e.g. caustics). Thanks to everyone who sent references and corrected mistakes, and please do keep me posted. To run, unpack via "sh thisfile", edit the makefile to your favorite *roff program, and type "make". The roffbib.c program is courtesy Paul Heckbert. Eric Haines, erich@eye.com # This is a shell archive. Remove anything before this line, # then unpack it by saving it in a file and typing "sh file". # # Wrapped by Eric Haines on Fri Sep 7 11:26:03 1990 # # This archive contains: # Makefile radhead.nr rad.refer roffbib.c # LANG=""; export LANG PATH=/bin:/usr/bin:$PATH; export PATH echo x - Makefile cat >Makefile <<'@EOF' ROFF = troff rad.print: rad.refer roffbib roffbib temp $(ROFF) -ms radhead.nr temp rm temp @EOF chmod 644 Makefile echo x - radhead.nr cat >radhead.nr <<'@EOF' .nr PO 1.35i .po 1.35i .ce \s+4RADIOSITY BIBLIOGRAPHY\s0 .ce 3 collected and annotated by Eric Haines, 3D/Eye. erich@eye.com 9/90 .2C .ps 8 .vs 10 @EOF chmod 644 radhead.nr echo x - rad.refer cat >rad.refer <<'@EOF' %A John M. Airey %A M. Ouh-young %T Two Adaptive Techniques Let Progressive Radiosity Outperform the Traditional Radiosity Algorithm %R Technical Report TR89-020 %I University of North Carolina Department of Computer Science %D 1989 %A John M. Airey %A John H. Rohlf %A Frederick P. Brooks, Jr. %T Towards Image Realism with Interactive Update Rates in Complex Virtual Building Environments %J Computer Graphics (1990 Symposium on Interactive 3D Graphics) %V 24 %N 2 %D March 1990 %P 41-50 %A James Arvo %T Backward Ray Tracing %B SIGGRAPH '86 Developments in Ray Tracing seminar notes %V 12 %D Aug. 1986 %Z light ray tracing %O also appeared in SIGGRAPH '89 Radiosity course notes %A James Arvo %A David Kirk %T Particle Transport and Image Synthesis %J Computer Graphics (SIGGRAPH '90 Proceedings) %V 24 %N 4 %D August 1990 %P 63-66 %K Boltzmann equation, Monte Carlo, particle transport, ray tracing, rendering equation %A Daniel R. Baum %A John R. Wallace %A Michael F. Cohen %A Donald P. Greenberg %T The Back-Buffer Algorithm: An Extension of the Radiosity Method to Dynamic Environments %J The Visual Computer %V 2 %D 1986 %P 298-306 %A Daniel R. Baum %A James M. Winget %T Real Time Radiosity Through Parallel Processing and Hardware Acceleration %J Computer Graphics (1990 Symposium on Interactive 3D Graphics) %V 24 %N 2 %D March 1990 %P 67-75 %A Daniel R. Baum %A Holly E. Rushmeier %A James M. Winget %T Improving Radiosity Solutions Through the Use of Analytically Determined Form-Factors %J Computer Graphics (SIGGRAPH '89 Proceedings) %V 23 %N 3 %D July 1989 %P 325-334 %A Christian Bouville %A Kadi Bouatouch %A Pierre Tellier %A Xavier Pueyo %T A Theoretical Analysis of Global Illumination Models %J Proceedings Eurographics Workshop on Phosimulation, Realism and Physics in Computer Graphics %C Rennes, France %D June 1990 %P 53-66 %Z energy transport equations %A Jichun Bu %A Ed F. Deprettere %T A VLSI System Architecture for High-Speed Radiative Transfer 3D Image Synthesis %J The Visual Computer %V 5 %N 3 %D June 1989 %P 121-133 %A Chris Buckalew %A Donald Fussell %T Illumination Networks: Fast Realistic Rendering with General Reflectance Functions %J Computer Graphics (SIGGRAPH '89 Proceedings) %V 23 %N 3 %D July 1989 %P 89-98 %A Chris Buckalew %T Illumination Networks %R PhD thesis %I Computer Science Department, U. of Texas, Austin %D August, 1990 %K global illumination %A James M. Bullis %T Models and Algorithms for Computing Realistic Images Containing Diffuse Reflections %R Master's thesis %I Dept. of Computer Science, University of Minnesota %D Aug. 1989 %K global illumination %Z as of 8/90, order from James Bullis, 3306 Richmond Ave, St Paul MN 55126 %A Peter Burger %A Duncan Gillies %T Interactive Computer Graphics: Functional, Procedural, and Device-Level Methods %I Addison-Wesley %C Wokingham, England %D 1989 %Z Discusses color image quantization, quaternions, and soft (blobby) objects, among many other topics. %A A.T. Campbell,III %A Donald S. Fussell %T Adaptive Mesh Generation for Global Diffuse Illumination %J Computer Graphics (SIGGRAPH '90 Proceedings) %V 24 %N 4 %D August 1990 %P 155-164 %A S. Chandrasekar %T Radiative Transfer %I Oxford University Press %D 1950 %A Subdeb Chattopadhyay %A Akira Fujimoto %T Bi-directional Ray Tracing %B Computer Graphics 1987 (Proceedings of CG International '87) %E Tosiyasu Kunii %I Springer Verlag %C Tokyo %D 1987 %P 335-343 %A Hong Chen %A En-Hua Wu %T An Efficient Radiosity Solution for Bump Texture Generation %J Computer Graphics (SIGGRAPH '90 Proceedings) %V 24 %N 4 %D August 1990 %P 125-134 %A Shenchang Eric Chen %T A Progressive Radiosity Method and its Implementation in a Distributed Processing Environment %R Master's Thesis %I Program of Computer Graphics, Cornell University %D January 1989 %A Shenchang Eric Chen %T Incremental Radiosity: An Extension of Progressive Radiosity to an Interactive Image Synthesis System %J Computer Graphics (SIGGRAPH '90 Proceedings) %V 24 %N 4 %D August 1990 %P 135-144 %A Michael Cohen %T A Radiosity Method for the Realistic Image Synthesis of Complex Diffuse Environments %R Master's Thesis %I Program of Computer Graphics, Cornell University %D Aug. 1985 %A Michael Cohen %A Donald P. Greenberg %T The Hemi-Cube: A Radiosity Solution for Complex Environments %J Computer Graphics (SIGGRAPH '85 Proceedings) %V 19 %N 3 %D Aug. 1985 %P 31-40 %A Michael Cohen %A Donald P. Greenberg %A Dave S. Immel %A Philip J. Brock %T An Efficient Radiosity Approach for Realistic Image Synthesis %J IEEE Computer Graphics and Applications %V 6 %N 3 %D March 1986 %P 26-35 %A Michael Cohen %A Shenchang Eric Chen %A John R. Wallace %A Donald P. Greenberg %T A Progressive Refinement Approach to Fast Radiosity Image Generation %J Computer Graphics (SIGGRAPH '88 Proceedings) %V 22 %N 4 %D Aug. 1988 %P 75-84 %A Robert L. Cook %A Thomas Porter %A Loren Carpenter %T Distributed Ray Tracing %J Computer Graphics (SIGGRAPH '84 Proceedings) %V 18 %N 3 %D July 1984 %P 137-145 %Z Monte Carlo distribution of rays to get gloss, translucency, penumbras, depth of field, motion blur %K probabilistic ray tracing, monte carlo, motion blur, stochastic sampling %A Robert L. Cook %T Stochastic Sampling in Computer Graphics %J ACM Transactions on Graphics %V 5 %N 1 %D Jan. 1986 %P 51-72 %A Robert L. Cook %T Practical Aspects of Distributed Ray Tracing %B SIGGRAPH '86 Developments in Ray Tracing seminar notes %D Aug. 1986 %K probabilistic ray tracing %A R.V. Dunkle %T Radiant Interchange in an Enclosure with Specular Surfaces and Enclosures with Window or Diathermanous Walls %B Heat Transfer, Thermodynamics and Education (Boelter Anniversary Volume) %E H.A. Johnson %I McGraw Hill %C New York %D 1964 %A E.R.G. Eckert %A E.M. Sparrow %T Radiative Heat Exchange Between Surfaces with Specular Reflection %J International Journal of Heat and Mass Transfer %V 3 %D 1961 %P 42-54 %A R. Farrell %T Determination of Configuration Factors of Irregular Shapes %J Journal of Heat Transfer %D May 1976 %P 311-313 %A James D. Foley %A Andries van Dam %A Steven K. Feiner %A John F. Hughes %B Computer Graphics, Principles and Practice, Second Edition %I Addison-Wesley %C Reading, Massachusetts %D 1990 %Z Overview of research to date %A David W. George %A Francois X. Sillion %A Donald P. Greenberg %T Radiosity Redistribution for Dynamic Environments %J IEEE Computer Graphics and Applications %V 10 %N 4 %D July 1990 %P 26-34 %A David W. George %T A Radiosity Redistribution Algorithm for Dynamic Environments %R Master's Thesis %I Program of Computer Graphics, Cornell University %D August 1990 %K global illumination %A Cindy M. Goral %A Kenneth E. Torrance %A Donald P. Greenberg %A Bennett Battaile %T Modelling the Interaction of Light Between Diffuse Surfaces %J Computer Graphics (SIGGRAPH '84 Proceedings) %V 18 %N 3 %D July 1984 %P 212-22 %Z the first article %A Cindy M. Goral %T A Model for the Interaction of Light Between Diffuse Surfaces %R Master's Thesis %I Program of Computer Graphics, Cornell University %D January 1985 %A Donald P. Greenberg %A Michael Cohen %A Kenneth E. Torrance %T Radiosity: A Method for Computing Global Illumination %J The Visual Computer %V 2 %D 1986 %P 291-297 %A Donald P. Greenberg %A Michael Cohen %A Roy Hall %A Holly Rushmeier %A John Wallace %T Radiosity %B SIGGRAPH '89 Radiosity Course Notes %D July 1989 %Z includes new material and article reprints %A Stefan Haas %A Georgios Sakas %T Methods for Efficient Sampling of Arbitrary Distributed Volume Densities %J Proceedings Eurographics Workshop on Phosimulation, Realism and Physics in Computer Graphics %C Rennes, France %D June 1990 %P 215-227 %Z Comparison of methods of sampling atmospheric effects along a ray %A David E. Hall %T An Analysis and Modification of Shao's Radiosity Method for Computer Graphics Image Synthesis %R Master's Thesis %I School of Mechanical Engineering, Georgia Institute of Technoloty %D March 1990 %A Roy Hall %B Illumination and Color in Computer Generated Imagery %I Springer-Verlag %C New York %D 1989 %Z includes C code for radiosity algorithms %A Tariq P. Hamid %T The Radiosity Model %R Project Report %I Dept. of Computer Science, University of Glasgow %D May 1988 %A Pat Hanrahan %A David Salzman %T A Rapid Hierarchical Radiosity Algorithm for Unoccluded Environments %J Proceedings Eurographics Workshop on Phosimulation, Realism and Physics in Computer Graphics %C Rennes, France %D June 1990 %P 151-171 %A Paul Heckbert %T Adaptive Radiosity Textures for Bidirectional Ray Tracing %J Computer Graphics (SIGGRAPH '90 Proceedings) %V 24 %N 4 %D August 1990 %P 145-154 %K density estimation, texture mapping, quadtree, adaptive subdivision, sampling %A Hoyt C. Hottel %A Adel F. Sarofim %T Radiative Transfer %I McGraw Hill %C New York %D 1967 %A John R. Howell %T A Catalog of Radiation Configuration Factors %I McGraw Hill %C New York %D 1982 %A Dave S. Immel %A Michael Cohen %A Donald P. Greenberg %T A Radiosity Method for Non-Diffuse Environments %J Computer Graphics (SIGGRAPH '86 Proceedings) %V 20 %N 4 %D Aug. 1986 %P 133-142 %A Masa Inakage %T Caustics and Specular Reflection Models for Spherical Objects and Lenses %J The Visual Computer %V 2 %N 6 %D 1986 %P 379-383 %Z cheap caustics by using approximations of reflectance/refraction for spheres and lenses %A James T. Kajiya %A Brian P. Von Herzen %T Ray Tracing Volume Densities %J Computer Graphics (SIGGRAPH '84 Proceedings) %V 18 %N 3 %D July 1984 %P 165-174 %K atmospherics %A James T. Kajiya %T The Rendering Equation %J Computer Graphics (SIGGRAPH '86 Proceedings) %V 20 %N 4 %D Aug. 1986 %P 143-150 %K shading, diffuse reflection %A Arjan J.F. Kok %A Celal Yilmaz %A Laurens H.J. Bierens %T A Two-Pass Radiosity Method for Bezier Patches %J Proceedings Eurographics Workshop on Phosimulation, Realism and Physics in Computer Graphics %C Rennes, France %D June 1990 %P 117-126 %A Nadia Magnenat-Thalmann %A Daniel Thalmann %T Image Synthesis %I Springer-Verlag %C Tokyo %D 1987 %Z includes summaries of ideas from many articles in this bibliography %A Thomas J.V. Malley %T A Shading Method for Computer Generated images %R Master's Thesis %I University of Utah %D June 1988 %K ray tracing %A Gregory M. Maxwell %A Michael J. Bailey %A Victor W. Goldschmidt %T Calculations of the Radiation Configuration Factor Using Ray Casting %J Computer-Aided Design %V 18 %N 7 %D Sept. 1986 %P 371-379 %A Joseph Marks %A Robert Walsh %A Jon Christensen %A Mark Friedell %T Image and Intervisibility Coherence in Rendering %J Proceedings of Graphics Interface '90 %D May 1990 %P 17-30 %K ray tracing, coherence %A Nelson L. Max %T Atmospheric Illumination and Shadows %J Computer Graphics (SIGGRAPH '86 Proceedings) %V 20 %N 4 %D Aug. 1986 %P 117-124 %A Gary W. Meyer %A Holly E. Rushmeier %A Michael F. Cohen %A Donald P. Greenberg %A Kenneth E. Torrance %T An Experimental Evaluation of Computer Graphics Imagery %J ACM Transactions on Graphics %V 5 %N 1 %D Jan. 1986 %P 30-50 %Z side-by-side test of reality vs. a radiosity image %A Hans Moravec %T 3D Graphics and the Wave Theory %J Computer Graphics (SIGGRAPH '81 Proceedings) %V 15 %N 3 %D August 1981 %P 289-296 %A Tomoyuki Nishita %A Isao Okamura %A Eihachiro Nakamae %T Shading Models for Point and Linear Light Sources %J ACM Transactions on Graphics %V 4 %N 2 %D April 1985 %P 124-146 %A Tomoyuki Nishita %A Eihachiro Nakamae %T Continuous Tone Representation of Three-Dimensional Objects Taking Account of Shadows and Interreflection %J Computer Graphics (SIGGRAPH '85 Proceedings) %V 19 %N 3 %D July 1985 %P 23-30 %A Tomoyuki Nishita %A Eihachiro Nakamae %T Continuous Tone Representation of Three-Dimensional Objects Illuminated by Sky Light %J Computer Graphics (SIGGRAPH '86 Proceedings) %V 20 %N 4 %D Aug. 1986 %P 125-132 %A Tomoyuki Nishita %A Yashuhiro Miyawaki %A Eihachiro Nakamae %T A Shading Model for Atmospheric Scattering Considering Luminous Intensity Distribution of Light Sources %J Computer Graphics (SIGGRAPH '87 Proceedings) %V 21 %N 4 %D July 1987 %P 303-310 %A Laszlo Newmann %A Attila Neumann %T Photosimulation: Interreflection with Arbitrary Reflectance Models and Illumination %J Computer Graphics Forum %V 8 %D 1989 %P 21-34 %A Laszlo Neumann %A Attila Neumann %T Efficient Radiosity Methods for Non-Separable Reflectance Models %J Proceedings Eurographics Workshop on Phosimulation, Realism and Physics in Computer Graphics %C Rennes, France %D June 1990 %P 83-102 %A Claude Puech %A Francois Sillion %A Christophe Vedel %T Improving Interaction with Radiosity-based Lighting Simulation Programs %J Computer Graphics (1990 Symposium on Interactive 3D Graphics) %V 24 %N 2 %D March 1990 %P 51-57 %A Werner Purgathofer %A Michael Zeiller %T Fast Radiosity by Parallelization %J Proceedings Eurographics Workshop on Phosimulation, Realism and Physics in Computer Graphics %C Rennes, France %D June 1990 %P 173-183 %A Rodney J. Recker %A David W. George %A Donald P. Greenberg %T Acceleration Techniques for Progressive Refinement Radiosity %J Computer Graphics (1990 Symposium on Interactive 3D Graphics) %V 24 %N 2 %D March 1990 %P 59-66 %A Rodney J. Recker %T Improved Techniques for Progressive Refinement Radiosity %R Master's Thesis %I Program of Computer Graphics, Cornell University %D January 1990 %A M. Roelens %A G. Fertey %A B. Peroche %T Light Sources in a Ray Tracing Environment %J Proceedings Eurographics Workshop on Phosimulation, Realism and Physics in Computer Graphics %C Rennes, France %D June 1990 %P 195-213 %Z A method for showing cone of light atmospherics %A Holly E. Rushmeier %T Extending the Radiosity Method to Transmitting and Specularly Reflecting Surfaces %R Master's Thesis %I Program of Computer Graphics, Cornell University %D 1986 %A Holly E. Rushmeier %T The Zonal Method for Calculating Light Intensities in the Presence of a Participating Medium %J Computer Graphics (SIGGRAPH '87 Proceedings) %V 21 %N 4 %D July 1987 %P 293-302 %K atmospherics %A Holly E. Rushmeier %T Realistic Image Synthesis for Scenes with Radiatively Participating Media %R Doctoral Thesis %I Cornell University %D 1988 %A Holly E. Rushmeier %A Kenneth E. Torrance %T Extending the Radiosity Method to Include Specularly Reflecting and Translucent Materials %J ACM Transactions on Graphics %V 9 %N 1 %D Jan. 1990 %P 1-27 %A Holly E. Rushmeier %A Daniel R. Baum %A David E. Hall %T Accelerating the Hemi-Cube Algorithm for Calculating Radiation Form Factors %J 5th AIAA/ASME Thermophysics and Heat Transfer Conference %C Seattle, Washington %D June 1990 %A Holly E. Rushmeier %A Stephen D. Tynor %T Incorporating the BRDF into an Infrared Scene Generation System %J Conference on Characterization, Propagation and Simulation of Infrared Scenes, SPIE Proceedings %C Orlando, Florida %V 1311 %D April 1990 %A Betrand Le Saec %A Christophe Schlick %T A Progressive Ray-Tracing-based Radiosity with General Reflectance Functions %J Proceedings Eurographics Workshop on Phosimulation, Realism and Physics in Computer Graphics %C Rennes, France %D June 1990 %P 103-116 %A Hanan Samet %T Applications of Spatial Data Structures %I Addison-Wesley %C Reading, Massachusetts %D 1990 %Z short section on radiosity %K quadtrees, octrees %A Min-Zhi Shao %A Qun-Sheng Peng %A You-Dong Liang %T A New Radiosity Approach by Procedural Refinements for Realistic Image Synthesis %J Computer Graphics (SIGGRAPH '88 Proceedings) %V 22 %N 4 %D Aug. 1988 %P 93-101 %A Peter Shirley %T A Ray Tracing Method for Illumination Calculation in Diffuse-Specular Scenes %J Proceedings of Graphics Interface '90 %D May 1990 %P 205-212 %K stratified sampling %A Peter Shirley %T Physically Based Lighting Calculations for Computer Graphics %R PhD thesis %I Dept. of CS, U. of Illinois, Urbana-Champaign %D September, 1990 %K global illumination %A Peter Shirley %T Physically Based Lighting Calculations for Computer Graphics: A Modern Perspective %J Proceedings Eurographics Workshop on Phosimulation, Realism and Physics in Computer Graphics %C Rennes, France %D June 1990 %P 67-81 %Z rendering techniques summary and extensions %A Robert Siegel %A John R. Howell %T Thermal Radiation Heat Transfer %I Hemisphere Publishing Corporation %C New York %D 1981 %A Francois Sillion %A Claude Puech %T A General Two-Pass Method Integrating Specular and Diffuse Reflection %J Computer Graphics (SIGGRAPH '89 Proceedings) %V 23 %N 3 %D July 1989 %P 335-344 %A Brian E. Smits %A Gary Meyer %T Newton's Colors: Simulating Interference Phenomena in Realistic Image Synthesis %J Proceedings Eurographics Workshop on Phosimulation, Realism and Physics in Computer Graphics %C Rennes, France %D June 1990 %P 185-194 %Z interference effects (e.g. oil slick & soap bubbles) %A E.M. Sparrow %T A New and Simpler Formulation for Radiative Angle Factors %J Transactions of the ASME, Journal of Heat Transfer %V 85 %N 2 %D 1963 %P 81-88 %A E.M. Sparrow %A R.D. Cess %T Radiation Heat Transfer %I Hemisphere Publishing Corporation %C Washington %D 1978 %A Stephen N. Spencer %T The Hemisphere Radiosity Method: A Tale of Two Algorithms %J Proceedings Eurographics Workshop on Phosimulation, Realism and Physics in Computer Graphics %C Rennes, France %D June 1990 %P 127-135 %A J. Vilaplana %A Xavier Pueyo %T Exploiting Coherence for Clipping and View Transformations in Radiosity Algorithms %J Proceedings Eurographics Workshop on Phosimulation, Realism and Physics in Computer Graphics %C Rennes, France %D June 1990 %P 137-150 %K hemicube %A John R. Wallace %A Michael F. Cohen %A Donald P. Greenberg %T A Two-Pass Solution to the Rendering Equation: A Synthesis of Ray Tracing and Radiosity Methods %J Computer Graphics (SIGGRAPH '87 Proceedings) %V 21 %N 4 %D July 1987 %P 311-320 %K probabilistic ray tracing, z-buffer %A John R. Wallace %T A Two-Pass Solution to the Rendering Equation: A Synthesis of Ray Tracing and Radiosity Methods %R Master's Thesis %I Program of Computer Graphics, Cornell University %D January 1988 %A John R. Wallace %A Kells A. Elmquist %A Eric A. Haines %T A Ray Tracing Algorithm for Progressive Radiosity %J Computer Graphics (SIGGRAPH '89 Proceedings) %V 23 %N 3 %D July 1989 %P 315-324 %Z calculating form-factors via ray tracing to avoid hemicube problems %A John R. Wallace %T Radiosity and Ray Tracing: A Comparison of Shading Strategies %B SIGGRAPH '90 Advanced Topics in Ray Tracing course notes %D Aug. 1990 %A John R. Wallace %T Trends in Radiosity for Image Synthesis %J Proceedings Eurographics Workshop on Phosimulation, Realism and Physics in Computer Graphics %C Rennes, France %D June 1990 %P 1-14 %A George N. Walton %T Algorithms for Calculating Radiation View Factors Between Plane Convex Polygons with Obstructions %J Fundamentals and Applications of Radiation Heat Transfer (24th National Heat Transfer Conference and Exhibition) %V HTD-Vol. 72 %D Aug. 1987 %P 45-52 %A Yigong Wang %A Wayne A. Davis %T Octant Priority for Radiosity Image Rendering %J Proceedings of Graphics Interface '90 %D May 1990 %P 83-91 %K hemi-cube, space subdivision %A Yigong Wang %T Image Synthesis Using Radiosity Methods %R Dotoral Thesis %I University of Alberta %D 1990 %A Gregory J. Ward %A Francis M. Rubinstein %A Robert D. Clear %T A Ray Tracing Solution for Diffuse Interreflection %J Computer Graphics (SIGGRAPH '88 Proceedings) %V 22 %N 4 %D Aug. 1988 %P 85-92 %A Alan Watt %T Fundamentals of Three-Dimensional Computer Graphics %I Addison-Wesley %C Wokingham, England %D 1989 %Z also discusses ray tracing, functionally-based modeling, stochastic sampling, and Fourier theory, among other topics. %A Mark Watt %T Light-Water Interaction using Backward Beam Tracing %J Computer Graphics (SIGGRAPH '90 Proceedings) %V 24 %N 4 %D August 1990 %P 377-385 %K backward ray tracing, caustics, light beam tracing, specular to diffuse transfer %A John A. Wiebelt %T Engineering Radiation Heat Transfer %I Holt, Rinehart and Winston, Inc %C New York %D 1966 %A Hau Xu %A Qun-Shang Peng %A You-Dong Liang %T Accelerated Radiosity Method for Complex Environments %B Eurographics '89 %D 1989 %P 51-61 %I Elsevier Science Publishers %C New York %Z Partitions object space for solutions in subdomains %A A.C. Yilmaz %A S. Hagestein %A Ed F. Deprettere %A P. Dewilde %T A Hardware Solution to the Generalized Two-Pass Approach for Rendering of Artificial Scenes %J Proceedings Eurographics Hardware Workshop %C Hamburg, West Germany %D Sept. 1989 %P 65-79 %O also appeared in IEEE Computer Architecture & Real Time Graphics Symposium, June 1989, Delft @EOF chmod 644 rad.refer echo x - roffbib.c cat >roffbib.c <<'@EOF' /* * A very simple version of ROFFBIB * * Paul Heckbert, 1985 */ #include typedef struct { char *code,*pref,*post; } reftrans; static reftrans reftab[] = { "%A", "", ",", /* author (possibly several) */ "%B", "\\fI", "\\fP,", /* book title */ "%C", "", ",", /* city */ "%D", "", ",", /* date */ "%E", "", " ed.,", /* editor of book */ "%G", "NTIS ", ",", /* government order number */ "%I", "", ",", /* issuer (publisher) */ "%J", "\\fI", "\\fP,", /* journal/magazine */ "%K", "{", "},", /* keywords */ "%N", "no. ", ",", /* number (vol 5 no 3) */ "%O", "(", "),", /* other (misc info) */ "%P", "pp. ", ",", /* pages */ "%R", "", ",", /* report number */ "%T", "``", "'',", /* title */ "%V", "vol. ", ",", /* volume */ "%Y", "[", "],", /* owner(s) of copy */ "%Z", "\\fI", "\\fP," /* comments */ }; #define NREF (sizeof reftab / sizeof reftab[0]) static int lno; main(ac,av) int ac; char **av; { char line[500]; int i,j; FILE *fp; if (ac==1) fp = stdin; else if ((fp = fopen(av[1],"r"))==NULL) { fprintf(stderr,"Can't find %s\n",av[1]); exit(1); } lno = 0; while (!feof(fp)) { for (j=0; getline(fp,line)>0; j++) { if (strlen(line)<4 || line[0]!='%' || line[2]!=' ') { fprintf(stderr,"line %d is (%s)\n",lno,line); printf("\n%s\n",line); continue; } for (i=0; i=NREF) { fprintf(stderr,"line %d bad code (%s)\n",lno,line); printf("\n%s\n",line); continue; } if (j==0 && (line[1]=='A' || line[1]=='E')) surfirst(line); printf("%s%s%s\n",reftab[i].pref,line+3,reftab[i].post); } printf("\n"); } fclose(fp); } getline(fp,str) FILE *fp; char *str; { char *s; int c; s = str; do { while ((c = getc(fp))!='\n' && c!=EOF) *s++ = c; *s++ = ' '; lno++; } while ((*s++ = c = getc(fp))!='%' && c!='\n' && c!=EOF); ungetc(c,fp); s[-2] = 0; return strlen(str); } surfirst(str0) /* put surname first */ char *str0; { char *str,*s,buf[500]; str = str0+3; s = str+strlen(str)-1; do { while (s>=str && *s!=' ') s--; } while (s>str && *--s==','); if (s>str) { s += 2; s[-1] = 0; sprintf(buf,"%%%c \\fB%s\\fP, %s",str0[1],s,str); strcpy(str0,buf); } } @EOF chmod 644 roffbib.c exit 0 From greg Fri Sep 7 17:45:20 1990 Return-Path: Received: by hobbes.lbl.gov (3.2/SMI-3.2) id AA21573; Fri, 7 Sep 90 17:45:16 PDT Date: Fri, 7 Sep 90 17:45:16 PDT From: greg (Gregory J. Ward) Message-Id: <9009080045.AA21573@hobbes.lbl.gov> To: shirley@iuvax.cs.indiana.edu Subject: Simulation for Graphics Status: RO Hi Pete, Thank you for sending out the summary of the French workshop. I am interested in many of the papers you mentioned. I'm particularly keen to read your paper and the similar one byLe Saec and Schlick. I am also interested in the Princton paper, but will write to salzman for a copy. If it's not too much trouble, could you xerox and mail me copies of the two papers? My address is: Greg Ward Lawrence Berkeley Lab 1 Cyclotron Rd., 90-3111 Berkeley, CA 94720 I would be very grateful. -Greg From shirley@iuvax.cs.indiana.edu Fri Sep 7 17:53:19 1990 Return-Path: Received: from iuvax.cs.indiana.edu (129.79.254.192) by hobbes.lbl.gov (3.2/SMI-3.2) id AA21586; Fri, 7 Sep 90 17:53:13 PDT Message-Id: <9009080053.AA21586@hobbes.lbl.gov> Received: by iuvax.cs.indiana.edu Date: Fri, 7 Sep 90 19:53:17 -0500 From: peter shirley To: greg@hobbes.lbl.gov Subject: Re: Simulation for Graphics Status: RO Fine Greg. I will do that. There have been some requests for a bunch of papers, and I'm not sure if I'll do something in bulk, but two papers I can handle. Do you want the Interference paper from UofO? Not very interesting for IE, but great for pictures. pete PS-- I'll be getting my personal iris in about 3 weeks. Will your radiance port run on this, or does it need a mega-iris? From greg Fri Sep 7 18:34:47 1990 Return-Path: Received: by hobbes.lbl.gov (3.2/SMI-3.2) id AA21635; Fri, 7 Sep 90 18:34:43 PDT Date: Fri, 7 Sep 90 18:34:43 PDT From: greg (Gregory J. Ward) Message-Id: <9009080134.AA21635@hobbes.lbl.gov> To: shirley@iuvax.cs.indiana.edu Subject: Re: Simulation for Graphics Status: RO I am going to see Gary Meyer next Tuesday, and will ask him to bring a copy of his paper when he comes. Your personal IRIS should work fine. I haven't tried the port on anything faster anyway. (See if you can get X11, though. Bad as it is, SGI is moving to it exclusively next year anyway.) -Greg From ph@miro.berkeley.edu Thu Sep 20 13:38:11 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA08223; Thu, 20 Sep 90 13:38:07 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Thu, 20 Sep 90 13:38:09 PDT Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA12798; Thu, 20 Sep 90 13:39:34 PDT Received: by miro.Berkeley.EDU (4.1/1.41) id AA13130; Thu, 20 Sep 90 13:26:23 PDT Date: Thu, 20 Sep 90 13:26:23 PDT From: ph@miro.berkeley.edu (Paul Heckbert) Message-Id: <9009202026.AA13130@miro.Berkeley.EDU> To: globillum@miro.berkeley.edu Subject: Mike Cohen reports from Eurographics Status: RO [Mike had some trouble mailing this to globillum@miro.berkeley.edu, so I'm mailing it for him. If you've had any trouble with "globillum", let me know. I'm trying to track down the problem. -Paul Heckbert] >From m-cohen@cs.utah.edu Thu Sep 20 08:01:29 1990 Date: Thu, 20 Sep 90 09:01:42 -0600 From: m-cohen@cs.utah.edu (Michael Cohen) I have just returned from Europe and greatly enjoyed the volume of discussion which has been generated. I will not comment now on what has been said. At Eurographics, I sat in on a meeting of "global illuminators" not unlike this group. The issues which were raised were very similar, which is no surprise. The results of the meeting were to form a working group to address the same kind of problems we have been discussing. I suggested there be some kind of cooperation across the ocean and mentioned this group, which met with interest on their side. I am a bit reluctant to simply suggest adding a new list of names to this mailing list. There is something to be said for a small group. (At least you know who is NOT participating.) On the other hand we should have some contact. They are a serious group of researchers. Kadi Bouatouch which John Wallace and others of you may know should be forming the mailing list, etc. I suggested he contact Paul. If there is some comment on the plusses and minusses of merging efforts, this may be a good time to say it. On a similar note, there was also a decision to hold a workshop in Barcelona next April or May. You have now heard a brief report from the one held in France this June. Maybe John can comment on the value of it. They were very pleased by the high level of participation from the States and would like to have that continue. I have not worked through the rendering papers presented at EG yet. They seem to be of varying quality and importance, etc. If people are interested, I will try to make some comments, or the text available to those who do not have acess to it. That's the report from across the ocean, Michael From shirley@iuvax.cs.indiana.edu Thu Sep 20 13:52:23 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA08279; Thu, 20 Sep 90 13:52:19 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Thu, 20 Sep 90 13:52:23 PDT Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA12882; Thu, 20 Sep 90 13:53:49 PDT Received: from iuvax.cs.indiana.edu by miro.Berkeley.EDU (4.1/1.41) id AA13451; Thu, 20 Sep 90 13:44:23 PDT Message-Id: <9009202044.AA13451@miro.Berkeley.EDU> Received: by iuvax.cs.indiana.edu Date: Thu, 20 Sep 90 15:44:38 -0500 From: shirley@iuvax.cs.indiana.edu To: globillum@miro.berkeley.edu Subject: Europeans Status: RO I would like to see the European list merged with ours. I don't think the currently low traffic would justify any caution on our part. pete From lalonde%qucis.queensu.ca%qucdn.queensu.ca@Csa1.lbl.gov Fri Sep 21 08:22:30 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA09793; Fri, 21 Sep 90 08:22:27 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Fri, 21 Sep 90 08:22:26 PDT Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA15351; Fri, 21 Sep 90 08:23:47 PDT Received: from QUCDN.QueensU.CA by miro.Berkeley.EDU (4.1/1.41) id AA29632; Fri, 21 Sep 90 08:11:17 PDT Received: from qusunb.qucis.queensu.ca by QUCDN.QueensU.CA (IBM VM SMTP R1.2.2MX) with TCP; Fri, 21 Sep 90 10:35:19 EDT Received: by qusunb.qucis.queensu.ca (4.0/SMI-3.2) id AA08876; Fri, 21 Sep 90 10:34:47 EDT Date: Fri, 21 Sep 90 10:34:47 EDT From: lalonde%qucis.queensu.ca%qucdn.queensu.ca@Csa1.lbl.gov Message-Id: <9009211434.AA08876@qusunb.qucis.queensu.ca> To: globillum@miro.berkeley.edu Subject: Radiosity without polygonalization Status: RO Hello, Does anyone have any references about doing radiosity without polygonal subdivion of the scene? I'm doing some work in this but would love to know if anyone else has approached the problem. I don't know about anyone else, but I really hate to break up nice curves to render them. Thanks, Paul Paul A. Lalonde Internet: lalonde@qucis.queensu.ca Home Phone: (613)546-4713 Work Phone: (613)545-7100 "The only true law is that which leads to freedom" - Richard Bach, _Jonathan Livingston Seagull_ From spencer@cgrg.ohio-state.edu Fri Sep 21 05:08:28 1990 Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA09722; Fri, 21 Sep 90 05:08:24 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Fri, 21 Sep 90 05:08:24 PDT Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA14712; Fri, 21 Sep 90 05:09:52 PDT Received: from heinlein.cgrg.ohio-state.edu by miro.Berkeley.EDU (4.1/1.41) id AA27661; Fri, 21 Sep 90 05:00:57 PDT Return-Path: Received: by heinlein.cgrg.ohio-state.edu (5.64/900625.02) id AA09653; Fri, 21 Sep 90 08:01:06 -0400 Date: Fri, 21 Sep 90 08:01:06 -0400 From: spencer@cgrg.ohio-state.edu (Stephen N. Spencer) Message-Id: <9009211201.AA09653@heinlein.cgrg.ohio-state.edu> To: globillum@miro.berkeley.edu In-Reply-To: peter shirley's message of Thu, 20 Sep 90 15:44:38 -0500 <9009202044.AA13451@miro.Berkeley.EDU> Subject: re: Europeans Status: RO Yes, let's merge the two lists. After all, "global" IS our first name. :-) Email traffic should not be a problem. steve From fxs@saturn.graphics.cornell.edu Fri Sep 21 08:47:11 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA09843; Fri, 21 Sep 90 08:47:06 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Fri, 21 Sep 90 08:47:12 PDT Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA15454; Fri, 21 Sep 90 08:48:39 PDT Received: from devvax.TN.CORNELL.EDU by miro.Berkeley.EDU (4.1/1.41) id AA29959; Fri, 21 Sep 90 08:40:47 PDT Received: from SATURN.GRAPHICS.CORNELL.EDU by devvax.TN.CORNELL.EDU (5.64/1.3-Cornell-Theory-Center) id AA21051; Fri, 21 Sep 90 11:39:58 -0400 Date: Fri, 21 Sep 90 11:40:35 edt From: fxs@saturn.graphics.cornell.edu (Francois X. Sillion) Received: by saturn.graphics.cornell.edu (14.4.1.1/2.0nn-Program-of-Computer-Graphics) id AA11053; Fri, 21 Sep 90 11:40:35 edt Message-Id: <9009211540.AA11053@saturn.graphics.cornell.edu> To: %qucdn.queensu.ca.lalonde%qucis.queensu.ca%graphics.cornell.edu%saturn.graphics.cornell.edu@Csa1, globillum@miro.berkeley.edu Subject: Re: Radiosity without polygonalization Status: RO Paul A. Lalonde asks : > Does anyone have any references about doing radiosity > without polygonal subdivion of the scene? I'm doing some work > in this but would love to know if anyone else has approached > the problem. ``A Two-Pass Radiosity Method for Bezier Patches'', by A. Kok, C. Yilmaz, and L. Bierens. in the proceedings of the Eurographics Workshop on Photosimulation, realism, etc... hel in Rennes last June. As far as I understand, sample points are ``uniformly'' distributed on the surfaces (uniform apparently meaning a uniform subdivision of the control polygons in u-v coord.) Form factors are then computed but it is unclear what these exactly represent... (area to point, area to area, ... ??) This paper sounds like a good 'first step' in the direction of getting rid of polygons on curved surfaces, but much remains to be done in terms of finding smart sampling strategies. Also a more rigorous definition of energy transfers is needed. --Francois Sillion From turner@apple.com Fri Sep 21 09:26:59 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA09895; Fri, 21 Sep 90 09:26:55 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Fri, 21 Sep 90 09:26:57 PDT Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA15638; Fri, 21 Sep 90 09:28:20 PDT Received: from apple.com by miro.Berkeley.EDU (4.1/1.41) id AA00461; Fri, 21 Sep 90 09:17:25 PDT Received: by apple.com (5.61/25-eef) id AA14580; Fri, 21 Sep 90 09:17:32 -0700 for globillum@miro.Berkeley.EDU Date: Fri, 21 Sep 90 09:17:32 -0700 From: turner@apple.com Message-Id: <9009211617.AA14580@apple.com> To: globillum@miro.berkeley.edu, lalonde%qucis.queensu.ca%apple.com@Csa1.lbl.gov Subject: Re: Radiosity without polygonalization Status: RO Sure, In our radiosity/raytracing system Eric Chen and myself render polygons and patches. Polygons get tesselated in the traditional manner, patches are partitioned in their natrual parameter space. It works just fine. In fact I can think of no reason to sample curved geometry (ie, tesselate it) simply to create form facter sites. I'd be interested to hear from others think of this approach. -Doug Turner turner@apple.com 408-974-0484 From ph@miro.berkeley.edu Fri Sep 21 14:00:46 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA10353; Fri, 21 Sep 90 14:00:42 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Fri, 21 Sep 90 14:00:47 PDT Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA16996; Fri, 21 Sep 90 14:02:13 PDT Received: by miro.Berkeley.EDU (4.1/1.41) id AA04528; Fri, 21 Sep 90 13:51:19 PDT Date: Fri, 21 Sep 90 13:51:19 PDT From: ph@miro.berkeley.edu (Paul Heckbert) Message-Id: <9009212051.AA04528@miro.Berkeley.EDU> To: globillum@miro.berkeley.edu Subject: radiosity without polygons Status: RO Wallace-Elmquist-Haines89 took steps toward radiosity without polygonization. They polygonize for the purposes of shooting, storage, and display, but when they ray trace to compute form factors, they use the true, curved geometry in their occlusion tests. And then there are people doing global illumination of both specular and diffuse scenes using ray tracing: Kajiya87 and Ward-Rubinstein-Clear88 simulated radiosity (among other things) without polygonization. And in my Siggraph90 paper I discussed global illumination without polygonization, instead storing the radiosity in a texture parameterized by each surface's (u,v), as did Arvo86. Some interesting questions: 1) What data structures are appropriate for storing radiosity information, if not uniform grid polygonizations? * Campbell-Fussell90 investigated BSP trees for subdivision/poly. * Quadtrees and k-d trees are also a possibility 2) What about surfaces that are difficult to parameterize, such as arbitrary implicit surfaces? 3) How would these data structures evolve over time in animation? Paul From eye!johnw@uu.psi.com Mon Sep 24 09:46:42 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA13662; Mon, 24 Sep 90 09:46:39 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Mon, 24 Sep 90 09:46:48 PDT Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA25545; Mon, 24 Sep 90 09:48:16 PDT Received: from uu.psi.com by miro.Berkeley.EDU (4.1/1.41) id AA22837; Mon, 24 Sep 90 09:34:27 PDT Received: from eye.UUCP by uu.psi.com (5.61/3.1.090690-Performance Systems International) id AA21054; Mon, 24 Sep 90 12:30:55 -0400 Received: from cedar by eye with SMTP (15.11/15.6) id AA07295; Mon, 24 Sep 90 11:29:25 edt Received: by cedar (15.11/15.6) id AA00967; Mon, 24 Sep 90 11:29:19 edt Date: Mon, 24 Sep 90 11:29:19 edt From: eye!johnw@uu.psi.com Message-Id: <9009241529.AA00967@cedar> To: globillum@miro.berkeley.edu Subject: Polygonalization for radiosity Status: RO More on radiosity without polygonalization: As Doug Turner points out, the radiosity method does not inherently require the polygonalization of curved surfaces. Polygonalization is mostly a result of the hemi-cube algorithm, as well as the desire to perform the final smooth shading of radiosity images in hardware z-buffers. Surface geometry has to be delt with at three levels: 1. Representation of patch geometry (i.e., the geometry of surfaces when determining the illumination they provide): You have to take into account the geometry of patches when you compute the form-factor from them to the surfaces receiving light. In conventional, full-matrix radiosity with the hemi-cube, the form-factors are determined by scan converting patches onto a hemi-cube positioned at element vertices on the receiving surfaces. Patches were polygonalized only because of the requirement for scan conversion. Algorithms in which ray casting is used to compute form-factors can treat generalized patch geometries without polygonalization. 2. Representation of shadowing geometry: Again, the hemi-cube algorithm determined occlusion using a z-buffer, so polygonalization was a convenient way to represent curved surfaces. Later methods based on ray casting don't have this limitation. 3. Representation of surface shading (i.e., the receiving elements): Somehow you need to represent the continuous shading across surfaces. The illumination is computed at discrete points on the surface and then the smooth shading is reconstructed using some form of interpolation. As Doug Turner described, curved patches can be partioned into elements in the u,v parametric space of the surface. Form-factors can be computed at the element vertices using the true surface normal. Thus the radiosities at these points will represent the "correct" shading of the curved surface. Reconstruction of the smooth shading across the surfaces has typically been performed by passing the elements down to a hardware Gouraud shader, which imposes polygonal elements. If the renderer can handle curved surfaces directly, there's no reason to polygonalize. The image of three spheres in the 1987 paper "A Two-Pass Solution to the Rendering Equation" (Wallace, Cohen and Greenberg) used the method described by Doug Turner i.e., subdivide sphere into curved elements. Radiosities were computed at the vertices of the elements using the true normal to the sphere. The curved elements were then rendered using ray casting, bilinearly interpolating the vertex radiosities in the parametric space of the sphere. John From m-cohen@cs.utah.edu Wed Sep 26 09:49:38 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA20343; Wed, 26 Sep 90 09:49:34 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Wed, 26 Sep 90 09:49:44 PDT Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA04711; Wed, 26 Sep 90 09:51:14 PDT Received: from cs.utah.edu by miro.Berkeley.EDU (4.1/1.41) id AA09208; Wed, 26 Sep 90 09:39:39 PDT Received: by cs.utah.edu (5.64/utah-2.16-cs) id AA17916; Wed, 26 Sep 90 10:39:51 -0600 Date: Wed, 26 Sep 90 10:39:51 -0600 From: m-cohen@cs.utah.edu (Michael Cohen) Message-Id: <9009261639.AA17916@cs.utah.edu> To: erich@eye.com, globillum@miro.berkeley.edu Subject: Eurographics Status: RO Here is a list of some of the relavent papers from Eurographics 90: TITLE = "A Shadow Algorithm for CSG" AUTHOR = F.W. Jansen and A.N.T. Van Der Zalm PAGES = 51-62 TITLE = "Cross Scanline Algorithm" AUTHOR = T. Tanaka and T. Takahashi PAGES = 63-74 NOTE = anti-aliasing TITLE = "Hemi-Cube Ray Tracing: A Method for Generating Soft Shadows" AUTHOR = U. Meyer PAGES = 365-376 TITLE = "Shading and Shadowing of Linear Light Sources" AUTHOR = P. Poulin and J. Amanatides PAGES = 377-386 TITLE = "Tightly-Coupled Multiprocessing for a Global Illumination Algorithm" AUTHOR = G. Drettakis, E. Fiume, and A. Fournier PAGES = 387-398 NOTE = FIAT TITLE = "Three-Dimensional Texturing Using Lattices" AUTHOR = R.R. Lewis PAGES = 439-448 TITLE = "Interactive Ray tracing for Image Production with Increasing Realism" AUTHOR = A.A. Sousa, A.M.C. Costa, and F.N. Ferreira PAGES = 449-458 TITLE = "Rendering Mirages and Other Atmospheric Phenomena" AUTHOR = M. Berger, N. levit, and T. Trout PAGES = 459-468 TITLE = "Optimization of Binary Space Partirtion Algorithm (BSP) for the Visualization of Dynamic Scenes" AUTHOR = E. Torres PAGES = 507-518 TITLE = "Fast rendering of Arbitrary Distributed Volume Densities" AUTHOR = G. Sakas PAGES = 519-530 TITLE = "Tries: Data Structures Based on Binary Representation for Ray Tracing" AUTHOR = J.-P. Thirion PAGES = 530-542 From eye!erich@uu.psi.com Thu Sep 27 14:49:24 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA23386; Thu, 27 Sep 90 14:49:20 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Thu, 27 Sep 90 14:49:17 PDT Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA10637; Thu, 27 Sep 90 14:50:43 PDT Received: from uu.psi.com by miro.Berkeley.EDU (4.1/1.41) id AA03216; Thu, 27 Sep 90 14:33:46 PDT Received: from eye.UUCP by uu.psi.com (5.61/3.1.090690-Performance Systems International) id AA20921; Thu, 27 Sep 90 17:30:15 -0400 Received: from juniper by eye with SMTP (15.11/15.6) id AA12254; Thu, 27 Sep 90 16:48:05 edt Received: by juniper (15.11/15.6) id AA14672; Thu, 27 Sep 90 16:48:01 edt Date: Thu, 27 Sep 90 16:48:01 edt From: eye!erich@uu.psi.com Message-Id: <9009272048.AA14672@juniper> To: globillum@miro.berkeley.edu Subject: Anyone read this? Cc: erich@juniper.berkeley.edu Status: RO I saw the posting that follows on the net some time ago. Has anyone out there read it? If so, please do pass on a summary of it to us all, if you would. Also, I'd like to get a date of publication so I can add it to the radiosity bibliography (which is now available on freedom.graphics.cornell.edu via anonymous FTP). Eric Haines Newsgroups: comp.graphics >From: pjs@basalt.pa.dec.com (Philip Schneider) Subject: Re: Arbitrarily-Shaped Light Sources Date: Mon, 17 Sep 90 17:52:37 GMT Steve Hollasch writes : > How do raytracers make light sources out of arbitrary objects? I >thought a while back that one approach would be to find the direction to >the object from the illuminated point, fire a random cone of rays at the >object, and assign some fraction of the object's light to the point for >each unobstructed ray ....... Get in touch with the University of Washington Department of Computer Science. Two or three years ago Dan O'Donnell wrote an M.S. thesis on what he called "solid light sources". (Sorry, my copy is in a box right now, so I don't recall the exact title :-( Real nice work, as I recall, and the resulting pictures were pretty interesting -- one of them featured a coffee mug, with steam rising from it that turned into a glowing "neon sign" light formed into the shape of the word "Espresso" (of course, I'm biased from having worked alongside him at the UW graphics lab :-) -- Philip J. Schneider | pjs@decwrl.dec.com DEC Advanced Technology Development | decwrl!pjs 100 Hamilton Avenue | (415)853-6538 Palo Alto, CA 94301 | (415)386-8232 From hr3@prism.gatech.edu Sat Sep 29 14:19:50 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA29005; Sat, 29 Sep 90 14:19:44 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Sat, 29 Sep 90 14:19:52 PDT Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA18456; Sat, 29 Sep 90 14:21:24 PDT Received: from hydra.gatech.edu by miro.Berkeley.EDU (4.1/1.41) id AA13181; Sat, 29 Sep 90 14:13:53 PDT Received: by hydra.gatech.edu (5.61/3.1) id AA11032; Sat, 29 Sep 90 17:14:11 -0400 Date: Sat, 29 Sep 90 17:14:11 -0400 From: hr3@prism.gatech.edu (RUSHMEIER,HOLLY E) Message-Id: <9009292114.AA11032@prism.gatech.edu> To: globillum@miro.berkeley.edu Subject: Terminology Status: RO A while ago Pete Shirley brought up the problem of the terminology used to describe reflectance (i.e. specular, diffuse, etc.) I think this is a subject worth discussing, particularly after rereading this years Siggraph article by Takagi, Takaoka, Oshima and Ogata. In section 3.3, they reject the use of the Cook-Torrance model partly because it models the diffuse portion of reflectance as Lambertian. It seems to me Lambertian reflectance is unsatisfactory only because Takagi et al., in Fig. 3.6, choose to include the reflectance lobe near the mirror direction as part of the diffuse portion of reflectance, and Cook-Torrance include this lobe in the specular portion of reflectance. There are other instances where diffuse versus specular is confusing. In one reflectance model I use for infrared applications, Sandford/Robertson, diffuse is used for the component which is outside of the specular lobe, (which may or may not be Lambertian) and specular is used for the specular lobe, which may or may not be centered in the mirror direction. In a tech report by Nayar, Ikeuchi and Kanade that I got from Carnegie Mellon, they propose a three component reflectance model -- a diffuse lobe (modelled as Lambertian) , a specular lobe (from Torrance-Sparrow or Beckmann-Spizzichino) and a specular spike. I think it is hopeless to try to get everybody to agree on specific definitions of diffuse and specular. Instead I would like to see "diffuse" and "specular" retired, and terms like Lambertian and mirror-like which are less ambiguous used. That leaves the problem with what do we call stuff that isn't Lambertian or mirror-like, and how do we describe reflectances that approach Lambertian or approach mirror-like behavior without long cumbersome explanations. I will be happy to use whatever the majority of people in the group agree on in stuff I am writing currently. Also, I would love to be able to read other people's papers without having to prepare a little dictionary to translate their terms into my terms. Speaking of terms, do people prefer radiance or intensity for energy per unit projected area unit time and unit solid angle? In the past I have used intensity, since it is used in heat transfer. I would be happy to switch to radiance, in fact for infrared stuff that is the term I use. Along the lines of the standard input file format that was discussed earlier, obviously I would like to avoid a format that forces one to describe reflectance by specifying a diffuse reflectance and a specular reflectance. -- Holly From shirley@iuvax.cs.indiana.edu Sat Sep 29 17:29:43 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA29076; Sat, 29 Sep 90 17:29:39 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Sat, 29 Sep 90 17:29:53 PDT Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA19013; Sat, 29 Sep 90 17:31:26 PDT Received: from iuvax.cs.indiana.edu by miro.Berkeley.EDU (4.1/1.41) id AA19405; Sat, 29 Sep 90 17:23:34 PDT Message-Id: <9009300023.AA19405@miro.Berkeley.EDU> Received: by iuvax.cs.indiana.edu Date: Sat, 29 Sep 90 19:23:49 -0500 From: shirley@iuvax.cs.indiana.edu To: globillum@miro.berkeley.edu, hr3@prism.gatech.edu Subject: Re: Terminology Status: RO I will go with Holly on using any terms people agree on-- no matter how poorly chosen (a bad standard is better than none at all!). I have a weak opinion that the term "specular" should not be adopted without modification because it is too overloaded. I prefer "radiance" to "intensity" because the IES has an ANSI standard defining a consistent set of terms and units that includes radiance, while the heat transfer community has no such standard (that I know of. Holly?). The catch with using radiance is all the Cornell radiosity papers use "intensity", but I think they all are pretty good about defining their usage in each paper, so not that much confusion might develop. The European graphics community seems to be using IES units as far as I can tell. I think the Physics community is too. Still, I think that the important thing is that we all use the same terms. I think Paul H has made some terminology suggestions about distributed ray tracing being a misleading term, and everyone is confused by "backward ray tracing" (you should be ashamed of yourself Jim A :^}). I'm happy to go with Paul on using "distribution ray tracing". Another term that is getting its meaning expanded is "radiosity". I like Holly's participating media paper's usage of "zonal method" to mean a method that discretizes the environment into constant property zones. I would use radiosity to mean a zonal method for diffuse surfaces (the radiosity quantity isn't that meaningful for non-diffuse surfaces). I'd be thrilled if we could put some definitions on a sheet and stick to them so that I could stop having to worry about these things every time I want to write a paper! pete From greg Sat Sep 29 18:57:59 1990 Return-Path: Received: by hobbes.lbl.gov (3.2/SMI-3.2) id AA29148; Sat, 29 Sep 90 18:57:56 PDT Date: Sat, 29 Sep 90 18:57:56 PDT From: greg (Gregory J. Ward) Message-Id: <9009300157.AA29148@hobbes.lbl.gov> To: globillum@miro.Berkeley.EDU Subject: Re: Terminology Status: RO I also prefer the use of "radiance" over "intensity" to describe energy/time/area/solid_angle. "Radiant intensity" is used by the IES for energy/time/solid_angle -- which can be the source of some confusion. I have always thought of "diffuse" and "Lambertian" as interchangable, but Holly is right that some people use diffuse differently. If the terms are different, then I don't know the difference, and if they are identical, we can do away with one of them. I agree that we should use Lambertian as the more exact term. I have seen "specular" used many different ways, and I agree that it is a sloppy term, but I don't think "mirror-like" is a very good substitute. To differentiate between mirror reflection and Lambertian components, I have heard others use the term "off-specular", but I don't care for this much, either. We could use "non-Lambertian", so there would only be "Lambertian" and "non-Lambertian". The problem then would be confusion over whether non-Lambertian meant reflection that doesn't obey Lambert's law, or the part of the BRDF (bidirectional reflectance distribution function) remaining once the Lambertian component has been removed. I vote that we use specular to mean the component of reflection that doesn't obey Lambert's law, ie. the part of the BRDF remaining after the Lambertian component is removed. I think this is a sensible interpretation of the term as it has been used in the past, and it is reasonably unambiguous. I don't really see any good substitute and I don't think the term should be abandoned. The only catch is that we would have to live with specular reflections that are nowhere near the mirror direction. I vote also for keeping diffuse around. The vast majority of people use it to mean Lambertian, so I don't find its use nearly as distracting as specular. If we keep one, we should keep them both. If everyone wants to abandon diffuse and specular, I will keep them out of future papers, but I don't know if I will be able to stop muttering them in my sleep. -Greg From shirley@iuvax.cs.indiana.edu Sat Sep 29 19:54:11 1990 Return-Path: Received: from iuvax.cs.indiana.edu (129.79.254.192) by hobbes.lbl.gov (3.2/SMI-3.2) id AA29358; Sat, 29 Sep 90 19:54:06 PDT Message-Id: <9009300254.AA29358@hobbes.lbl.gov> Received: by iuvax.cs.indiana.edu Date: Sat, 29 Sep 90 21:53:37 -0500 From: peter shirley To: globillum@miro.Berkeley.EDU, greg@hobbes.lbl.gov Subject: Re: Terminology Status: RO Greg's use of specular is consistent with the European Graphics and Heat Transfer use I think. How about: Diffuse = Lambertian Specular = Directional Ideal Specular = Delta function pete From shirley@iuvax.cs.indiana.edu Sun Sep 30 07:49:39 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA29659; Sun, 30 Sep 90 07:49:35 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Sun, 30 Sep 90 07:49:46 PDT Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA19923; Sun, 30 Sep 90 07:51:12 PDT Received: from iuvax.cs.indiana.edu by miro.Berkeley.EDU (4.1/1.41) id AA18441; Sun, 30 Sep 90 07:11:39 PDT Message-Id: <9009301411.AA18441@miro.Berkeley.EDU> Received: by iuvax.cs.indiana.edu Date: Sun, 30 Sep 90 09:11:55 -0500 From: shirley@iuvax.cs.indiana.edu To: globillum@miro.berkeley.edu Subject: standard terminology Status: RO Perhaps if we can agree on some terminology we should write a short summary for the ray tracing news or siggraph or whatever with some concise definitions and rationale. Maybe 2 or 3 pages. Does anyone think this is a good idea? pete From atc@cs.utexas.edu Sun Sep 30 11:55:54 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA29748; Sun, 30 Sep 90 11:55:50 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Sun, 30 Sep 90 11:55:57 PDT Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA20630; Sun, 30 Sep 90 11:57:30 PDT Received: from cs.utexas.edu by miro.Berkeley.EDU (4.1/1.41) id AA28658; Sun, 30 Sep 90 11:49:28 PDT Posted-Date: Sun, 30 Sep 90 13:49:41 CDT Message-Id: <9009301849.AA24138@cs.utexas.edu> Received: by cs.utexas.edu (5.64/1.76) From: atc@cs.utexas.edu (Alvin T. Campbell III) Date: Sun, 30 Sep 90 13:49:41 CDT X-Mailer: Mail User's Shell (6.5.6 6/30/89) To: globillum@miro.berkeley.edu Subject: standard terminology Cc: atc@cs.utexas.edu Status: RO I agree with Pete's suggestion that we write up and publish whatever standard terminology we agree upon. Our current discussion group has representatives from most of the types of people doing research in global illumination: engineers, mathematicians, computer scientists, and architects. Therefore anything we agree upon likely will be generally useful. However, we will need to get this information out to individuals not on our mailing list, in order that they might consider using our results. We should definitely try to get the standard in print. Posting to the net or sending out bulk e-mail has some drawbacks. Many people, particularly outside the US, would have no access to the information electronically. Also, there are various hassles with maintaing documents on line. People would occasionally delete files accidentally, so they would either cease to use the standard or need to contact one of us for a replacement. My suggestion is to write up a small paper and submit it to IEEE Computer Graphics and Applications. The form should be much like Eric Haines's "A Proposal for Standard Graphics Environments" (CG&A, November 1987). Eric can give us some idea how long the submissions pipeline may take. I am anxious to see what develops. A. T. Campbell, III CS Department, University of Texas atc@cs.utexas.edu From m-cohen@cs.utah.edu Sun Sep 30 15:18:36 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA29820; Sun, 30 Sep 90 15:18:33 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Sun, 30 Sep 90 15:18:49 PDT Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA21265; Sun, 30 Sep 90 15:20:23 PDT Received: from cs.utah.edu by miro.Berkeley.EDU (4.1/1.41) id AA04771; Sun, 30 Sep 90 15:03:18 PDT Received: by cs.utah.edu (5.64/utah-2.16-cs) id AA04306; Sun, 30 Sep 90 16:03:36 -0600 Date: Sun, 30 Sep 90 16:03:36 -0600 From: m-cohen@cs.utah.edu (Michael Cohen) Message-Id: <9009302203.AA04306@cs.utah.edu> To: globillum@miro.berkeley.edu Subject: Terminology Status: RO I suppose I should throw in my two cents worth. I think we might agree on three terms: I. Ideal diffuse or Lambertian Diffuse (either is acceptable) II. Ideal Specular III. General These can apply to reflectance or transmittance. E.G., "My bidirectional reflectance model consists of Ideal Diffuse terms, ideal specular terms and a Phong model for the general reflectance." On the other issue: Intensity vs. Radiance vs. ??? Intensity is an overloaded term but people know what you are talking about. Radiance tends to stay more tightly defined but people have a harder time with it. I will defer any strong opinion on this one. -Michael From don%allegra.tempo.nj.att.com@research.att.com Sun Sep 30 23:14:46 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA29989; Sun, 30 Sep 90 23:14:42 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Sun, 30 Sep 90 23:14:59 PDT Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA22050; Sun, 30 Sep 90 23:16:33 PDT Received: from research.att.com by miro.Berkeley.EDU (4.1/1.41) id AA23999; Sun, 30 Sep 90 23:08:20 PDT Message-Id: <9010010608.AA23999@miro.Berkeley.EDU> Received: by research; Mon Oct 1 02:08:15 EDT 1990 Date: Mon, 1 Oct 90 02:08:04 EDT From: don@allegra.tempo.nj.att.com (Don Mitchell) To: globillum@miro.berkeley.edu Subject: radiance Status: RO Since we are talking about issuing a standards proposal, I do have a strong opinion about "radiance". I think we should use standard radiometric terminology (radiance, irradiance, radiant intensity, etc). The term "intensity" has too many definitions. In radiometry, it is watts per solid angle, in geometrical optics it is watts per wavefront area, in Sparrow & Cess it is watts per area per solid angle. The word is also used informally to express the power of a light source, or just subjective brightness. When this word appears in a graphics paper, you have to stop and look carefully at definitions to see which of these many possible meanings it might have. Radiometric units are used in computer vision and illumination engineering. Along with photometry and colorimetry, these are the accepted standards for talking about visible light. Quite a few graphics people are already using these units. The terminology of heat transfer has been used in some formal discussions of shading models in graphics (thanks to the important work at Cornell by Torrance, Cook, and others). But heat transfer is not exactly the same physics as illumination, and there is different phenomenology. Studying heat, one doesn't worry about colorimetry or apparent brightness or imaging systems. Studying illumination, one doesn't worry about black bodies and radiative equilibrium (unless you set your thermostat to 6000 K). From fxs@saturn.graphics.cornell.edu Mon Oct 1 05:26:49 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA00173; Mon, 1 Oct 90 05:26:45 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Mon, 1 Oct 90 05:26:54 PDT Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA22418; Mon, 1 Oct 90 05:28:28 PDT Received: from devvax.TN.CORNELL.EDU by miro.Berkeley.EDU (4.1/1.41) id AA05890; Mon, 1 Oct 90 05:19:35 PDT Received: from SATURN.GRAPHICS.CORNELL.EDU by devvax.TN.CORNELL.EDU (5.64/1.3-Cornell-Theory-Center) id AA06551; Mon, 1 Oct 90 08:19:37 -0400 Date: Mon, 1 Oct 90 08:19:03 edt From: fxs@saturn.graphics.cornell.edu (Francois X. Sillion) Received: by saturn.graphics.cornell.edu (14.4.1.1/2.0nn-Program-of-Computer-Graphics) id AA25648; Mon, 1 Oct 90 08:19:03 edt Message-Id: <9010011219.AA25648@saturn.graphics.cornell.edu> To: globillum@miro.berkeley.edu Subject: Terminology & Standards Status: RO The idea of defining a standard terminology for reflectance components sounds great, and would make both writing and reading papers easier. However, I want to point out that I believe notations and terminology should still be carefully explained in all papers (after all, there will always be someone to use the terms in his/her own way). We should probably not try and re-invent the wheel, since many people have tried already to define standards : for example, "Geometrical Considerations and Nomenclature for Reflectance", by Nicodemus, Richmond and Hsia, (National Bureau of Standards, now NIST) and Ginsberg and Limperis, published in 1977, defines not only units such as radiance and or radiant exitance, but also attempts to standardize the notations for the geometry, and some qualifiers, such as diffuse (a.k.a. isotropic, lambertian), and specular (or regular, defined as mirror-like). I agree very much with Michael Cohen that diffuse and specular should be used only for the two extreme cases of Lambertian and mirror-like. Also, I think it is probably a good idea to use radiance, even though I might define in my papers the two terms to be the same, and then use intensity... Several people here at Cornell are developing a general reflectance model for statistical rough surfaces, and we have been thinking for a while about terminology. We separate the BRDF into three parts, that are not defined purely from their directional properties, but also have a strong physical meaning : - We call specular the mirror-like part of the reflection. Another definition, due to Steve Westin, is ``a surface is specular if you can comb your hair in it''. This part appears in physical-optics models when the coherent component of the average EM field is evaluated, and can be shown to decrease exponentialy with surface roughness. (That is to say, there is still some significant physical behavior behind the delta function). - We call "directional diffuse" the part that can be predicted by the statistical averaging of the reflected field, or "incoherent term". This term may or may not be Lambertian, and may or not be shaped as a "specular blob". [By the way, "off-specular" is used to describe a directional blob that reaches its maximum in a direction different from the specular direction. It is observed at large incident angles, on rough surfaces, and is modeled by the Cook-Torrance model]. - What we call the diffuse part, is a Lambertian term, supposedly originating from internal scattering (below the surface) and/or multiple reflections on the surface. The "directional diffuse" part of the reflectance, which is the most interesting one in many cases, probably deserves a better name, but we couldn't think of one... It should be noted that in a simple model of reflection by microfacets, such as Cook-Torrance, the directional diffuse term originates from specular (mirror) reflection on the micro-facets, but the end result, in our view, is not to be called specular. Finally, If the "Lambertian part of the BRDF" mentioned by Greg is defined as the minimum value of the BRDF, in our terminology it can be caused both by diffuse and directional-diffuse reflection. Therefore, splitting the reflectance into lambertian, general, and specular components will hide some of the physics involved. I apologize for complicating the subject further, but I believe it is an important question to decide whether the separation of the reflectance into different parts (which will always be somewhat arbitrary) should be done on the basis of the directional properties, or on the basis of the physics of reflection. I am looking forward to reading any reactions to this message... --Francois Sillion From chense@apple.com Mon Oct 1 11:52:55 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA00117; Mon, 1 Oct 90 11:52:52 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Mon, 1 Oct 90 11:53:08 PDT Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA24191; Mon, 1 Oct 90 11:54:41 PDT Received: from apple.com by miro.Berkeley.EDU (4.1/1.41) id AA18160; Mon, 1 Oct 90 11:44:05 PDT Received: from [90.1.0.10] by apple.com with SMTP (5.61/25-eef) id AA27924; Mon, 1 Oct 90 11:44:18 -0700 for globillum@miro.Berkeley.EDU Received: by goofy.apple.com (5.61/25-eef) id AA20841; Mon, 1 Oct 90 11:44:13 -0700 for globillum@miro.Berkeley.EDU Date: Mon, 1 Oct 90 11:44:13 -0700 From: chense@apple.com Message-Id: <9010011844.AA20841@internal.apple.com> To: globillum@miro.berkeley.edu Subject: Terminology Status: RO Since we are trying to use some discrete names to describe a continuous function, it is subject to aliasing problems no matter what names we come up with. Recognizing this makes me feel more comfortable in throwing in my two cents worth. I don't think we need to abandon diffuse and specular. Neither should we try to give them specific meanings, such as specular means directional. These terms are very overloaded and we should leave them alone. They are ambiguious. But that's precisely what they should be used for-- in the same way when people say something is red. I tend to agree with Michael's suggestions that we use ideal diffuse for Labmbertian and ideal specular for mirror-like. They are informative and easy for people to relate to. I prefer ideal diffuse to Lambertian diffuse because it is less obscure and matches ideal specular well (otherwise, what would you call ideal specular?). Calling everything else "general" is a little bit too general but I don't have better suggestions. I agree with Don, the term intensity is very loaded. We probably should use radiance instead. Eric From shirley@iuvax.cs.indiana.edu Mon Oct 1 13:00:27 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA00844; Mon, 1 Oct 90 13:00:22 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Mon, 1 Oct 90 13:00:30 PDT Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA24561; Mon, 1 Oct 90 13:02:03 PDT Received: from iuvax.cs.indiana.edu by miro.Berkeley.EDU (4.1/1.41) id AA20530; Mon, 1 Oct 90 12:51:16 PDT Message-Id: <9010011951.AA20530@miro.Berkeley.EDU> Received: by iuvax.cs.indiana.edu Date: Mon, 1 Oct 90 14:51:22 -0500 From: shirley@iuvax.cs.indiana.edu To: globillum@miro.berkeley.edu Subject: terms Status: RO MC: >> I. Ideal diffuse or Lambertian Diffuse (either is acceptable) >> II. Ideal Specular >> III. General Sounds good, I think we all know what these terms would mean (though I think "Lambertian" alone would be better than "Lambertian Diffuse". >> These can apply to reflectance or transmittance. >> Intensity is an overloaded term but people know what you are talking about. >> Radiance tends to stay more tightly defined but people have a harder time >> with it. I will defer any strong opinion on this one. I was confused for quite a while because intensity is used quite differently in physics. Radiance has no competing technical definitions that I know of. FS: >> The idea of defining a standard terminology for reflectance components >> sounds great, and would make both writing and reading papers easier. >> However, I want to point out that I believe notations and >> terminology should still be carefully explained in all papers (after all, >> there will always be someone to use the terms in his/her own way). I would like to be able to reference a good paper on standard terms so that my 7.5 page papers can become 8 page papers. >> We should probably not try and re-invent the wheel, since many people >> have tried already to define standards : for example, >> "Geometrical Considerations and Nomenclature for Reflectance", by >> Nicodemus, Richmond and Hsia, (National Bureau of Standards, now NIST) >> and Ginsberg and Limperis, published in 1977, defines not only >> units such as radiance and or radiant exitance, but also attempts >> to standardize the notations for the geometry, and some qualifiers, >> such as diffuse (a.k.a. isotropic, lambertian), and specular (or regular, >> defined as mirror-like). I think Nicodemus' work has all been absorbed by the IES/ANSI standard, so it would be nice to just use it. If you don't have a copy it is ANSI/IES RP-16-1986 (ISBN 0-87955-022-6). Here is what it defines (not complete): Radiant flux (radiant power) Radiant Intensity (not radiance or intensity) Radiance Radiator (Light source, luminaire) Diffusing surfaces and media (perform at least some scattering) Lambertian surface Complete diffusion (no incident flux can remain in an image forming state) Wide-angle diffusion Narrow-angle diffusion Regular (specular) reflection Specular angle Diffuse reflection (more general than Lambertian) BRDF I would especially like to be able to use the first 4 without definition. In addition to BRDF, I'd like to add a power oriented measure (for a Lambertian surface the BRDF is K, and this "other" measure would be K'cos theta). >> I agree very much with Michael Cohen that diffuse and specular should be used >> only for the two extreme cases of Lambertian and mirror-like. Also, I think >> it is probably a good idea to use radiance, even though I might define >> in my papers the two terms to be the same, and then use intensity... A good compromise-- if you use intensity, have one throw away sentence about radiance (and vice-versa). EC: >> I tend to agree with Michael's suggestions that we use ideal diffuse for >> Lbmbertian and ideal specular for mirror-like. They are informative and >> easy for people to relate to. I prefer ideal diffuse to Lambertian diffuse >> because it is less obscure and matches ideal specular well (otherwise, what >> would you call ideal specular?). Calling everything else "general" is a >> little bit too general but I don't have better suggestions. I don't either. Sounds like there's a lot going on at Cornell on this... pete From hr3@prism.gatech.edu Wed Oct 3 06:59:18 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA04542; Wed, 3 Oct 90 06:59:14 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Wed, 3 Oct 90 06:59:20 PDT Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA05005; Wed, 3 Oct 90 07:01:01 PDT Received: from hydra.gatech.edu by miro.Berkeley.EDU (4.1/1.41) id AA17413; Wed, 3 Oct 90 06:50:22 PDT Received: by hydra.gatech.edu (5.61/3.1) id AA19571; Wed, 3 Oct 90 09:50:45 -0400 Date: Wed, 3 Oct 90 09:50:45 -0400 From: hr3@prism.gatech.edu (RUSHMEIER,HOLLY E) Message-Id: <9010031350.AA19571@prism.gatech.edu> To: globillum@miro.berkeley.edu Subject: articles Status: RO A while ago I asked if anyone had copies of a couple of articles I needed for reference. Apparently someone passed along my request, because I received the general form factors paper from Qun-Sheng Pen at Zhejiang University in the mail this morning. Thanks for your help, Holly From ph@miro.berkeley.edu Wed Oct 3 16:51:26 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA05439; Wed, 3 Oct 90 16:51:22 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Wed, 3 Oct 90 16:51:33 PDT Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA09817; Wed, 3 Oct 90 16:53:16 PDT Received: by miro.Berkeley.EDU (4.1/1.41) id AA08309; Wed, 3 Oct 90 16:44:09 PDT Date: Wed, 3 Oct 90 16:44:09 PDT From: ph@miro.berkeley.edu (Paul Heckbert) Message-Id: <9010032344.AA08309@miro.Berkeley.EDU> To: globillum@miro.berkeley.edu Subject: terminology Status: RO A short paper on terminology is an excellent idea. I've rarely seen the term "diffuse" used in a non-Lambertian sense, so I've never qualified it with terms such as "ideal diffuse" or "Lambertian". If there is a sizeable community that uses "diffuse" in a broader sense than "Lambertian", however, then we should use a qualifier. Holly mentioned a few papers with such use of the term "diffuse", but such definitions are the exception, I believe. "Specular" is a vaguer term to me, which could mean either sharp or fuzzy reflection (or transmission). So here we definitely need qualifiers. "Ideal specular" is a good term, I think, for a delta function BRDF. What to call non-ideal specular, and how broadly to define "specular", are more difficult questions. In my siggraph paper this year, I wanted "ideal specular" to include interfaces that are part reflective and part transmissive with distributions that are delta functions (such as glass), and also birefractive materials (such as calcite) as well, so I defined "ideal specular" as reflectance and transmittance that scatters light in a finite number of directions. Note that this definition places no limitations on the direction of the reflected or transmitted rays, so further qualifiers beyond "ideal" would be needed to be fully specific. I defined "specular" as everything that was left after diffuse was subtracted, and "rough specular" as everything specular that wasn't "ideal specular". These last two definitions were more problematical and I would welcome alternative suggestions. The above definition of "ideal specular" maps very cleanly into ray tracing: ideal specular can be simulated with classic ray tracing, while rough specular requires distribution ray tracing (since the distributions of rough specular have positive solid angle). We need a word which means "reflectance or transmittance". I've used the word "interaction" to mean "reflection or transmission", but never found a satisfactory word for the coefficient of interaction. I've also groped to find a term for the thing you get when you weld together a BRDF and a BTDF (bidirectional transmittance distribution function). I don't think of the BRDF and BTDF as separate functions, but as the halves of the whole function. I find it convenient to wrap up all surface shading into the function BDF(in, out, lambda, u, v) which is bidirectional (reflectance or transmittance) distribution as a function of incoming light direction vector "in", outgoing light direction vector "out", wavelength, and surface parameters u and v, where "in" and "out" vary over an entire sphere of directions. Is there a name for this sucker? From atc@cs.utexas.edu Wed Oct 3 12:41:00 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA05072; Wed, 3 Oct 90 12:40:55 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Wed, 3 Oct 90 12:40:54 PDT Received: from cs.utexas.edu by lbl.gov (4.1/1.39) id AA08382; Wed, 3 Oct 90 12:42:32 PDT Posted-Date: Wed, 3 Oct 90 14:40:42 CDT Message-Id: <9010031940.AA14579@cs.utexas.edu> Received: by cs.utexas.edu (5.64/1.76) From: atc@cs.utexas.edu (Alvin T. Campbell III) Date: Wed, 3 Oct 90 14:40:42 CDT X-Mailer: Mail User's Shell (6.5.6 6/30/89) To: gjward@Csa1.lbl.gov Subject: images storage format and software Status: RO Greg, A few weeks ago you sent out mail to the global illumination group concerning your image storage format. As I recall, you also included some source code. I would like to try this out, but unfortunately I accidentally deleted your letter. Could you please mail me another copy of the information? Thanks. A. T. From hr3@prism.gatech.edu Thu Oct 4 06:45:05 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA06302; Thu, 4 Oct 90 06:45:00 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Thu, 4 Oct 90 06:45:08 PDT Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA11164; Thu, 4 Oct 90 06:46:51 PDT Received: from hydra.gatech.edu by miro.Berkeley.EDU (4.1/1.41) id AA04954; Thu, 4 Oct 90 06:37:54 PDT Received: by hydra.gatech.edu (5.61/3.1) id AA24014; Thu, 4 Oct 90 09:38:14 -0400 Date: Thu, 4 Oct 90 09:38:14 -0400 From: hr3@prism.gatech.edu (RUSHMEIER,HOLLY E) Message-Id: <9010041338.AA24014@prism.gatech.edu> To: globillum@miro.berkeley.edu Subject: reflectance+transmittance Status: RO A while ago Ted Himlan at Cornell collected a lot of documents about standard terminology for radiation and optics. One thing he turned up was a series on Optical Radiation Measurements, by Venable and Hsia and NBS (now NIST). In the chapter "Describing Spectrophotometric Measurements", they refer to a descriptor that indicates the manner in which radiation emerges from a sample space (i.e. a surface area) as the "scattering function". We could refer to the combination of the BRDF and BTDF as BSDF - bidirectional scattering distribution function. I can see that diffuse and specular won't die. I think at best though we can use diffuse as meaning weakly dependent on direction, and specular as meaning strongly dependent on direction. I also think ideal diffuse is easily interchangeable with Lambertian. Ideal specular is a different problem. Since ideal is synonymous with model or perfect, I would rather not qualify it further. An alternative I have seen is "regular". -- Holly From shirley@iuvax.cs.indiana.edu Thu Oct 4 06:56:45 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA06314; Thu, 4 Oct 90 06:56:42 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Thu, 4 Oct 90 06:56:55 PDT Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA11193; Thu, 4 Oct 90 06:58:37 PDT Received: from iuvax.cs.indiana.edu by miro.Berkeley.EDU (4.1/1.41) id AA05329; Thu, 4 Oct 90 06:50:21 PDT Message-Id: <9010041350.AA05329@miro.Berkeley.EDU> Received: by iuvax.cs.indiana.edu Date: Thu, 4 Oct 90 08:50:35 -0500 From: shirley@iuvax.cs.indiana.edu To: globillum@miro.berkeley.edu, hr3@prism.gatech.edu Subject: Re: reflectance+transmittance Status: RO There is another reflectance/scattering structure I'd like a standard term for-- the probability density function of where an energy packet will scatter: p(in, out) is probability density with respect to solid angle of scattering in direction out. This type of measurement is more natural than BRDF when dealing with power transport. It, combined with R(in) would completely describe reflectance behavior. (I don't want to use this INSTEAD of BRDF, but in addition). Is there a standard term for this? I call it the scattering probability function. pete From eye!erich@uu.psi.com Thu Oct 4 07:20:55 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA06326; Thu, 4 Oct 90 07:20:51 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Thu, 4 Oct 90 07:21:05 PDT Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA11299; Thu, 4 Oct 90 07:22:33 PDT Received: from uu.psi.com by miro.Berkeley.EDU (4.1/1.41) id AA05998; Thu, 4 Oct 90 07:12:58 PDT Received: from eye.UUCP by uu.psi.com (5.61/3.1.090690-Performance Systems International) id AA19960; Thu, 4 Oct 90 10:09:27 -0400 Received: from juniper by eye with SMTP (15.11/15.6) id AA28890; Thu, 4 Oct 90 09:47:48 edt Received: by juniper (15.11/15.6) id AA20143; Thu, 4 Oct 90 09:47:41 edt Message-Id: <9010041347.AA20143@juniper> From: eye!erich@uu.psi.com ( Eric Haines) Date: Thu, 4 Oct 1990 09:47:40 EDT X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: globillum@miro.berkeley.edu Subject: speculuse and diffar Cc: erich@juniper.berkeley.edu Status: RO Specular I agree with Paul H. that specular is a fuzzy word. The term is pretty overloaded. For example, for workstation vendors "specular" merely means highlights from light sources using Phong's distribution function. In classical ray tracing the distribution function can get more involved (e.g. different distributions, Fresnel term, etc), but we still use "specularity" to mean "shininess" and this usually affects only the highlights from light sources. I use "specular reflection" and "specular transmission" if I'm trying to be precise. But if I use "reflection" and "transmission" when talking about ray tracing, most know I mean the contributions from the ray shot in the mirror direction and the refracted ray. If anything, a term like "specular reflection" usually means to a ray trace researcher only the contribution from the reflected ray, not from the light sources. Specular contributions from light sources are thought of as "highlights", or not thought about at all; they're just a part of the shading model, of little concern to a ray trace researcher trying to speed up ray intersections or somesuch. No one in his right mind (currently) shoots a distribution of rays to find out the specular highlight contribution of each light source. In our ray tracer we tend to call highlights the "specular" contribution, and set "reflectivity" and "transmittance" to determine the contribution of reflected & refracted rays (note that we don't use the S word for these). This usage is mostly due to having built onto an exist library (HP's "Starbase" graphics library) with its own terminology, but we should recognize that this library is widely used and accepted. So, my point is just that "specular" and "specularity" are adjectives that have very different meanings depending on context. I don't have any great solution, but find the problem interesting. Do we want to put forward a general definition of "specular" to mean the non-uniform part of the distribution of light from a surface? Sounds reasonable to me, but then we have to give specific transport mechanisms definitions that don't rely on the word "specular" to describe them, e.g. we would talk about the amount of contribution from a reflection ray in ray tracing as "reflectivity", perhaps; the reflection distribution from light sources to the eye would be the "highlight". Calling these very different mechanisms (one involving shooting rays, another one sampling a distribution function) both "specular contributions" may be true, but is not descriptive terminology. All for now, Eric Haines From greg Tue Oct 9 17:38:38 1990 Return-Path: Received: by hobbes.lbl.gov (3.2/SMI-3.2) id AA10214; Tue, 9 Oct 90 17:38:34 PDT Date: Tue, 9 Oct 90 17:38:34 PDT From: greg (Gregory J. Ward) Message-Id: <9010100038.AA10214@hobbes.lbl.gov> To: globillum@miro.Berkeley.EDU Subject: example calculation Cc: greg Status: RO Hi Everyone, I'm not sure how useful this is going to be as a point for comparison, but I have finished an approximate calculation of a simple rectangular space with diffuse surfaces. I wouldn't guarantee the accuracy to six places, but it should be enough to get us agreeing on ballpark answers, units and so forth. Most of the numbers are within 1%, but a few may be off by as much as 5%. The basic space is a 10 by 6 by 3 rectangular room (length units are irrelevant, but think of them as meters if you like). At the center of the ceiling is a single square fixture that measures .5 on a side. The (monochromatic) emittances and reflectances are as follows: Surface Emittance (w/m^2) Reflectance (%) ======= ================= =============== Source 31.416 0 Ceiling 0 70 Walls 0 50 Floor 0 30 The final radiosities are given below for each surface. The calculation points are separated by .5 in each dimension, starting .25 from the edge. The given coordinates are measured from the origin at one corner of the room. The longer wall is aligned with the x-axis, and the z-axis points up. Since the room has quadrilateral symmetry, calculations are given for just one corner of the room. CEILING ------- X Y Radiosity (w/m^2) = = ================= 0.25000000 0.25000000 0.01138425 0.25000000 0.75000000 0.01313788 0.25000000 1.25000000 0.01407056 0.25000000 1.75000000 0.01490716 0.25000000 2.25000000 0.01517399 0.25000000 2.75000000 0.01550306 0.75000000 0.25000000 0.01319291 0.75000000 0.75000000 0.01506596 0.75000000 1.25000000 0.01621138 0.75000000 1.75000000 0.01687870 0.75000000 2.25000000 0.01734945 0.75000000 2.75000000 0.01770386 1.25000000 0.25000000 0.01472538 1.25000000 0.75000000 0.01668177 1.25000000 1.25000000 0.01778619 1.25000000 1.75000000 0.01855013 1.25000000 2.25000000 0.01899696 1.25000000 2.75000000 0.01914586 1.75000000 0.25000000 0.01633714 1.75000000 0.75000000 0.01844667 1.75000000 1.25000000 0.01948564 1.75000000 1.75000000 0.02024516 1.75000000 2.25000000 0.02071336 1.75000000 2.75000000 0.02088888 2.25000000 0.25000000 0.01789834 2.25000000 0.75000000 0.02029221 2.25000000 1.25000000 0.02156526 2.25000000 1.75000000 0.02242694 2.25000000 2.25000000 0.02265319 2.25000000 2.75000000 0.02295852 2.75000000 0.25000000 0.01987031 2.75000000 0.75000000 0.02248096 2.75000000 1.25000000 0.02381134 2.75000000 1.75000000 0.02445815 2.75000000 2.25000000 0.02476985 2.75000000 2.75000000 0.02515098 3.25000000 0.25000000 0.02168045 3.25000000 0.75000000 0.02465294 3.25000000 1.25000000 0.02589215 3.25000000 1.75000000 0.02645940 3.25000000 2.25000000 0.02696654 3.25000000 2.75000000 0.02724821 3.75000000 0.25000000 0.02374505 3.75000000 0.75000000 0.02670775 3.75000000 1.25000000 0.02791567 3.75000000 1.75000000 0.02838275 3.75000000 2.25000000 0.02891958 3.75000000 2.75000000 0.02901374 4.25000000 0.25000000 0.02518392 4.25000000 0.75000000 0.02832584 4.25000000 1.25000000 0.02933080 4.25000000 1.75000000 0.02983849 4.25000000 2.25000000 0.03027030 4.25000000 2.75000000 0.03061055 4.75000000 0.25000000 0.02607069 4.75000000 0.75000000 0.02907095 4.75000000 1.25000000 0.03020237 4.75000000 1.75000000 0.03073880 4.75000000 2.25000000 0.03095506 4.75000000 2.75000000 31.4159265 FLOOR ----- X Y Radiosity (w/m^2) = = ================= 0.25000000 0.25000000 0.01015400 0.25000000 0.75000000 0.01122695 0.25000000 1.25000000 0.01216249 0.25000000 1.75000000 0.01296263 0.25000000 2.25000000 0.01347411 0.25000000 2.75000000 0.01380374 0.75000000 0.25000000 0.01162805 0.75000000 0.75000000 0.01283973 0.75000000 1.25000000 0.01395678 0.75000000 1.75000000 0.01486528 0.75000000 2.25000000 0.01560173 0.75000000 2.75000000 0.01601771 1.25000000 0.25000000 0.01360239 1.25000000 0.75000000 0.01511654 1.25000000 1.25000000 0.01656299 1.25000000 1.75000000 0.01787189 1.25000000 2.25000000 0.01892671 1.25000000 2.75000000 0.01947751 1.75000000 0.25000000 0.01622055 1.75000000 0.75000000 0.01815677 1.75000000 1.25000000 0.02018784 1.75000000 1.75000000 0.02211131 1.75000000 2.25000000 0.02368511 1.75000000 2.75000000 0.02453778 2.25000000 0.25000000 0.01934452 2.25000000 0.75000000 0.02203424 2.25000000 1.25000000 0.02498133 2.25000000 1.75000000 0.02788695 2.25000000 2.25000000 0.03034291 2.25000000 2.75000000 0.03174435 2.75000000 0.25000000 0.02297257 2.75000000 0.75000000 0.02675407 2.75000000 1.25000000 0.03099317 2.75000000 1.75000000 0.03543063 2.75000000 2.25000000 0.03924163 2.75000000 2.75000000 0.04149249 3.25000000 0.25000000 0.02705865 3.25000000 0.75000000 0.03205292 3.25000000 1.25000000 0.03806442 3.25000000 1.75000000 0.04465337 3.25000000 2.25000000 0.05047386 3.25000000 2.75000000 0.05398497 3.75000000 0.25000000 0.03085844 3.75000000 0.75000000 0.03738140 3.75000000 1.25000000 0.04546639 3.75000000 1.75000000 0.05465413 3.75000000 2.25000000 0.06309141 3.75000000 2.75000000 0.06828176 4.25000000 0.25000000 0.03407802 4.25000000 0.75000000 0.04178086 4.25000000 1.25000000 0.05186804 4.25000000 1.75000000 0.06361728 4.25000000 2.25000000 0.07476903 4.25000000 2.75000000 0.08168386 4.75000000 0.25000000 0.03584532 4.75000000 0.75000000 0.04430811 4.75000000 1.25000000 0.05562513 4.75000000 1.75000000 0.06908717 4.75000000 2.25000000 0.08197656 4.75000000 2.75000000 0.09009412 X-WALL ------ X Z Radiosity (w/m^2) = = ================= 0.25000000 0.25000000 0.01603960 0.25000000 0.75000000 0.01658436 0.25000000 1.25000000 0.01605669 0.25000000 1.75000000 0.01463861 0.25000000 2.25000000 0.01224808 0.25000000 2.75000000 0.00949257 0.75000000 0.25000000 0.01822472 0.75000000 0.75000000 0.01881588 0.75000000 1.25000000 0.01837406 0.75000000 1.75000000 0.01672274 0.75000000 2.25000000 0.01420237 0.75000000 2.75000000 0.01102857 1.25000000 0.25000000 0.02130161 1.25000000 0.75000000 0.02202314 1.25000000 1.25000000 0.02139672 1.25000000 1.75000000 0.01954389 1.25000000 2.25000000 0.01647511 1.25000000 2.75000000 0.01242632 1.75000000 0.25000000 0.02509084 1.75000000 0.75000000 0.02602232 1.75000000 1.25000000 0.02539117 1.75000000 1.75000000 0.02307302 1.75000000 2.25000000 0.01926707 1.75000000 2.75000000 0.01404970 2.25000000 0.25000000 0.02980807 2.25000000 0.75000000 0.03122394 2.25000000 1.25000000 0.03049603 2.25000000 1.75000000 0.02769942 2.25000000 2.25000000 0.02269138 2.25000000 2.75000000 0.01583740 2.75000000 0.25000000 0.03532759 2.75000000 0.75000000 0.03736026 2.75000000 1.25000000 0.03692889 2.75000000 1.75000000 0.03365491 2.75000000 2.25000000 0.02715688 2.75000000 2.75000000 0.01804847 3.25000000 0.25000000 0.04114754 3.25000000 0.75000000 0.04439067 3.25000000 1.25000000 0.04430217 3.25000000 1.75000000 0.04055824 3.25000000 2.25000000 0.03252780 3.25000000 2.75000000 0.02044064 3.75000000 0.25000000 0.04694136 3.75000000 0.75000000 0.05104579 3.75000000 1.25000000 0.05192355 3.75000000 1.75000000 0.04803256 3.75000000 2.25000000 0.03829699 3.75000000 2.75000000 0.02323987 4.25000000 0.25000000 0.05164056 4.25000000 0.75000000 0.05689534 4.25000000 1.25000000 0.05860377 4.25000000 1.75000000 0.05468850 4.25000000 2.25000000 0.04366764 4.25000000 2.75000000 0.02556933 4.75000000 0.25000000 0.05428700 4.75000000 0.75000000 0.06027419 4.75000000 1.25000000 0.06242040 4.75000000 1.75000000 0.05870437 4.75000000 2.25000000 0.04679698 4.75000000 2.75000000 0.02684548 Y-WALL ------ Y Z Radiosity (w/m^2) = = ================= 0.25000000 0.25000000 0.01959936 0.25000000 0.75000000 0.02022097 0.25000000 1.25000000 0.01916556 0.25000000 1.75000000 0.01722267 0.25000000 2.25000000 0.01419036 0.25000000 2.75000000 0.01047861 0.75000000 0.25000000 0.02192977 0.75000000 0.75000000 0.02252979 0.75000000 1.25000000 0.02153332 0.75000000 1.75000000 0.01923800 0.75000000 2.25000000 0.01609385 0.75000000 2.75000000 0.01211624 1.25000000 0.25000000 0.02385556 1.25000000 0.75000000 0.02439873 1.25000000 1.25000000 0.02342732 1.25000000 1.75000000 0.02116588 1.25000000 2.25000000 0.01775289 1.25000000 2.75000000 0.01319875 1.75000000 0.25000000 0.02554671 1.75000000 0.75000000 0.02614940 1.75000000 1.25000000 0.02509958 1.75000000 1.75000000 0.02260681 1.75000000 2.25000000 0.01879053 1.75000000 2.75000000 0.01396981 2.25000000 0.25000000 0.02658299 2.25000000 0.75000000 0.02723759 2.25000000 1.25000000 0.02626222 2.25000000 1.75000000 0.02366757 2.25000000 2.25000000 0.01969741 2.25000000 2.75000000 0.01452824 2.75000000 0.25000000 0.02733945 2.75000000 0.75000000 0.02796613 2.75000000 1.25000000 0.02697156 2.75000000 1.75000000 0.02434958 2.75000000 2.25000000 0.02009894 2.75000000 2.75000000 0.01475180 All values were produced using the algorithm presented in my `88 Siggraph paper. These numbers may not be what is needed to validate a new calculation, but I would be curious to see how they compare to more conventional radiosity calculations. -Greg From greg Tue Oct 9 17:48:35 1990 Return-Path: Received: by hobbes.lbl.gov (3.2/SMI-3.2) id AA10244; Tue, 9 Oct 90 17:48:31 PDT Date: Tue, 9 Oct 90 17:48:31 PDT From: greg (Gregory J. Ward) Message-Id: <9010100048.AA10244@hobbes.lbl.gov> To: globillum@miro.Berkeley.EDU Subject: corrections Status: RO Where is the unsend command when you need it? Besides a spelling error or two, the example calculation I sent out has some problems in the labeling of the results columns for the X and Y walls. Namely, the coordinates for X-WALL should be X and Z (rather than X and Y) and the coordinates for the Y-WALL should be Y and Z. Sure gives you confidence about the numbers, doesn't it? -Greg From shirley@iuvax.cs.indiana.edu Tue Oct 9 21:03:53 1990 Return-Path: Received: from iuvax.cs.indiana.edu (129.79.254.192) by hobbes.lbl.gov (3.2/SMI-3.2) id AA10364; Tue, 9 Oct 90 21:03:47 PDT Message-Id: <9010100403.AA10364@hobbes.lbl.gov> Received: by iuvax.cs.indiana.edu Date: Tue, 9 Oct 90 23:04:04 -0500 From: peter shirley To: greg@hobbes.lbl.gov Subject: Re: example calculation Status: RO Thanks a lot Greg. I'll cogitate on checking your numbers (and thus my code!). pete From eye!erich@uu.psi.com Tue Oct 9 10:56:18 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA09875; Tue, 9 Oct 90 10:56:14 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Tue, 9 Oct 90 10:56:29 PDT Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA00610; Tue, 9 Oct 90 10:58:08 PDT Received: from uu.psi.com by miro.Berkeley.EDU (4.1/1.41) id AA01915; Tue, 9 Oct 90 10:39:14 PDT Received: from eye.UUCP by uu.psi.com (5.61/3.1.090690-Performance Systems International) id AA05369; Tue, 9 Oct 90 13:34:55 -0400 Received: from juniper by eye with SMTP (15.11/15.6) id AA15123; Tue, 9 Oct 90 11:01:04 edt Received: by juniper (15.11/15.6) id AA24493; Tue, 9 Oct 90 11:01:01 edt Message-Id: <9010091501.AA24493@juniper> From: eye!erich@uu.psi.com ( Eric Haines) Date: Tue, 9 Oct 1990 11:00:59 EDT X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: globillum@miro.berkeley.edu Subject: Eurographics Workshop Status: RO This was passed on to me from Erik Jansen, who asked that I spread the word. I contacted Xavier Pueyo for details, and he says they are still working on dates and so on, and that he would contact me when this all becomes clearer. Please do pass on any information you all may receive on this through the globillum list (and so help avoid deluging Xavier). Thanks, Eric Haines, erich@eye.com --------- Eurographics Working Group on Rendering Following a successful workshop on "Photorealistic Rendering", held in June in Rennes, France, a meeting was held during the Eurographics Conference in Montreux 3-7 September 1990 to form a Working Group on Rendering. The working Group will be a platform for discussion and activities on subjects related to image synthesis and high-quality rendering techniques. As main topics were selected: - radiosity and ray tracing - illumination models - texture mapping - sampling, filtering, anti-aliasing This does not exclude other subjects such as: display algorithms in general, VLSI and multi-processor implementations, curved surfaces, etc. A second Workshop on Rendering was announced to be held in May 1991 in Barcelona, Spain. Exact dates will follow. The Workshop will be organized by Xavier Pueyo. Researchers who are interested to join the Working Group are requested to contact: Xavier Pueyo Dept. LiSI Universitat Politecnica de Catalunya Ed. ETSEIB Av. Diagonal, 647 pl. 8 08028 Barcelona Spain e-mail: eapueyo@ebrupc51.bitnet. Non-europeans and non-eurographics members are also welcome. From hr3@prism.gatech.edu Wed Oct 24 10:26:08 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA29217; Wed, 24 Oct 90 10:26:04 PDT Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Wed, 24 Oct 90 10:26:03 PDT Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA12976; Wed, 24 Oct 90 10:28:11 PDT Received: from hydra.gatech.edu by miro.Berkeley.EDU (4.1/1.41) id AA09353; Wed, 24 Oct 90 10:11:13 PDT Received: by hydra.gatech.edu (5.61/3.1) id AA27055; Wed, 24 Oct 90 13:12:13 -0400 Date: Wed, 24 Oct 90 13:12:13 -0400 From: hr3@prism.gatech.edu (RUSHMEIER,HOLLY E) Message-Id: <9010241712.AA27055@prism.gatech.edu> To: globillum@miro.berkeley.edu Subject: comparison with greg's data Status: RO We finally finished doing a radiosity solution to compare with the solution greg posted a while ago. We just used progressive refinement radiosity, using the hemi-cube only for form factors (no ray tracing, no analytical factors). We used 100x100 resolution on the top of the hemisphere. All the walls were discretized into .5 x .5 squares. For most points our results different from Greg's by a few per cent -- except for some wall points and several floor points which varied from Greg's solution by 10 to 20 per cent. It would be very interesting to compare with some non-hemicube, and/or non-progressive refinement results. If you would like our numerical results, let me know & I can mail them to you. Also, I have finished a Monte Carlo solution of the little stick geometry Dan mentioned quite a while ago. The file formats I use aren't standard, but if you are interested anyway let me know and I can give you information how to ftp the results. -- Holly From ph@miro.berkeley.edu Wed Nov 14 18:48:02 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA15862; Wed, 14 Nov 90 18:47:59 PST Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Wed, 14 Nov 90 18:48:05 PST Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA16925; Wed, 14 Nov 90 18:50:41 PST Received: by miro.Berkeley.EDU (4.1/1.41) id AA06048; Wed, 14 Nov 90 18:39:29 PST Date: Wed, 14 Nov 90 18:39:29 PST From: ph@miro.berkeley.edu (Paul Heckbert) Message-Id: <9011150239.AA06048@miro.Berkeley.EDU> To: globillum@miro.berkeley.edu Subject: symbolic solution of integral equations Status: RO Any experts out there on the symbolic solution of integral equations such as the rendering equation? Here's a problem for you: -------- From: ph@miro.Berkeley.EDU (Paul Heckbert) Newsgroups: sci.math Subject: solve this integral equation Date: 15 Nov 90 02:27:00 GMT Can you solve the system of integral equations: u(x) = u0 + c*integral(v(y)*x*y/(x^2+y^2)^(3/2), y, 0, 1); v(y) = v0 + c*integral(u(x)*x*y/(x^2+y^2)^(3/2), x, 0, 1); for the unknown functions u(x) and v(y) given constants u0, v0, and c? Here, "integral(f(x),x,a,b)" is integral of f(x) with respect to x from a to b. I've been unable to go beyond two terms in the Neumann series. These equations describe diffuse interreflection of light in a corner between two walls at right angles, where u(x) is the intensity or "radiosity" along one wall, v(y) is the intensity along the other wall, the direct illumination terms are u0 and v0, and reflectivity is 2*c. -------- A reference on this problem is %A Berthold K. P. Horn %T Understanding Image Intensities %J Artificial Intelligence %V 8 %P 201-231 %D 1977 %K shading, computer vision, radiosity From eye!erich@uu.psi.com Mon Nov 26 07:20:44 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA25807; Mon, 26 Nov 90 07:20:40 PST Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Mon, 26 Nov 90 07:20:41 PST Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA00430; Mon, 26 Nov 90 07:23:30 PST Received: from uu.psi.com by miro.Berkeley.EDU (4.1/1.41) id AA25723; Mon, 26 Nov 90 07:07:54 PST Received: from eye.UUCP by uu.psi.com (5.61/3.1.090690-Performance Systems International) id AA08085; Mon, 26 Nov 90 10:02:33 -0500 Received: from juniper by eye with SMTP (15.11/15.6) id AA05762; Mon, 26 Nov 90 09:41:33 est Received: by juniper (15.11/15.6) id AA05763; Mon, 26 Nov 90 09:41:31 est Date: Mon, 26 Nov 90 09:41:31 est From: eye!erich@uu.psi.com Message-Id: <9011261441.AA05763@juniper> To: globillum@miro.berkeley.edu Subject: Ning Zhang Status: RO I just received this note from Ning Zhang, and thought part of it of interest. -- Eric Haines ----------------------------------- >From Ning Zhang: PS: I have written a Radiosity package and both input and output are based on the NFF file format. Have you considered to have a similar benchmarking package for comparing different Radiosity software and hardware? I think that would be an interesting subject. ----- Self description ----- # Ning Zhang - Radiosity, Raytracing, Image Compression # School of Electrical Engineering # The University of Sydney # NSW 2006, Australia # + 61 (02) 692 2962 alias ning_zhang I have been in Germany for two year as a visiting scientist at the Computer Graphcis Center (ZGDV), Darmstadt. There I developed a Radiosity/Raytracing/FastZBuffer package running on many platforms, including 386PC. Recently I came to Australia as a visiting fellow at the Univ. of Sydney. Email: nzhang@ee.su.OZ.AU (In Germany, zhang@agd.fhg.de or zhang@zgdvda.uucp) From chense@apple.com Mon Nov 26 11:10:11 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA25988; Mon, 26 Nov 90 11:10:08 PST Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Mon, 26 Nov 90 11:10:15 PST Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA01665; Mon, 26 Nov 90 11:13:05 PST Received: from apple.com by miro.Berkeley.EDU (4.1/1.41) id AA26501; Mon, 26 Nov 90 11:04:03 PST Received: from [90.1.0.10] by apple.com with SMTP (5.61/25-eef) id AA08837; Mon, 26 Nov 90 11:02:50 -0800 for globillum@miro.Berkeley.EDU Received: by goofy.apple.com (5.61/25-eef) id AA28479; Mon, 26 Nov 90 11:02:44 -0800 for globillum@miro.Berkeley.EDU Date: Mon, 26 Nov 90 11:02:44 -0800 From: chense@apple.com Message-Id: <9011261902.AA28479@internal.apple.com> To: globillum@miro.berkeley.edu Subject: Re: Ning Zhang Cc: chense@apple.com Status: RO I'll be publishing a paper "Implementing Progressive Radiosity with User- Provided Polygon Display Routines" in the next Graphics Gems. This paper comes with source code (you provide the polygon display routines) to perform standard progressive radiosity (Cohen et. al., SIGGRAPH 88). Since the display routines are provided by users, it can be implemented with ray tracing, z-buffer or any hardware you have. The program does not have any i/o file formats but you should be able to define them for it. A test program is included to render the Cornell red and blue room (with two boxes inside). It might be intesting to do some benchmarking on the same test image. -- Eric From nzhang@ee.su.oz.au Mon Nov 26 15:49:27 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA26457; Mon, 26 Nov 90 15:49:23 PST Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Mon, 26 Nov 90 15:49:28 PST Received: from brutus.ee.su.oz.au by lbl.gov (4.1/1.39) id AA03296; Mon, 26 Nov 90 15:52:12 PST Received: by brutus.ee.su.oz.au (5.61/1.34) id AA12286; Tue, 27 Nov 1990 10:46:28 +1100 Date: Tue, 27 Nov 1990 10:46:28 +1100 From: nzhang@ee.su.oz.au (Ning Zhang) Message-Id: <9011262346.AA12286@brutus.ee.su.oz.au> To: gjward@Csa1.lbl.gov Subject: Radiosity test package Status: RO Hi, Greg, I have talked with Eric Haines about standard test package for radiosity. I learned from him that you are working on this subject and have done something. Could you add me to your list on this, if there is one, I am also interested in this subject. About myself, I developed a Raytracing/Radiosity/FastZbuffer package when I was in Germany. I am now a visiting fellow at the Univ. of Sydney. Regards, -Ning From shirley@iuvax.cs.indiana.edu Fri Dec 7 13:56:22 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA06843; Fri, 7 Dec 90 13:56:18 PST Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Fri, 7 Dec 90 13:56:24 PST Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA10378; Fri, 7 Dec 90 13:54:02 PST Received: from iuvax.cs.indiana.edu by miro.Berkeley.EDU (4.1/1.41) id AA13101; Fri, 7 Dec 90 13:44:16 PST Message-Id: <9012072144.AA13101@miro.Berkeley.EDU> Received: by iuvax.cs.indiana.edu Date: Fri, 7 Dec 90 16:44:09 -0500 From: shirley@iuvax.cs.indiana.edu To: globillum@miro.berkeley.edu Subject: skin BRDF? Status: RO Anyone have any references for the BRDF of human skin? How about just the spectral refl of skin for normal incidence? Thanks, pete PS-- anyone know Jim Arvo's new email address? From atc@cs.utexas.edu Fri Dec 7 15:11:32 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA06912; Fri, 7 Dec 90 15:11:28 PST Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Fri, 7 Dec 90 15:11:33 PST Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA10757; Fri, 7 Dec 90 15:09:08 PST Received: from cs.utexas.edu by miro.Berkeley.EDU (4.1/1.41) id AA13230; Fri, 7 Dec 90 14:18:26 PST Posted-Date: Fri, 7 Dec 90 16:18:02 CST Message-Id: <9012072218.AA21955@cs.utexas.edu> Received: by cs.utexas.edu (5.64/1.90) From: atc@cs.utexas.edu (Alvin T. Campbell III) Date: Fri, 7 Dec 90 16:18:02 CST X-Mailer: Mail User's Shell (6.5.6 6/30/89) To: shirley@iuvax.cs.indiana.edu, globillum@miro.berkeley.edu Subject: Re: skin BRDF? Status: RO Believe it or not, I have actually run across this before. When I implemented the Cook/Torrace shading model a few years back, I had to spend a lot of time looking through various colorimetry books. Most of the reflectance data I needed was either in "Color in Business, Science, and Industry," or "The Thermophysical Properties of Matter." In one of these books, probably the former, I saw data for skin reflectance of various human ethnic groups. For a complete bibliographic citation, see "A Reflectance Model for Computer Graphics" by Cook and Torrance, from SIGGRAPH '81. A. T. Campbell, III CS Department, University of Texas atc@cs.utexas.edu From hr3@prism.gatech.edu Sat Dec 8 09:52:37 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA07650; Sat, 8 Dec 90 09:52:33 PST Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Sat, 8 Dec 90 09:52:34 PST Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA17115; Sat, 8 Dec 90 09:50:14 PST Received: from hydra.gatech.edu by miro.Berkeley.EDU (4.1/1.41) id AA18251; Sat, 8 Dec 90 09:47:43 PST Received: by hydra.gatech.edu (5.61/3.1) id AA15262; Sat, 8 Dec 90 12:47:43 -0500 Date: Sat, 8 Dec 90 12:47:43 -0500 From: hr3@prism.gatech.edu (RUSHMEIER,HOLLY E) Message-Id: <9012081747.AA15262@prism.gatech.edu> To: globillum@miro.berkeley.edu Subject: skin brdf Status: RO The ASHRAE Fundamentals Handbook has all sorts of bizarre references for thermal properties of animals and people. As far as spectral reflectance for skin they list: H.F. Kuppenheim and R.R. Heer, Journal of Applied Physiology, Vol. 4, 1952, p. 800. J.D. Hardy and H.R. Hammel and D. Murgatroyd, Journal of Applied Physiology, Vol. 9, 1956, p. 257. The 1985 Fundamentals Handbook I have has a very small graph showing a hemispherical reflectance on p. 8.9 -- Holly From hr3@prism.gatech.edu Wed Dec 12 11:58:37 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA13035; Wed, 12 Dec 90 11:58:34 PST Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Wed, 12 Dec 90 11:58:40 PST Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA02730; Wed, 12 Dec 90 11:56:24 PST Received: from hydra.gatech.edu by miro.Berkeley.EDU (4.1/1.41) id AA04452; Wed, 12 Dec 90 11:52:14 PST Received: by hydra.gatech.edu (5.61/3.1) id AA11867; Wed, 12 Dec 90 14:52:12 -0500 Date: Wed, 12 Dec 90 14:52:12 -0500 From: hr3@prism.gatech.edu (RUSHMEIER,HOLLY E) Message-Id: <9012121952.AA11867@prism.gatech.edu> To: globillum@miro.berkeley.edu Subject: Siggraph 79 article Status: RO We are trying to locate "A Tutorial on Compensation Tables" by Catmull from Siggraph 79. Our library's copy of the 79 Proceedings has apparently been stolen. Does anybody know if this paper was included in any other books that we could look for? Thanks, Holly From atc@cs.utexas.edu Wed Dec 12 12:28:41 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA13052; Wed, 12 Dec 90 12:28:37 PST Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Wed, 12 Dec 90 12:28:42 PST Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA02876; Wed, 12 Dec 90 12:26:26 PST Received: from cs.utexas.edu by miro.Berkeley.EDU (4.1/1.41) id AA05029; Wed, 12 Dec 90 12:22:27 PST Posted-Date: Wed, 12 Dec 90 14:22:14 CST Message-Id: <9012122022.AA20004@cs.utexas.edu> Received: by cs.utexas.edu (5.64/1.90) From: atc@cs.utexas.edu (Alvin T. Campbell III) Date: Wed, 12 Dec 90 14:22:14 CST X-Mailer: Mail User's Shell (6.5.6 6/30/89) To: hr3@prism.gatech.edu (RUSHMEIER,HOLLY E) Subject: Re: Siggraph 79 article Cc: globillum@miro.berkeley.edu Status: RO The Catmull paper is reproduced in an IEEE collection of graphics articles, edited by Beatty and Booth. I believe the title of the collection is something like "Computer Graphics: A Tutorial, 2nd Edition". This book may well be in your library, or you can order directly from the IEEE. It is a handy addition to any graphics researcher's library, since it collects many hard-to-find articles from the early days of the field. Good luck in your search. A. T. From eye!erich@uu.psi.com Thu Dec 13 11:14:08 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA15057; Thu, 13 Dec 90 11:14:04 PST Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Thu, 13 Dec 90 11:14:10 PST Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA07063; Thu, 13 Dec 90 11:11:50 PST Received: from uu.psi.com by miro.Berkeley.EDU (4.1/1.41) id AA23266; Thu, 13 Dec 90 11:00:23 PST Received: from eye.UUCP by uu.psi.com (5.61/3.1.090690-Performance Systems International) id AA00113; Thu, 13 Dec 90 13:56:04 -0500 Received: from juniper by eye with SMTP (15.11/15.6) id AA03637; Thu, 13 Dec 90 13:56:32 est Received: by juniper (15.11/15.6) id AA18312; Thu, 13 Dec 90 13:56:29 est Date: Thu, 13 Dec 90 13:56:29 est From: eye!erich@uu.psi.com Message-Id: <9012131856.AA18312@juniper> To: globillum@miro.berkeley.edu Subject: Amusing... Status: RO I saw this on comp.graphics, and thought I'd pass it on (hopefully everyone on this list doesn't read comp.graphics, or do they? If you don't, please do tell us, so we know whether it's worth re-posting articles of interest). ----- Subject: Linguistical question about radiosity. Organization: University of Houston -- Department of Mathematics Date: Wed, 12 Dec 90 17:57:32 GMT With rendering, we have a noun "renderer" which is easy to decline (for all intents and purposes :-) and a verb "render" that's easy to conjugate: "What rendering method are you using?" "How fast can you render this scene?" With ray tracing, it is similar "I wrote a ray tracer". "When we trace a scene, foo happens." With radiosity, uh... "I wrote a radiositizer." "When I radiate this scene." "My radiator code is broken." ("You should drive a VW bug, then." :-) So, what's a good everyday verb to use for radiosity? "radiosity solver" is a tad long for informal use. I use "radiate", personally. "Let's radiate this scene and see what it looks like." has such a nice ring to it... -- J. Eric Townsend Internet: jet@uh.edu Bitnet: jet@UHOU Systems Mangler - UH Dept. of Mathematics - (713) 749-2120 Skate (UNIX || AmigaDos) "This meme's for you..." --------- As far as the article goes: so, what do you call it? Around here environments get "radiositized", which is quite a mouthful (and sounds vaguely dangerous, to boot: "How many millirems of radiation is emitted when you radiositize something?"). Eric Haines From tom@adam.byu.edu Thu Dec 13 13:54:58 1990 Return-Path: Received: from adam.byu.edu (128.187.3.2) by hobbes.lbl.gov (3.2/SMI-3.2) id AA15635; Thu, 13 Dec 90 13:54:45 PST Received: by adam.byu.edu (5.59/5.17) id AA06636; Thu, 13 Dec 90 14:51:06 MST Date: Thu, 13 Dec 90 14:51:06 MST From: tom@adam.byu.edu (Thomas W. Sederberg) Message-Id: <9012132151.AA06636@adam.byu.edu> To: greg@hobbes.lbl.gov Subject: Re: Siggraph `91 cover Status: RO Greg: Rick Beach, the proceedings editor, is in charge of selecting the cover images for the SIGGRAPH proceedings. I understand that these images are normally chosen from the papers that are accepted for the proceedings. There are a few other places that exceptional images can be printed, such as in the cover of the technical program. But unless you have a paper accepted for the conference, I believe that there is no hope of getting you space in the proceedings. Why don't you ask Rick Beach for further info: beach.siggraph@xerox.com Let me know if I can help further. Tom Sederberg From turner@apple.com Thu Dec 13 16:25:52 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA15903; Thu, 13 Dec 90 16:25:48 PST Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Thu, 13 Dec 90 16:25:55 PST Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA09047; Thu, 13 Dec 90 16:23:40 PST Received: from apple.com by miro.Berkeley.EDU (4.1/1.41) id AA28523; Thu, 13 Dec 90 16:15:26 PST Received: by apple.com (5.61/25-eef) id AA14396; Thu, 13 Dec 90 16:15:16 -0800 for globillum@miro.Berkeley.EDU Date: Thu, 13 Dec 90 16:15:16 -0800 From: turner@apple.com Message-Id: <9012140015.AA14396@apple.com> To: eye!erich@uu.psi.com, globillum@miro.berkeley.edu Subject: Re: Amusing... Status: RO Here at Apple I work with Eric Chen, so when I see one of his radiosity pictures, I usually exclaim "Wow Eric how long did it take you to cook that database?" or "Ummmm...nicely cooked scene Eric." So I'm a fan of the word: cook. It's short, it's sweet, it's to the point. I feel it fits well with the whole field having it's origins in heat transfer. -Doug From ph@miro.berkeley.edu Thu Dec 13 13:49:13 1990 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA15628; Thu, 13 Dec 90 13:49:07 PST Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Thu, 13 Dec 90 13:49:11 PST Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA08073; Thu, 13 Dec 90 13:46:56 PST Received: by miro.Berkeley.EDU (4.1/1.41) id AA26282; Thu, 13 Dec 90 13:49:04 PST Date: Thu, 13 Dec 90 13:49:04 PST From: ph@miro.berkeley.edu (Paul Heckbert) Message-Id: <9012132149.AA26282@miro.Berkeley.EDU> To: gjward@Csa1.lbl.gov, mcohen@cs.utah.edu Subject: Europeans Cc: ph@miro.berkeley.edu Status: RO I got the mailing list for the European "Rendering working group" from Xavier Pueyo the other day (finally) so rather than put everybody from that list on globillum automatically, I emailed each of them asking them if they'd like to join. In case you're interested, my note and the list I got from Xavier (edited into .mailrc form) follow: >From ph Wed Dec 12 15:59:03 1990 Date: Wed, 12 Dec 90 15:59:01 PST To: ag@bora.inria.fr, bouatouch@irisa.fr, brunet%ebrupc51.BITNET@jade.Berkeley.EDU, faconti@icnucevx.cnuce.cnr.it, frits@dutidh.tudelft.nl, fwj@dutidh.tudelft.nl, zgdvda!gsakas, healb@csovax.portsmouth.ac.uk, igute%dtupev5a.BITNET@jade.Berkeley.EDU, kroemker@agd.fhg.de, paterno@icnucevm.cnuce.cnr.it, peroche@image.emse.fr, philipp@gris.informatik.uni-tuebingen.de, pre@sauna.hut.fi, purgathofer@eigcl1.una.at, rein@dutidh.tudelft.nl, robert@cwi.nl, rvivo@aii.upv.es, scop@icnucevm.cnuce.cnr.it, strasser@gris.informatik.uni-tuebingen.de, wim@dutidh.tudelft.nl, xavier@lsi.upc.es Subject: globillum mailing list Dear fellow renderer: I received your email address from Xavier Pueyo as someone who might be interested in participating in the "globillum" electronic mailing list that Greg Ward and I started at SIGGRAPH '90 in August. The globillum mail group consists of 30 people in the United States and Canada at present. Our discussions center on algorithms for simulating global illumination in a general, accurate manner. Many of us are interested in generalizing methods to handle both diffuse and specular surfaces. Most of us use ray tracing or radiosity algorithms or some hybrid. There has been significant discussion of validation methods for algorithms (how do you find a "correct" solution when an analytic solution is not possible), sharing of bibliographies, and agreement on terminology. Mail traffic among us varies between one message every two weeks and several per day. Anyone can post a message to the group (you simply email to a special address at my machine here at UC Berkeley) and it will go to everyone else in the group. Because the mail goes to so many people we ask members not to post messages frivolously; we don't want the discussion to degenerate into a free-for-all as has the comp.graphics newsgroup on USENET, for instance. On the other hand, the exchange of ideas made possible by a global electronic network is very exciting, and we look forward to sharing interesting ideas with many of you. If you would like to join the group, email me your most reliable email address and perhaps a brief summary of your interests. Also tell me if you would like a copy of the past discussion in our mail group, which amounts to about 200,000 bytes. -Paul Paul Heckbert, Computer Science Dept. 570 Evans Hall, UC Berkeley INTERNET: ph@miro.berkeley.edu Berkeley, CA 94720 UUCP: ucbvax!miro.berkeley.edu!ph USA --------------------------------------------------------- # EUROPEAN RENDERING WORKING GROUP # note: puech & sillion not included in eurorend because they're on globillum alias eurorend bronsvoort bouatouch brunet claussen faconti \ gagalowicz heal jansen kroemker paterno peroche post \ pueyo purgathofer rekola sakas scopigno \ slusallek strasser vankly vanliere vivo # Wim F. Bronsvoort; Faculty of Technical Mathematics and Informatics; # Delft University of Technology; Julianalaan 132; 2628 BL Delft; Netherlands alias bronsvoort wim@duticg.tudelft.nl # Kadi Bouatouch; IRISA; Campus Beaulieu; 35042 Rennes; France alias bouatouch bouatouch@irisa.fr alias bouatouch2 kadi@irisa.fr # Ch. Bouville; CCETT TAV/SVS; BP 59; 35512 Cesson-Sevigne Cedex; France # Pere Brunet alias brunet brunet@ebrupc51.bitnet # Chapman P.A.; Lewis,E.; Department of Computer Sciences; # University of Bristol; England; United Kingdom # Ute Claussen; AITEC GmbH Co; Informationstechnologie KG; Am Hartweg 106; # D-4600 Dortmund; alias claussen igute@dtupev5a.bitnet # F. Devai; Computer and Automation Institute; Hungarian Academy of Sciences; # POB 63; Kende 13-17; H-1502 Budapest; Hungary # F. Devai; Dep. of Computer Science; University of Edinburgh; Edinburgh; # United Kingdom # Englert, G.; Sakas, G.; Technische Hochschule Darmstadt; # Fachgebiet Graphisch-Interaktive Systeme (GRIS); Wilhelminenstr, 7; # D-6100 Darmstadt; Germany # Giorgio Faconti alias faconti faconti@icnucevx.cnuce.cnr.it # Andre Gagalowicz; INRIA; Domaine de Voluceau; Rocquencourt; # 78153 Le Chesnay Cedex; France alias gagalowicz ag@bora.inria.fr # A. Garcia - P.Morer; Dept. Mecanica Aplicada; C.E.I.T.G.; Apart. 1555; # B. Ibaeta s/n; E-20009 S.Sebastian; # B. Geymayer; Institut f. Digitale Bildverarbeitung; u. Graphik; # Wastiangasse 6; A-8010 Graz; # Giger, C.; Technische Hochschule Darmstadt; FB Informatik; # FG Graphisch-Interactive Systeme; Wilhelminenstr. 7; D-6100 Darmstadt; # J. G. Griffiths; Dep. of Computer Science; University of Hull; Hull HU6 7RX; # United Kingdom # H. Hagen; Fachbereich Informatik; Institut f. Graphische Datenverarbeitung; # u. Computergeometrie; Universitat Kaiserslautern; Postfach 3049; # D-6750 Kaiserslautern; # Brian W. Heal; School of Information Science; Portsmouth Polytechnic; # Mercantile House; Hampshire Terrace; Portsmouth, PO1 2EG; United Kingdom alias heal healb@csovax.portsmouth.ac.uk # Hornung, Ch.; GTS-GRAL; Alsfelder Strasse 7; D-6100 Darmstadt; Germany # Erik W. Jansen; Faculty of Technical Mathematics and Informatics; # Delft University of Technology; Julianalaan 132; 2628 BL Delft; Netherlands alias jansen fwj@duticg.tudelft.nl # Detlef Kroemker alias kroemker kroemker@agd.fhg.de alias kroemker2 dkroemker@agd.fhg.de # H. Muller; Institut f. Informatik; Universitat Freiburg; Rheinstrasse 10-12; # D-7800 Freiburg i. Br; # L. Neumann; Software Development Department; Mikroker Cooperative; # Varosmajor, u.52; H-1122 Budapest; Hungary # A. Neumann; Railway Research Institute; Muzeum u.11; H-1088 Budapest; Hungary # A. Paoluzzi; M.Rosina; Dipartimento di Informatica e Sistematica; # Universita di Roma ``La Sapienza''; Via Buonarroti, 12; 00184 Roma; Italy # Fabio Paterno alias paterno paterno@icnucevm.cnuce.cnr.it # M. Peroche; ENSM de Saint-Etienne; Dep. Informatique Appliquee; # 158, Cours Fauriel; F-42023 Saint-Etienne Cedex 2; France # Bernard Peroche alias peroche peroche@image.emse.fr # M. Pins; Hild,H.; Institut fur Betriebs und Dialogsysteme; # Universitat Karlsruhe; Karlsruhe; West Germany # J. Popsel; UNI GH Paderborn; Fachgebiet Datentechnik; D-4790 Paderborn; # Frits Post; Faculty of Technical Mathematics and Informatics; # Delft University of Technology; Julianalaan 132; 2628 BL Delft; Netherlands alias post frits@duticg.tudelft.nl # Claude Puech; LIENS; 45, rue d'Ulm; 75230 Paris Cedex 05; France alias puech puech@dmi.ens.fr # Xavier Pueyo; Dept.Llenguatges i Sistemes Informatics; # Universitat Politecnica de Catalunya; Av. Diagonal, 647 planta 8; # 08028-Barcelona; Spain; alias pueyo xavier@lsi.upc.es alias pueyo2 eapueyo@ebrupc51.bitnet # Werner Purgathofer; Institut fur Praktische Informatik; Techn. Univ. Vienna; # A-1040 Karlsplatz 13/180; Autriche; alias purgathofer purgathofer@eigcl1.una.at # Panu Rekola alias rekola pre@cs.hut.fi # Giorgios Sakas alias sakas gsakas@zgdvda.uucp # B. O. Schneider; Universitat Tubingen; # Wilhelm-Schickard-Institut fur Informatik; Graphisch-Interaktive-Systeme; # Auf der Morgenstelle 10/C9; D-7400 Tubingen; West Germany # S. Schuierer; Institut fur Informatik; Rheinstr. 10-12; Universitat Freiburg; # D-7800 Freiburg; # H. Schumann; Sektion Informatik; Universitat Rostock; # Albert Einstein Strasse 21; DDR-2500 Rostock; # Roberto Scopigno; CNUCE; Consiglio Nazionale delle Richerche; # Via S.Maria, 36; 56100 Pisa; Italy alias scopigno scop@icnucevm.cnuce.cnr.it # F. Seron; ETS Ingenieros de Zaragoza; Universidad de Zaragoza; # Maria de la Luna 3; E-50015 Zaragoza; # Francois X. Sillion alias sillion fxs@saturn.graphics.cornell.edu # Phillip Slusallek alias slusallek philipp@gris.informatik.uni-tuebingen.de # A. Augusto Sousa; INESC.Norte; Largo Mompilher 22; 4000 Porto; Portugal # Wolfgang Strasser; Universitat Tubingen; Wilhelm-Schickard-Institut; # Auf der Morgenstelle 10, C9; D-7400 Tubingen; West Germany alias strasser strasser@gris.informatik.uni-tuebingen.de # P. Stucki; Institut f. Informatik; Universitat Zurich-Irchel; # Winterthurerstrasse 190; CH-8057 Zurich; # T. Theoharis; St. Catharine's College; Cambridge CB2 1RL; United Kingdom # J. Torres; Univ. de Granada; Avda. Sur; Edif. Presidente II; E-18014 Granada; # Reiner van Kly alias vankly rein@duticg.tudelft.nl # Robert van Liere alias vanliere robert@cwi.nl # Roberto Vivo; Dep. Sist. Informaticos y Comp.; U.P.V.; Camino de Vera s/n; # E-46071 Valencia; Spain alias vivo rvivo@aii.upv.es # END OF RENDERING WORKING GROUP MAILING LIST From ph@miro.berkeley.edu Thu Jan 3 14:26:54 1991 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA13429; Thu, 3 Jan 91 14:26:47 PST Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Thu, 3 Jan 91 14:26:49 PST Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA24511; Thu, 3 Jan 91 14:24:59 PST Received: by miro.Berkeley.EDU (4.1/1.41) id AA15918; Thu, 3 Jan 91 14:16:40 PST Date: Thu, 3 Jan 91 14:16:40 PST From: ph@miro.berkeley.edu (Paul Heckbert) Message-Id: <9101032216.AA15918@miro.Berkeley.EDU> To: globillum@miro.berkeley.edu Subject: new members of globillum mailing list Status: RO At Michael Cohen's suggestion, I got in touch with Kadi Bouatouch and Xavier Pueyo to invite European researchers to join our "globillum" mailing list. From Xavier I got a list of members of the "European Rendering Working Group" that Xavier and Kadi collected after the Eurographics workshop in Rennes, France last summer. I sent mail to all of those (about 22) inviting them to join our group if they were interested in discussing global illumination. Several of them joined, so here's an updated list of members of globillum. We're now up to 41 people. (For most of the Europeans I've included paper-mail addresses and a brief list of interests that they mentioned. I include this information for them but not the Americans and Canadians mostly because most of the North Americans have met each other, but have not met the Europeans. If people would like it I could collect similar info from everyone.) # GLOBAL ILLUMINATION MAILING LIST, 1/3/91 # append the following to your .mailrc file # # send corrections/additions to Paul Heckbert # note: preferred way to send mail to everyone on list is to mail to # globillum (aliased below), where a master copy of list is being maintained. alias globillum globillum@miro.berkeley.edu alias globillum_explicit \ amanatides arvo asensio baum bouatouch buckalew bullis \ campbell carlton chen mcohen delft \ fussell george greenberg greene haines \ hanrahan heal heckbert kirk kolb lalonde \ dmitchell puech pueyo purgathofer recker \ rushmeier scopigno shirley sillion slusallek \ spencer turner vanliere jwallace ward # John Amanatides, York U, Toronto alias amanatides amana@cs.yorku.ca # Jim Arvo, Apollo / Yale alias arvo arvo@wisdom.graphics.cornell.edu # Frederic Asensio, LIENS alias asensio asensio@ens.ens.fr # Dan Baum, Silicon Graphics alias baum drb@sgi.com # Kadi Bouatouch; IRISA; Campus de Beaulieu; 35042 Rennes Cedex; France # interests: ray tracing, sampling, realism, physics & perception alias bouatouch kadi@irisa.fr alias bouatouch2 bouatouch@irisa.fr # Ch. Bouville; CCETT; Rue du Clos Courtel; 35512 Cesson-Sevigne Cedex; France # interests: ray tracing, sampling, realism, physics & perception alias bouville bouville@ccettix.uucp # Wim F. Bronsvoort; Faculty of Technical Mathematics and Informatics; # Delft University of Technology; Julianalaan 132; 2628 BL Delft; Netherlands alias bronsvoort wim@duticg.tudelft.nl # Chris Buckalew, Cal Poly alias buckalew buckalew@polyslo.calpoly.edu # Jim Bullis, Dicomed alias bullis mg13502@uc.msc.umn.edu # A. T. Campbell III, U of Texas, Austin alias campbell atc@cs.utexas.edu # Eloise Carlton, Fujitsu America alias carlton eloisec@fai.com # Eric Chen, Apple alias chen chense@apple.com # Michael Cohen, U of Utah alias mcohen mcohen@cs.utah.edu # 'delft' is an alias for Jansen, Bronsvoort, Post, van Kly at Tech. U of Delft # interests: VLSI for radiosity; ray tracing, texture mapping, CSG alias delft globillum@duticg.tudelft.nl # Don Fussell, U of Texas, Austin alias fussell fussell@cs.utexas.edu # David George, DEC, Palo Alto alias george dwg@decwrl.dec.com # Don Greenberg c/o Fran Brown, Cornell U alias greenberg fmb@squid.graphics.cornell.edu # Ned Greene, Apple / U of California, Santa Cruz alias greene greene@apple.com # Eric Haines, 3D/Eye alias haines erich@eye.com # Pat Hanrahan, Princeton U alias hanrahan pmh@princeton.edu # Brian W. Heal; School of Information Science; Portsmouth Polytechnic; # Mercantile House; Hampshire Terrace; Portsmouth, PO1 2EG; United Kingdom # interests: rendering octree models, post-hidden-surface-removal rendering alias heal healb@csovax.portsmouth.ac.uk # Paul Heckbert, U of California, Berkeley alias heckbert ph@miro.berkeley.edu # Frederik W. Jansen (Erik); Faculty of Technical Mathematics and Informatics; # Delft University of Technology; Julianalaan 132; 2628 BL Delft; Netherlands alias jansen fwj@duticg.tudelft.nl # Dave Kirk, Caltech alias kirk dk@egg.gg.caltech.edu # Craig Kolb, Yale, Graphics Gems ftp administrator alias kolb kolb@yale.edu # Paul Lalonde, Queen's U alias lalonde lalonde@qucis.queensu.ca # Don Mitchell, Bell Labs, Murray Hill NJ alias dmitchell don@research.att.com # Frits Post; Faculty of Technical Mathematics and Informatics; # Delft University of Technology; Julianalaan 132; 2628 BL Delft; Netherlands alias post frits@duticg.tudelft.nl # Claude Puech, LIENS / Stanford alias puech puech@ens.ens.fr # Xavier Pueyo; Dept.Llenguatges i Sistemes Informatics; # Universitat Politecnica de Catalunya; Av. Diagonal, 647 planta 8; # 08028-Barcelona; Spain; # interests: diffuse environments alias pueyo xavier@lsi.upc.es alias pueyo2 eapueyo@ebrupc51.bitnet # Werner Purgathofer; Institute for Computer Graphics; Techn. Univ. Vienna; # Karlsplatz 13 / 186; A-1040 Wien / Austria # interests: parallel ray tracing and radiosity, BSP, color, animation alias purgathofer purgathofer@eigvs4.una.at alias purgathofer2 purgathofer@eigcl1.una.at # Rod Recker, ATT Pixel Machines alias recker rjr@pixels.att.com # Holly Rushmeier, Georgia Tech alias rushmeier hr3@hydra.gatech.edu # Roberto Scopigno; CNUCE; Consiglio Nazionale delle Richerche; # Via S.Maria, 36; 56100 Pisa; Italy # interests: volume rendering, user interfaces, parallel processing, geography alias scopigno scop@icnucevm.cnuce.cnr.it # Pete Shirley, Indiana U alias shirley shirley@iuvax.cs.indiana.edu # Francois Sillion, Cornell U alias sillion fxs@squid.graphics.cornell.edu # Phillip Slusallek; Universitaet Tuebingen, WSI/GRIS; # Auf der Morgenstelle 10, C9, D-7400 Tuebingen; FRG # interests: CAD, surfaces, doing PhD on physical basis of glob. illum. alias slusallek philipp@gris.informatik.uni-tuebingen.de # Stephen Spencer alias spencer spencer@cgrg.ohio-state.edu # Doug Turner, Apple alias turner turner@apple.com # Reiner van Kly alias vankly rein@duticg.tudelft.nl # Robert van Liere; Department of Interactive Systems; # Center for Mathematics and Computer Science (CWI); # Kruislaan 413, 1098 SJ Amsterdam, The Netherlands # interests: generalizing radiosity method, parallel methods for radiosity alias vanliere robertl@cwi.nl alias vanliere2 robert@cwi.nl # John Wallace, 3D/Eye alias jwallace johnw@eye.com # Greg Ward, Lawrence Berkeley Lab alias ward gjward@lbl.gov # END OF GLOBAL ILLUMINATION MAILING LIST From ph@miro.berkeley.edu Thu Jan 17 13:27:13 1991 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA00399; Thu, 17 Jan 91 13:27:06 PST Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Thu, 17 Jan 91 13:27:08 PST Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA17193; Thu, 17 Jan 91 13:25:32 PST Received: by miro.Berkeley.EDU (4.1/1.41) id AA27926; Thu, 17 Jan 91 13:11:00 PST Date: Thu, 17 Jan 91 13:11:00 PST From: ph@miro.berkeley.edu (Paul Heckbert) Message-Id: <9101172111.AA27926@miro.Berkeley.EDU> To: globillum@miro.berkeley.edu, jmw@sgi.com Subject: finite element methods for global illumination Status: RO To rejuventate discussion in "globillum", I suggest that those of us who just submitted SIGGRAPH papers, who feel comfortable about it, summarize their papers for the rest of the group. Even those who didn't submit a paper might want to describe their current global illumination work. A note about the propriety of discussing work-in-progress and distributing paper drafts electronically: I think email can help augment published journals and conferences without displacing or subverting them. Each has its place: published papers provide the permanent record and reference; email is great for fast international communication and brainstorming. I'm not attempting to influence the siggraph review process in the slightest, but rather I'm interested in sharing my ideas with others, and hearing their ideas, so that we can all improve our methods, hopefully resulting in even better published papers in the future. I think it would be inappropriate to distribute entire papers electronically, if they have been or ever might be copyrighted, but distribution of abstracts is another matter. To get things started, here's the abstract of a paper I just co-wrote with Jim Winget. I follow it with a terse summary of the paper's ideas. Also, in the course of my work, I came across some new references in the computer vision, thermal radiation and finite element literature that might be of interest to others. Send me your references, I'll collect them and mail them to everyone. -Paul ------------------------------------- Finite Element Methods for Global Illumination Paul Heckbert, UC Berkeley Jim Winget, Silicon Graphics (SIGGRAPH '91 paper draft, 8 Jan 1991) ABSTRACT The interreflection of light between surfaces is governed by an integral equation. Existing radiosity algorithms transform this integral equation into a system of linear equations. Such algorithms are simple applications of the finite element method. Techniques are presented for applying more advanced finite element techniques to the global illumination problem in order to yield more accurate results. First, piecewise-linear, piecewise-quadratic, and higher order elements are discussed as a superior alternative to current piecewise-constant radiosity assumptions. Second, Galerkin techniques are a more robust alternative to current point collocation (point sampling) techniques. Finally, occlusions in a scene give rise to discontinuities such as shadow edges in the solution function. {\it Discontinuity meshing} is introduced as a technique for resolving these discontinuities by adaptive placement of element boundaries. Illustrations, algorithms, and results are given for two-dimensional {\it radiosity in flatland} problems. ------ Terse summary for globillumers: Global illumination is governed by a Fredholm integral equation of the second kind. This equation is called the "rendering equation" in computer graphics circles [Kajiya86] and the "mutual illumination equation" in computer vision circles [Koenderink-van Doorn, J. Opt. Soc. Am, June 1983, p. 843; Forsyth-Zisserman, Proc. Comp Vis & Pat Rec, 1989 (CVPR '89), p. 466]. Radiosity algorithms typically ignore the errors introduced during their discretization step. In fact, existing radiosity algorithms are a simple form of finite element method. Existing methods use piecewise-constant elements during form factor calculation (the Gouraud shading commonly used for output is just a "display hack", in my opinion), they evaluate form factors only from polygon centers (or vertices), and they often use uniform polygonization meshes. In finite element jargon, these three assumptions correspond to the use of piecewise constant elements, point collocation methods, and uniform non-adaptive meshes. Accuracy of the radiosity solution functions can be improved on all three fronts: piecewise-linear, -quadratic, or higher order elements can be used to improve approximation fit; Galerkin techniques can be used in place of point collocation to improve the faithfulness of the discretized problem to the continuous problem; and a priori "discontinuity meshing" can be used to choose a subdivision mesh (e.g. polygonization) that can resolve discontinuities in the solution function. (Discontinuities in value arise at shadow edges from point light sources or at shadow edges where surfaces touch or intersect. Discontinuities in slope occur at penumbras arising from area light sources casting shadows caused by separated objects.) Most of the above is illustrated in a reduced-dimensionality world we call "radiosity in flatland". Many global illumination ideas are easier to visualize, implement, and compare in flatland, making it a good testbed. Our results are 2-D so far. Some of our main sources of inspiration: [Kajiya86] for emphasis on integral equation. [Baum89] for emphasis on need for more accurate form factors. [Ward88, Campbell90] for emphasis on adaptive sampling/meshing of radiosity. From hr3@prism.gatech.edu Fri Jan 18 06:52:04 1991 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA01187; Fri, 18 Jan 91 06:52:00 PST Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Fri, 18 Jan 91 06:51:59 PST Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA19396; Fri, 18 Jan 91 06:50:24 PST Received: from hydra.gatech.edu by miro.Berkeley.EDU (4.1/1.41) id AA00749; Fri, 18 Jan 91 06:42:04 PST Received: by hydra.gatech.edu (5.61/3.1) id AA03816; Fri, 18 Jan 91 09:42:01 -0500 Date: Fri, 18 Jan 91 09:42:01 -0500 From: hr3@prism.gatech.edu (RUSHMEIER,HOLLY E) Message-Id: <9101181442.AA03816@prism.gatech.edu> To: globillum@miro.berkeley.edu Subject: Scientific American Status: RO I suppose I was the last person to get the Feb. Sci. Am., so everybody has probably already discussed this. Can anybody tell me how they did the beams on the cover? Was it a simple post-process approximation, or something more complicated? Is the museum picture on p. 109 supposed to look significantly different on either side of the white stripe? My favorite statement from the article is "Radiosity is not only fast (after the initial calculations have been done)..." -- Holly From spencer@cgrg.ohio-state.edu Fri Jan 18 07:04:08 1991 Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA01199; Fri, 18 Jan 91 07:04:04 PST Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Fri, 18 Jan 91 07:04:09 PST Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA19533; Fri, 18 Jan 91 07:02:34 PST Received: from heinlein.cgrg.ohio-state.edu by miro.Berkeley.EDU (4.1/1.41) id AA00770; Fri, 18 Jan 91 06:54:11 PST Return-Path: Received: by heinlein.cgrg.ohio-state.edu (5.64/900625.02) id AA01907; Fri, 18 Jan 91 09:54:03 -0500 Date: Fri, 18 Jan 91 09:54:03 -0500 From: spencer@cgrg.ohio-state.edu (Stephen N. Spencer) Message-Id: <9101181454.AA01907@heinlein.cgrg.ohio-state.edu> To: globillum@miro.berkeley.edu In-Reply-To: RUSHMEIER,HOLLY E's message of Fri, 18 Jan 91 09:42:01 -0500 <9101181442.AA03816@prism.gatech.edu> Subject: Scientific American Status: RO I've only seen a colleague's copy, not having gotten to a bookstore yet, but I noticed a disturbing printing error (or so I think) in the museum image that was on the SIGGRAPH 1988 cover: what's that white lower-left to upper-right stripe? Argh! (I read the caption, but not the whole article: if there's some reasoning for the stripe in the article, I've missed it.) steve From eye!erich@uu.psi.com Fri Jan 18 14:17:36 1991 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA02213; Fri, 18 Jan 91 14:17:32 PST Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Fri, 18 Jan 91 14:17:34 PST Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA21521; Fri, 18 Jan 91 14:16:00 PST Received: from uu.psi.com by miro.Berkeley.EDU (4.1/1.41) id AA02575; Fri, 18 Jan 91 14:07:00 PST Received: from eye.UUCP by uu.psi.com (5.61/3.1.090690-Performance Systems International) id AA10600; Fri, 18 Jan 91 17:02:26 -0500 Received: from juniper by eye with SMTP (15.11/15.6) id AA18623; Fri, 18 Jan 91 16:34:00 est Received: by juniper (15.11/15.6) id AA12678; Fri, 18 Jan 91 16:33:57 est Message-Id: <9101182133.AA12678@juniper> From: eye!erich@uu.psi.com (Eric Haines) Date: Fri, 18 Jan 1991 16:33:57 EST X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: globillum@miro.berkeley.edu Subject: Scientific American Cc: erich@juniper.berkeley.edu Status: RO Answers on the Scientific American article (Feb., with radiosity images by Don P. Greenberg): - The image with the white diagonal stripe across it (the full image also on the cover of the SIGGRAPH 88 Proceedings) is indeed two separate images, and it's meant to show how you can change colors easily. I had the same comment ("Hey, what's that white stripe, a printing error?"). My guess is that the images were generated for the SIGGRAPH 88 cover with minor variations in color schemes tested, so there probably weren't any images available that were radically different. So, it's probably a real life example, but unfortunately you can't really see much difference in the colors. Any Cornellians who were actually there have any comments based on more than conjecture? - Actually, there was a bug I noticed: Ronchamp was spelled Ronchamps in the article. Rats. - I came up with the technique for the beams of light from the windows. It's not "true" atmospherics (a la Rushmeier), but (although you can't tell from this particular shot) the beams do blend with the environment (i.e. beams behind a pew are not seen, etc). Don pressed us for some beams for a bunch of weeks, and finally I came up with a technique that could compute in a finite amount of time. Basically, I use the windows to define a set of beams, then stochastically sample these volumes and add in the contributions. What's funny is that the beams look "realistic" compared to my mental image of what beams of light should look like. However, I then actually found a real picture of Ronchamp with beams of light coming in, and the beams are in fact very sharp edged! One detail that adds to the "realism" of the real picture is that the stained glass has variations in it, giving the beams of light variance within them. If I show Ronchamp images rendered with un-stochastic beams of light (i.e. perfectly sharp edged), people don't like them because they feel they're unrealistic. I wonder if this is a case of people having seen too MUCH computer graphics, where almost everything has sharp edges. Also, maybe people recall beams of light coming out of the clouds (where the beams are usually not sharp edged) - we don't see stained glass as much, I guess. It's interesting to me how much context matters: if you show someone a picture and say "this is my kitchen," they go, "OK". If you say, "this is a computer graphic rendering of a kitchen," they go "Oh, yeah, you can see the following problems..." I remember seeing Cindy Goral's radiosity rendering of the sculpture (name forgotten) on the computer screen for the first time, and not questioning it at all - I was convinced it was a scanned-in photo of a real sculpture. Part of this effect was that this was the first radiosity image (other than the inside of a patriotically colored empty box) of anything, and we weren't used to seeing them at all. The image didn't look like a scan-line rendering or a ray trace, so it looked real. Reminds me of AI research: whenever some difficult task is mastered by a computer (e.g. play chess well, etc), this is taken to mean that the task is not proof of intelligence. When we develop a new rendering technique, it becomes part of our vocabulary and we are then less often fooled by images which use these soon old techniques. Enough stories for now, Eric Haines, erich@eye.com From mcohen@cs.utah.edu Fri Jan 18 14:38:51 1991 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA02244; Fri, 18 Jan 91 14:38:47 PST Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Fri, 18 Jan 91 14:38:50 PST Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA21595; Fri, 18 Jan 91 14:36:53 PST Received: from cs.utah.edu by miro.Berkeley.EDU (4.1/1.41) id AA02708; Fri, 18 Jan 91 14:30:16 PST Received: by cs.utah.edu (5.65/utah-2.16-cs) id AA13215; Fri, 18 Jan 91 15:28:50 -0700 Date: Fri, 18 Jan 91 15:28:50 -0700 From: mcohen@cs.utah.edu (Michael Cohen) Message-Id: <9101182228.AA13215@cs.utah.edu> To: eye!erich@uu.psi.com, globillum@miro.berkeley.edu Subject: Re: Scientific American Cc: erich@juniper.berkeley.edu Status: RO Some more history: One guess is that the editors got two images of the museum, one brownish, and one blueish (I remember these variations) and then the printers tried to get them to match. Who knows? It could happen! Also, if you remember the Meyer et al articles with the experiment in which we sat people down to look at the REAL vs. RAD images, the "public" did better job of finding the REAL image than the graphnics. The graphnics picked the radiosity image to the real one since as everyone knows (or at least knew then), simulated images have sharper edges than real ones. I suspect there are plenty of situations in which you can fool people if that is your goal. -Michael From chense@apple.com Fri Jan 18 16:05:31 1991 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA02348; Fri, 18 Jan 91 16:05:27 PST Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Fri, 18 Jan 91 16:05:27 PST Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA22047; Fri, 18 Jan 91 16:03:51 PST Received: from apple.com by miro.Berkeley.EDU (4.1/1.41) id AA03208; Fri, 18 Jan 91 15:55:47 PST Received: from [90.1.0.10] by apple.com with SMTP (5.61/25-eef) id AA26602; Fri, 18 Jan 91 15:55:42 -0800 for globillum@miro.Berkeley.EDU Received: by goofy.apple.com (5.61/25-eef) id AA10432; Fri, 18 Jan 91 15:55:36 -0800 for globillum@miro.Berkeley.EDU Date: Fri, 18 Jan 91 15:55:36 -0800 From: chense@apple.com Message-Id: <9101182355.AA10432@internal.apple.com> To: globillum@miro.berkeley.edu Subject: Re: Scientific American Cc: chense@apple.com Status: RO The museum picture in Feb. Scientific American is ideed two separate images with different floor colors. The original museum I created for Siggraph88 cover had a blue carpted floor (i.e., the right one in S.A.). But I was told that blue won't reproduce very well in printing. Therefore, the floor was changed to brown (i.e., the left one in S. A.) in the final image. The two images actually looked quite different on the screen. The color bleeding effect propagated to the whole museum and gave the blue one a cool tint and the brown one a warm tint(i.e., the walls and ceiling are all neutral grey). The image on Siggraph88 cover was printed directly from digital data(i.e., It was quite scary actually because the printer never knew what the image was supposed to look like before the printing and we didn't see the image until it was printed. We were afraid the color would be completely off because of all the gamma and white point corrections. It turned out very well--maybe a little bit on the yellow side just to be picky). I think the two images S.A. used were from slides shot from screen directly. By the time they printed on paper, all the subtle color variations were pretty much lost already. If you ask me about the S. A. picture, I'll say the diagonal stripe sucks. They could have used a thin vertical white line to split the picture into two halves. The bold diagonal line is rude and destroys whatever is left in that picture. -- Eric From greg Thu Jan 24 13:42:54 1991 Return-Path: Received: by hobbes.lbl.gov (3.2/SMI-3.2) id AA02811; Thu, 24 Jan 91 13:42:48 PST Date: Thu, 24 Jan 91 13:42:48 PST From: greg (Gregory J. Ward) Message-Id: <9101242142.AA02811@hobbes.lbl.gov> To: globillum@miro.berkeley.edu, jmw@sgi.com, ph@miro.berkeley.edu Subject: current research Status: RO Well, I haven't submitted any papers for Siggraph in quite a while, but I'm happy to talk about my research. (The way things are going, this may be the only place you'll ever hear about it...) Hopefully, people who are interested in the same kinds of things will give me feedback or offer suggestions. 1. Z-buffered animation from ray tracing Actually, this is a hack for getting fast animations out of ray tracing renderers. Basically, I store a z-buffer with the ray-traced images sampling every N timesteps, and perform z-buffer rendering on individual pixels for the frames in between. This work is more or less finished, I just need to have someone write it up for me! 2. Bidirectional reflectance distribution function measurement and modeling We have been developing an instrument for quick measurement of the BRDF's of different materials and are looking at various mathematical models for reproducing the data with a few parameters. Everyone is familiar with the Phong model, most people have heard of the Torrance-Sparrow model (I challenge anyone to write it down from memory), but there are quite a few other models to choose from, and no one seems to have found the answer for every class of surface. If you have BRDF measurements of architectural surfaces, or a pet reflectance model, please let me know. (Holly Rushmeier has been kind enough to share her research in this area with me. Thanks, Holly!) 3. Fast direct calculations for ray tracing I have developed a moderately successful technique for reducing the number of shadow tests necessary for computing the direct component of a ray tracing calculation. The approach falls more along the lines of something Pete Shirley mentioned in his 1990 GI paper than Eric Haines' light buffer algorithm in that it trades speed for accuracy rather than speed for memory. If anyone's interested, I'd be happy to share details. 4. Improved daylight calculations Actually, this is what I hope to be working on in the near future. Current methods are hopelessly inadequate when it comes to modeling intense sources of highly directional radiation bouncing about off of (sometimes specular) room surfaces. The solutions I plan to explore fall along the lines of what Paul Heckbert has been investigating with bidirectional sampling techniques. That's the official agenda. Don't ask me what I've really been doing! -Greg From @research.att.com:don@allegra.att.com Thu Jan 24 14:29:28 1991 Return-Path: <@research.att.com:don@allegra.att.com> Received: from research.att.com (192.20.225.2) by hobbes.lbl.gov (3.2/SMI-3.2) id AA02926; Thu, 24 Jan 91 14:29:23 PST Message-Id: <9101242229.AA02926@hobbes.lbl.gov> Received: by research; Thu Jan 24 17:29:10 EST 1991 Date: Thu, 24 Jan 91 17:29:01 EST From: don@allegra.att.com (Don Mitchell) To: greg@hobbes.lbl.gov Subject: research Cc: don@research.att.com Status: RO I'd be interested in hearing about your shadow-test algorithm. I talk about Shirley's in my book. I like the stuff you and Paul are doing with sampling. I want to be able to put radiosity into my ray tracer, but most schemes are not general enough to deal with arbitrary objects in the scene. Something along the lines of what you worked on is sure to be the answer. From fwj@dutidh.tudelft.nl Fri Jan 25 05:02:12 1991 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA04119; Fri, 25 Jan 91 05:02:09 PST Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Fri, 25 Jan 91 05:02:05 PST Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA15021; Fri, 25 Jan 91 05:00:27 PST Received: from mcsun.EU.net by miro.Berkeley.EDU (4.1/1.41) id AA06161; Fri, 25 Jan 91 04:43:05 PST Received: by mcsun.EU.net with SMTP; Fri, 25 Jan 91 13:43:02 +0100 Received: from [130.161.180.1] by hp4nl.nluug.nl with SMTP id AA27178 (5.58.1.14/2.14); Fri, 25 Jan 91 13:41:57 MET Received: by dutrun.tudelft.nl (5.57/1.10) id AA19266; Fri, 25 Jan 91 08:52:48 +0100 (MET) Message-Id: <9101250752.AA19266@dutrun> Received: by dutidh; Fri, 25 Jan 91 08:57:27 -0100 Date: Fri, 25 Jan 91 08:57:27 -0100 From: fwj@dutidh.tudelft.nl To: globillum@miro.berkeley.edu Status: RO Subject: Current Research (Greg Ward's message) We are also working on a version of Shirley's algorithm with an efficient calculation of the direct component. We are using a shadow coherence method. We tried to submit a paper for Siggraph but missed the deadline (paper was sent by express mail on Jan 4 but failed to be in Provo, Utah by Jan 9 - can we have an address in Europe next time?). We will submit a new version of the paper to the EG rendering Workshop in Barcelona, Spain (see Call for Papers in previous newsletters). Erik Jansen/Arjan Kok From shirley@iuvax.cs.indiana.edu Fri Jan 25 09:21:46 1991 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA04421; Fri, 25 Jan 91 09:21:42 PST Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Fri, 25 Jan 91 09:21:47 PST Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA16040; Fri, 25 Jan 91 09:20:22 PST Received: from iuvax.cs.indiana.edu by miro.Berkeley.EDU (4.1/1.41) id AA06263; Fri, 25 Jan 91 06:11:39 PST Message-Id: <9101251411.AA06263@miro.Berkeley.EDU> Received: by iuvax.cs.indiana.edu Date: Fri, 25 Jan 91 08:14:35 -0500 From: shirley@iuvax.cs.indiana.edu To: globillum@miro.berkeley.edu Subject: Image file formats Status: RO I'm rewriting my code from scratch (a yearly exercise :^}), and am writing output routines now. I want to leave my options open for image manipulation at display time, so I'd like a general spectral image format. If there were no space constraints, I'd want something like: Header (number of pixels, number and location of spectral samples, interpolation rule between samples) Pixel values (spectral radiance float for each wavelength) I'm now thinking that a slight modification of what Greg Ward uses would be enough, where the pixels are stored with one byte per spectral sample, and a one byte exponent. Has anyone tried this? Greg, is there any problem, in practice, using one byte precision? pete From greg Fri Jan 25 09:38:29 1991 Return-Path: Received: by hobbes.lbl.gov (3.2/SMI-3.2) id AA04469; Fri, 25 Jan 91 09:38:24 PST Date: Fri, 25 Jan 91 09:38:24 PST From: greg (Gregory J. Ward) Message-Id: <9101251738.AA04469@hobbes.lbl.gov> To: globillum@miro.berkeley.edu, shirley@iuvax.cs.indiana.edu Subject: Re: Image file formats Status: RO Dear Pete and Glob, The only drawback with a one byte per spectral sample plus one byte shared exponent format is that it is limited to an accuracy of about 1%. If you need better accuracy at each sample, you will have to go to more bits. Frankly, unless you are going to smother the visible spectrum with sample points, I don't think that the 1% error in each sample is going to be very significant compared to whatever interpolation technique you apply. I would be very interested in whatever format you come up with. Have you thought about compression techniques? It's been my experience that Lempel-Ziv as employed by compress on an uncompressed image does pretty well, and is certainly easy to implement(!). I use run-length encoding with my three-sample (OK, so I admit it's just RGB) format, and compress still manages to squeeze the result down to 50% of the original size in most cases. -Greg From don%allegra.att.com@research.att.com Fri Jan 25 13:01:03 1991 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA05385; Fri, 25 Jan 91 13:00:59 PST Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Fri, 25 Jan 91 13:01:04 PST Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA17340; Fri, 25 Jan 91 12:59:38 PST Received: from research.att.com by miro.Berkeley.EDU (4.1/1.41) id AA08411; Fri, 25 Jan 91 12:49:15 PST Message-Id: <9101252049.AA08411@miro.Berkeley.EDU> Received: by research; Fri Jan 25 15:49:13 EST 1991 Date: Fri, 25 Jan 91 15:49:05 EST From: don@allegra.att.com (Don Mitchell) To: globillum@miro.berkeley.edu Subject: image-file headers Status: RO Tom Duff and I designed a "picfile" format six years ago that Bell Labs uses. The biggest win is that headers are variable-length ascii, an idea that we have found very useful. A basic header is: TYPE=dump WINDOW=0 0 1280 720 NCHAN=3 It assumes only that that there is a 2-dimensional array of samples, that each sample is NCHAN bytes long, and that this data is encoded in some way specified by TYPE (dump, runcode, bitmap, ccitt-g4, etc). You do a picopen and picread, and you get one row of decoded data. Data is usually uchars, floats, or complex in our applications. You can add any additional attribute=value lines in the header. Usually, there is higher-level information that application programs deal with. Command history is also kept around by most of our software tools. A typical header is: TYPE=dump WINDOW=0 0 640 768 NCHAN=3 CHAN=rgb COMMAND= piccat WHEELS.frand IN EXPER.WHEELS.frand COMMAND= FX COMMAND= picjoin JUNK1 JUNK2 OUT COMMAND= resample 320 IN JUNK1 -igamma 1 -ogamma 1 COMMAND= transpose IN OUT COMMAND= resample 256 IN OUT -igamma 1 -ogamma 1 COMMAND= transpose ERRORIMAGE OUT COMMAND= histoequalize IN ERRORIMAGE COMMAND= picaverage WHEELS.perfect IN OUT COMMAND= FX COMMAND= picnegate WHEELS.frand OUT COMMAND= FX COMMAND= resample 320 IN JUNK2 -igamma 1 -ogamma 1 COMMAND= transpose IN OUT COMMAND= resample 256 IN OUT -igamma 1 -ogamma 1 COMMAND= transpose SPECTRUM OUT COMMAND= distortion WHEELS.perfect.bw WHEELS.frand.bw From don%allegra.att.com@research.att.com Fri Jan 25 13:11:16 1991 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA05395; Fri, 25 Jan 91 13:11:13 PST Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Fri, 25 Jan 91 13:11:10 PST Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA17378; Fri, 25 Jan 91 13:09:45 PST Received: from research.att.com by miro.Berkeley.EDU (4.1/1.41) id AA08439; Fri, 25 Jan 91 12:58:27 PST Message-Id: <9101252058.AA08439@miro.Berkeley.EDU> Received: by research; Fri Jan 25 15:58:33 EST 1991 Date: Fri, 25 Jan 91 15:58:24 EST From: don@allegra.att.com (Don Mitchell) To: globillum@miro.berkeley.edu Subject: research Status: RO I submitted a paper to SIGGRAPH this year: Spectrally Optimal Sampling for Distributed Ray Tracing abstract Distributed ray tracing is a multidimensional extension of the conventional ray tracing algorithm. Like all ray tracing techniques, it suffers from the aliasing problems associated with point sampling. In conventional ray tracing, a theory of two-dimensional nonuniform sampling exists which describes how aliasing can be converted into high-frequency random noise. Nonuniform (stochastic) sampling is an integral part of the distributed ray tracing scheme; and in this paper, the two-dimensional theory is extended. An implementation demonstrates that aliasing in motion blur, shadow penumbras and depth-of-field focusing can be driven into higher frequencies by appropriate sampling strategies. By driving noise into higher frequencies, it can be more completely removed by filtering and is less conspicuous to the human observer. From greg Fri Jan 25 14:16:27 1991 Return-Path: Received: by hobbes.lbl.gov (3.2/SMI-3.2) id AA05754; Fri, 25 Jan 91 14:16:23 PST Date: Fri, 25 Jan 91 14:16:23 PST From: greg (Gregory J. Ward) Message-Id: <9101252216.AA05754@hobbes.lbl.gov> To: don@allegra.att.com Subject: Re: image-file headers Status: RO Hey, hey! It seems that I use the exact same variable-length header format as Don in my picture files! (Even with the blank line to indicate the end of header and command history to boot!) I think this kind of independent consensus deserves some kind of special recognition. All we need to do now is agree on variable names. (Actually, this is the same problem TIFF has with user-definability.) -Greg From ph@miro.berkeley.edu Wed Feb 13 11:30:44 1991 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA05661; Wed, 13 Feb 91 11:30:40 PST Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Wed, 13 Feb 91 11:30:45 PST Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA23237; Wed, 13 Feb 91 11:29:41 PST Received: by miro.Berkeley.EDU (4.1/1.41) id AA28691; Wed, 13 Feb 91 11:30:09 PST Date: Wed, 13 Feb 91 11:30:09 PST From: ph@miro.berkeley.edu (Paul Heckbert) Message-Id: <9102131930.AA28691@miro.Berkeley.EDU> To: gjward@Csa1.lbl.gov Subject: europe Cc: ph@miro.berkeley.edu Status: RO I got mail from a guy named Ute Claussen of Dortmund, Germany recently, requesting to join the globillum group. In his (papermail) letter, he said that he and a friend have recently written a radiosity program for IBM PC's that they are publishing in the German equivalent of BYTE magazine. I thought you might want to communicate with him, especially since you'll be over in Europe soon. He is: # Ute Claussen; Nordstr. 39; 4600 Dortmund 1; Germany # interests: illumination, real time rendering, car simulators, radiosity on PC alias claussen ute@gris.informatik.uni-tuebingen.de alias claussen_old igute@dtupev5a.bitnet +49 231/81 41 83 (private) +49 231/17 99 11 (company) I'll send him email suggesting that he summarize his radiosity program to globillum in email. ---- Did you hear about British Airways' reduced airfares? Will you and Cindy be able to take advantage of that? From schlick@timide.greco-prog.fr Thu Feb 14 00:39:35 1991 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA06606; Thu, 14 Feb 91 00:39:31 PST Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Thu, 14 Feb 91 00:39:43 PST Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA25900; Thu, 14 Feb 91 00:38:32 PST Received: from ucbvax.Berkeley.EDU by miro.Berkeley.EDU (4.1/1.41) id AA03957; Thu, 14 Feb 91 00:25:56 PST Received: from inria.inria.fr by ucbvax.Berkeley.EDU (5.63/1.42) id AA05537; Thu, 14 Feb 91 00:25:48 -0800 Received: from geocub.greco-prog.fr by inria.inria.fr (5.65+/90.0.9) via Fnet-EUnet id AA14433; Thu, 14 Feb 91 09:25:35 +0100 (MET) Received: from timide.greco-prog.fr by geocub.greco-prog.fr, Thu, 14 Feb 91 09:34:00 EST Received: by timide.greco-prog.fr (4.0/SMI-4.0) id AA00685; Thu, 14 Feb 91 09:24:16 +0100 Date: Thu, 14 Feb 91 09:24:16 +0100 From: schlick@timide.greco-prog.fr (SCIROCCO) Message-Id: <9102140824.AA00685@timide.greco-prog.fr> To: globillum@miro.berkeley.edu Status: RO Hello G.I.s (Global Illuminators, of course...) I'm new to the group and I just read the old issues (thanks Paul). I want to come back --- just for a moment --- on the diffuse/specular discussion that was suspended without being closed. Why ? For me, the reason is that "diffuse" and "specular" are terms that everyone has been using for years. So very strong semantic mental associations have been created for each of the terms in our minds... and who can easily break his mental associations (isn't it Sigmund ?) The problem comes from the fact that we want to give subjective names to scientific notions. The solution that I propose --- that should be appealing for our scientific brains (!) --- is to take the ONLY objective term that characterizes our surfaces that is the >> shape of the distribution function << Three categories can be exhibit : Uniform distribution (UD) Delta (or Dirac) distribution (DD) Potatoid distribution (PD) I think the 3 terms are unconfusing because everyone knows what a uniform or a delta distribution is, and everyone can imagine how a potatoid distribution looks like (potatoes can really have any shape !) To get in link with the recent discussion in comp.graphics, some very nice sentences could appear in the globillum community : "I cook the scene using a new potatoid distribution" Why not create a gastromic award for the next SIGGRAPH ? More seriously, diffuse & specular can be used in papers, according to the writer's mental associations, but the new terminology offers an easy way to explain these personal meanings at the beginning of the paper. Well, the word "potatoid" certainly isn't the right one. In fact, I don't know if it ever exist in english : it is a litteral traduction from french. I have think about Free Form Distribution (but FFD is already used), Irregular Distribution or General Distribution... I don't have enough english vocabulary to find a better one. As far as we are speaking about terminology revolutions, what about throwing away the term "radiosity method". Sure there are a lot of historical reasons for the word. But radiosity does really have a sense only in diffuse environments, speaking of radiosity in general environments, especially when your are using IES units instead of heat transfer units, sounds odd. As stated by Peter in his thesis, "radiosity method" --- at least progressive radiosity --- can be viewed as a light transfer simulation (I don't remember the real term he used) instead of a linear system resolution. So what we are using here in Bordeaux for several months, and what I propose to the community is : Iterative Light Distribution (Method) or Progressive Light Distribution (Method) Well, that were my five cents (three cents tax for oversea message !) Christophe From greg Thu Feb 14 09:52:03 1991 Return-Path: Received: by hobbes.lbl.gov (3.2/SMI-3.2) id AA07218; Thu, 14 Feb 91 09:51:55 PST Date: Thu, 14 Feb 91 09:51:55 PST From: greg (Gregory J. Ward) Message-Id: <9102141751.AA07218@hobbes.lbl.gov> To: globillum@miro.berkeley.edu, schlick@timide.greco-prog.fr Subject: terminology Status: RO I agree with Christophe's suggestion of dropping "radiosity method". I think that what we are really talking about is finite element analysis of light transfer, and the UNIT radiosity has very little to do with the general problem. In fact, I can't really use the term for my work at all since radiosity is an inappropriate quantity for non-diffuse environments. -Greg From greg@hobbes.lbl.gov Thu Feb 14 10:07:41 1991 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA07278; Thu, 14 Feb 91 10:07:38 PST Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Thu, 14 Feb 91 10:07:41 PST Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA27287; Thu, 14 Feb 91 10:06:34 PST Received: from lbl.gov by miro.Berkeley.EDU (4.1/1.41) id AA05610; Thu, 14 Feb 91 09:52:09 PST Received: from hobbes.lbl.gov by lbl.gov (4.1/1.39) id AA27170; Thu, 14 Feb 91 09:51:17 PST Received: by hobbes.lbl.gov (3.2/SMI-3.2) id AA07218; Thu, 14 Feb 91 09:51:55 PST Date: Thu, 14 Feb 91 09:51:55 PST From: greg@hobbes.lbl.gov (Gregory J. Ward) Message-Id: <9102141751.AA07218@hobbes.lbl.gov> To: globillum@miro.berkeley.edu, schlick@timide.greco-prog.fr Subject: terminology Status: RO I agree with Christophe's suggestion of dropping "radiosity method". I think that what we are really talking about is finite element analysis of light transfer, and the UNIT radiosity has very little to do with the general problem. In fact, I can't really use the term for my work at all since radiosity is an inappropriate quantity for non-diffuse environments. -Greg From eye!erich@uu.psi.com Sat Feb 16 19:20:22 1991 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA11850; Sat, 16 Feb 91 19:20:18 PST Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Sat, 16 Feb 91 19:20:27 PST Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA20572; Sat, 16 Feb 91 19:19:25 PST Received: from uu.psi.com ([136.161.128.3]) by miro.Berkeley.EDU (4.1/1.41) id AA22191; Sat, 16 Feb 91 19:12:27 PST Received: from eye.UUCP by uu.psi.com (5.61/3.1.090690-Performance Systems International) id AA05902; Sat, 16 Feb 91 16:17:54 -0500 Received: from juniper by eye with SMTP (15.11/15.6) id AA03869; Sat, 16 Feb 91 15:50:27 est Received: by juniper (15.11/15.6) id AA16496; Sat, 16 Feb 91 15:50:23 est Date: Sat, 16 Feb 91 15:50:23 est From: eye!erich@uu.psi.com Message-Id: <9102162050.AA16496@juniper> To: globillum@miro.berkeley.edu Subject: Progressive versus ? Cc: erich@juniper.berkeley.edu Status: RO So, here's another definitional question: Progressive radiosity is called "Progressive Radiosity". What shall we call the other kind(s) of radiosity where the full matrix is computed & solved? "Full Matrix Radiosity", "Full Solution Radiosity", "Simultaneous Equation Radiosity" (and you thought that the term "radiosity" was lengthy), or just plain "Radiosity"? I don't like just "Radiosity", since this seems like it should be an overarching term which includes the progressive algorithm. Also, one more thing to consider is Pat Hanrahan's hierarchical structuring work for "Full" radiosity - he's taking some of the matrixness out of things and replacing them with a different structure (though of course a matrix of some sort could be derived from his solution scheme). I guess we could turn to the world of advertising and have "Radiosity Lite" (for progressive rad) and "Radiosity Dry" (in honor of those boring fine-white elephant, that is to say, finite element books always referenced in papers about the full matrix solution). I'm interested in any answers ASAP, as I need the term for the extended abstract for the Barcelona workshop. Eric Haines, erich@eye.com p.s. Potatoid distribution, indeed. From drb%studmuffin.asd.sgi.com@sgi.com Sun Feb 17 15:04:37 1991 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA12351; Sun, 17 Feb 91 15:04:34 PST Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Sun, 17 Feb 91 15:04:47 PST Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA27252; Sun, 17 Feb 91 15:03:43 PST Received: from SGI.COM by miro.Berkeley.EDU (4.1/1.41) id AA24615; Sun, 17 Feb 91 14:44:07 PST Received: from giraffe.asd.sgi.com by SGI.COM via SMTP (5.65+bind 1.5+ida/910110.SGI) for globillum@miro.Berkeley.EDU id AA10619; Sun, 17 Feb 91 14:43:08 -0800 Received: from studmuffin.asd.sgi.com by giraffe.asd.sgi.com via SMTP (5.64-bind 1.5+ida/900721.SGI) for sgi.sgi.com!juniper.Berkeley.EDU!erich id AA07729; Sun, 17 Feb 91 14:42:37 -0800 Received: by studmuffin.asd.sgi.com (5.52/900721.SGI) for @giraffe.asd.sgi.com:globillum@miro.Berkeley.EDU id AA16800; Sun, 17 Feb 91 14:41:57 PST Date: Sun, 17 Feb 91 14:41:57 PST From: drb%studmuffin.asd.sgi.com@sgi.com (Dan Baum) Message-Id: <9102172241.AA16800@studmuffin.asd.sgi.com> To: eye!erich@uu.psi.com, globillum@miro.berkeley.edu Subject: Re: Progressive versus ? Cc: erich@juniper.berkeley.edu Status: RO When we came up with the term "full matrix radiosity," we considered several alternative but couldn't think of anything more descriptive. I like the term in that it suggests that the matrix is assembled and stored unlike progressive refinement. However, it would be nice if the name implied that the "full solution" is also computed directly, unlike the progressive refinement. dan From don%allegra.att.com@research.att.com Sun Feb 17 15:35:53 1991 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA12384; Sun, 17 Feb 91 15:35:49 PST Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Sun, 17 Feb 91 15:36:03 PST Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA27443; Sun, 17 Feb 91 15:35:03 PST Received: from research.att.com by miro.Berkeley.EDU (4.1/1.41) id AA24806; Sun, 17 Feb 91 15:16:45 PST Message-Id: <9102172316.AA24806@miro.Berkeley.EDU> Received: by research; Sun Feb 17 18:16:51 EST 1991 Date: Sun, 17 Feb 91 18:15:08 EST From: don@allegra.att.com (Don Mitchell) To: globillum@miro.berkeley.edu Subject: nomenclature Status: RO I have always been disturbed by radiosity terminology. First, I think the language of Illumination Engineering and Radiometry should be used instead of heat-transfer jargon. I'd like to hear people talk about "direct component of illumination" (local) and "interflected component" (global) and "diffuse interflected" and "specular interflected". Secondly, we should not confuse algorithms with shading effects. There may be many ways to compute various components of illumination. Ray tracing [Ward] or path tracing [Kajiya] or light textures [Shirley and Heckbert] are distinctly different algorithms from what I think of as the "Cornell Algorithms" of computing form factors between faces and solving a matrix. When people say "radiosity" it is not always clear whether they mean the Cornell algorithm or the diffuse interflected component of illumination. In Greenberg's recent Sci Am. article, he talks about radiosity versus ray tracing. I think he is talking about algorithms in that case. From shirley@iuvax.cs.indiana.edu Sun Feb 17 17:48:32 1991 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA12459; Sun, 17 Feb 91 17:48:28 PST Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Sun, 17 Feb 91 17:48:41 PST Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA28293; Sun, 17 Feb 91 17:47:42 PST Received: from iuvax.cs.indiana.edu by miro.Berkeley.EDU (4.1/1.41) id AA25208; Sun, 17 Feb 91 17:28:38 PST Message-Id: <9102180128.AA25208@miro.Berkeley.EDU> Received: by iuvax.cs.indiana.edu Date: Sun, 17 Feb 91 20:29:01 -0500 From: shirley@iuvax.cs.indiana.edu To: globillum@miro.berkeley.edu Subject: More Barcelona Status: RO Hello out there. Only a few people have responded to my query about Barcelona. Greg W is probably going, as is Eric H. Holly R will probably not make it. I have been shopping for airfares and have not done better than $950 round-trip, so I am probably out. I may get lucky on a special fare, but I'm not holding my breath. pete PS-- if you can get to Spain, it should be good. Last year's workshop in France was great fun. From ph@miro.berkeley.edu Sun Feb 17 21:55:44 1991 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA12593; Sun, 17 Feb 91 21:55:39 PST Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Sun, 17 Feb 91 21:55:47 PST Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA29432; Sun, 17 Feb 91 21:54:48 PST Received: by miro.Berkeley.EDU (4.1/1.41) id AA25875; Sun, 17 Feb 91 21:33:45 PST Date: Sun, 17 Feb 91 21:33:45 PST From: ph@miro.berkeley.edu (Paul Heckbert) Message-Id: <9102180533.AA25875@miro.Berkeley.EDU> To: globillum@miro.berkeley.edu Subject: Re: Progressive versus ? Status: RO How about: MATRIX RADIOSITY a la Goral, Cohen85 where the kernel of the integral operator is discretized in a lattice of rows and columns (a matrix) and stored in its entirety. PROGRESSIVE RADIOSITY a la Cohen88 where the kernel is sampled a column at a time, as part of the iterative algorithm for solving the system of equations HIERARCHICAL RADIOSITY a la Hanrahan90 where the kernel is discretized (sampled) adaptively, as in Warnock's hidden surface algorithm or in quadtree subdivision Perhaps if progressive (iterative, on-the-fly) variants of hierarchical radiosity and other variations come along, we'll need composite names like "progressive hierarchical radiosity", etc. I'm undecided on whether what we're now calling "radiosity algorithms" should be renamed, to distinguish it from radiosity (the unit). Greg and Don make good arguments that the name "radiosity algorithm" is misleading. The most viable, concise alternative I've heard is "zonal methods". Any others? -Paul in other news, the following people have joined globillum since Jan. 3: (note that we now have representatives from Japan and Australia!) # Mike Allison, Lawrence Livermore Lab alias allison allison4@llnl.gov # Christian Bouville; CCETT; Rue du Clos Courtel; 35512 Cesson-Sevigne Cedex; # France alias bouville bouville%ccettix@irisa.fr # Ute Claussen; Nordstr. 39; 4600 Dortmund 1; Germany # interests: illumination, real time rendering, car simulators, radiosity on PC alias claussen ute@gris.informatik.uni-tuebingen.de alias claussen_old igute@dtupev5a.bitnet # Chuck Grant, Lawrence Livermore Lab alias grant grant1@llnl.gov alias grant2 grant%delvalle.llnl.gov@lll-lcc.llnl.gov # Kazufumi Kaneda; Electric Machinery Lab, Hiroshima U. alias kaneda kin@eml.hiroshima-u.ac.jp # Daniele Marini; Eidomatics Lab, Computer Science Dept, Univ. of Milan; Italy # interests: radiosity, ray tracing, parallel processing (Meiko) alias marini marini@imiucca.unimi.it # Nelson Max, Lawrence Livermore Lab alias max max2@llnl.gov # Eihachiro Nakamae; Electric Machinery Lab, Hiroshima U. alias nakamae naka@eml.hiroshima-u.ac.jp # Tomoyuki Nishita; Electric Machinery Lab, Hiroshima U. alias nishita nis@eml.hiroshima-u.ac.jp # Panu Rekola; Computer Science Dept, Helsinki U of Tech.; Finland alias rekola pre@cs.hut.fi # Christophe Schlick; LaBRI; U of Bordeaux; 351 Cours de la Liberation # 33400 Talence; France # interests: ray tracing, radiosity, antialiasing, general reflectance functions alias schlick schlick@geocub.greco-prog.fr # Jim Winget, Silicon Graphics alias winget jmw@sgi.com # Ning Zhang; School of Electrical Engineering; U of Sydney; NSW 2006; Australia # interests: radiosity, ray tracing, physically-based illumination models alias zhang nzhang@ee.su.oz.au From fwj@dutidh.tudelft.nl Mon Feb 18 04:01:49 1991 Return-Path: Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA12841; Mon, 18 Feb 91 04:01:46 PST Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Mon, 18 Feb 91 04:01:58 PST Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA00945; Mon, 18 Feb 91 04:00:51 PST Received: from mcsun.EU.net by miro.Berkeley.EDU (4.1/1.41) id AA27031; Mon, 18 Feb 91 03:49:31 PST Received: from hp4nl.nluug.nl by mcsun.EU.net with SMTP; id AA21844 (5.65a/CWI-2.73); Mon, 18 Feb 91 12:49:45 +0100 Received: from [130.161.180.1] by hp4nl.nluug.nl with SMTP id AA23845 (5.58.1.14/2.14); Mon, 18 Feb 91 12:48:48 MET Received: by dutrun.tudelft.nl (5.57/1.10) id AA07466; Mon, 18 Feb 91 12:05:31 +0100 (MET) Message-Id: <9102181105.AA07466@dutrun> Received: by dutidh; Mon, 18 Feb 91 12:11:21 -0100 Date: Mon, 18 Feb 91 12:11:21 -0100 From: fwj@dutidh.tudelft.nl To: globillum@miro.berkeley.edu Status: RO Subject: nomenclature - Don Mitchell's remarks I completely agree with Don's first remark. We should decide on a terminology on the level of shading components: "direct diffuse|specular reflection" and "diffuse|specular inter[re]flection". It would also be convenient to have different terms for the preprocessed (stored) intensity at the patch: ? radiosity: total diffuse and specular reflection ? radiosity: total diffuse component ? radiosity: diffuse interreflection component I do not have any idea what to suggest for the "?"s. Talking about radiosity vs ray tracing makes sense if you talk about the shading components that can be modelled with traditional radiosity and traditional ray tracing algorithms, but it is indeed confusing with the terminology of the algorithms (matrix vs shooting). Erik From daemon Thu Feb 28 15:44:27 1991 Received: from hobbes.lbl.gov by lbl.gov (4.1/1.39) id AA17497; Thu, 28 Feb 91 06:45:29 PST Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA14228; Thu, 28 Feb 91 06:45:48 PST Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Thu, 28 Feb 91 06:45:59 PST Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA17492; Thu, 28 Feb 91 06:45:11 PST Received: from iuvax.cs.indiana.edu by miro.Berkeley.EDU (4.1/1.41) id AA12001; Thu, 28 Feb 91 06:26:09 PST Message-Id: <9102281426.AA12001@miro.Berkeley.EDU> Received: by iuvax.cs.indiana.edu Date: Thu, 28 Feb 91 09:32:52 -0500 From: shirley@iuvax.cs.indiana.edu To: globillum@miro.berkeley.edu Subject: More Barcelona info Status: RO Kadi Bouatouch tells me the Barcelona deadline has been extended to March 6th. Does anyone know if email postscript submissions will be accepted? thanks, pete From daemon Thu Feb 28 15:53:41 1991 Received: from hobbes.lbl.gov by lbl.gov (4.1/1.39) id AA17526; Thu, 28 Feb 91 06:54:47 PST Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA14235; Thu, 28 Feb 91 06:55:06 PST Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Thu, 28 Feb 91 06:55:23 PST Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA17522; Thu, 28 Feb 91 06:54:33 PST Received: from iuvax.cs.indiana.edu by miro.Berkeley.EDU (4.1/1.41) id AA11987; Thu, 28 Feb 91 06:06:27 PST Message-Id: <9102281406.AA11987@miro.Berkeley.EDU> Received: by iuvax.cs.indiana.edu Date: Thu, 28 Feb 91 09:13:09 -0500 From: shirley@iuvax.cs.indiana.edu To: globillum@miro.berkeley.edu Subject: More Barcelona Status: RO Just as I had decided it was too expensive, all the airfares have dropped like rocks. Roundtrip between Indy and Barcelona is now less than $400!! Just letting y'all know in case that makes it changes anybody's plans. Now, do I have time to submit something...? pete From daemon Sun Mar 3 16:51:27 1991 Received: from hobbes.lbl.gov by lbl.gov (4.1/1.39) id AA29271; Sun, 3 Mar 91 07:52:06 PST Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA20774; Sun, 3 Mar 91 07:52:20 PST Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Sun, 3 Mar 91 07:52:33 PST Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA29268; Sun, 3 Mar 91 07:51:50 PST Received: from iuvax.cs.indiana.edu by miro.Berkeley.EDU (4.1/1.41) id AA01155; Sun, 3 Mar 91 07:32:08 PST Message-Id: <9103031532.AA01155@miro.Berkeley.EDU> Received: by iuvax.cs.indiana.edu Date: Sun, 3 Mar 91 10:38:51 -0500 From: shirley@iuvax.cs.indiana.edu To: globillum@miro.berkeley.edu Subject: Barcelona (again!) Status: RO My final mailing on Barcelona (I promise!). TWA is selling REFUNDABLE roundtrip tickets for $390 (from Indiana), so I couldn't say no! And once again, the submission deadline is sometime next week (Wenesday or Friday?), and email postscript is acceptable. The "yankees" on this list who've told me they're probably attending are: Greg Ward Eric Haines Francois Sillion* Claude Puech* me I think (based on the Rennes workshop and recent email) that many of the best European researchers will also be there. pete *honorary North Americans (these guys say they're eating at MacDonald's now!) From daemon Wed Mar 13 21:39:50 1991 Received: from hobbes.lbl.gov by lbl.gov (4.1/1.39) id AA07051; Wed, 13 Mar 91 12:41:31 PST Received: from Csa1.LBL.Gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA12058; Wed, 13 Mar 91 12:41:31 PST Received: from lbl.gov by Csa1.LBL.Gov with INTERNET ; Wed, 13 Mar 91 12:41:50 PST Received: from miro.Berkeley.EDU by lbl.gov (4.1/1.39) id AA07048; Wed, 13 Mar 91 12:41:15 PST Received: by miro.Berkeley.EDU (4.1/1.41) id AA02667; Wed, 13 Mar 91 12:25:58 PST Date: Wed, 13 Mar 91 12:25:58 PST From: ph@miro.berkeley.edu (Paul Heckbert) Message-Id: <9103132025.AA02667@miro.Berkeley.EDU> To: globillum@miro.berkeley.edu Subject: Architectural CAD book wants examples Status: RO For your info: From: dnoble@kahn.ced.berkeley.edu (Douglas Noble) Newsgroups: comp.graphics Subject: Book on Visual Repres. in Architecture Date: 17 Aug 90 19:49:49 GMT Organization: College of Environmental Design, U.C. Berkeley Computer Aided Visual Representation in Architecture Karen Kensek Douglas Noble, AIA, Ph.D. Department of Architecture University of California, Berkeley We are currently working on developing a book on this subject which we hope to have published in the Spring of 1991. The book will graphically demonstrate the state of the art in computer generated visualization for architects. The orientation of the book is toward the general public, with some emphasis on the professions of architecture and visualization. We expect the nature of the illustrations to be impressive enough to capture the interest of a very broad section of the population. The main point of the book is to capture the brilliant images produced from the synthesis of two artistic endeavors, architecture and computer graphics. If you or your firm are interested in participating by including your own work please contact us at the address noted below. A longer version of this announcement is available on request. Douglas Noble Department of Architecture 232 Wurster Hall University of California Berkeley, CA 94704 (415) 642-4942 e-mail: dnoble@ced.berkeley.edu I spoke with Doug last week and he said: We are still working on the book. I am always interested in learning of others doing work in this area. Please let them know of our project, and I look forward to hearing from them!!!! Doug Noble From greg Mon Mar 18 09:05:10 1991 Date: Mon, 18 Mar 91 09:05:06 +0100 From: greg (Greg Ward) Message-Id: <9103180805.AA00948@lesosun1.epfl.ch> To: globillum@miro.berkeley.edu Subject: Greg Ward's new address Status: RO Hello everyone, I'm on sabbatical for 9 months (through November) in Switzerland. In case anyone wants to write to me or drop by, my address is: Greg Ward LESO - EPFL CH-1015 Lausanne SWITZERLAND ph. 41 (21) 693 4545 fax 41 (21) 693 2722 e-mail greg@lesosun1.epfl.ch This also means that I will probably not be attending Siggraph this year (sigh), but I will be closeby the European conferences, so if you know of any that are a well kept secret, please clue me in. -Greg From daemon Wed Apr 10 01:09:36 1991 Received: from iuvax.cs.indiana.edu by miro.Berkeley.EDU (4.1/1.41) id AA29880; Tue, 9 Apr 91 15:44:50 PDT Message-Id: <9104092244.AA29880@miro.Berkeley.EDU> Received: by iuvax.cs.indiana.edu Date: Tue, 9 Apr 91 17:44:53 -0500 From: peter shirley To: globillum@miro.Berkeley.EDU Subject: papers Status: RO Hi everyone. I am interested in what papers you guys might have going into print these days. If so, would you be willing to mail abstracts to this list? I will put in my ante: (to appear Graphics Interface '90) A Ray Tracing Framework for Global Illumination Systems by Shirley, Sung, and Brown The fundamental software components useful for a zonal ray tracing system are described. The interface protocols and some implementational observations are outlined for each of the key components. Components for sampling, ray-object intersection, and zonal (radiosity) calculations are emphasized. Some results from a global illumination program assembled from the components are discussed. thanks, pete From daemon Wed Apr 10 04:42:50 1991 Received: from SGI.COM by miro.Berkeley.EDU (4.1/1.41) id AA03858; Tue, 9 Apr 91 19:18:54 PDT Received: from giraffe.asd.sgi.com by SGI.COM via SMTP (5.65+bind 1.5+ida/910110.SGI) for globillum@miro.Berkeley.EDU id AA19418; Tue, 9 Apr 91 19:18:44 -0700 Received: from studmuffin.asd.sgi.com by giraffe.asd.sgi.com (5.52/900721.SGI) for sgi.sgi.com!iuvax.cs.indiana.edu!shirley id AA18685; Tue, 9 Apr 91 19:18:42 PDT Received: by studmuffin.asd.sgi.com (5.52/900721.SGI) for @giraffe.asd.sgi.com:globillum@miro.Berkeley.EDU id AA22870; Tue, 9 Apr 91 19:18:40 PDT Date: Tue, 9 Apr 91 19:18:40 PDT From: drb@studmuffin.asd.sgi.com (Dan Baum) Message-Id: <9104100218.AA22870@studmuffin.asd.sgi.com> To: peter shirley , globillum@miro.Berkeley.EDU Subject: Re: papers Status: RO Here's my abstract: "Making Radiosity Usable: Automatic Preprocessing and Meshing Techniques for the Generation of Accurate Radiosity Solutions" by Baum, Mann, Smith, Winget (to appear in SIGGRAPH '91) Few end-users, such as architects and designers use radiosity since generating accurate solution of real world environments is user-intensive and requires significant knowledge of the method. The output of most commerical modeling packages must be substantially "cleaned up" to satisfy the geometrical and topological criteria imposed by radiosity solution algorithms. Furthermore, the mesh used as the basis of the radiosity computation must meet several additional requirements for the solution to be accurate. A set of geometrical and topological requirements is formalized that when satisfied yields an accurate radiosity solution. A series of algorithms is introduced that automatically processes raw model databases to meet thse requirements. Thus, the end-user can concentrate on the design rather than on the details of the radiosity solution process. These algorithms are generally independent of the radiosity solution technique user, and thus apply to all mesh based radiosity methods. dan From daemon Wed Apr 10 17:38:42 1991 Received: from uu.psi.com by miro.Berkeley.EDU (4.1/1.41) id AA13723; Wed, 10 Apr 91 08:24:07 PDT Received: from eye.UUCP by uu.psi.com (5.61/3.1.090690-Performance Systems International) id AA05350; Wed, 10 Apr 91 11:22:21 -0400 Received: from juniper by eye with SMTP (15.11/15.6) id AA17436; Wed, 10 Apr 91 10:31:34 edt Received: by juniper (15.11/15.6) id AA00312; Wed, 10 Apr 91 10:31:32 edt Message-Id: <9104101431.AA00312@juniper> From: erich@uu.psi.com@eye.UUCP (Eric Haines) Date: Wed, 10 Apr 1991 10:31:31 EDT X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: globillum@miro.Berkeley.EDU Subject: abstracts Status: RO Following Pete's lead, here's the abstract for our Barcelona Workshop paper: Shaft Culling for Efficient Ray-Traced Radiosity Eric Haines, John Wallace 3D/Eye Inc, Ithaca, NY In radiosity algorithms, much time is spent computing visibility between two surfaces. One approach to approximating this visibility is to use ray casting methods. A new algorithm is presented which takes advantage of object coherency when using ray casting for radiosity. An efficient method is presented to form a volume between the emitter and receiver, and then generate a candidate list of items partially or wholly within the volume. Using this list, ray casting is performed to determine the amount of visibility between surfaces. Statistics are presented showing the decrease in overall computation time compared to a traditional ray casting technique. ---- My hundred word summary: When doing ray casting for radiosity there are a number of areas where different forms of coherence can be used, e.g. for a step of progressive radiosity, the light source is always one of the endpoints of all rays. Also in radiosity, rays endpoints can be derived directly before any ray testing is done (as opposed to ray tracing, where the ray must be shot in order to derive the origin of the reflection, refraction, and shadow rays). The scheme is a hybrid of bounding volume hierarchies and 5D ray tracing with some interesting optimizations for testing boxes against the shaft (a shaft being defined as the volume of space between two elements being tested for visibility). This paper will also be a part of the Frontiers in Rendering SIGGRAPH course notes, and the Barcelona Workshop will eventually appear as a Springer-Verlag book, so it won't be totally inaccessible to all. Eric From daemon Wed Apr 10 20:05:25 1991 Received: from apple.com by miro.Berkeley.EDU (4.1/1.41) id AA15931; Wed, 10 Apr 91 10:53:22 PDT Received: from [90.1.0.10] by apple.com with SMTP (5.61/25-eef) id AA14901; Wed, 10 Apr 91 10:53:29 -0700 for globillum@miro.Berkeley.EDU Received: by goofy.apple.com (5.61/25-eef) id AA09756; Wed, 10 Apr 91 10:53:09 -0700 for globillum@miro.Berkeley.EDU Date: Wed, 10 Apr 91 10:53:09 -0700 From: Eric Chen Message-Id: <9104101753.AA09756@internal.apple.com> To: globillum@miro.Berkeley.EDU Subject: papers Status: RO To appear in Siggraph 91: A Progressive Multi-Pass Method for Global Illumination Shenchang Eric Chen, Holly E. Rushmeier , Gavin Miller, Douglass Turner Advanced Technology Group Apple Computer Inc. 20705 Valley Green Dr. Cupertino, CA 95014 The George Woodruff School of Mechanical Engineering Georgia Institute of Technology Atlanta, GA 30332-0405 ABSTRACT A new progressive global illumination method is presented which produces approximate images quickly, and then continues to systematically produce more accurate images. The method combines the existing methods of progressive refinement radiosity, Monte Carlo path tracing and light ray tracing. The method does not place any limitation on surface properties such as ideal Lambertian or mirror-like. To increase efficiency and accuracy, the new concepts of light source reclassification, caustics reconstruction, Monte Carlo path tracing with a radiosity preprocess and an interruptible radiosity solution are introduced. The method presents the user with most useful information about the scene as early as possible by reorganizing the method into a radiosity pass, a high frequency refinement pass and a low frequency refinement pass. The implementation of the method is demonstrated, and sample images are presented. From daemon Wed Apr 10 20:13:05 1991 Received: from cs.utexas.edu by miro.Berkeley.EDU (4.1/1.41) id AA16083; Wed, 10 Apr 91 11:00:19 PDT Received: from muleshoe.cs.utexas.edu by cs.utexas.edu (5.64/1.98) with SMTP id AA08055; Wed, 10 Apr 91 12:59:38 -0500 Posted-Date: Wed, 10 Apr 91 12:59:31 CDT Message-Id: <9104101759.AA00765@muleshoe.cs.utexas.edu> Received: by muleshoe.cs.utexas.edu (5.59/1.4-Client) id AA00765; Wed, 10 Apr 91 12:59:32 CDT From: subramn@cs.utexas.edu (K. R. Subramanian) Date: Wed, 10 Apr 91 12:59:31 CDT X-Mailer: Mail User's Shell (6.5.6 6/30/89) To: globillum@miro.Berkeley.EDU Subject: abstracts.. Status: RO Here is the abstract of our submission to Graphics Interface '91. ---------------- Automatic Termination Criteria for Ray Tracing Hierarchies K.R.Subramanian and Donald S. Fussell Department of Computer Sciences The University of Texas at Austin A common problem in space subdivision hierarchies used in ray tracing is determining the proper termination criteria to stop subdivision. We propose a cost model based on scene characteristics that can be used to predict the correct termination point to optimize performance. The characteristics are determined as the hierarchy is being built. The model is applied to a variety of space subdivision schemes to test its accuracy. Experimental results indicate the power and usefulness of this model when applied to some standard ray tracing benchmarks. ------------------- -- K.R.Subramanian subramn@cs.utexas.edu The University of Texas at Austin. (512)-471-9708(Off) Computer Sciences, Taylor Hall 2.124 (512)-452-9603(Home) Austin, Tx 78712-1188. From daemon Wed Apr 10 22:09:02 1991 Received: from ramius.llnl.gov by miro.Berkeley.EDU (4.1/1.41) id AA17907; Wed, 10 Apr 91 12:56:31 PDT Received: by ramius.llnl.gov (4.1/LLNL-1.18) id AA17817; Wed, 10 Apr 91 12:54:13 PDT Date: Wed, 10 Apr 91 12:54:13 PDT From: nelson@ramius.llnl.gov (Nelson Max) Message-Id: <9104101954.AA17817@ramius.llnl.gov> To: globillum@miro.Berkeley.EDU Status: RO Here is the (revised) title, abstract and idea of a rejected Siggraph '91 paper Linear Radiosity Approximation using Vertex-to Vertex Form Factors by Nelson Max and Michael Allison Lawrence Livermore National Laboratory Abstract Using radiosity computed at vertices, the radiosity across a triangle can be approximated by linear interpolation. We develop vertex-to-vertex form factors based on this linear radiosity approximation, and show how they can be computed efficiently using modern hardware-accelerated shading and z-buffer technology. Basic idea: Use the red and green channels to represent two of the three barycentric coordinates of a triangle, and the blue and alpha channels to record the polygon id. Then the data in a z-buffered hemicube at a vertex can be used to efficiently get the vertex-to-vertex form factors, by summing a barycentric coordinate times the hemicube delta form factor into the appropriate vertex index, obtained from the polygon id. The paper also discusses the modifications necessary to handle a vertex which belongs to two separate surfaces, for example, along a corner between two walls of a room. The paper may never get published, because the referees thought it was not original enough, but I hope to generalize it to higher order polynomials, using finite element ideas. From daemon Wed Apr 10 23:05:42 1991 Received: from hydra.gatech.edu by miro.Berkeley.EDU (4.1/1.41) id AA18828; Wed, 10 Apr 91 13:53:21 PDT Received: by hydra.gatech.edu (5.61/3.1) id AA24860; Wed, 10 Apr 91 16:53:24 -0400 Date: Wed, 10 Apr 91 16:53:24 -0400 From: hr3@prism.gatech.edu (RUSHMEIER,HOLLY E) Message-Id: <9104102053.AA24860@prism.gatech.edu> To: globillum@miro.Berkeley.EDU, nelson@ramius.llnl.gov Subject: vertex to vertex factors Status: RO I have looked at formulating a vertex to vertex form factor also, assuming linear interpolation. I think a number of other people have too. Using the hardware z-buffer is really clever. I use all the channels for the surface id, as though someday I'm planning to do millions and millions of surfaces. What kind of improvements did you find using the new factors? I assume they were significant or it wouldn't be worth looking at higher orders. I derived a solution for factors from edge vertices (I think): Let dA1 be the origin of the coordinate system, and let the z-axis be aligned with the normal to surface dA1. Let A2 be defined by the coordinates (a,b,c),(0,d,0) and (0,-f,0). If d and f are both not equal to zero I obtained: FdA1-A2 = (1/2PI) {2a/sqrt(a**2+c**2) times asin(sqrt(a**2+c**2)/sqrt(a**2+b**2+c**2) + PI} The cases for d=0 or f=0 are a bit messier to write out. Overall it makes sense to me that the result doesn't depend on d and f(the length of the edge), but just on the orientation of A2 relative to A1. Has anybody else looked at this or the corner case? -- Holly Rushmeier From daemon Thu Apr 11 03:11:50 1991 Received: from extro.ucc.su.OZ.AU ([129.78.64.1]) by miro.Berkeley.EDU (4.1/1.41) id AA01722; Wed, 10 Apr 91 17:54:04 PDT Received: from brutus.ee.su.OZ.AU by extro.ucc.su.OZ.AU (5.61+/1.34) id AA22501; Thu, 11 Apr 1991 10:53:41 +1000 Received: by brutus.ee.su.oz.au (5.61/1.34) id AA23250; Thu, 11 Apr 1991 10:54:43 +1000 Date: Thu, 11 Apr 1991 10:54:43 +1000 From: nzhang@ee.su.oz.au (Ning Zhang) Message-Id: <9104110054.AA23250@brutus.ee.su.oz.au> To: globillum@miro.Berkeley.EDU Subject: Re: papers Status: RO Here is the abstract of a rejected siggraph'91 paper and the idea of a paper accepted by the Eurographics workshop. Synchronous Refinement: An Efficient Radiosity Solution for General Global Illumination Simulation Ning Zhang, School of Electrical Engineering, University of Sydney Previous hybrid algorithms for global illumination simulation are limited in a combination of ideal diffuse and mirror-like specular reflectance models. In this paper we present an efficient, general solution of global illumination for general reflectance distributions. We use an extended progressive refinement algorithm, which defines our solution framework, to propagate both diffusely and specularly reflected energy in a synchronous way so that bidirectional reflectance distribution functions can be directly used for accurately computing light energy transfer between surfaces. Our solution involves a distribution classification/merging method to keep time and space complexity under control. We employ the combination of geometry and illumination criteria for adaptive sampling. Finally flexible control of energy propagating in the synchronous refinement may make the solution applicable to an incremental radiosity solution. Basic idea: The algorithm is an attempt to put Immel's algorithm in progressive radiosity. Radiosity distribution is represented by hemi-sphere instead of hemi-cube (a reviewer suggested that it could be represented by spherical harmonics in frequency domain) and stored for shooting patches only. --- This paper is the extension of some sections in the last paper. Two Methods for Speeding up Form-factor Calculation Ning Zhang, School of Electrical Engineering, University of Sydney Method 1: Extended Hemi-cube Every point in triangles or quadrilaterals, which are commonly used in radiosity, can be addressed by (u,v) index values. By storing (u,v) vaules in the hemi-cube buffer, only one rotation,projection and scan- conversion for all elements of a polygon. Method 2: ``Cache-pool'' scheme for Ray-casting The rays fired for determining form-factor between an emitter and a receiver are bounded in a limit volume like a shaft. We use Kay/Kajiya's algorithm to build a global hierarchy (tree) structure for the scene and use the `shaft volume' to prune the tree for building a `cache-pool' which can be used for reducing the traveling in the tree. From greg Fri Apr 12 10:47:52 1991 Date: Fri, 12 Apr 91 10:47:49 +0200 From: greg (Greg Ward) Message-Id: <9104120847.AA11959@lesosun1.epfl.ch> To: globillum@miro.Berkeley.EDU Subject: yet another abstract Status: RO Hi Everyone, Just thought I'd throw in the abstract of the paper I will present at the European Rendering Workshop in Barcelona this May: Adaptive Shadow Testing for Ray Tracing Greg Ward, Lawrence Berkeley Laboratory ABSTRACT We present a simple technique for improving the efficiency of ray tracing in scenes with a large number of light sources. The sources are sorted according to their potential contribution, and only those sources whose shadows are above a specified threshold are tested. The remainder are added into the result in propor- tion to a statistical estimate of their visibility. The algorithm requires very little storage, and produces no objectionable artifacts. CONCEPT In scenes with many light sources, only a few will create strong shadows in any one part of the scene. These will generally be the sources with the highest concentration of light in that section due to source brightness, direction and proximity. The remainder of the light sources will contribute, but without causing any significant contrast gradients. Since it is contrast that stimulates the human visual system, lack of contrast translates to low importance for visual studies. This observation leads to a simple optimization: we can perform shadow testing on the sources with the highest potential contributions first, and quit testing when the remainder of the contributions is below some threshold. By itself, this approach will ensure an absolute error bound equal to the given threshold. However, it is still not optimal since we don't know what to do with the remainder of untested sources. Do we add them all in, leave them all out, or add in some and leave out others? How we answer this question in effect determines the efficiency of our algorithm. If we do a good job guessing at the visibility of light sources we don't test, our results will be very closer to those of the full calculation without the associated cost. I am glad to hear Eric H. say that the proceedings will be published. I have been relishing the copy Peter Shirley made for me of last year's proceedings. (Thanks again, Pete!) Adios! -Greg From greg Fri Apr 12 13:09:44 1991 Date: Fri, 12 Apr 91 13:09:41 +0200 From: greg (Greg Ward) Message-Id: <9104121109.AA12319@lesosun1.epfl.ch> To: fxs@squid.graphics.cornell.edu Subject: reflection model Status: RO Hi Francois, I'm now in Switzerland, banging away on another keyboard. I hope that your papers were accepted by Siggraph -- they are very good! I just got a closer look at the paper by Xiao on light reflection models, and I wanted to get ahold of him directly with some questions I had. Can you give me his e-mail address? I could also ask you the questions, but I imagine that you are busy enough as it is. Au revoir, Greg From daemon Fri Apr 12 18:31:29 1991 Received: from mcsun.EU.net by miro.Berkeley.EDU (4.1/1.41) id AA10826; Fri, 12 Apr 91 09:15:44 PDT Received: from hp4nl.nluug.nl by mcsun.EU.net with SMTP; id AA27148 (5.65a/CWI-2.81); Fri, 12 Apr 91 18:15:38 +0200 Received: from dutrun.tudelft.nl by hp4nl.nluug.nl with SMTP id AA17167 (5.58.1.14/2.14); Fri, 12 Apr 91 17:13:32 +0100 Received: by dutrun.tudelft.nl (5.57/1.10) id AA18148; Fri, 12 Apr 91 17:31:03 +0200 (MET) Message-Id: <9104121531.AA18148@dutrun> Received: by dutidh; Fri, 12 Apr 91 17:29:42 met Date: Fri, 12 Apr 91 17:29:42 met From: Erik Jansen To: globillum@miro.Berkeley.EDU Status: RO Subject: Info on Barcelona workshop The program of the Barcelona workshop is completed. It contains 25 presentations on the following four subjects: - rendering equation (sampling strategies) 6 papers - efficient radiosity methods (discretization, visibility preproc.) 8 papers - parallel ray tracing/radiosity (multi-proc. implem.) 6 papers - visualization (general) A total of 20 papers on global illumination! Plus the presentations of the two invited speakers (Sillion and Ward). I think the program gives a very interesting overview of current research on radiosity. There will be a preprint of the proceedings available at the workshop. The workshop itself, however, is only open for the participants and the authors of the not-accepted papers. So if you are not among them then you have to obtain a copy of the papers from one of your friends. The official proceedings will be published by Springer verlag, but that will take some time. Erik Jansen From daemon Fri Apr 12 19:04:54 1991 Received: from mcsun.EU.net by miro.Berkeley.EDU (4.1/1.41) id AA10965; Fri, 12 Apr 91 09:51:17 PDT Received: from hp4nl.nluug.nl by mcsun.EU.net with SMTP; id AA29739 (5.65a/CWI-2.81); Fri, 12 Apr 91 18:51:17 +0200 Received: from dutrun.tudelft.nl by hp4nl.nluug.nl with SMTP id AA20563 (5.58.1.14/2.14); Fri, 12 Apr 91 17:49:05 +0100 Received: by dutrun.tudelft.nl (5.57/1.10) id AA18317; Fri, 12 Apr 91 17:46:05 +0200 (MET) Message-Id: <9104121546.AA18317@dutrun> Received: by dutidh; Fri, 12 Apr 91 17:44:07 met Date: Fri, 12 Apr 91 17:44:07 met From: Erik Jansen To: globillum@miro.Berkeley.EDU Status: RO Subject: paper for Barcelona Workshop Our contribution to the workshop is the following paper (basically the one that failed to meet the SG deadline): Source selection for the direct lighting computation in global illumination Arjan J.F. Kok Frederik W. Jansen Delft University of Technology* The Netherlands Abstract Computation of the global illumination in a scene can be improved by separating the direct component of the lighting that is received by a patch directly from light sources, from the indirect component that is received by intermediate interreflection from other patches. The indirect component is calculated during the preprocessing and is stored as the radiosity shading at the patch. The direct component is calculated during the rendering phase by tracing shadow rays like in conventional ray tracing. The number of shadow rays can be reduced by exploiting shadow coherence, and by making a selection for the number of light sources that are taken into account for the direct lighting computation. Different criteria to select these sources are given. Key words: radiosity, global illumination, source sampling As you see quite similar to Ward's presentation. We maintain during the preprocessing for each patch a list of the n strongest (shadow contrast creating) light sources and sum the contribution of the rest to the preprocessed radiosity that is stored at the patch vertices. Different criteria can be applied to determine n and to decide how many shadow rays should be cast during the rendering phase. The techniques are very effective and give high-quality pictures (with both sharp and soft shadows). From daemon Fri Apr 12 22:26:00 1991 Received: from charon.cwi.nl by miro.Berkeley.EDU (4.1/1.41) id AA12017; Fri, 12 Apr 91 13:12:13 PDT Received: by charon.cwi.nl with SMTP; Fri, 12 Apr 91 22:12:20 +0200 Received: by paling.cwi.nl with SMTP; Fri, 12 Apr 91 22:12:19 +0200 Message-Id: <9104122012.AA04004@paling.cwi.nl> To: globillum@miro.Berkeley.EDU Subject: abstracts, abstracts, abstracts, .... Date: Fri, 12 Apr 91 22:12:17 +0200 From: robertl@cwi.nl Status: RO Here's mine (accepted to the EG Rendering Workshop in Barcalona). Divide and Conquer Radiosity. ---------------------------- Robert van Liere CWI, Amsterdam ABSTRACT (of an extended abstract) ---------------------------------- We present a parallel algorithm for solving the radiosity equations. The implementation of the algorithm is well suited for shared memory multi-processor systems. The basic idea of the algorithm is intuitively described as follows : 1. Divide a scene into a number of disjunct subscenes. A subscene boundary is modeled as an ideal translucent surface; i.e. the boundary can pass on light to the adjacent subscene without modifications. 2. Apply a fixed number of iterations of the progressive refinement solution process to each subscene. 3. Transfer the accumulated energy on the translucent boundary of each subscene to the adjacent subscene. 4. Render all subscenes. Boundaries are not rendered. 5. Goto step 2. Although we have limited ourselves to diffuse environments, the algorithm can easily be extended to specular environments. In the paper we use existing ``standard'' methods to do convergence and error analysis of the solution process. We provide empirical support for this analysis by using a complex scene as a test case for 1, 4, 8 and 16 subscenes. Finally, we touch upon forthcomming work : + determining heuristics for optimal subscene subdivision + dynamic subscene subdivision and last but not least : + MINIMIZING MEMORY CONSUMPTION OF BOUNDARIES !!!! ------------------------------------------------ -- Robert From daemon Mon Apr 15 22:39:04 1991 Received: from research.att.com by miro.Berkeley.EDU (4.1/1.41) id AA01937; Mon, 15 Apr 91 13:24:44 PDT Message-Id: <9104152024.AA01937@miro.Berkeley.EDU> Received: by inet; Mon Apr 15 16:24 EDT 1991 Date: Mon, 15 Apr 91 16:24:17 EDT From: don@allegra.att.com (Don Mitchell) To: globillum@miro.Berkeley.EDU Subject: SIGGRAPH paper Status: RO I sent an abstract of my SIGGRAPH 91 paper to you all some months ago. Right now I am agonizing over whether to change the title from Spectrally Optimal Sampling for Distributed Ray Tracing to Spectrally Optimal Sampling for Distribution Ray Tracing I don't think I will change it. My feeling is "Distributed Ray Tracing" is not the best name, but everyone in graphics knows exactly what it means. We all talked about this issue before. Cook's algorithm could be called Cook Ray Tracing Distribution Ray Tracing (probably the best proposal) Monte Carlo Ray Tracing Multidimensional Ray Tracing Stochastic Ray Tracing But if you do this, somewhere in your paper you will have to say: "...where by "Foobar Ray Tracing" I mean distributed ray tracing [Cook84,Cook86]." I figure as long as you have to say that, then it is just confusing to use a variety of non-standard names for it. From daemon Tue Apr 16 07:05:14 1991 Received: from QUCDN.QueensU.CA by miro.Berkeley.EDU (4.1/1.41) id AA04954; Mon, 15 Apr 91 21:54:10 PDT Received: from qucis.queensu.ca by QUCDN.QueensU.CA (IBM VM SMTP R1.2.2MX) with TCP; Tue, 16 Apr 91 00:54:53 EDT Received: from qusuna.qucis.queensu.ca by qucis.queensu.ca (4.1/SMI-4.1-qs1.1) id AA09087; Tue, 16 Apr 91 00:54:35 EDT From: lalonde@qucis.queensu.ca (Paul Lalonde) Received: by qusuna.qucis.queensu.ca (4.0/SMI-4.0-qc1.1) id AA13046; Tue, 16 Apr 91 00:54:31 EDT Date: Tue, 16 Apr 91 00:54:31 EDT Message-Id: <9104160454.AA13046@qusuna.qucis.queensu.ca> To: globillum@miro.Berkeley.EDU Subject: more abstracts... Status: RO Following in the recent burst of abstracts, here is a working draft of the abstract from my MSc thesis, due out in August (I hope). -Paul Presented is a progressive radiosity algorithm using progressive adaptive refinement of the scene into patches between which to compute form factors. Instead of subdividing prior to rendering, I propose a method of adaptively subdividing the scene bassed upon the change in radiance over a surface. The subdivision is accomplished by creating convex non-overlaping patches positioned at the model's surfaces over which the radiance is near constant, aproximating the surface. The patches are represented as disks with arcs cut from them, whose radii are related to rate of change of the illumination on the surface being approximated by the disk. Patches are generated adaptively by sampling the radiance of a surface using ray casting techniques. Patches found to overlap can be subdivided by inserting appropriate chords and appropriately redistributing their radiances. By using known illumination information the sample points and restructuring as more information becomes known the subdivisions come to fall along shadow edges and other discontinuities in the scene. An efficient method is presented for storage and lookup of these patches. An extension is also presented allowing specular interactions and caustic effects to be properly simulated. Paul A. Lalonde Internet: lalonde@qucis.queensu.ca Home Phone: (613)546-4713 Work Phone: (613)545-6754 "The only true law is that which leads to freedom" - Richard Bach, _Jonathan Livingston Seagull_ From daemon Tue Apr 16 17:08:16 1991 Received: from carla.dist.unige.it by miro.Berkeley.EDU (4.1/1.41) id AA06732; Tue, 16 Apr 91 07:51:43 PDT Received: from imiucca.unimi.it by carla.dist.unige.it with SMTP (5.61++/IDA-1.2.8) id AA29405; Tue, 16 Apr 91 16:57:00 +0200 From: marini@imiucca.unimi.it Received: by imiucca.unimi.it (15.11/15.6) id AA02214; Tue, 16 Apr 91 16:50:41 mdt (GMT+1) Date: Tue, 16 Apr 91 16:50:41 mdt Message-Id: <9104162250.AA02214@imiucca.unimi.it> To: globillum@miro.Berkeley.EDU Status: RO Hello I very interested in one papers, but I dont find it, anybody can send me ???? it is A FAST SCAN LINE ALGORITHM FOR RENDERING PARAMETRIC SURFACE Computer Graphics 13 (2) pag. 289-99 year 1979 Thank you very..... very much!!!! P.S. my email is marini@imiucca.unimi.it and my address surface is: Pela Barbara (D. Marini) Dipartimento di Scienze dell'Informazione Universita' degli Studi di Milano Laboratorio di Eidomatica via VIOTTI 5 20133 MILANO (ITALY) again thank you and sorry for my English!!! Barbara. From daemon Wed Apr 17 04:08:01 1991 Received: from cs.utexas.edu by miro.Berkeley.EDU (4.1/1.41) id AA11230; Tue, 16 Apr 91 18:55:10 PDT Received: from ebirah.cs.utexas.edu by cs.utexas.edu (5.64/1.99) with SMTP id AA11523; Tue, 16 Apr 91 20:54:49 -0500 Posted-Date: Tue, 16 Apr 91 20:53:45 CDT Message-Id: <9104170153.AA06547@ebirah.cs.utexas.edu> Received: by ebirah.cs.utexas.edu (5.59/1.4-Client) id AA06547; Tue, 16 Apr 91 20:53:50 CDT From: atc@cs.utexas.edu (Alvin T. Campbell III) Date: Tue, 16 Apr 91 20:53:45 CDT X-Mailer: Mail User's Shell (6.5.6 6/30/89) To: globillum@miro.Berkeley.EDU Subject: abstract Cc: atc@cs.utexas.edu Status: RO Below is the abstract of a paper Don Fussell and I submitted to SIGGRAPH '91. It was not accepted, but the reviews were generally positive, so we are rewriting it for submission elsewhere. Analytic Illumination with Polygonal Light Sources A. T. Campbell, III Donald S. Fussell Department of Computer Sciences The University of Texas at Austin Austin, TX 78712 Modeling the effects of finite-sized light sources has been an active area of research for many years. Most methods simplify the problem by approximating the area source with a collection of point sources. The only existing analytic methods work in screen space to compute a single image. This paper presents an object-space algorithm to model illumination from polygonal light sources. The result is a collection of smooth-shaded polygonal facets which may be rendered from any viewing position. Binary Space Partitioning trees are used to compute the umbra and penumbra boundaries efficiently. Fast analytic techniques are developed for illumination calculations. Numerical optimization techniques are used to sample the shading function in unshadowed regions finely enough to find all significant illumination gradations. Illumination calculations are optimized to concentrate computational effort on parts of the scene where they are most needed. From daemon Wed Apr 17 18:33:41 1991 Received: from uu.psi.com by miro.Berkeley.EDU (4.1/1.41) id AA15174; Wed, 17 Apr 91 09:21:11 PDT Received: from eye.UUCP by uu.psi.com (5.61/3.1.090690-Performance Systems International) id AA23032; Wed, 17 Apr 91 12:19:21 -0400 Received: from juniper by eye with SMTP (15.11/15.6) id AA09672; Wed, 17 Apr 91 11:56:44 edt Received: by juniper (15.11/15.6) id AA01561; Wed, 17 Apr 91 11:56:42 edt Date: Wed, 17 Apr 91 11:56:42 edt From: Eric Haines Message-Id: <9104171556.AA01561@juniper> To: globillum@miro.Berkeley.EDU Subject: Barcelona radiosity papers Status: RO Dear globillumers, Here's the list of what looked like global illumination related papers to be presented at: %J Second Eurographics Workshop on Rendering %C Barcelona, Spain %D May 1991 I just added them to my radiosity bibliography (feel free to ask me to send you a full version), and thought I'd pass them on to everyone who's not going to Barcelona just to give you a tantalizing sense of what's coming out. Eric Haines ---- %A A. Anderson %A M. Grant %T VISILUX: A Radiosity Based Lighting Design Tool %A Bruno Arnaldi %A Xavier Pueyo %A J. Vilaplana %T On the Division of Environments by Virtual Walls for Radiosity Computation %A A. Chalmers %A D. Paddon %T Parallel Processing of Progressive Refinement Radiosity Methods %A G. Drettakis %A Eugene Fiume %T Structure-Directed Sampling, Reconstruction and Data Representation for Global Illumination %A M. Feda %A Werner Purgathofer %T Progressive Refinement Radiosity on a Transputer Network %A N. Gatenby %A W. Hewitt %T Radiosity in Computer Graphics: A proposed Alternative to the Hemi-cube Algorithm %A P. Guitton %A J. Roman %A Christophe Schlick %T Two Parallel Approaches for a Progressive Radiosity %A Arjan J.F. Kok %A F. Jansen %T Source Selection for the Direct Lighting Computation in Global Illumination %A B. Lange %T The Simulation of Radiant Light Transfer with Stochastic Ray Tracing %A R. van Liere %T Divide and Conquer Radiosity %A Laszlo Newmann %A C. Kelemen %T Solution of Interreflection Problem for Very Complex Environments by Transillumination Method %A M. Paulin %A J. Jessel %A R. Caubet %T An Extended Radiosity Using Parallel Ray-Traced Specular Transfer %A Francois Sillion %T The State of the Art in Physically-based Rendering and its Impact on Future Applications %A F. Tampieri %A D. Lischinski %T The Constant Radiosity Assumption Syndrome %A P. Tellier %A Kadi Bouatouch %T Implementation of a Global Illumination Model with a General Reflectance %A Christophe Vedel %A Claude Puech %T A Testbed for Adaptive Subdivision in Progressive Radiosity %A Eric A. Haines %A John R. Wallace %T Shaft Culling for Efficient Ray-Traced Radiosity %A Ning Zhang %T Two Methods for Speeding up Form-factor Calculation From daemon Wed Apr 17 20:32:49 1991 Received: from apple.com by miro.Berkeley.EDU (4.1/1.41) id AA15841; Wed, 17 Apr 91 11:15:39 PDT Received: from [90.1.0.10] by apple.com with SMTP (5.61/25-eef) id AA01267; Wed, 17 Apr 91 11:15:43 -0700 for globillum@miro.berkeley.edu Received: by goofy.apple.com (5.61/25-eef) id AA14399; Wed, 17 Apr 91 11:15:38 -0700 for globillum@miro.berkeley.edu Date: Wed, 17 Apr 91 11:15:38 -0700 From: Eric Chen Message-Id: <9104171815.AA14399@internal.apple.com> To: globillum@miro.Berkeley.EDU Subject: object-oriented graphics paper Status: RO To appear in Second Eurographics Workshop on Object Oriented Graphics, Texel, The Netherlands, June 4-7, 1991: An Object-Oriented Testbed for Global Illumination Shenchang Eric Chen, Kenneth Turkowski, Douglass Turner Advanced Technology Group Apple Computer Inc. 20705 Valley Green Dr. MS-60W Cupertino, CA 95014, USA ABSTRACT Global illumination rendering involves the simulation of light interreflections between emitting and reflecting surfaces. Accounting for global illumination is necessary in the quest of generating images indistinguishable from real photographs. However, computing global illumination effects is a difficult problem and no published algorithm is capable of simulating all the effects in a reasonable amount of time so far. In order to facilitate the experimentation of new global illumination algorithms, we propose a research testbed designed for this purpose. The testbed is object-oriented and encapsulates the basic components of rendering into classes that can be derived and overridden easily. The testbed allows new geometry, shading methods and display architecture to be added orthogonally. We have implemented a number of new rendering algorithms with the testbed and results are demonstrated. From daemon Fri Apr 19 00:23:22 1991 Received: by miro.Berkeley.EDU (4.1/1.41) id AA27389; Thu, 18 Apr 91 15:05:09 PDT Date: Thu, 18 Apr 91 15:05:09 PDT From: ph@miro.Berkeley.EDU (Paul Heckbert) Message-Id: <9104182205.AA27389@miro.Berkeley.EDU> To: globillum@miro.Berkeley.EDU Subject: from Xavier Pueyo Status: RO >From SMTPUSER%EBRUPC51.BITNET@lilac.berkeley.edu Thu Apr 18 02:50:27 1991 Date: Thu, 18 Apr 91 11:48 GMT From: 723_XAVIER%XUS@DECNET.UPC.ES Subject: Rend. Worksh. Program. To: ph@miro.Berkeley.EDU Second Eurographics Workshop on Rendering PRELIMINARY PROGRAMME BARCELONA (Spain), 13-15 May 1991 May 13: C.Schlick An Adaptative Samplig Technique for Multidimen sional Ray Tracing B.Lange The Simulation of Radiant Light Transfer with D.Kirk, J.Arvo Unbiased Sampling Techniques for Image Synthesis P.Shirley Direct Lighting Calculation by Monte-Carlo Integration G.Drettakis, E.Fiume Structure-Directed Sampling, Reconstruction and Data Representationfor Global Illumination A.Kok, F.Jansen Source Selection for the Direct lighting computation in global illumination May 14 : F.Tampieri, D.Lischinski The Constant Radiosity Assumption Syndrome C.Vadel, C.Puech A Testbed for Adaptative Subdivision in Progessive Radiosity N.Gatenby, W.Hewitt Radiosity in Computer Graphics: A proposed Alternative to the Hemi-cube Algorithm P.Tellier, K.Bouatouch Implementation of a Global Illumination Model with a General Reflectance} A.Anderson, M.Grant VISULUX: A Radiiosity Based Lighting Design Tool L.Neumann, C.Kelemen Solution of Interreflection Problem for Very Complex Environments by Transillumination Method E.Haines, J.Wallace Shaft Culling for Efficient Ray-Traced Radiosity N.Zhang Two Methods for Speeding up Form-factor Calculation May 15: M.Feda, W.Purgathofer Progressive Refinement Radiosity on a Transputer Network A.Chalmers, D.Paddon Parallel Processing of Progressive Refinement Radiosity Methods P.Guitton, J.Roman, C.Schilck Two Parallel Approaches for a Progressive Radiosity M.Paulin, J.Jessel, R.Caubet An Extended Radiosity Using Parallel Ray-Traced Specular Transfer V.Isler, C.Aykanat, B.Ozguc Subdivision of 3D Space Based on the Graph Partitioning for Parallel Ray Tracing R.van Liere Divide and Conquer Radiosity B.Arnaldi, X.Pueyo, J.Vilaplana On the Division of Environments by Virtual Walls for Radiosity Computation G.Sakas, B.Kernke Texture Shaping: A Method for Modeling Arbitrarily-Shaped Volum Objects in Texture Space P.Brivio, P.Furini, M.Righetti, D.Marini Synthesis of Multispectral Images of Natural Landscape S.Clav\'e, M.Gross A Rendering Pipeline for Street Lighting Simulation I.Tastl, W.Purgathofer Color Space and Human Color Perception From daemon Tue Jun 11 20:26:21 1991 Received: from uu.psi.com by miro.Berkeley.EDU (4.1/1.41) id AA29065; Tue, 11 Jun 91 10:39:14 PDT Received: from eye.UUCP by uu.psi.com (5.61/3.1.090690-Performance Systems International) id AA04008; Tue, 11 Jun 91 13:37:02 -0400 Received: from juniper by eye with SMTP (15.11/15.6) id AA28071; Tue, 11 Jun 91 12:47:37 edt Received: by juniper (15.11/15.6) id AA12797; Tue, 11 Jun 91 12:47:32 edt Date: Tue, 11 Jun 91 12:47:32 edt From: Eric Haines Message-Id: <9106111647.AA12797@juniper> To: globillum@miro.Berkeley.EDU Subject: Ning Zhang Status: RO Does anyone know the whereabouts of Ning Zhang? He was supposed to be at the Barcelona Eurographics Workshop but didn't show. I used to write him at: # Ning Zhang - Radiosity, Raytracing, Image Compression # School of Electrical Engineering # The University of Sydney # NSW 2006, Australia # + 61 (02) 692 2962 alias ning_zhang nzhang@ee.su.oz.au but it bounced. I wrote the systems administrator, who forwarded the note to "H Yan", who once worked with him but didn't know where he had gone. Can anyone tell me where he's located (email address, in particular)? I'm interested in talking with him as his extended abstract for the Barcelona notes was very similar in approach to our "shaft culling" algorithm for radiosity ray-casting. A great example of parallel independent development, in fact. Anyway, I wanted to discuss this topic further. Any help appreciated, Eric Haines, erich@eye.com From daemon Tue Jun 11 23:28:32 1991 Received: from apple.com by miro.Berkeley.EDU (4.1/1.41) id AA02130; Tue, 11 Jun 91 14:11:51 PDT Received: from [90.1.0.10] by apple.com with SMTP (5.61/25-eef) id AA06681; Tue, 11 Jun 91 14:12:13 -0700 for globillum@miro.Berkeley.EDU Received: by goofy.apple.com (5.61/25-eef) id AA08787; Tue, 11 Jun 91 14:12:08 -0700 for globillum@miro.Berkeley.EDU Date: Tue, 11 Jun 91 14:12:08 -0700 From: Eric Chen Message-Id: <9106112112.AA08787@internal.apple.com> To: globillum@miro.Berkeley.EDU Subject: rendering workshop Cc: chense@apple.com Status: RO Does anyone care to summarize what was going on in the Barcelona rendering workshop? I saw a listing of the names of all the papers supposed to be presented but that's as much as I know. Will the papers be publshed and what were the hot topics? I just got back from the Eurographics workshop on object-oriented graphics (held in Texel, an island north of Holland). There wasn't a lot of papers related to rendering. As a matter of fact, mine is about the only one on rendering. However, there was a lot of dicussions on object-oriented design and how it can help in developing graphics systems. For people who are doing a lot of system development work, you probably want to check out the current state of object-oriented technologies. The papers presented in the workshop will be published by Springer-Verlag (may take a year). The next workshop is tentatively decided to be held in Geneva next winter (you skiers take note). There will be a panel and a tutorial in this year's Siggraph about object- oriented graphics. Eric From daemon Wed Jun 12 08:46:29 1991 Received: from dutrun.tudelft.nl by miro.Berkeley.EDU (4.1/1.41) id AA10293; Tue, 11 Jun 91 23:28:28 PDT Received: from dutidh.tudelft.nl by dutrun.tudelft.nl with SMTP id AA07491 (5.65a+/IDA-1.4.2 for globillum@miro.Berkeley.EDU); Wed, 12 Jun 91 08:27:35 +0200 Message-Id: <9106120627.AA07491@dutrun.tudelft.nl> Received: by dutidh; Wed, 12 Jun 91 08:24:23 met Date: Wed, 12 Jun 91 08:24:23 met From: Erik Jansen To: globillum@miro.Berkeley.EDU Status: RO Subject: summary Barcelona Workshop Yes, I was intended to write a short account on the workshop (for Computer Graphics Forum) and mail it to the Globillum members, but it will take another few days. Erik Jansen From daemon Wed Jun 12 15:03:48 1991 Received: from dutrun.tudelft.nl by miro.Berkeley.EDU (4.1/1.41) id AA14464; Wed, 12 Jun 91 05:49:28 PDT Received: from duticg.tudelft.nl by dutrun.tudelft.nl with SMTP id AA09977 (5.65a+/IDA-1.4.2 for globillum@miro.Berkeley.edu); Wed, 12 Jun 91 14:48:35 +0200 Message-Id: <9106121248.AA09977@dutrun.tudelft.nl> Received: by duticg; Wed, 12 Jun 91 14:49:12 met Date: Wed, 12 Jun 91 14:49:12 met From: Arjan Kok To: globillum@miro.Berkeley.EDU Subject: Barcelona Workshop Status: RO I made very brief summaries (only a few lines per paper) of the papers presented at the workshop in Barcelona. Arjan Kok Summaries of papers presented at the second Eurographics Workshop on Rendering Barcelona, Spain, 13-15 may 1991 Gregory Ward Adaptive shadow testing for ray tracing Method for reducing the number of shadow rays for scenes with a large number of light sources. The sources are sorted on their contribution, and only for the most important sources rays are cast. The influence of the other sources is estimated statistically. Tests are done with different tolerances (threshold to determine whether sources are important) and certainties (rate of accuracy). The method gives good reduction and is able to find the most important shadows because it selects contrast as criterion. Francois Sillion The state of the art in physically-based rendering and its impact on future applications Describes recent developments in radiosity such as incremental changes (for changing geometries), use of general reflection functions and hierarchical algorithms. The paper gives also an overview of some 'new' problems such as error metrics, discretization (meshing, adaptive refinement). Also the problem how to separate modeling and rendering is discussed. Christophe Schlick An adaptive sampling technique for multidimensional integration by ray- tracing Describes a sampling method that includes the following characteristics: adaptivity, irregularity, complete stratification, importance sampling and uncorrelation. It allows a fast reconstruction. Implementation is done using look-up tables. Brigitta Lange The simulation of radiant light transfer with stochastic ray-tracing Describes a stochastic ray tracing method based on "the rendering equation" and using path tracing. Importance sampling is performed by distributing the samples for the diffuse and specular reflection on basis of the reflection properties. David Kirk, James Arvo (no presentation) Unbiased variance reduction for global illumination Application of Monte Carlo method, using an importance sampling probability function (ISPDF) and stratification. Peter Shirley, Changyaw Wang Direct lighting calculation by Monte Carlo integration Application of Monte Carlo techniques for rendering scenes with multiple light sources. Only one shadow ray per viewing ray is used. Some issues for the design of probability densities for light sources are given. George Drettakis, Eugene Fiume Structure-directed sampling, reconstruction, and data representation for global illumination Discusses methods to use knowledge about the modeling and viewing parameters for rendering scenes. A structure-directed framework based on oracles (decision making processes) is presented. Arjan Kok, Frederik Jansen Source selection for the direct lighting component in global illumination Describes criteria for deciding which patches should be considered to be light sources in a two pass method in which direct lighting component is calculated separately in the second pass. Filippo Tampieri, Dani Lischinski The constant radiosity assumption syndrome In progressive refinement the radiosity of the shooting patch is assumed to be constant. This is not correct. It is better to take into account the variation of the radiosity of the source. A progressive refinement method is given that takes into account the non uniform radiosity distribution of the shooting patch. Christophe Vedel, Claude Puech A testbed for adaptive subdivision in progressive radiosity Describes problems related to adaptive mesh subdivision for progressive radiosity. Experiments with different subdivision criteria such as linear or quadratic gradients were reported. For the storage for the radiosities a binary tree structure is used. N. Gatenby, W.T. Hewitt Radiosity in computer graphics: a proposed alternative to the hemi-cube algorithm A hemisphere discretization method. The hemisphere is split in triangular regions with nearly equal areas. Pierre Tellier, Kadi Bouatouch Physics-based lighting models: implementation issues Describes a two-pass method. Scenes are discretized in points instead of patches. To calculate the formfactors more efficiently a visibility graph is used. A. Anderson, M. Grant Visilux: a radiosity based lighting design tool Describes the Visilux lighting simulation system designed for Philips. Laszlo Neuman, Csaba Kelemen (no presentation, extended abstract) Solution of interreflection problem for very complex environments by transillumination method Describes an efficient method for the interreflection problem. Eric Haines, John Wallace Shaft culling for efficient ray-traced radiosity A shaft is a volume between an emitter and receiver. A list of enclosing boxes, c.q. patches that are in that volume is generated. The ray casting to determine visibility between emitter and receiver can be reduced by only testing the rays against the patches in the shaft. Methods to make the shafts, and to determine which object are in the shaft are given. Ning Zhang (no presentation, extended abstract) Two methods for speeding up form-factor calculation Describes almost the same method as Haines, and a method to speed up the hemi-cube method. Martin Feda, Werner Purgathofer Progressive refinement radiosity on a transputer network Describes progressive refinement radiosity method implemented on transputers. The transputers are separated in two networks connected by a master transputer. The worker network performs the radiosity calculations, and the renderer network continuously generates images. Alan Chalmers, Derek Paddon Parallel processing of progressive refinement radiosity methods Describes parallel processing radiosity shoot methods on a transputer network. Comparisons are made between different processor topologies (ring, hypercube, torus, AMP). The AMP (a minimum path) configuration shows the best results. P. Guitton, J. Roman, C. Schlick Two parallel approaches for a progressive radiosity Describes ray tracing based progressive radiosity implemented on a transputer network. J.P. Jessel, M. Paulin, R. Caubet An extended radiosity using parallel ray-traced specular transfers Describes a parallel extended radiosity method. The method is implemented on a parallel architecture dedicated to ray-tracing (based on transputers). Veysi Isler, Cevdet Aykanat, Bulent Ozguc Subdivision of 3D space based on the graph partitioning for parallel ray tracing Describes a heuristic algorithm to subdivide the 3D space by converting the problem into a graph partitioning problem Robert van Liere Divide and conquer radiosity Describes an algorithm that separates the scene in different subscenes by placing virtual walls. Each of the subscenes is solved with a progressive refinement method (on separate processors if necessary). After all scenes are solved, energy is transfered from one subscene to another. Then the radiosities are again solved independently for the subscenes. Bruno Arnaldi, Xavier Pueyo, Josep Vilaplana On the division of environments by virtual walls for radiosity computation Divide the scene in local environments by putting virtual walls in the scene. The formfactors within a local environment are calculated (can be done in parallel). Then one global system of equations is made from all the local environment subsystems. This system is solved to get the radiosities. Georgios Sakas, Bertram Kernke Texture shaping: a method for modelling arbitrarily-shaped volume objects in texture space Describes a fast approach for generating density functions defining volume objects of arbitrary shape based on textures. Ingeborg Tastl, Werner Purgathofer Color spaces and human color perception Describes the construction of a colorimetric system that better conforms to the human color perception. P.A. Brivio, P. Furini, M. Righetti, D. Marini Synthesis of multispectral images of natural landscape Generation, visualisation and rendering of natural landscapes. Salvador Clave, Markus Gro' A rendering pipeline for street lighting simulation Describes the rendering pipeline used for the simulation of street lighting. Physical surface light sources with distribution curves are used. From daemon Wed Jun 12 20:09:21 1991 Message-Id: <9106121809.AA04520@lesosun1.epfl.ch> Received: by research; Wed Jun 12 14:09:02 EDT 1991 Date: Wed, 12 Jun 91 14:08:26 EDT From: don@allegra.att.com (Don Mitchell) To: greg@lesosun1.epfl.ch Subject: Barcelona Paper Status: RO Can I get a copy of your paper on Adaptive Shadow Testing? Can you email the postscript? From greg Thu Jun 13 10:20:47 1991 Date: Thu, 13 Jun 91 10:20:41 +0200 From: greg (Greg Ward) Message-Id: <9106130820.AA04943@lesosun1.epfl.ch> To: don@allegra.att.com Subject: Re: Barcelona Paper Status: RO Hi Don, I'm afraid that I don't have a nice PostScript version of the paper. The best I can do is a MicroSoft Word 4.0 document (passed through binhex on the Macintosh) and some encapsulated PostScript figures. I can also send you a hardcopy of the paper as it appeared in the preliminary proceedings, or you can wait for the final version that should be ready in a couple of weeks. -Greg From greg Tue Jun 25 09:52:52 1991 Date: Tue, 25 Jun 91 09:52:04 +0200 From: greg (Greg Ward) Message-Id: <9106250752.AA09223@lesosun2.epfl.ch> To: don@allegra.att.com Subject: Re: Barcelona Paper Status: RO Hi Don, I have the final version of the paper on light source sampling if you are still interested. Send me your address and I'll mail you a copy. There was also a very interesting paper by Christophe Schlick on sampling that you would no doubt be interested in. If you haven't asked him already, you can reach Christophe at schlick@geocub.greco-prog.fr. -Greg From daemon Wed Jun 26 18:35:27 1991 Message-Id: <9106261635.AA12509@lesosun1.epfl.ch> Received: by alice; Wed Jun 26 12:36:10 EDT 1991 Date: Wed, 26 Jun 91 12:34:55 EDT From: don@allegra.att.com (Don Mitchell) To: greg@lesosun1.epfl.ch Subject: Barcelona Paper Status: RO Sure, I'd like to see it. My address is: Don P. Mitchell AT&T Bell Laboratories Murray Hill, NJ 07974 Thanks. From daemon Thu Jun 27 21:28:36 1991 Received: from uu.psi.com by miro.Berkeley.EDU (4.1/1.41) id AA21129; Thu, 27 Jun 91 10:15:28 PDT Received: from eye.UUCP by uu.psi.com (5.61/3.1.090690-Performance Systems International) id AA05227; Thu, 27 Jun 91 13:13:16 -0400 Received: from juniper by eye with SMTP (15.11/15.6) id AA01799; Thu, 27 Jun 91 13:14:43 edt Received: by juniper (15.11/15.6) id AA28673; Thu, 27 Jun 91 13:14:40 edt Date: Thu, 27 Jun 91 13:14:40 edt From: Eric Haines Message-Id: <9106271714.AA28673@juniper> To: globillum@miro.Berkeley.EDU Subject: little bug in Christophe's paper Status: RO I received this note a little while ago from Christophe Schlick about his Barcelona workshop paper. His paper, on adaptive sampling for Cook's distributed (stochastic, or whatever you call it) ray tracing, looks worth trying out, and so I thought I'd pass on the bug in the course notes version of the paper: ---- About my paper, if you want to try the technique, you should notice that there is an mistype error on page 7 (discovered by Greg Ward). On page 7, in the recursion relation for sigma, the arguments on the left-hand side are (i) and (i+2^n) instead of (2i) and (2i+2^n). ---- Eric Haines From daemon Thu Jun 27 23:11:37 1991 Received: from apple.com by miro.Berkeley.EDU (4.1/1.41) id AA21988; Thu, 27 Jun 91 13:40:22 PDT Received: by apple.com (5.61/25-eef) id AA28353; Thu, 27 Jun 91 13:40:26 -0700 for globillum@miro.Berkeley.EDU Date: Thu, 27 Jun 91 13:40:26 -0700 From: Douglass Turner Message-Id: <9106272040.AA28353@apple.com> To: erich@uu.psi.com@eye.UUCP, globillum@miro.Berkeley.EDU Subject: Re: little bug in Christophe's paper Status: RO How do those of us that didn't attend Barcelona get copies of the papers? From daemon Fri Jul 12 12:08:16 1991 Received: from dutrun.tudelft.nl by miro.Berkeley.EDU (4.1/1.41) id AA14480; Fri, 12 Jul 91 02:50:12 PDT Received: from dutidh.tudelft.nl by dutrun.tudelft.nl with SMTP id AA11601 (5.65a+/IDA-1.4.2 for globillum@miro.Berkeley.EDU); Fri, 12 Jul 91 11:49:22 +0200 Message-Id: <9107120949.AA11601@dutrun.tudelft.nl> Received: by dutidh; Fri, 12 Jul 91 11:46:52 met Date: Fri, 12 Jul 91 11:46:52 met From: Erik Jansen To: globillum@miro.Berkeley.EDU Subject: Scientific report on EG Workshop on Rendering Status: RO Here is the scientific report of the EG Workshop on Rendering that was held at Barcelona, May 13-15. The report will be published in the 10-4 issue of Computer Graphics Forum. If there are any questions or comments, please feel free to contact me. Erik Jansen REPORT ON THE SECOND EUROGRAPHICS WORKSHOP ON RENDERING Introduction Following a successful workshop on Photosimulation and Realism in Computer Graphics held in 1990 in Rennes, France, a second workshop was held this year from 13-15 May at the Polytechnical University of Catalunya in Barcelona, Spain. The main topics covered by the two invited speakers and the 23 paper presentations, organized in four main sessions, were ray tracing, radiosity, multi-processor implementations of ray tracing and radiosity, and rendering applications. Rendering equation Photo-realistic rendering strives to calculate the global illumination in a scene by sampling the diffuse and specular reflected light between the surfaces (patches) in the scene as accurately as possible. Conventional ray tracing techniques sample only the light reflected by a patch that is received directly (with or without indirect specular reflection) from light sources. Extended ray tracing tries to solve the complete 'rendering equation' by sampling also the light that is diffusely reflected by a patch and that was received from all other patches in the scene. Alternatively, or in combination with these sampling techniques, a radiosity preprocessing can be applied to estimate the radiosity of (the vertices of) each patch. The sampling efficiency can be increased by stochastic (importance) sampling and deterministic (structural, directional) sampling methods that direct the sampling effort to those areas where important contributions may be expected (i.e. the light sources). This can either be done by applying knowledge about the environment (position of light sources, etc.) or by adapting the sampling directions during the sampling process. An open issue is whether stochastic techniques are really required, or that deterministic sampling techniques are sufficient. In his invited presentation Ward presented a method that samples the light of the most important light sources and estimates the received energy of the other light sources by applying the same probability factor found for the important light sources to these light sources too. Schlick presented an adaptive stochastic ray tracing method based on a N- rooks sampling technique that distributes samples pseudo-randomly in image space while still allowing easy reconstruction. Lange presented techniques and weighting factors to implement Kajiya's path tracing algorithm for diffuse and specular reflection. A paper by Kirk and Arvo discussed the use of conic shafts oriented towards the light sources to localize those directions where the sampling density should be increased. Shirley and Wang proposed a probability function for shooting one ray at a time to sample light from multiple light sources simultaneously. Drettakis and Fiume discussed the use of structural knowledge about the scene and the rendering process to reduce the number of samples to represent a given illumination. Kok and Jansen described a two-pass algorithm that uses the information from a radiosity preprocessing to identify the most important light sources, to which in a second pass shadow rays are cast to improve the shadow accuracy of the patch radiosities. Efficient radiosity methods Pure radiosity methods calculate the diffusely reflected light by a patch by a radiosity preprocessing with a projective (hemi-cube or hemi-sphere) method or with ray tracing. Improvements are sought in a better discretization of the hemi-sphere and in new adaptive patch subdivision techniques to represent more accurately shading gradients. Also visibility preprocessing and spatial subdivision techniques are of interest. In his invited presentation, Sillion reviewed a number of recent developments, i.e. incremental radiosity changes caused by moving objects, general reflectance distributions for bidirectional diffuse and specular reflection, and hierarchical algorithms to handle complex scenes. Reliable error estimates (a good error metric) and adaptive and automatic patch meshing techniques for complex scenes, remain open issues. Tampieri and Lischinski proposed to take into account the distribution of light over a shooting patch while shooting to other nearby patches. Vedel and Puech proposed the use of radiosity gradients to check the soundness of linear interpolation and to choose elements for subdivision. Gatenby and Hewitt described a triangular hemi-sphere discretization. Tellier and Bouatouch reported on a visibility preprocessing that uses a visibility graph. Haines and Wallace described a shaft culling algorithm that reduces the number of ray object intersections for a bundle of rays shot from one patch to another by calculating a shaft volume between the two patches and culling those objects that do not intersect the shaft volume. Parallel radiosity Multi-processing is an interesting option for radiosity and ray tracing. Rendering times can be reduced and large model data bases can be distributed over the processors. Model distribution can be based on spatial subdivision techniques. Load distribution can be done by distributing the rays over the processors and passing model data between the processors, or by communicating rays between processors. With a progressive radiosity algorithm, additional information has to be broadcast to determine the patch with the highest unshot energy. Quadratic performances can be avoided by hierarchically subdividing the scene into cells that are separated by virtual walls. A global solution is then derived after several iterations from the local solutions. Feda and Purgathofer described a multi-processor architecture with one master processor and two subsystems for radiosity preprocessing and rendering; the rendering improves continuously as the radiosity solution progresses. Chalmers and Paddon compared different network topologies, such as ring, hypercube, torus and a minimum path configuration, which seemed to perform the best. Guitton, Roman and Schlick compared a stochastic and a deterministic (each ray directed to a specific patch) shooting method. Jessel, Paulin and Caubet exploited a voxel space partitioning to distribute the model data over the processors. Isler, Aykanat and Ozguc converted the load distribution problem into a graph partitioning problem that is solved by a heuristic algorithm. Experiments with virtual walls implementations were presented by van Liere, and by Arnaldi, Pueyo and Vilaplana. Visualization The final session covered two papers on colour and texture, and three papers on general rendering applications. Sakas and Kernke modeled texture-shaped objects by combining object shape and three-dimensional texture in the frequency domain, and converting the result back into the space domain. Tastl and Purgathofer reported on experiments to obtain a, for human perception, uniformly distributed colour space. Anderson and Grant presented a radiosity application for lighting design in buildings. Brivio, Furini, Righetti and Marini showed an application of rendering techniques to visualization of natural terrain models obtained from satellite data. Clave and Gross presented results of city street lighting simulation. Discussion During the discussion two groups could be discerned, one group interested in 'really' realistic images and an other interested in interactive use of rendering. In the '256 rays per pixel is not enough' camp one tries to address topics such as how to model and render human beings in bright day light, how to render natural scenes, how to model light sources, etc. In the 'animation' camp one focusses on efficiency improving techniques and multi-processor implementations. Both camps, however, face the problem of how to measure the accuracy of their simulation and how to model real complex scenes. Ward offered to make his models ftp-able and invited others to contribute to the model base too. Conclusion The workshop brought together 47 participants from 11 countries including Canada and the US, who enjoyed an interesting program. The workshop was well organized by Xavier Pueyo and his staff. By the good quality of the invited and contributed papers, the EG workshop on rendering has established itself as a meeting point for those working on and interested in photo-realistic rendering. The third EG workshop on rendering will be announced during the Eurographics'91 conference in Vienna. Program of the Second EG Workshop on Rendering Invited speakers G. Ward, Adaptive Shadow Testing for Ray Tracing F. Sillion, The State of the Art in Physically-based Rendering and its Impact on Future Applications Rendering equation C. Schlick, An adaptive sampling technique for Multidimensional Integration by Ray Tracing B. Lange, The Simulation of Radiant Light Transfer with Stochastic Ray Tracing D. Kirk, J. Arvo, Unbiased Variance Reduction for Global Illumination P. Shirley, C. Wang, Direct Lighting Calculation by Monte-Carlo Integration G. Drettakis, E. Fiume, Structure-Directed Sampling, Reconstruction and Data Representation for Global Illumination A. Kok, F. Jansen, Source Selection for the Direct Lighting Computation in Global illumination Efficient radiosity methods F. Tampieri, D. Lischinski, The Constant Radiosity Assumption Syndrome C. Vedel, C. Puech, Some Experiments on Adaptive Subdivision for Progressive Radiosity N. Gatenby, W. Hewitt, Radiosity in Computer Graphics: A Proposed Alternative to the Hemi-cube Algorithm P. Tellier, K. Bouatouch, Physics-based Lighting Models: Implementation Issues E. Haines, J. Wallace, Shaft Culling for Efficient Ray-Traced Radiosity Parallel radiosity M. Feda, W. Purgathofer, Progressive Refinement Radiosity on a Transputer Network A. Chalmers, D. Paddon, Parallel Processing of Progressive Refinement Radiosity Methods P. Guitton, J. Roman, C. Schlick, Two Parallel Approaches for a Progressive Radiosity M. Paulin, J. Jessel, R. Caubet, An Extended Radiosity Using Parallel Ray-Traced Specular Transfers V. Isler, C. Aykanat, B. Ozguc, Subdivision of 3D Space Based on the Graph Partitioning for Parallel Ray Tracing R. van Liere, Divide and Conquer Radiosity B. Arnaldi, X. Pueyo, J. Vilaplana, On the Division of Environments by Virtual Walls for Radiosity Computation Visualization G. Sakas, B. Kernke, Texture Shaping: A Method for Modeling Arbitrarily- Shaped Volume Objects in Texture Space I. Tastl, W. Purgathofer, Color Space and Human Color Perception A. Anderson, M. Grant, Visulux: A Radiosity Based Lighting Design Tool P. Brivio, P. Furini, M. Righetti, D.Marini, Synthesis of Multispectral Images of Natural Landscape S. Clave, M. Gross, A Rendering Pipeline for Street Lighting Simulation From daemon Thu Jul 18 18:46:50 1991 Received: from uu.psi.com by miro.Berkeley.EDU (4.1/1.41) id AA04175; Thu, 18 Jul 91 09:28:35 PDT Received: from eye.UUCP by uu.psi.com (5.65b/4.0.071791-Performance Systems International) id AA10956; Thu, 18 Jul 91 12:26:51 -0400 Received: from juniper by eye with SMTP (15.11/15.6) id AA25327; Thu, 18 Jul 91 10:29:18 edt Received: by juniper (16.6/15.6) id AA12322; Thu, 18 Jul 91 10:29:17 -0400 Date: Thu, 18 Jul 91 10:29:17 -0400 From: Eric Haines Message-Id: <9107181429.AA12322@juniper> To: globillum@miro.Berkeley.EDU Subject: Connection Machine radiosity software available Status: RO For those of you that have a Connection Machine and don't read comp.graphics (I suspect the intersection of these sets is NULL), here's a notice of some interest: >From: sg10+@andrew.cmu.edu (Stephen Jonathan Gifford) Newsgroups: comp.graphics Subject: Radiosity renderer for the Connection Machine Date: 16 Jul 91 17:04:52 GMT Organization: Junior, Electrical and Computer Engineering, Carnegie Mellon, Pittsburgh, PA Lines: 29 Radiosity For the Connection Machine (CM-2) ------------------------------------------- CMRAD Version 2.0 is now available via anonymous FTP from calpe.psc.edu (128.182.62.148) or by request from gifford@cmf.nrl.navy.mil (134.207.7.4). CMRAD is a data parallel two pass renderer for the CM-2. The first pass is a progressive radiosity renderer with ray traced form factors and adaptively subdivided elements. The second pass consists of a relatively straightforward ray tracer that uses the radiosity solution for shading. Polygonal output from the radiosity pass can be rendered using a standard graphics workstation. Output from the second pass can be displayed on a CM framebuffer or other color device. CMRAD has a wide range of options to let you play with just about all the parameters of the radiosity pass. It has an equally wide range of defaults so it isn't terribly difficult to get started. CMRAD does not support any standard scene input language, although it does come with a hierarchical input format of its own to make scene generation easier. This package comes with enough documentation to get the renderer up and running. Neither the Pittsburgh Supercomputing Center nor the Connection Machine Facility of the Naval Research Laboratory officially support this software. All questions, comments, and bug reports should be directed to gifford@cmf.nrl.navy.mil (or) gifford@a.psc.edu. From daemon Thu Jul 25 10:38:31 1991 Date: Thu, 25 Jul 91 01:23:49 PDT From: ph@miro.Berkeley.EDU (Paul Heckbert) To: globillum@miro.Berkeley.EDU Status: RO Dear Global Illuminators, This is actually coming from the terminal of Greg Ward, abusing the overseas network with vi. As Paul mentioned in a previous message, I have taken over the duties of maintaining the globillum mailing list while he is busy tearing up the European autobahns. Following are a few new people I have just added to the list. -Greg # Andrew Anderson, ABACUS, University of Strathclyde, Glasgow, Scotland alias anderson andy@abacu.strath.ac.uk Our research involves work on a radiosity lighting model amongst other visualistion tools, so this list would be of immense benefit to us. I would be very grateful if you could send us some more information about the mailing list and include us on it. # George Drettakis, University of Toronto, Toronto, Canada alias drettakis dret@dgp.toronto.edu I am investigating a new approach to solving the global illumination problem, that I am calling "A Structure-Directed Approach to Sampling Reconstruction and Data Representation for Global Illumination". A first proposal can be found in the EuroGraphics workshop this year in Barcelona. I am looking into using sampling and filtering techniques as well as properties of both the scene and the rendering process, to achieve equivalent or better quality at a significantly lower cost, while hopefully developing some metrics of quality and error for light-transfer techniques. # Neil Gatenby, Manchester Computing Centre, Manchester, England alias gatenby gatenby@vax3.graphics.manchester-computing-centre.ac.uk Thanks for the reply, here's the info on my/our research interests: * Radiosity # Alternatives to the hemi-cube algorithm # accurate NUMERICAL form factor calculation # Parallelisation of the algorithm # use in scientific fields, rather than visual realism # use of sophisticated primitives, rather than patches As you can see, radiosity is a bit of recurring theme there! Neil # Josep Vilaplana, Universitat Politecnica de Catalunya, Barcelona, Spain alias vilaplana vilaplana@lsi.upc.es I'm working with Xavier Pueyo in the research of techniques allowing to accelerate the Radiosity and Ray Tracing algorithms. Parallel techniques and Harware is included in my research. From daemon Fri Aug 16 15:27:24 1991 Date: Fri, 16 Aug 91 09:01:18 -0400 From: hr3@prism.gatech.edu (RUSHMEIER,HOLLY E) To: globillum@miro.Berkeley.EDU Subject: sig '91 abstracts Status: RO Hi -- I have the abstracts for the illumination related siggraph papers from this year in electronic form. Since its kind of a long file I won't send it out to everyone (since a lot of people do have the proceedings). If you want the abstracts, let me know and I will send them to you by return e-mail. -- Holly From daemon Mon Aug 26 15:21:21 1991 Date: Mon, 26 Aug 91 09:06:53 -0400 From: Eric Haines To: globillum@miro.Berkeley.EDU Subject: a new radiosity program Status: RO Saw this on comp.graphics and thought it of interest to you. Eric >From: jk87377@cc.tut.fi (Juhana Kouhia) Subject: Public Radiositizers; a note [On radiosity programs] ... one which is released a months ago by Mr. Pattanaik and a new version of it is coming later in a couple months, I bet. Radiositizer by Pattanaik is available from iear.arts.rpi.edu, pub/graphics/ray/Rad.1.0.thin.tar.Z and from nic.funet.fi, pub/graphics/programs/pattarad.1.0.tar.Z. Hopefully you'll like it. From daemon Tue Aug 27 19:54:42 1991 From: erich@eye.com (Eric Haines) Date: Tue, 27 Aug 1991 13:40:11 EDT X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: globillum@miro.Berkeley.EDU Subject: an interesting letter Cc: erich@juniper.eye.com Status: RO I received a letter from Andy Newton which I thought of interest to the group. He has a somewhat different slant on things due to his application area. So, with his permission and without further ado, here 'tis. Eric Haines -------------- I was at SIGGRAPH '89 and attended the ray tracing tutorial which was great. About the only credit point I can claim in CG is to have pointed out to Andrew Glassner that the "1 over R squared" rule of energy attenuation only applies to point energy sources. 'Fudge factors' for attenuation are exactly what we need to avoid. I must admit that this jaundiced me a bit about ray tracing in computer graphics but hopefully I've seen the error of my ways. Back to the story .. I work in a satellite image interpretation research group. Our interest in ray tracing is for simulating all parts of the process of the formation of satellite images - optics, camera motion, atmosphere, surface scattering and global (as in hemispherical!) light source illumination. We do work at two scales - where the basic scene is a DEM (height grid) and for very complicated 3-d scenes for plant canopy reflectance simulation. So ray tracing is a really powerful tool to allow us to simulate as many parts of these complex processes as we can model but what we need to do is not quite computer graphics. What I mean by this is that what we need out of our models are accurate, truthful, energies (in real units) not measures of visual brightness. We need physical results. One example of this is wavelength sampling by importance sampling a spectral response curve as opposed to treating light as an RGB 'colour'. (Though I can't recall any references to doing exactly this it is proposed in Cook's original stochastic sampling papers and my implementation is very similar to his for reflected ray direction). Our main problems are (i) illumination from such a big light source (the sky hemisphere) with 'diffuse' reflectors (ii) ensuring that we model energies correctly and (iii) using physical directional reflectances. I may be going out on a bit of a limb here so please excuse me if I do - I'm not as familiar as I ought to be with general CG practise - but I'll try to explain what I mean. I've spent the better part of 3 years supporting and trying to add to a tracer I inherited when I came to work here. Now that has turned out not to be particularly smart as its been a lot harder to modify and bug fix than if it was my own work. Anyway the point is that through out most of that time we had no good model for the directional and spectral variation of that thing outside the window - the sky. As our main interest is _supposed_ to be the satellite work, not the graphics, I felt we couldn't come to grand conclusions from our results if the illumination function was simply not representative of the real world. Now I've managed to solve this problem by implementing a model of atmospheric scattering processes due to Zibordi and Voss so its time to make the physics correct and BTW write a fresh tracer. I have seen some work on CG models of the sky which are functional and not physical. This model is quite fast enough to create a sky radiance LUT at any resolution required on a per scene basis so if you know of anyone out there who needs a model of the sky's irradiance maybe I could help. The thing about any such illumination model is, of course, that the energy results are per steradian of solid angle of illuminating source. With the point sampling infinitesimally thin ray what solid angle does a ray reaching the sky have? If its a primary ray then ok it can have some solid angle associated with the pixel but how should ray solid angles be transformed by reflection etc? The only work I've seen that is remotely like this is Amantide's cones. However that doesn't use the geometric concept of a solid angle. One plus point of considering solid angle is of course that the effects of distance attenuation by divergence are implicitly included. So I'm very interested in how much solid angle is used as yet another ray parameter in more general CG work. Is this really common, or unheard of? There's a reflectance concept in remote sensing called Bi-Directional Reflectance Distribution Function (BRDF), which may also be use in CG or have a parallel, that defines directional reflectance as a 5-d array of pairwise directional spectral reflectance coefficients. For each wavelength (quantised, of course), for each incident direction (over the 2 Pi hemisphere), for each emergent direction, define a reflectance coefficient. Such things can be used as reflectance LUTs or integrated, subdivided and importance sampled. Are similar things done for interesting material reflectances in the main stream? ---------------------- His reply to my reply (which I don't include here): The global illumination mailing list you mention sounds very interesting - please do go ahead and post my note to that list and I'll contact Paul Heckbert about joining. The SIGGRAPH paper you mentioned also sounds good - some colleagues here are representing BRDFs as spherical harmonics, which is obviously storage efficient but storage as a set of precomputed importance sampling intervals should be more computationally straightforward. I'll definitely check out the paper when my proceedings arrive. ------------------- # Andy Newton - physical radiance modelling, natural scenes, rays with solid angle # Remote Sensing Research, University College London # Photogrammetry, # UCL, Gower Street # London, ENGLAND # +44 71 387 7050 x2742 alias andy_newton anewton@ps.ucl.ac.uk alias andy_newton anewton%uk.ac.ucl.ps@uk.ac.ucl.cs bio sketch for the RTN: Although the graphics is more fun than the Remote Sensing this is what I'm supposed to be doing ... Applying ray tracing to the understanding of remote sensed images of the natural world, mainly satellite imagery. Much more interested in physical accuracy than efficiency. Also how to correctly model, and sample, very large and non-uniform light sources (the sky!) in ray tracing. How to relate the point sampling paradigm of the infinitessimal ray to light energy transport. Physical reflectance models like BRDF. Doing distance attenuation and variable light source sampling properly (probably) using solid angle. I'd be really interested in any references anyone has to ray tracing for physical process simulations or radiance calculations using solid angle as a ray property. On offer: a realistic sky radiance model based on atmospheric scattering. From daemon Wed Aug 28 00:06:43 1991 Date: Tue, 27 Aug 91 16:50:53 -0400 From: hr3@prism.gatech.edu (RUSHMEIER,HOLLY E) To: anewton@ps.ucl.ac.uk, globillum@miro.Berkeley.EDU Subject: graphics, remote sensing Status: RO Thanks Eric for forwarding Andy Newton's note.Here are a few thoughts I had about it: There is working going on combining graphics & remote sensing. Chris Borel at Los Alamos (I think he's in globillum, he is at ccb@eos1.lanl.gov) has calculated BRDF's for plant canopies using the radiosity method on individual leaves (thousands of them). His first paper on this appeared in Journal of Remote Sensing, and I think others will follow. Attaching a solid angle to rays is one way to think about the solution of the equation of transfer for accurately calculating radiances. Another way to think of it is that ray casting is just a way of evaluating the integrand at in a stochastic direction (of the radiance on a surface, or of the source radiance in a volume) or at a stochastically chosen point on a path (for the path integral of source radiance from the nearest opague surface). Jim Kajiya introduced these ideas in his '86 Siggraph paper, but didn't elaborate on the details of area sources or ambient participating media. It took me a while to figure out the details for my thesis, I imagine a number of other people have been through the same thing. The only physically accurate ray tracer available in public domain (or any place else) that I know about is is Greg Ward's Radiance. We're using it for a computer vision project where accuracy is important. I'm using it instead of my homemade stuff because it is well documented and reliable. It doesn't include participating media, but if you wanted to build your own system to do that I think that Radiance would be a good place to start. -- Holly From greg Wed Aug 28 10:16:37 1991 Date: Wed, 28 Aug 91 10:16:33 +0200 From: greg (Greg Ward) To: anewton@ps.ucl.ac.uk Subject: hello from Switzerland Cc: globillum@miro.berkeley.edu Status: RO Hello Andy, Since I've been put in temporary charge of the globillum mailing list while Paul is touring Europe, I took the initiative and added your name so that you should get any future mailings. If you don't, just let me know... Let me be the first to take you up on your offer of a better sky radiance model. We have been using the CIE standard sky distributions for our work in daylighting for some time. It is physical but not always accurate because of the difficulty in determining the atmospheric turbidity and the variability of cloud conditions in general. I would be happy to provide you with some code for calculating this function if you are interested. By the way, I hope that Eric referred you to the excellent paper by Takagi et al that appeared at Siggraph `90. It sounds like many of your concerns were at least touched on briefly by them. As for BRDF's, I have been working myself with Ken Turkowski under contract from Apple Computer on reflectance measurements and models for computer graphics. I suppose that Eric told you already about the paper by He, Torrance and Sillion in this year's Siggraph. This is probably the best physical model developed to date for isotropic reflection, though it is somewhat challenging to implement. (It took me weeks to get it right.) For anisotropic BRDF's (reflectances that change with azimuth), even the measurement is challenging. The few companies in the US will characterize a single surface for you for a few thousand dollars. I don't know about your budget, but this kind of expense sure doesn't fit in mine. So I've been working on a faster, cheaper gonioreflectometer. (Report forthcoming... I hope!) Regarding rays and associated solid angles, I just want to agree with Holly. If importance sampling is used in such a way that geometric factors (ie. cosine weighting for irradiance) are considered, all rays will be associated with equal (projected) solid angles. The ray values can then be added together and multiplied by the total (projected) solid angle and voila! It is fortuitous that such an implicit use of geometry also results in the best a priori sampling distribution. However, if you find during the sampling process that certain areas call for more rays than others, you can go ahead and sample these areas more densly as long as you remember to change the weight of the associated rays accordingly. The process I have been using to calculate irradiance (with reasonable success) is to divide the hemisphere into equal projected solid angles and send one ray in a stochiastically selected direction in each. This starts me out with a fully stratified Monte Carlo sampling. Then I estimate the variance contributed by each region and send extra samples to those regions that need it the most. The new rays are simply averaged in with the old ones for each region and the final summation is pi (the projected solid angle of a hemisphere) times the average of all the regions. Again, you are welcome to take a look at the code if you like. If you want to get more code than you can shake a stick at, Radiance is available from anonymous ftp on hobbes.lbl.gov (128.3.12.38). -Greg From greg Wed Sep 4 18:11:18 1991 Date: Wed, 4 Sep 91 18:11:14 +0200 From: greg (Greg Ward) To: anewton@ps.ucl.ac.uk, erich@eye.com, hr3@prism.gatech.edu, plewis@ps.ucl.ac.uk, shw@bruno.graphics.cornell.edu Subject: Globular ray tracing Status: RO Hi Andy, I'm keeping my response public because I'd be interested to hear what others have to say on this topic as well. First off, there must have been a little confusion in my mention of recent Siggraph papers. Ken Turkowski has not (yet) written a paper on BRDF's -- the only paper I know of at this year's Siggraph was by Xiao Dong He, Ken Torrance and Francois Sillion of Cornell. You were no doubt confused by my use of the word "He" in the context of my last letter. There are two main parts to the calculation of illumination in Radiance, "direct" and "indirect". These parts are distinguished by the method used to calculate the contributions rather than the sources of the contributions themselves. "Direct" contributions are computed by considering the directionality, brightness, and solid angle subtended by a light source and a single ray traced to a (jittered) location to test for occlusion. (Large sources are often broken up into smaller pieces to avoid occlusion and geometric errors.) I believe this method is similar to one you currently employ. I also make some approximations to avoid the visibility testing all of the light sources, but these are probably irrelevant to our discussion. "Indirect" contributions are computed using a Monte Carlo sampling of the hemisphere as I described in my last letter. The results of this calculation are then stored and reused for nearby values as described in a paper I wrote for Siggraph `88. (Actually, I wrote it the first time for Siggraph `87!) In this pass, any sources encountered that were part of the "direct" calculation are ignored -- very important for maintaining proper energy balance! By the way, Jim Arvo referred me to a Siggraph paper he wrote this year with David Kirk that points out very clearly that the type of adaptive sampling I use is biased. And that's a nasty word. Directional reflectance properties currently must be handled either during the direct calculation (which is view-dependent), or by some other sampling technique such as sending extra specular rays. (Specular and diffuse components are not non-physical, by the way. They have very real meaning. Specular is that component which is reflected coherently off the surface of a dielectric material, and diffuse is that component which is re-emitted by particles suspended in the material. A diffuse term implies a colloidal material, hence it does not really apply to metals.) For outdoor scenes, the sky component is almost always left out of the direct calculation. Since it represents such a large solid angle, it is more efficient to compute the sky's contribution intermittently using a Monte Carlo sampling of the projected hemisphere. The orientation of this hemisphere is given by the surface, and the contributions of all non-source rays is included, however they might manage to reach the sky or other "indirect" illuminators. The weight or "power" of these rays is PI divided by the total number of samples on the hemisphere for a straight Monte Carlo sampling, and the weights are modified as I explained before for adaptive sampling. The correct weight is PI instead of 2*PI because it is the value of the projected hemisphere we are interested in, not the total hemisphere. The radiance of the sky is computed from the CIE formulas. You should look at the file ray/lib/skybright.cal in the Radiance 1.4 distribution, and the program ray/src/gen/gensky.c which sets the parameters. The only other articles on Radiance that might be useful to you are the ones published in the Winter 1988 edition of the Journal of the Illuminating Engineering Society and the June 1990 issue of Lighting Design and Application. Both are U.S. trade journals, so I can send you reprints if you can't find them. I don't expect the reflectometer I've been working on to ever make it into the field. (If you'd seen it you'd believe me.) -Greg P.S. Please do send me those man pages. And while you're at it, please resend your last message. I somehow managed to delete it! Thanks! From daemon Wed Sep 4 17:45:31 1991 Date: Wed, 4 Sep 91 11:37:18 -0400 From: hr3@prism.gatech.edu (RUSHMEIER,HOLLY E) To: anewton@ps.ucl.ac.uk, erich@eye.com, greg@lesosun1.epfl.ch, hr3@prism.gatech.edu, shw@bruno.graphics.cornell.edu Subject: Re: Global illumination and complex BRDFs in ray tracing .. Cc: A.Newton@cs.ucl.ac.uk, plewis@ps.ucl.ac.uk Status: RO Hi -- In the computer vision problem we're working on that we use Radiance for we are also interested in calculating energy/area on a sensor pixel for a given exposure time, that is we are calculating integral over pixel area integral over solid angle subtended by finite pinhole L(incident) cos(theta) dw(pinhole) dApixel averaged over the pixel area and averaged over time. We use Radiance to do this basically by picking a point on the sensor pixel, picking a point on the finite pinhole and then using Radiance to calculate the incident radiance L from the direction defined by the two points. Thats essentially what we're doing, in practice we make several images for several pinhole locations, each of which has several sample per pixel by filtering a large image to a small one, and then averaging the images using appropriate weight factors. Well, I guess that isn't crystal clear. The point I'm trying to make though is to separate out the ideas of estimated L(incident) and the integrals over solid angle and area of L(incident) that you need to calculate energy on the sensor pixel. You can then make a Monte Carlo estimate of those integrals by choosing random points, and using Radiance to accurately return L(incident). -- Holly From daemon Wed Sep 4 18:02:42 1991 Date: Wed, 4 Sep 91 11:48:48 -0400 From: hr3@prism.gatech.edu (RUSHMEIER,HOLLY E) To: globillum@miro.Berkeley.EDU Subject: more complete reference Status: RO Hi -- In my last message I didn't give a complete reference for Chirs (Chris) Borel's paper, it is : C.C. Borel, S.A.W. Gerstl, and B.J. Powers "The Radiosity Method in Optical Remote Sensing of Structured 3-D Surfaces" Remote Sensing of Environment, vol. 36,no. 1, pp. 13-44 Also in the following issue is: N.S. Goel, I. Rozehnal and Thompson, R.L. "A Computer Graphics Based Model for Scattering from Objects of Arbitrary Shapes in the Optical Region" Remote Sensing of Environment, vol 36, no2 pp. 73-104. In this paper an implementation of the radiosity method is described with a revised method for calculating form factors. From a quick reading it seems to me that they have replaced the hemi-cube with a discretized hemisphere, and use a kind of painters algorithm for the zbuffer. Dr. Goel reports that the computational time increases only with N or NlogN (rather than Nsquared) for their method. He wrote me a letter saying he was interested in comments on the paper from the computer graphics point of view. If any of you get time to look at the paper, his email address is NGOEL@BINGTJW.bitnet. -- Holly From daemon Thu Sep 5 12:11:54 1991 X400-Trace: GB* *UK.AC; arrival Thu, 5 Sep 91 10:12:17 Z action Relayed X400-Trace: gb*gold 400*uk.ac; arrival Thu, 5 Sep 91 10:11:09 Z action Relayed X400-Trace: GB*GOLD 400*UK.AC; arrival Thu, 5 Sep 91 11:07:39 + 0100 action Relayed Date: Thu, 5 Sep 91 11:07:39 + 0100 P1-Message-Id: gb*gold 400*uk.ac;<4731.684065259@ps.ucl.ac.uk> Ua-Content-Id: globillum bac... From: Andy Newton To: greg@lesosun1.epfl.ch Cc: A.Newton@cs.ucl.ac.uk Subject: globillum back issues .. Importance: normal Status: RO RFC-822-HEADERS: Source-Info: enceladus.ps.ucl.ac.uk ========================== Greg, I know you're just looking after globillum for Paul Heckbert (where's he getting to in Europe, by the way? anywhere near London?) but do you have globillum archives or back issues I could browse? I feel maybe I need some background to what you guys have been discussing upto now. Cheers, Andy From daemon Fri Sep 13 20:18:06 1991 Date: Fri, 13 Sep 91 12:53:52 -0400 From: Eric Haines To: globillum@miro.Berkeley.EDU Subject: Send me your references, if you wish Cc: erich@juniper.eye.com Status: R RADIOSITY BIBLIOGRAPHY UPDATE I'm starting to do the yearly update of the radiosity bibliography I started some time ago. For "radiosity" read "global illumination related paper which goes beyond classical scanline and ray-tracing techniques" (which is why it gets called the radiosity bibliography instead). The bibliography is free to all, and is provided mostly because I enjoy providing such information to people. An older version of this bibliography of articles is available online via FTP from weedeater.math.yale.edu [130.132.23.17] in pub/Papers/RadBib.shar. If you don't have FTP access, ask me and I'll send you the old one. So, what I need from you all are updates. I've already included Barcelona workshop, SIGGRAPH '91, Graphics Interface '91 and Eurographics '91 papers, along with a few from Visual Computer and Computer Graphics Forum. No doubt I've missed some. So, if you want higher exposure for your research, please send me any references missing from the old version. (If you want lower exposure, like your embarassing research paper removed from the list, hmmm, maybe I can make money off of this after all...). There are undoubtedly pre-1991 papers in conferences that I've missed ("Radiosity Effects of Surroundings on Golf-Balls" from the Palm Springs Optics & Hedge-Clipping Conference comes to mind) and I'd love to list them. If you're not sure that I have a reference, write me - the worst that happens is that you waste a few minutes with information I already have. Also, I have found various minor errors in a few of the references over time (page numbers, exact date, etc). So, please feel free to check your references for correctness and update me. Entries are in "refer" format: %A James T. Kajiya %T The Rendering Equation %J Computer Graphics (SIGGRAPH '86 Proceedings) %V 20 %N 4 %D Aug. 1986 %P 143-150 %K shading, diffuse reflection and it saves me some time if you can pass them on like this. The new version of the bibliography should be ready at this end sometime next week (time here permitting), at which time I'll announce its availability. Eric Haines, erich@eye.com From daemon Fri Sep 13 21:18:54 1991 Date: Fri, 13 Sep 91 14:46:18 -0400 From: Eric Haines To: globillum@miro.Berkeley.EDU Subject: oh, and the ray tracing bibliography, too Cc: erich@juniper.eye.com Status: R To all, I forgot to mention: if you have updates or corrections for the separate "Ray Tracing Bibliography" (started by Paul Heckbert and now maintained by me), please let me know. Again, the older ray tracing bib is available on weedeater.math.yale.edu in the file with "RTbib" at the start. I'm interested in both papers directly about ray tracing algorithms, or about using ray casting for other processes. Technical articles only, no "isn't ray tracing cool, look at these pictures" references please. Do not send me references you get directly from Rick Speer's copyrighted postscript bibliography which came out recently (I believe a copy is on weedeater). Rick tells me that he's selling the un-postscripted version, and so he says that I may not use any new references from his list. Of course, many of his references came directly from Paul & my reference list, but our list is in the public domain at this point, so no matter. Also, be warned: Rick believes that using any of his reference list in any copyrighted work, even copying a reference in it and using that in your paper, is a violation of his copyright. Whether any of this holds water legally is not my concern - Rick feels, rightly or not, that such use is an infringement and so I will not use his material. As near as I can tell, there are about 50 articles/theses which he has listed which I don't have, mostly from semi-obscure journals, or minor masters theses, or in Japanese. Geez, talk about a tempest in a teapot (or VW bug?)! This all makes me not want to maintain this bib anymore and switch to doing something more profitable, like collecting baseball cards or something. Thanks, Eric Haines, erich@eye.com From daemon Mon Sep 16 21:23:38 1991 From: erich@eye.com (Eric Haines) Date: Mon, 16 Sep 1991 14:37:51 EDT X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: globillum@miro.Berkeley.EDU Subject: why not to copy Rick's bibliography Cc: erich@juniper.eye.com Status: R I thought I would pass on this note from Rick Speer about another good reason one should not copy anything in his bibliography. Rick's ray tracing bibliography looks like a nice tool, as he has done a lot of cross-referencing, so don't be scared off by his aggressive stance on copyright. Basically, don't copy anything directly from it and you'll be safe from legal action by him and _Computer Graphics Forum_, where it was first published (Vol. 10, No. 2, June 1991, p. 145-174). Enough on this topic, just wanted to make sure none of you repeat my mistaken assumptions, let's get back to research topics, Eric >From speer@anchor.cs.colorado.edu Thu Sep 12 17:41 EDT 1991 To: erich@eye.com By the way, like copyrighted maps, my paper contains certain markers that make it possible to determine whether copying has occurred. Rick From daemon Wed Sep 25 22:15:19 1991 Date: Wed, 25 Sep 91 15:25:55 -0400 From: Eric Haines To: globillum@miro.Berkeley.EDU Subject: Rad & Ray reference bibliographies available Cc: erich@juniper.eye.com Status: RO The updated radiosity and ray tracing reference bibliographies are now available. Anonymous ftp to weedeater.math.yale.edu and look in either /incoming or /pub/Papers. RadBib.09.91 is the radiosity bibliography, RayBib.09.91.Z is the ray tracing bib. I also added a simple awk script to search the refer lists for a word or phrase and spit out these references. Nothing brilliant; feel free to make it clever and send me an update. By the way, in case you don't know, there's a huge database of references for computer graphics at gatekeeper.dec.com in pub/misc/graf-bib, ordered by year for 1976-1986. It's very extensive for the time period covered (one of my favorite titles is an article called "A hidden-line algorithm for hyperspace" - what could it mean?), with some 6300+ references. Thanks to all the people who sent me updates and corrections. Enjoy the new bibliography, and keep me posted about your latest articles, Eric From daemon Mon Oct 7 15:25:12 1991 Date: Mon, 7 Oct 91 10:06:44 -0400 From: Eric Haines To: globillum@miro.Berkeley.EDU Subject: Radiosity papers via FTP Status: R At weedeater.math.yale.edu [130.132.23.17] in pub/Papers are two more papers available via FTP: Ronchamp.tar.Z - "Ronchamp: A Case Study for Radiosity" Beams.tar.Z - "Beams O' Light: Confessions of a Hacker" The Ronchamp paper discusses various problems we've encountered in using meshed radiosity algorithms (i.e. the ones pioneered by Cornell) and some solutions - a non-theoretical and hands-on oriented paper. It's in the same vein as Baum et al's worthwhile SIGGRAPH '91 Proceedings paper. The Beams paper is a short, light paper on how we did the beams of light effect for the Ronchamp chapel stills and movie (Scientific American, Feb. 1991, and our SIGGRAPH '91 film show entry). The papers are in postscript, kindly converted by Juhana Kouhia. They first appeared in the "Frontiers in Rendering" SIGGRAPH '91 Course Notes. Since course notes typically are difficult to find, and since I'm not planning on reworking either of these papers for the journals, I thought I would make them available here. Enjoy, Eric Haines, erich@eye.com p.s. incidentally, if you don't normally read USENET news, you might want to resubscribe to comp.graphics.research and see the discussion of ray-traced radiosity going on. I particularly liked Dave George's explanations. From greg Mon Oct 28 13:48:13 1991 Date: Mon, 28 Oct 91 13:47:19 +0100 From: greg (Greg Ward) To: globillum@miro.Berkeley.EDU Subject: New results for comparison Status: R Hello Everybody, As you may or may not remember, I have set up a site for sharing the results of global illumination algorithms. It is hobbes.lbl.gov (128.3.12.38), reachable by anonymous ftp for both pickup and delivery. This site also contains the Radiance software distribution, which most of you know about. If you don't, you will learn very shortly as I plan to announce its next release in a few weeks. The subdirectory containing simulation runs for comparison is is pub/tests. Sometime ago, I finished some new calculations on a simple space with obstructions, specular and RGB-colored surfaces. I still have not run any examples with general surface reflectance distributions (BRDF's) or more than three spectral samples. I just got around to organizing the results and making some postscript plots for their easier digestion. Here is a current table of contents: ------------------------------------------------------- TESTS This directory contains some test scenes and results for checking calculations against other people's programs. The subdirectories are broken down according to model type as follows: empty/*/* - Environments without obstructions obstructed/*/* - Obstructed environments */diffuse/* - Diffuse surfaces only */specular/* - Surfaces may have some (ideal) specularity */brdf/* - Surfaces may have arbitrary BRDF's */*/grey - Grey surfaces only */*/rgb - Surfaces with RGB color */*/spectral - Surfaces with > 3 spectral samples All models and files should be put in the bottom set of directories. Solutions should be given in human-readable text form, and should describe very thoroughly how they were obtained. Please name your files uniquely using some abbreviation of your name or group, so we don't get name collisions when everyone starts dumping their results into the obstructed/brdf/spectral directory (ha, ha). There are currently Radiance-generated results in the following directories: empty/diffuse/grey empty/diffuse/rgb empty/specular/grey empty/specular/rgb obstructed/diffuse/grey obstructed/diffuse/rgb obstructed/specular/grey obstructed/specular/rgb Most of the directories contain README files explaining their contents. The empty/diffuse/grey directory contains results not only from Radiance, but also from Holly Rushmeier and sometimes Sumanta Pattanaik. -------------------------------------------------- Francois Sillion has told me that he has results he is willing to share using general BRDF's, and I know there are people out there with results for multiple spectral samples, so we may be able to come up with a fairly complete set of environments if everyone pitches in. -Greg From daemon Wed Nov 27 17:34:27 1991 Date: Wed, 27 Nov 91 15:59:05 MET From: Roberto Scopigno Subject: Delaunay sw To: GlobillumMailingList Status: R Dear Globillum subscribers, I am looking for a free distribution implementation of the Delaunay triangulation in the 3D space (or nD). Could anyone help me? Thanks Roberto Roberto SCOPIGNO Parallel Processing Group Phone: +39 50 593304 CNUCE - Istituto del C.N.R. FAX: +39-50-589354 Via Santa Maria 36 56100 PISA - ITALY E-MAIL: SCOP@ICNUCEVM.CNUCE.CNR.IT From daemon Thu Nov 28 11:18:01 1991 Date: Wed, 27 Nov 91 11:42:23 GMT From: Christopher.Patmore@prg.oxford.ac.uk To: globillum@miro.Berkeley.EDU Subject: Extension of sky luminance functions? Status: R Hi there. Does anyone have or know of a continuous extension to the CIE standard luminance functions (for clear and overcast skies) to account for reflection from the ground? I've been using these functions to model ambient light in radiosity solutions and cloud rendering. The discontinuity produced by a reflected fraction of this function to account for ground reflection produces unwanted discontinuities in my shading. While this is not so noticeable in a radiosity solution, raytracing highlights the inefficiencies of such a system. Chris Patmore From atc@cs.utexas.edu Fri Dec 6 09:26:31 1991 Return-Path: From: atc@cs.utexas.edu (Alvin T. Campbell III) Date: Fri, 6 Dec 1991 10:26:16 -0600 To: globillum@miro.berkeley.edu Subject: dissertation completed Status: RO Fellow global illuminators, I have just completed and defended my doctoral dissertation. Its bibliographic citation is listed below, in BibTeX format: @PHDTHESIS{campbell91, AUTHOR = {{Campbell, III}, A. T.}, TITLE = "Modeling Global Diffuse Illumination for Image Synthesis", SCHOOL = "University of Texas at Austin", YEAR = 1991, MONTH = dec} I am in the process of turning it into a UT CS Department tech report. When it is available, I will send a separate message with ordering information. A. T. Campbell, III, new Ph.D. From erich@eye.com Wed Jan 8 09:59:43 1992 Return-Path: Date: Wed, 8 Jan 92 12:39:39 -0500 From: Eric Haines To: globillum@miro.berkeley.edu Subject: new reference Status: RO I just received a new reference for the Radiosity bibliography [free for the asking] which I maintain: %A Amitabh Varshney %T Parallel Radiosity Techniques for Mesh-Connected SIMD Computers %R Master's Thesis, Technical Report TR91-028 %I Department of Computer Science, University of North Carolina at Chapel Hill %D July 1991 %K parallelism Things have been pretty darn quiet on this mailing list. Does anyone else have any new references they'd like to bring to everyone's attention? (I haven't read the above, just have the reference). Eric Haines, erich@eye.com From holly@cam.nist.gov Mon Jan 13 10:27:07 1992 Return-Path: Date: Mon, 13 Jan 92 12:59:27 EST From: holly@cam.nist.gov (Holly_Rushmeier) To: globillum@miro.berkeley.edu Subject: light videos & PE Status: RO Since I am starting a new job I am giving some thought to new projects I want to develop. I would like to get some input on a couple of different subjects: 1. We have a Princeton Engine at NIST. Has anybody used one? It is built for image processing, but perhaps it could have some application to image synthesis. I could spend some time looking into its use unless somebody else has already done a lot of work in this area. 2. Last Siggraph Dan Baum had a video showing a progressive refinement radiosity solution in progress, with the shooting patches highlighted. What other videos illustrating global illumination principles are around? Are any of them available for purchase? Thanks, Holly Rushmeier NIST Gaithersburg, MD 20899 holly@cam.nist.gov From atc@cs.utexas.edu Wed Jan 15 13:06:06 1992 Return-Path: X400-Received: by mta chx400.switch.ch in /PRMD=switch/ADMD=arcom/C=CH/; Relayed; Wed, 15 Jan 1992 22:05:36 +0100 X400-Received: by /PRMD=SWITCH/ADMD=ARCOM/C=CH/; Relayed; Wed, 15 Jan 1992 15:01:59 +0100 Date: Wed, 15 Jan 1992 15:01:59 +0100 X400-Originator: atc@cs.utexas.edu X400-Mts-Identifier: [/PRMD=SWITCH/ADMD=ARCOM/C=CH/;9201152102.AA07092] X400-Content-Type: P2-1984 (2) From: "(Alvin T. Campbell III)" To: drb@sgi.com, ph@duticg.tudelft.nl, max2@llnl.gov, krs@allegra.att.com, greg@lesosun1.epfl.ch, johnw@eye.com Cc: atc@cs.utexas.edu Subject: dissertation in the mail Status: RO Graphics colleagues, I thought you would like to know that your copies of my dissertation are now in the mail. They will probably arrive within a week. The UT Computer Science department only gave me a few copies for my use; since you are the people who expressed most interest in my research, you are the recipients of those copies. In the next day or so, I will post a message to the global illumination mailing list with information on ordering copies from the CS department. If you know anyone else who wants a copy of the document, please refer them to that message. Thanks for your support and interest. A. T. Campbell, III CS Department, University of Texas atc@cs.utexas.edu From atc@cs.utexas.edu Wed Jan 15 13:06:06 1992 Return-Path: X400-Received: by mta chx400.switch.ch in /PRMD=switch/ADMD=arcom/C=CH/; Relayed; Wed, 15 Jan 1992 22:05:36 +0100 X400-Received: by /PRMD=SWITCH/ADMD=ARCOM/C=CH/; Relayed; Wed, 15 Jan 1992 15:01:59 +0100 Date: Wed, 15 Jan 1992 15:01:59 +0100 X400-Originator: atc@cs.utexas.edu X400-Mts-Identifier: [/PRMD=SWITCH/ADMD=ARCOM/C=CH/;9201152102.AA07092] X400-Content-Type: P2-1984 (2) From: "(Alvin T. Campbell III)" To: drb@sgi.com, ph@duticg.tudelft.nl, max2@llnl.gov, krs@allegra.att.com, greg@lesosun1.epfl.ch, johnw@eye.com Cc: atc@cs.utexas.edu Subject: dissertation in the mail Status: RO Graphics colleagues, I thought you would like to know that your copies of my dissertation are now in the mail. They will probably arrive within a week. The UT Computer Science department only gave me a few copies for my use; since you are the people who expressed most interest in my research, you are the recipients of those copies. In the next day or so, I will post a message to the global illumination mailing list with information on ordering copies from the CS department. If you know anyone else who wants a copy of the document, please refer them to that message. Thanks for your support and interest. A. T. Campbell, III CS Department, University of Texas atc@cs.utexas.edu From greg Wed Jan 15 13:29:29 1992 Return-Path: Date: Wed, 15 Jan 92 13:29:23 PST From: greg (Gregory J. Ward) To: atc@cs.utexas.edu Subject: Re: dissertation in the mail Status: RO Hi A.T., Thanks for sending me a copy of your dissertation. Congratulations! I don't know how you decided that I would be one of the lucky recipients, but your generosity is much appreciated. Where to now? -Greg From atc@cs.utexas.edu Wed Jan 15 13:42:52 1992 Return-Path: From: atc@cs.utexas.edu (Alvin T. Campbell III) Date: Wed, 15 Jan 1992 15:15:23 -0600 To: lsu@leland.stanford.edu, ann@rice.edu, ecamahor@cs.utexas.edu, herzlich%neuron.enet@decwrl.dec.com, barnett@aurora.urich.edu, watson@mpd.tandem.com, globillum@miro.berkeley.edu Subject: my dissertation Cc: atc@cs.utexas.edu Status: RO Fellow graphics researchers, The tech report of my dissertation is now available from the UT Computer Sciences Department. The bibliographic citation is listed below: A. T. Campbell, III, "Modeling Global Diffuse Illumination for Image Synthesis," (Ph.D.), University of Texas at Austin, Department of Computer Sciences, technical report TR-91-39, December 1991, 155 pages. To obtain a copy, please make your U.S. bank check or international money order in the amount of $5.00 payable to: The University of Texas and send payment along with your request for TR-91-39 to: Technical Report Center Department of Computer Sciences TAY 2.124 University of Texas at Austin Austin, TX 78712-1188 I appreciate your support and interest. A. T. Campbell, III CS Department, University of Texas atc@cs.utexas.edu From atc@cs.utexas.edu Wed Jan 15 13:50:52 1992 Return-Path: From: atc@cs.utexas.edu (Alvin T. Campbell III) Date: Wed, 15 Jan 1992 15:50:46 -0600 To: greg@hobbes.lbl.gov (Gregory J. Ward) Subject: Re: dissertation in the mail Cc: atc@cs.utexas.edu Status: RO Okay, Greg, you caught me. Lucky recipients of the dissertation fall into several categories: 1) Personal friends 2) People with whom I've worked before 3) People with whom I've exchanges papers before 4) People who work at places I'm planning to apply You fall into category 4. Last fall I did not have much time for interviewing, so I'm still early in the job search. I thought I'd contact people at various places I'm interested in, and see what the hiring situation is. A. T. From greg Wed Jan 15 14:14:46 1992 Return-Path: Date: Wed, 15 Jan 92 14:14:41 PST From: greg (Gregory J. Ward) To: atc@cs.utexas.edu Subject: Re: dissertation in the mail Status: RO Hi A.T., I'm flattered that you would want to work here at LBL, but the hiring situation is pretty bad right now. The funding for my work has never been fat (I'm still running on a Sun 3/60 for example), and this year may be the last that we have any money for lighting simulation, period. I assume that you are considering SGI. You might also try Apple computer's Advanced Technology Group (Ken Turkowski -- turk@apple.com) and Pixar if you haven't already. I'll let you know if my situation here takes a turn for the better, but right now things look rather bleak. Good luck with your job search!! -Greg P.S. I'd be happy to send five dollars to cover duplication costs for your dissertation. From atc@cs.utexas.edu Wed Jan 15 14:57:09 1992 Return-Path: From: atc@cs.utexas.edu (Alvin T. Campbell III) Date: Wed, 15 Jan 1992 16:57:05 -0600 To: greg@hobbes.lbl.gov (Gregory J. Ward) Subject: Re: dissertation in the mail Status: RO Greg, My mental images of National Laboratories is being completely blown. For the past several years, I have seen lots of good work coming out of National Labs (Lawrence Livermore, Lawrence Berkeley, Sandia), so I assumed that they must be great places to work. At SIGGRAPH I asked Nelson Max about the hiring situation at Livermore; he said that it was not good, but suggested that I contact your group. With your status report, I wonder if I should bother at any of the other National Labs? I had already decided to try the other places you mentioned. Thanks for the suggestions, though. If any place else comes to mind, please let me know. Don't worry about the charge for the dissertation. You actually seem interested in reading it, which is enough reward for me. I'll keep you posted with further developments. A. T. From @cornellc.cit.cornell.edu:dhs@saturn.graphics.cornell.edu Wed Jan 29 09:05:56 1992 Return-Path: <@cornellc.cit.cornell.edu:dhs@saturn.graphics.cornell.edu> Date: Wed, 29 Jan 92 11:20:38 est From: David H. Salesin To: globillum@miro.berkeley.edu Subject: ElectroGIG software Cc: derose@parc.xerox.com Reply-To: dhs@graphics.cornell.edu Status: RO Does anyone have any experience with ElectroGIG? I can't really argue with the price, but if the software's no good, there's not much point in getting it.... Thanks! David >From Communications of the ACM, Nov. 1991: In an effort to enhance computer graphics education on a national level, GIG USA is offering a limited number of complete 3D graphics packages free of charge to accredited universities, colleges and schools throughout the U.S. The ElectroGIG system, which lists for $30,000, includes retracing [sic - should be ray-tracing] and animation applications and runs on Silicon Graphics and DEC 5000 workstations. Written requests must be mailed (phone calls or faxes will not be accepted) on official school letterhead by staff or faculty members only to GIG USA, Inc., 7380 Sand Lake Rd., Suite 390, Orlando, FL 32819, attention: GIG Educational Software Program. From erich@eye.com Thu Feb 13 14:13:57 1992 Return-Path: Date: Thu, 13 Feb 92 16:49:41 -0500 From: Eric Haines To: globillum@miro.berkeley.edu Subject: Errata to Intro to RT book Status: RO Since everyone doesn't read comp.graphics and the corrections are worthwhile: Errata to _An Introduction to Ray Tracing_, first edition, edited by Andrew Glassner (glassner.pa@xerox.com), Academic Press 1989. compiled by Eric Haines (erich@eye.com) from all authors' contributions date: 2/13/92 ----- p. 34, line 2: change "Rather then present" to "Rather than presenting". ----- p. 37, line 7 of text: change "is the closest intersection point on" to "is the closest intersection distance on". ----- p. 37, line 8 of text: change "If no such point exists" to "If no such root exists". ----- p. 38, in the Example, after "First normalize": a right bracket ("]") is missing on the line beginning with "Rd = [". ----- p. 52, equation (C9): change "(in other words, if Vd > 0)" to "(in other words, if Vd < 0)". ----- p. 58, Figure 8: change the axes' labels from "X" and "Y" to "U" and "V". ----- p. 60, third equation in (E2): change "Nd" to "Na". ----- p. 62, first line after equation (E11): change "substituting v for u" to "substituting v for u and substituting Nb for Nc". ----- p. 66, lines 7 and 8 of algorithm: change "if t1 > tnear, set t1 = tnear" to "if t1 > tnear, set tnear = t1". Change "if t2 < tfar, set t2 = tfar" to "if t2 < tfar, set tfar = t2". ----- p. 69, first line after equation (G5): change "can be factored out" to "can be deleted". ----- p. 70, lower right corner of matrix in (G2): change "315" to "-315". ----- p. 70, halfway down page, on down: the calculations for t0 and t1 are shown incorrectly. First, the leading "(" sign in each calculation should be deleted. More importantly, the term "-(-3.46)" should also appear over the denominator "2*4.67". The answers are correct. To summarize: -(-3.46) - sqrt( SAME AS BEFORE ) t0 = ----------------------------------- 2 * 4.67 = -10.3 and: -(-3.46) + sqrt( SAME AS BEFORE ) t1 = ----------------------------------- 2 * 4.67 = 11.1 ----- p. 70, last line: change "t0 is positive" to "t1 is positive". ----- p. 77, references: change reference 9 from "Siggraph 269-278" to "Siggraph '86 Proceedings, p. 269-278, August 1986." ----- p. 86, last paragraph before Algebraic Surfaces header: change "where all the the intersections of the ray with all the objects in the CSG tree are required" to end as "may be required". ----- p. 88, equation "t = etc": change from "t = etc" to "t = -etc", i.e. a minus sign is missing, so negate the right hand side of the equation. ----- p. 91, last formula in the Sphere section (in the text): change to x1^2 + y1^2 + z1^2 = 1 ^ subscript was "0" ----- p. 91, in the Paraboloid section, second equation: change the two minus signs to plus signs (i.e. before z1 and z0). ----- p. 93, torus equation corrections: change two equations a2 = 2(x1^2+y1^2+z1^2)((x0^2+y0^2+z0^2)-(a^2+b^2)) + 4 * (x0x1+y0y1+z0z1)^2 + 4a^2z1^2 ^ ^ was "2" was "-" a0 = ((x0^2+y0^2+z0^2)-(a^2+b^2))^2 - 4a^2(b^2-z0^2) ^ squaring was left off ----- p. 95, last sentence before the Simplicial Splines and Steiner Patches section: change "of" to "or, i.e. it should read "numerical techniques or subdivision algorithms". ----- p. 95, last formula on the page: change to z(u,v) = h y(v) ^ subscript was "x" ----- p. 100, Figure 7 is wrong. The upper figure is in error; the lower part is correct. In the upper figure, the outer contour is the silhouette of a 3D parametric surface. Curve c1 is the intersection of one plane with that surface, and c2 is the intersection of another plane, perpendicular to the first. The line of intersection of the two planes is collinear with the ray, indicated by the line with the arrow. The other three lines in the figure are extraneous and should be ignored. The lower part of the figure shows the two curves in uv space. ----- p. 101, the last sentence in the Bicubic Patches section: change "this can involve a loss of extra computation" should be "this can involve extra computation". ----- p. 101, the second equation in the Numerical Methods section: change the second "=" in the line to a "+" (it's the only equation with two "=" in it). ----- p. 105, the 2-D line equation: change to (y1)x - (x1)y - (x0y1 - y0x1) = 0 ^ was a "+" ----- p. 108, formula for f: This does not agree with Fig. 10. Using the same notation as in the figure, change to: For this shape, f is 2 2 2 2 (x-r (u)) + (y-r (u)) + (z - r (u)) - a (u) = 0 x y z where (r , r , r ) is the center of the sphere and a is the radius. x y z ----- p. 140, equation (7h): missing right parenthesis, change to "...- 1)))N." ----- p. 148, section on distribution term D, 8th line: change "the angle between L and H" to "N and H". ----- p. 156, section 5.4, 2nd paragraph: change "spectral transmission curve" to "specular transmission curve". ----- p. 158, in Fdt(lambda) definition: change "diffuse reflection" to "diffuse transmission". ----- p. 158, line immediately after Fdt(lambda) definition: change "We note that the diffuse reflectance" to "diffuse transmittance". ----- p. 238, Fig. 24: A chunk is missing in the upper left corner. The labels should read: "Directions crossed with", and "Applies to". ----- p. 260, reference by Gervautz: change "Comput. Graph." to "Computers and Graphics". ----- p. 288, immediately after the DERIVATION OF REFRACTION FORMULAS header: The introductory paragraph is missing. It reads: We derive three alternative formulas for the refracted ray direction in ray tracing in order to prove their equivalence and to demonstrate the process of translating physical laws into optimized computational formulas. It is common knowledge that light rays refract when they strike an interface between two different transparent media, such as air-water, air-glass, or glass-water. In 1621 Dutch mathematician Willebrord Snell discovered a formula quantifying this observation: the ratio of the sines of the incident and refracted angles equals the ratio of the indices of refraction of the two materials. Snell's law is: eta sin( theta ) = eta sin( theta ) 1 1 2 2 where theta-sub-1 is the angle of incidence, theta-sub-2 is the angle of refraction (both measured from the perpendicular to the interface) and eta-sub-1 and eta-sub-2 are the two indices of refraction on the incident and refracted sides of the interface, respectively. Light passing through a material slows relative to its speed in a vacuum by a factor equal to the index of refraction of that material. In fact, Snell's law is a simple consequence of this speed variation and Fermat's _Principle of Least Time_, which states that light takes the fastest path to get from one point to another [Feynman63]. For computation we need to recast Snell's law in terms of (x,y,z) direction vectors. This can be done in several different ways. In the derivations below we make extensive use of angles and trigonometry, but thankfully, it is possible to eliminate all of these terms from the final formulas, so theta-sub-1 and theta-sub-2 need never be computed. As a convention, vectors are upper case and scalars are lower case. ----- END From erich@eye.com Fri Mar 20 14:20:55 1992 Return-Path: Date: Fri, 20 Mar 92 09:51:44 -0500 From: Eric Haines To: globillum@miro.berkeley.edu Subject: Anyone seen this one? Status: RO I just received a flyer for a new computer graphics book. I was wondering if anyone had seen these papers (and whether they're worth tracking down - answers can be confidential if you prefer, of course). Thanks, Eric Haines p.s. if anyone has page numbers for these, I'd appreciate them (for the radiosity bibliography). %A Eihachiro Nakamae %A Tomoyuki Nishita %T Lighting Simulation in Computer Graphics %A Mark A. Z. Dippe %A Erling Henry Wold %T Stochastic Sampling: Theory and Application %B Progress in Computer Graphics %E George W. Zobrist %I Ablex Publishing %C Norwood, NJ %D 1991 From mfc@princeton.edu Mon Apr 6 07:12:17 1992 Return-Path: Date: Mon, 6 Apr 92 09:44:11 -0400 From: Michael Cohen To: globillum@miro.berkeley.edu Subject: Is Image Synthesis a Solved Problem? Status: RO Dear Globillumnus, I will be delivering an invited talk at the Eurographics workshop on Rendering in Bristol next month. I look forward to seeing some of you there. The title of the talk is "Is Image Synthesis a Solved Problem?". My intention is to use this forum to bring up a number of questions and issues which I feel have been addressed well and not so well in the field. Hopefully, it might also address a perception in the industry that a lot of research resources are misdirected towards image synthesis work. Nick Negroponte opened the recent Symposium on Interactive 3D Graphics with the description of the field of computer graphics as just emerging from the "dark ages" (1975-1990) in which much of the efforts were (mis)spent on realistic imaging. Anyway, since this is a topic dear to us all, rather than write a personal treatise on the topic, I want all of you to pitch in with your two cents worth. So, before you go on to your next mail message, take 3 minutes to repond to this totally unscientific survey. (If you can't see the bottom of this message from here, don't fear. There are only 5 or 6 questions). 0. How would you define the goal of image synthesis? I. What are the key issues that are still unanswered or not answered well in realistic image synthesis? Rate each issue as unsolved (0) to solved (5). Unsolved Solved 0 1 2 3 4 5 (a) local reflection models (b) the hidden surface problem (c) rendering caustics (d) dealing with environment complexity (e) mapping results to display devices (f) parallelization of image synthesis algorithms (g) dealing with color (h) dealing human perceptual issues (i) other (please specify) (j) and another? II. Many people in the graphics think that the MAIN problem remaining in image synthesis is simply that we cannot model, with sufficient detail, the environments we want to create images of. Do you agree? Disagree Agree 0 1 2 3 4 5 III. Overall, how far do YOU think we have come in solving the image synthesis problem. If 0 means we have not even scratched the surface, to 5 meaning the problem is all but solved, Unsolved Solved 0 1 2 3 4 5 IV. Overall, how do you think the computer graphics field AS A WHOLE views the progress of solving the image synthesis problem? Again, if 0 means we have not even scratched the surface, and 5 meaning the problem is all but solved, Unsolved Solved 0 1 2 3 4 5 V. Thanks for the responses so far. Any additional comments would be welcome, e.g., how should the field change its focus (if in fact you think it should)? Your chance to add some comment: VI. May I quote you? YES NO ------------------- Thanks. I'll see some of you in England, and will send you all the results. -Michael From greg Mon Apr 6 14:38:14 1992 Return-Path: Date: Mon, 6 Apr 92 14:38:11 PDT From: greg (Gregory J. Ward) To: mfc@princeton.edu Subject: Re: Is Image Synthesis a Solved Problem? Status: RO Hi Michael, Here are my responses to your survey questions: 0. I would define the goal of image synthesis as the accurate calculation of a 2-dimensional map of radiance values from a computer model of a physical environment. I. How solved are the following, where 0 is Unsolved and 5 is Solved? a) local reflection models: 1 b) the hidden surface problem: 4 c) rendering caustics: 1 d) dealing with environment compl.: 1 e) mapping results to displays: 2 f) parallelization of image..: 1 g) dealing with color: 1 h) dealing with humans: 0 i) dealing with daylight: 2 j) animation (walk-through) accuracy: 1 II. I agree that we cannot model in sufficient detail, but we haven't the algorithms to deal with complex cases even if we could. 3. III. Overall, I would say were somewhere between 1 and 2, probably closer to a 1. IV. I can only guess what the rest of the graphics community thinks. Maybe a 3 or 4? V. I think we should place more emphasis on combining local and global illumination models, a la Sillion's work (although I favor Monte Carlo methods). Also, I think that current meshing strategies are woefully inadequate. I would like to see more attention paid to meshing for accuracy, or doing away with meshing altogether. VI. Yes, quote away. Just don't reproduce my typso. Have fun in England. Wish I were going! -Greg From GATENBY@v3.cgu.mcc.ac.uk Thu Apr 16 03:31:19 1992 Return-Path: Via: sun3.nsfnet-relay.ac.uk; Thu, 16 Apr 1992 10:55:09 +0100 Date: Thu, 16 Apr 92 10:55 GMT From: "Neil Gatenby, CGU, University of Manchester" To: GLOBILLUM Subject: Gouraud shading Status: RO All @ globillum: I've got this problem (more a query really) with Gouraud shading - I sent the following message to comp.graphics.research 9 days ago and it still hasn't appeared here, so I thought I'd give globillum a spin: ============================================================================= I wonder if anyone out there could help/empathise/sympathise[ :-( ] with this problem I've been having for over a year now: I'm trying to render pictures generated using radiosity algorithms, but when I do adaptive subdivision, I end up with (say) a quadrilateral with N (>4) points along its border whose RGB values I know, and I want to Gouraud shade across the polygon. Now I know that Gouraud shading is only well-defined for triangles, but the software I was using (DEC PHIGS v2.2 running on VMS v5.4) was confident about smooth shading over as many vertices as I cared to choose, so I plugged in the data (see end of file) and ended up with *really* sharp lines along the edge which has multiple RGB values. I know this is *not* Mach banding (well, its not _expected_ Mach banding) - Mach banding is what I expect if I try and Gouraud shade quadrilaterals - this is an error in the shading algorithm. So, I thought "******* DEC - I'll try it on Sun PHIGS" (don't know version) and got *exactly* the same error. Now we've just got a shiny new HP 9000/720 CRX 24Z - running StarBase - and I get the exactly the same error again with the same data. Now, I know that I can get around the problem by not trying to render a quadrilateral which has >4 points across which I want smooth shading, but my question is this: o Does your rendering software do the same thing with this data ? o Why ??? ANY help/suggestions/ideas much appreciated. Here's the data - its format is: int /* no of polygons */ int /* no of verts to be shaded across */ float float float /* X Y Z of 1st point of 1st poly */ float float float /* R G B of 1st point of 1st poly */ .. .. float float float /* X Y Z of last point of 1st poly */ float float float /* R G B of last point of 1st poly */ <... rest of polygons ... > As shown here, its three squares, lying in the plane y=20, two small ones with 4 vertices to be shaded across (CEHG, EFIH) and one big one with 5 vertices to be shaded across (ABFEC). I get an *awful* sharp line along CF. A ----------- B | | | | | | | E | C ----------- F | | | | | | G ----------- I H Try re-arranging the data so that you render a triangle (AEC) and a quadrilateral (ABFE) instead of ABFEC - this makes the problem vanish; but why is it there in the first place ????? Thanks in advance. Neil Neil Gatenby | The views expressed here could Computer Graphics Unit | easily represent the views of Univ of Manchester, Manchester | my employers -- I haven't been M13 9PL, England | so ridiculous as to ask them... ------------------------------------------------------------------------------- Email: gatenby@uk.ac.mcc.cgu.v2 Tel: (+44)61 275 6095 Fax: (+44)61 275 6040 Strive to Survive, Causing Least Suffering Possible ------------------------ SNIP! ---------------------------------------------- 3 4 1.00000E+01 2.00000E+01 1.50000E+01 7.38287E-01 6.69512E-01 7.67340E-01 5.00000E+00 2.00000E+01 1.50000E+01 5.35259E-01 4.76308E-01 5.58419E-01 5.00000E+00 2.00000E+01 2.00000E+01 5.20033E-01 4.69389E-01 5.52817E-01 1.00000E+01 2.00000E+01 2.00000E+01 7.98697E-01 7.45726E-01 8.30082E-01 4 5.00000E+00 2.00000E+01 1.00000E+01 5.43252E-01 4.80033E-01 5.61503E-01 5.00000E+00 2.00000E+01 1.50000E+01 5.35259E-01 4.76308E-01 5.58419E-01 1.00000E+01 2.00000E+01 1.50000E+01 7.38287E-01 6.69512E-01 7.67340E-01 1.00000E+01 2.00000E+01 1.00000E+01 7.86607E-01 7.24586E-01 8.12099E-01 5 1.00000E+01 2.00000E+01 2.00000E+01 7.98697E-01 7.45726E-01 8.30082E-01 2.00000E+01 2.00000E+01 2.00000E+01 8.63633E-01 8.25140E-01 8.84702E-01 2.00000E+01 2.00000E+01 1.00000E+01 9.06373E-01 8.83813E-01 9.21609E-01 1.00000E+01 2.00000E+01 1.00000E+01 7.86607E-01 7.24586E-01 8.12099E-01 1.00000E+01 2.00000E+01 1.50000E+01 7.38287E-01 6.69512E-01 7.67340E-01 From krs@allegra.att.com Thu Apr 16 08:00:33 1992 Return-Path: From: krs@allegra.att.com (K. R. Subramanian) Date: Thu, 16 Apr 1992 10:22:00 EDT To: "Neil Gatenby, CGU, University of Manchester" , GLOBILLUM Subject: Re: Gouraud shading Status: RO Looks like a T vertex problem to me. -- KRS -- From eric_chen@gateway.qm.apple.com Thu Apr 16 11:50:02 1992 Return-Path: Date: 16 Apr 92 11:16:44 U From: "Eric Chen" Subject: Re: Gouraud shading To: GATENBY@v3.cgu.mcc.ac.uk Cc: globillum@miro.berkeley.edu Status: RO Reply to: RE>Gouraud shading The scanline directly above CF is obtained by interpolating colors from edge AC and BF. CF is interpolated with colors from CEF. That's why you see discontinuity along CF. If the polygons are rotated in some degree, say 45, or CEF is not colinear, the discontinuity may be less obvious. The right solution is to avoid T-vertices in Gouraud shading. Hope this help. Eric Chen From ph@duticg.tudelft.nl Mon May 18 06:34:05 1992 Return-Path: Date: Mon, 18 May 92 15:06:59 met From: Paul Heckbert To: globillum@miro.berkeley.edu Subject: rendering workshop proceedings Status: RO Hello from sunny Bristol, UK, where the Third Eurographics rendering workshop is just beginning! Alan Chalmers has printed up about 50 extra copies of the proceedings of this workshop which you can order by sending him 25 pounds sterling in cash (if you dare) or email him your VISA card account number, expiration date, and name. The proceedings are paperback, about 200 pages total, with color figures, containing 20 papers. They will be available either as a Springer-Verlag book or as a Eurographics technical report at some date in the future (maybe a year?) but if you want a copy soon, this is your best bet. Send your orders to: Alan Chalmers Department of Computer Science University of Bristol University Walk Bristol BS8 1TR United Kingdom Phone: +44-272-303109 Fax: +44-272-251154 email: alan@compsci.bristol.ac.uk From GATENBY@vmsfe.mcc.ac.uk Thu May 21 07:33:54 1992 Return-Path: Via: vmsfe.manchester-computing-centre.ac.uk; Thu, 21 May 1992 15:04:16 +0100 Date: Thu, 21 May 92 15:00 GMT From: "Neil Gatenby, CGU, University of Manchester" To: GLOBILLUM Subject: Inverse bump mapping Status: RO Dear all: Someone (Paul Heckbert???) at the recent (and excellent) 3rd Eurographics workshop on rendering was asking about inverse bump mapping; here's a _good_ reference: "Inverse Displacement Mapping", JW Patterson, SG Hoggar, JR Logie, (in) Proceeding of 9th Eurographics UK conference, University of Sheffield, 10th-12th April 1991. pp 105-134 Neil Neil Gatenby, Computer Graphics Unit, | Email: gatenby@uk.ac.mcc.cgu.v2 University of Manchester, | Tel: (+44)61 275 6095 Manchester M13 9PL, England. | Fax: (+44)61 275 6040 ------------------------------------------------------------------------------- Strive to Survive, Causing Least Suffering Possible From marini@imiucca.csi.unimi.it Tue Jul 14 10:43:15 1992 Date: Tue, 14 Jul 92 09:47:41 +0200 From: D. Marini (DSI) Return-Path: To: globillum@miro.berkeley.edu, shirley@iuvax.cs.indiana.edu Subject: Re: participating media BOF at siggraph Status: RO Unfortunately I will not attend next SIGRAPH, I am strongly interested in partecipating media for radiosity rendering. Can you maintain me informed about the planned meeting and follow-up? Will you kindly insert my e_mail in a possible list? We are working on a model for rendering DEM scenarios with fog, clouds etc. and modelling sky emittance; do you know some similar research. Thanking you in advance for your kind attention, Daniele Marini Dipartimento di Scienze della Informazione Universit degli Studi di Milano via Vomelico 39 20135 MILANO, ITALY tel +392 55006 358 fax +392 55006 334 e_mail: marini@imiucca.cis.unimi.it From erich@eye.com Wed Aug 5 10:01:38 1992 Return-Path: Date: Wed, 5 Aug 92 12:41:56 -0400 From: Eric Haines To: globillum@miro.berkeley.edu Subject: new references Status: RO To all, After SIGGRAPH is the time of the year in which I start seriously gathering new references for the "radiosity" bibliography (it should be called the "global illumination except for purely classical ray-tracing" bibliography, but that was a bit long). What follows are the new references I've gathered so far (I still have to include SIGGRAPH '92 and Graphics Interface '92 references, and the 3rd Eurographics Workshop on Rendering is added but not included below in the interests of brevity). If you have anything to add, correct, etc, please do let me know. I also appreciate the full names of people (e.g. Eihachiro Nakamae instead of E. Nakamae), so please pass these on. As soon as the Eurographics '92 proceedings references have been entered into this database I'll announce the release of the latest bibliography. In case you don't know, the current bibliography is available for FTP as princeton.edu:/pub/Graphics/Papers/RadBib.09.91 Thanks, Eric Haines erich@eye.com %E James R. Arvo %T Graphics Gems II %I Academic Press %C San Diego %D 1991 %Z includes a radiosity chapter of some new algorithms and C code %A Buming Bian %T Accurate Simulation of Scene Luminance %R PhD thesis %I Worcester Polytechnic Institute, Worcester, MA %D June 1990 %A Buming Bian %A Norman Wittels %T Accurate Image Simulation by Hemisphere Projection %J Proceedings of SPIE/IS&T %V 1453 %C San Jose, CA %D February 1991 %A Buming Bian %A Norman Wittels %A Donald S. Fussell %T Non-Uniform Patch Luminance for Global Illumination %J Proceedings of Graphics Interface '92 %C Vancouver, BC %D May 1992 %P 310-318 %A Buming Bian %T Hemispherical Projection of a Triangle %B Graphics Gems III %E David Kirk %I Academic Press %C San Diego %D 1992 %P 314-317 %A A.T. Campbell,III %T Modeling Global Diffuse Illumination for Image Synthesis %R PhD Thesis, Technical Report TR-91-39 %I Dept. of Computer Sciences, Univ. of Texas at Austin %D December 1991 %K shadow, BSP trees, mesh generation %A Alan G. Chalmers %T A Minimum Path System for Parallel Processing %R PhD thesis, Technical Report #? %I University of Bristol, Department of Computer Science %C Bristol, UK %D Jan. 1992 %K parallelism, MIMD %A Michael F. Cohen %T Radiosity %B State of the Art in Computer Graphics: Visualization and Modeling %E David E. Rogers %E Ray A. Earnshaw %I Springer Verlag %C New York %D 1991 %P 59-90 %A Michael F. Cohen %A James Painter %T State of the Art in Image Synthesis %B Advances in Computer Graphics IV? %E G. Garcia %E I. Herman %I Springer Verlag %C New York %D 1991 %P 59-113 %A Mark A. Z. Dippe %A Erling Henry Wold %T Stochastic Sampling: Theory and Application %B Progress in Computer Graphics %E George W. Zobrist %I Ablex Publishing %C Norwood, NJ %D 1991 %P ? %A S. Handa %A T. Takada %T Rendering of Density Clouds and Surfaces Using the Ray Casting Technique %E Tosiyasu L. Kunii %B Visual Computing: Integrating Computer Graphics with Computer Vision (Proceedings of CG International '92) %I Springer Verlag %C New York %D 1992 %P ? %E David B. Kirk %T Graphics Gems III %I Academic Press %C San Diego %D 1992 %Z includes a radiosity chapter of some new algorithms and C code %A S.P. Mudur %A S.N. Pattanaik %T Multidimensional Illumination Functions for Visualization of Complex 3D Environments %J The Journal of Visualization and Computer Animation %V 1 %P 49-58 %D John Wiley & Sons, 1990 %K Multidimensional illumination functions, 3D environment visualisation, spherical cover, environment dependent subdivision %A Eihachiro Nakamae %T Lighting Simulation in Computer Graphics %B Progress in Computer Graphics %E George W. Zobrist %I Ablex Publishing %C Norwood, NJ %D 1991 %P ? %A Eihachiro Nakamae %T Rendering of Outdoor Scenes %E Tosiyasu L. Kunii %B Visual Computing: Integrating Computer Graphics with Computer Vision (Proceedings of CG International '92) %I Springer Verlag %C New York %D 1992 %P ? %A Eihachiro Nakamae %A H. Yamashita %T An Interactive Observation Tool for Physical Phenomena Distributed in 3D Fields %E Tosiyasu L. Kunii %B Visual Computing: Integrating Computer Graphics with Computer Vision (Proceedings of CG International '92) %I Springer Verlag %C New York %D 1992 %P ? %A Tomoyuki Nishita %A S. Takita %A Eihachiro Nakamae %T A Shading Model of Parallel Cylindrical Light Sources %E Tosiyasu L. Kunii %B Visual Computing: Integrating Computer Graphics with Computer Vision (Proceedings of CG International '92) %I Springer Verlag %C New York %D 1992 %P ? %A Kevin P. Picott %T Extensions of the Linear and Area Lighting Models %J IEEE Computer Graphics and Applications %V 12 %N 2 %D March 1992 %P 31-38 %A Mark C. Reichert %T A Two-Pass Radiosity Method Driven by Lights and Viewer Position %R Master's Thesis %I Program of Computer Graphics, Cornell Univ. %D Jan. 1992 %A Jack Tumblin %A Holly E. Rushmeier %T Tone Reproduction for Realistic Computer Generated Images %R Tech. Report GIT-GVU-91-13 %I Graphics, Visualization & Usability Center, Coll. of Computing, Georgia Institute of Tech. %D 1991 %Z a reasonable method to scale radiosity solutions %A Amitabh Varshney %T Parallel Radiosity Techniques for Mesh-Connected SIMD Computers %R Master's Thesis, Technical Report TR91-028 %I Department of Computer Science, University of North Carolina at Chapel Hill %D July 1991 %K parallelism %A G. Zibordi %A K.J. Voss %T Geometrical and Spectral Sky Radiance: Comparison between Simulations and Vield Measurements %J Remote Sensing of the Environment %V 27 %D 1989 %P 343-58 From erich@eye.com Fri Aug 7 10:47:58 1992 Return-Path: Date: Fri, 7 Aug 92 12:20:45 -0400 From: Eric Haines To: globillum@miro.berkeley.edu Subject: more references, FYI Status: RO Here are new articles dealing with global illumination (not including ray tracing per se) from Graphics Interface '92, SIGGRAPH '92, and Graphics Gems III. I thought these might be of interest to those who hadn't seen them. Eric Haines >From GI '92: %A Kadi Bouatouch %A Pierre Tellier %T A Two-Pass Physics-Based Global Lighting Model %J Proceedings of Graphics Interface '92 %I Canadian Information Processing Society %C Toronto, Ontario %D May 1992 %P 319-328 %A Buming Bian %A Norman Wittels %A Donald S. Fussell %T Non-Uniform Patch Luminance for Global Illumination ... %D May 1992 %P 310-318 >From SIGGRAPH '92: %A Don Mitchell %A Pat Hanrahan %T Illumination From Curved Reflectors %J Computer Graphics (SIGGRAPH '92 Proceedings) %V 26 %N 4 %D July 1992 %P 283-291 %K caustics, interval arithmetic, ray tracing %A Brian E. Smits %A James R. Arvo %A David H. Salesin %T An Importance-Driven Radiosity Algorithm ... %P 273-282 %A Seth J. Teller %T Computing the Antipenumbra of an Area Light ... %P 139-148 %A Gregory J. Ward %T Measuring and Modeling Anisotropic Reflection ... %P 265-272 %K monte carlo, ray tracing, shading %A Stephen H. Westin %A James R. Arvo %A Kenneth E. Torrance %T Predicting Reflectance Functions From Complex Surfaces ... %P 255-264 %K monte carlo, shading %A Xiao D. He %A Patrick O. Heynen %A Richard L. Phillips %A Kenneth E. Torrance %A Donald P. Greenberg %T A Fast and Accurate Light Reflection Model ... %P 253-254 %K shading %Z discusses multi-media presentation on SIGGRAPH '92 CD-ROM of SIGGRAPH '91 paper >From Graphics Gems III: %A Jeffrey C. Beran-Koehn %A Mark J. Pavicic %T Delta Form-Factor Calculation for the Cubic Tetrahedral Algorithm %E David Kirk %B Graphics Gems III %I Academic Press %C San Diego %D 1992 %P 324-328 %Z includes code %A Buming Bian %T Hemispherical Projection of a Triangle ... %P 314-317 %Z includes code %A Nelson L. Max %A Michael J. Allison %T Linear Radiosity Approximation Using Vertex-to-Vertex Form Factors ... %P 318-323 %K hardware, hemicube %A Filippo Tampieri %T Accurate Form-Factor Computation ... %P 329-333 %Z includes code %A Changyaw Wang %T Physically Correct Direct Lighting for Distribution Ray Tracing ... %P 307-313 %K monte carlo %Z includes code From erich@eye.com Wed Aug 12 14:05:04 1992 Return-Path: X400-Received: by mta chx400.switch.ch in /PRMD=switch/ADMD=arcom/C=CH/; Relayed; Wed, 12 Aug 1992 23:04:41 +0200 X400-Received: by /PRMD=SWITCH/ADMD=ARCOM/C=CH/; Relayed; Wed, 12 Aug 1992 18:03:01 +0200 Date: Wed, 12 Aug 1992 18:03:01 +0200 X400-Originator: erich@eye.com X400-Recipients: greg@hobbes.lbl.gov X400-Mts-Identifier: [/PRMD=SWITCH/ADMD=ARCOM/C=CH/;9208122103.AA04883] X400-Content-Type: P2-1984 (2) From: Eric Haines To: Paul.Heckbert@hostess.graphics.cs.cmu.edu, greg@lesosun1.epfl.ch Subject: just out of curiosity... Status: RO Paul & Greg, I'm not sure which of you is maintaining the re-mailer nowadays, so this note's to both of you. Is there any way to have the globillum mailer not send me every bounce from all the naughty email addresses that don't want to receive my pearls of wisdom? After my two postings on radiosity references I've been getting a trickle of "blabhable.goomble.edu has not received your message during the past 4 days, 3 minutes, 2 seconds...". I've deleted about 15 of these so far, and I was wondering if you can turn these off (i.e. not have me receive bounces) from your end of things. I know it's possible, since I never get this behavior with other mailing lists I'm involved in, but haven't a clue what to do. If it's easy, please do do it. Thanks, Eric Haines From greg Wed Aug 12 14:13:20 1992 Return-Path: Date: Wed, 12 Aug 92 14:13:13 PDT From: greg (Gregory J. Ward) To: Paul.Heckbert@hostess.graphics.cs.cmu.edu, erich@eye.com Subject: Re: just out of curiosity... Status: RO Gee, I wish I did know how to turn this off. Paul, do you have any ideas? -Greg P.S. Eric-- Paul is in transit from my coast to your coast, so he may not get around to this immediately. As far as I'm concerned, he's still in charge of the globillum list. (Is no my jhob.) From Paul.Heckbert@HOSTESS.GRAPHICS.CS.CMU.EDU Thu Aug 13 20:42:33 1992 Return-Path: Date: Thu, 13 Aug 92 23:40:20 EDT From: Paul.Heckbert@HOSTESS.GRAPHICS.CS.CMU.EDU To: erich@EYE.COM, greg@HOBBES.lbl.gov Subject: Re: just out of curiosity... Cc: ph@HOSTESS.GRAPHICS.CS.CMU.EDU Status: RO I'm on the East coast now (well I'm within five hours of it, anyway) and I'll try to get to your request within the next week or two, after I get moved into my new house. I didn't realize that you were getting these annoying mailer daemon messages also; I thought I was the only one. From holly@cam.nist.gov Fri Sep 11 14:46:56 1992 Return-Path: Date: Fri, 11 Sep 92 17:11:40 -0400 From: holly@cam.nist.gov (Holly_Rushmeier) To: globillum@miro.berkeley.edu Subject: standards Status: RO Hi -- Since there has been a lot of discussion about standard terminology in this group, and since I work at the National Institute of Standards and Technology (NIST), I have gotten a lot of requests about standards. I thought I would try to clear up what the deal is on who makes up standards, and then try to start up the terminology discussion again. The following is just an informal description, and I'm not writing in any official capacity. Anyway, NIST (formerly the NBS) is a government laboratory which is part of the United States Department of Commerce. It has historically been a lab for measurement technology and research on standards. More recently, with the name change, NIST has a broader purpose now, which is to generally assist industry in the development of technology. NIST does offer calibration services, standard reference materials, etc., but doesn't define or enforce standards. An organization that does coordinate voluntary standards in the US is ANSI (American National Standards Institute). ANSI is a private sector federation of many different organizations. ANSI is the US member of many international standards bodies. What does this have to do with global illumination? In the past discussion of terminology in this group Pete Shirley and others have pointed out that there is an ANSI/IES (Illuminating Engineering Society) standard "ANSI/IES RP-16-1986, Nomenclature and Definitions for Illuminating Engineering." The standard defines terms such as luminance,luminous intensity, units such as the candela and various types of reflectance. It also covers some information about color, lighting calculations, and television, film and theatre light. It also has some CIE data. It would seem like a good idea for us to use as much of the terminology from this standard as possible. So how do you get RP-16-1986? NIST can't distribute it, because we don't have the copyright. You can call the IES for a publications catalog (212)705-7920. Or you can contact ANSI (Sales department phone number (212)642-4900, address 1430 Broadway, New York, NY 10018). The ANSI catalog recommends that outside of the US you contact the standards organization in your country, or one of these ANSI sales agents: American Technical Publishers, Ltd. 68a Wilbury Way Hitch, Herts SG40TP England Japanese Standards Association 1-24 Akasaka 4-Chrome Minato-Ku Tokyo 107, Japan Standards Council of Canada 350 Sparks, Suite 1200 Ottawa K1P 6N7, Ontario, Canada The standard is about 60+ pages long, and lists for $39.00 in the catalog I looked at. So, all that being said, I was planning next week to try to summarize the terms from the standard that I think apply to image generation, and the questions that remain unresolved (e.g. rough specular vs. imperfect diffuse vs. ???). If anybody else has already compiled a digested version of the standard for computer graphics, please feel free to jump in and post it. -- Holly From holly@cam.nist.gov Mon Sep 14 08:18:52 1992 Return-Path: Date: Mon, 14 Sep 92 10:35:38 -0400 From: holly@cam.nist.gov (Holly_Rushmeier) To: globillum@miro.berkeley.edu Subject: standards, sect. 2, surfaces Status: RO Summary of applicable definitions from ANSI/IES RP-16-1986 "Nomenclature and Definitions for Illuminating Engineering" --- terms applicable to computer graphics global illumination calculations with no ambient participating medium ----- Section 2. Electromagnetic Radiation 2.1 Radiant Energy, Q. Energy traveling in the form of electromagnetic waves. It is measured in units of energy such as joules or kilowatt hours. 2.1.1 Spectral radiant energy, Q(subscript-Greek-lambda)... Radiant energy per unit wavelength interval;... 2.2 Photon. A quantum of radiant energy ... ... 2.4 Radiant flux (radiant power), (capital-Greek-phi) = dQ/dt. The time rate of flow of energy... 2.4.1 Spectral radiant flux (capital-Greek-phi)(subscript- Greek-lambda) = d( capital-Greek-phi)/d(Greek-lambda)... 2.5 Radiant flux areal density, d(capital-Greek-phi)/dA, (at a point on a surface). The quotient of the radiant flux incident on or emitted by an element of surface area at the point, by the area of the element. Radiant flux density emitted from a surface has been called emittance. (footnote -- "To be deprecated."). The preferred term for radiant flux density leaving a surface is exitance, (M). Radiant flux density incident on a surface is irradiance, (E). 2.5.1 (spectral exitance and irradiance) ... 2.6 Radiant intensity, I = d(capital-Greek-phi)/d(small-Greek-omega) (in a given direction). The radiant flux proceeding from a source per unit solid angle in the given direction... 2.6.1 (spectral radiant intensity) 2.7 Radiance, L = d(second partial) (capital-Greek-phi)/[d(omega)dA cos(theta)] = dI/[dA cos(theta)] (in a given direction at a point on the surface of a source, of a receiver, or of any other real or virtual surface). The quotient of the radiant flux leaving, passing through, or arriving at an element of the surface surrounding the point, and propagated in directions defined by an elementary cone containing the given direction, by the product of the solid angle of the cone and the area of the orthogonal projection of the element of the surface on a plane perpendicular to the given direction. Note: In the defining equation (theta) is the angle between the normal to the surface and the given direction. 2.7.1 (spectral radiance) From holly@cam.nist.gov Mon Sep 14 08:18:57 1992 Return-Path: Date: Mon, 14 Sep 92 10:36:42 -0400 From: holly@cam.nist.gov (Holly_Rushmeier) To: globillum@miro.berkeley.edu Subject: standards, sect. 2, volumes Status: RO Summary of applicable definitions from ANSI/IES RP-16-1986 "Nomenclature and Definitions for Illuminating Engineering" --- terms applicable to computer graphics global illumination calculations with a participating medium ----- --- (I have never heard, much less used these terms before myself, but I think the radiant sterisent would be less confusing than the source intensity/radiance I have seen/used in the past). Section 2. Electromagnetic Radiation ... 2.3 Radiant energy density w = dQ/dV. Radiant energy per unit volume ... ... 2.8 Radiant fluence , F[(capital-Greek-delta)t], (for a time interval (capital-Greek-delta)t, at a point in space). The omnidirectional radiant energy externally incident on an elementary sphere about the point, per unit cross-sectional area of the sphere. F[(capital-Greek-delta)t] = dQ/da |= integral over (capital-Greek-delta)t integral over 4 (Greek-pi) steradians L d(Greek-omega) dt| where da is the cross-sectional area of the sphere. 2.8.1 (spectral radiant fluence). 2.9 Radiant fluence rate, F(subscript-t) (at a point in space). The omnidirectional radiant flux externally incident on an elementary sphere, per unit cross sectional unit of the sphere. ... 2.9.1 (spectral fluence rate). 2.10 Radiant sterisent, L*(x), (at a point along a ray path). Rate of increase in radiance, per unit path length, at the point in the direction of the ray, due to "generated" (emitted or scattered) radiance, or the "generated" radiant intensity per unit volume, at the point and in the direction of the ray, by which a distributed source can be characterized. L* = dL(subscript-g)/dx = dI(subscript-g)/dV, where dx is an element of distance along the ray path, dV is an element of volume at the point, and the subscript g denotes a "generated" quantity. Note: This quantity is useful in dealing with radiative transfer through a region where significant emission or scattering into the ray, as well as attenuation by absorption or scattering out of the ray, occurs along a ray path; also for evaluating the intensity of an extended volume of emitting and partially transmitting (transparent) material. ... 2.10.1 (spectral radiant sterisent). From holly@cam.nist.gov Mon Sep 14 08:19:25 1992 Return-Path: Date: Mon, 14 Sep 92 10:35:04 -0400 From: holly@cam.nist.gov (Holly_Rushmeier) To: globillum@miro.berkeley.edu Subject: standards summary Status: RO The following two messages from me will contain the start of the summary of ANSI/IES RP-16-1986 that applies to global illumination. These messages summarize part of section 2 of the standard -- in all there are 13 parts: 1. Introduction 2. Electromagnetic Radiation 3. Light 4. Color 5. Visual Terms 6. Light Sources 7. Surfaces and Media for Light Control 8. Testing procedures 9. Lighting Calculations 10. Interior Lighting Applications 11. Exterior Lighting Applications 12. Nonlighting Applications 13. Tables -- Holly From holly@cam.nist.gov Wed Sep 16 07:14:45 1992 Return-Path: Date: Wed, 16 Sep 92 09:40:12 -0400 From: holly@cam.nist.gov (Holly_Rushmeier) To: globillum@miro.berkeley.edu Subject: RP-16-1986, sect. 3 Status: RO Continuation of -- Summary of applicable definitions from ANSI/IES RP-16-1986 "Nomenclature and Definitions for Illuminating Engineering" ______________ my comments __________________________________ -- I think that since we do wavelength by wavelength calculations for image synthesis, the quantities for describing electromagnetic radiation in Section 2 that I posted last time are the most applicable. However, for the purpose of reading the illumination literature the following definitions are useful. -- -- Also I think it is important to separate three basic terms, radiance, for quantity of electromagnetic radiation (measurable by a meter), luminance, for "light" as defined below (also measurable by a meter), and brightness for the sensation produced by the incident electromagnetic radiation. --- ____________________ begin summary of standard _____________ Section 3. Light * (* Symbols for radiometric terms are indentified by the subscript e, and those for photometric (luminous) terms by the subscript v. In the event that no confusion will occur, the subscripts may be omitted...) 3.1 Light. Radiant energy that is capable of exciting the retina and producing a visual sensation. The visible portion of the electro magnetic spectrum extends from about 380 to 770 nanometers. Note: The subjective impression produced by stimulating the retina is sometimes designated as light. Visual sensations are sometimes arbitrarily defined as sensations of light, and in line with this concept it is sometimes said that light cannot exist until an eye has been stimulated . Electrical stimulation of the retina or the visual cortex is described as producing flashes of light. In illuminating engineering, however, light is a physical entity -- radiant energy weighted by the luminous efficiency function ... It is a physical stimulus that can be applied to the retina. 3.1.1 Phot-. Combining form meaning, broadly, within the visible spectrum. 3.2 Luminous flux (capital-Greek-phi). Radiant flux (radiant power); the time rate of flow of radiant energy, evaluated in terms of a standardized visual response. (capital-Greek-phi)(subscript v) = K(subscript m) * integral over all wavelengths (Greek lambda) {(capital-Greek-phi)(subscript e, Greek lambda) * V(Greek lambda)} d (Greek-lambda) where (capital-Greek-phi)(subscript v) = lumens (capital-Greek-phi)(subscript e, Greek lambda) = watts per nanometer lambda = nanometers V(Greek lambda)= the spectral luminous efficiency K(subscript m) = the maximum spectral luminous efficiency in lm/W Unless otherwise indicated, the luminous flux is defined for photopic vision. For scotopic vision, V'(Greek lambda) and the corresponding maximum spectral luminous efficacy K'(subscript m) are substituted in the above equation. K(subscript m) and K'(subscript m) are derived fromt the basic SI definition of luminous intensity and have the values 683 lm/W and 1754 lm/W respectively ... 3.2.1 Lumen, lm. SI unit of luminous flux. Radiometrically, it is determined from the radiant power as in Paragraph 3.2. Photometrically, it is the luminous flux emitted within a unit solid angle (one steradian) by a point source having a uniform luminous intensity of one candela. 3.3 Luminous flux density at a surface, d(capital-Greek-phi)/dA The luminous flux per unit area at a point on a surfaces ... 3.3.1 Illuminance E = d(capital-Greek-phi)/dA. The areal densiy of the luminous flux incident at a point on a surface 3.3.1.1 Illumination. An alternative, but deprecated, term for illuminance... 3.3.1.2 Lux, lx. The SI unit of illuminance. One lux is one lumen per square meter (lm/m**2)... 3.3.1.3 Footcandle, fc. A unit of illuminance. One footcandle is one lumen per square foot (lm/ft**2). 3.3.1.4 Phot, ph. A unit of illuminance euqal to one lumen per square centimeter. The use of this unit is deprecated. 3.3.2 Luminous exitance, M = d(capital-Greek-phi)/dA. The areal density of luminous flux leaving a surface at a point. Formerly, luminous emittance (deprecated). Note: This is the total luminance flux emitted, reflected and transmitted from the surface and is independent of direction. ... 3.4 Luminous intensity I = d(capital-Greek-phi)/d(Greek-small-omega) (of a point source of light in a given direction). The luminous flux per unit solid angle in the direction in question ... Luminous intensity may be expressed in candelas or in lumens per steradian (lm/sr). 3.4.1 Candela, cd. The SI unit of luminous intensity. One candela is one lumen per steradian (lm/sr). Formerly, candle. Note: The fundamental luminous intensity defineion in the SI is the candela. The candela is the luminous intensity, in a given direciton of a source that emits monochromatic radiaiton of frequency 540*10(raised to 12th power) hertz that has a radiant intensity in that direction of 1/683 watt per steradian. ... 3.4.2 Candlepower, cp. Luminous intensity expressed in candelas. 3.4.3 Equivalent luminous intensity of an extended source at a specified distance. The intensity of a a point source that would produce the same illuminance at that distance ... ... 3.5 Luminance, L = d(second-derivative)(capital-Greek-phi)/d(Greek-omega)dA cos(theta) (in a direction and at a point on a real or imaginary surface). ... The quotient of the luminous flux at an element of the surface surrounding the point, and propagated in directions defined by an elementary cone containing the given direction, by the product of the solide angle of the cone and the area of the orthogonal projection of the element of the surface on a plan perpendicular to the given direction. The luminous flux may be leaving, passing through, and/or arriving ath the surface. ... Note: In common usage the term brightness usually refers to the strength of sensation that results from viewing surfaces or spaces from which light comes to the eye. This sensation is determined in part by the definitely measurable luminance defined above and in part by the conditions of observations such as the state of adaptation of the eye... 3.5.1 SI unit of luminance. Candela per square meter (cd/m**2); also lumen per steradian * square meter (lm/(sr*m**2). This is also called the nit. ...(continues with a lot of older units for luminance) .. ...(also definitions for luminous fluence & sterisent) ... 3.10.4 Luminous efficacy of radiant flux. The quotient of the total luminous flux by the total radiant flux. It is expressed in lm/W. 3.11 Luminous efficacy of a source of light. The quotient of the total luminous flux emitted by the total lamp power input. It is expressed in lm/W. From shirley@death.cs.indiana.edu Wed Sep 16 08:27:34 1992 Return-Path: Date: Wed, 16 Sep 1992 09:55:37 -0500 From: "peter shirley" To: globillum@miro.berkeley.edu Subject: luminance meters? Status: RO Holly's posts have gotten me thinking again that I want a device to measure luminance or something similar (spectral radiance through the visible spectrum would be best :^}) at a particular point in a particular direction. At the photography store, I found a device called a spot-meter that measures something (luminance-like quantity with a film response curve?) withing a one degree diamether cone. This cost about $350. What other devices are there? What do they cost? Anyone have any comments on their reliability? Pete Shirley shirley@cs.indiana.edu PS-- If you do get hold of the ANSI doc that Holly's been digesting for us (thanks Holly!), the definition for luminance is a lot easier to read than the much briefer definition for radiance, so you might get more out of the luminance definition (and the geometrical part is the same!). From holly@cam.nist.gov Wed Sep 16 09:03:43 1992 Return-Path: Date: Wed, 16 Sep 92 11:43:51 -0400 From: holly@cam.nist.gov (Holly_Rushmeier) To: globillum@miro.berkeley.edu Subject: luminance meters? Status: RO For the infamous original Cornell box experiment, I used a Tektronix J16 photometer. It had two different probes for measuring illuminance and irradiance. We didn't buy it for the experiment -- the lab had it for calibrating monitors. The directional sensitivity of the probe is plotted in the paper. I used it as a directional device for measuring light source radiance by taping a cardboard tube on. Here at NIST the Lighting group has a luminance mapper -- basically a digital camera that gives an accurate luminance at each pixel. In October (beginning of our fiscal year) we're planning to start a project to measure some simple scenes to develop some reference data sets for people to compare against calculations. My idea is to post and/or make available some initial results after a couple of months and get feed back from you all about how useful the data is. -- Holly P.S. on a separate subject -- could people who attended Eurographics post a summary of global illumination related stuff that was presented/discussed? From holly@cam.nist.gov Thu Sep 17 07:05:53 1992 Return-Path: Date: Thu, 17 Sep 92 09:21:10 -0400 From: holly@cam.nist.gov (Holly_Rushmeier) To: globillum@miro.berkeley.edu Subject: RP-16-1986, 7.1-7.3.2 Status: RO Continuation of -- Summary of applicable definitions from ANSI/IES RP-16-1986 "Nomenclature and Definitions for Illuminating Engineering" ______________ my comments __________________________________ Sections 4, 5 and 6 contain a lot of interesting information, but don't deal with definitions we have problems with. Section 4 covers "Color" and defines things such as the Munsell hue, value and chroma, the color temperature of lights, color matching functions, metamers, and the standard illuminants A,B,C and variations of D. Section 5 covers "Visual Terms" and defines things such as photopic, mesopic, and scotopic vision, the Purkinje phenomenon, Broca-Sulzer effect, flicker, glare, visual comfort probability (VCP) and the Stiles-Crawford effect. Section 6 covers "Light Sources" and defines all sorts of lamps and lamp terms including various incandescent lamps, electric-discharge lamps, laser and LED. One the other hand, Section 7 contains a lot of definitions relevant to surface properties that we are concerned with. It will take a few of messages to cover all the stuff in 7. The following covers specular/diffuse. The way I read it, specular reflection is only in the mirror direction and is preferably referred to as regular reflection. Diffuse is a general term and refers to reflection in any other direction. There are three potential modifiers for diffuse -- "perfect" (= lambertian), "narrow-angle" and "wide-angle". ____________________ begin summary of standard _____________ Section 7. Surfaces and Media for Light Control 7.1 Diffusing surfaces and media. Those surfaces and media that redistribute at least some of the incident flux by scattering. 7.1.1 Perfect diffusion. That in which flux is uniformly scattered in accord with Lambert's cosine law (see Paragraph 7.1.1.1) 7.1.1.1 Lambert's cosine law (I(subscript-Greek-theta) = I(subscript o) cos (Greek-theta)) The law stating that the luminous intensity in any direction from an element of a perfectly diffusing surface varies as the cosine of the angle between that direction and the perpendicular to the surface element. 7.1.1.2 Lambertian surface. A surface that emits or reflects light in accordance with Lambert's cosine law. A lambertian surface has the same luminance regardless of viewing angle. 7.1.2 Complete diffusion. That in which the diffusing medium completely redirects the incident flux by scattering, i.e., no incident flux can remain in an image-forming state. 7.1.3 Incomplete diffusion(partial diffusion). That in which the diffusing medium partially redirects the incident flux by scattering while the remaining fraction of incident flux is redirected without scattering, i.e., a fraction of the incident flux can remain in an image-forming state. 7.1.4 Wide-angle diffusion. That in which flux is scattered at angles far from the direction which the flux would take by regular reflection (se Paragraph 7.3.1) or transmission. 7.1.5 Narrow-angle diffusion. That in which flux is scattered at angles near the direction which the flux would take by regular reflection or transmission. 7.2 Redirecting surfaces and media. Those which change the direction of the flux without scattering the redirected flux. 7.3 Reflection. A general term for the process by which the incident flux leaves a (stationary) surface or medium from the incident side, without change in frequency. Note: Reflection is usually a combination of regular and diffuse reflection (see Paragraphs 7.3.1 and 7.3.2). 7.3.1 Regular (specular) reflection. That process by which incident flux is redirected at the specular angle ... 7.3.1.1 Specular angle. That angle between the perpendicular to the surface and the reflected ray that is numerically equal to the angle of incidence, and that lies in the same plane as the incident ray and the perpendicular, but on the opposite side. 7.3.2 Diffuse reflection. That process by which incident flux is redirected over a rage (sic) of angles (see also Paragraph 7.1) From sumant@saathi.ncst.ernet.in Thu Sep 17 09:02:38 1992 Return-Path: From: sumant@saathi.ncst.ernet.in To: holly@cam.nist.gov (Holly_Rushmeier) Cc: globillum@miro.berkeley.edu Subject: Re: RP-16-1986, sect. 3 Date: Thu, 17 Sep 92 14:57:37 +0530 Status: RO Hello Dr Holly_Rushmeier, Thank you very much for your efforts in educating us with the proper terminology in illumination engineering. I've a few minor doubts in a one or two places of your notes on the sect. 3. Sorry if I've not understood it properly. Sincerely, --------- sumant pattanaik ------------------------------------------------------------------- Doubt I ------- ->(capital-Greek-phi)(subscript v) = ->K(subscript m) * integral over all wavelengths (Greek lambda) -> {(capital-Greek-phi)(subscript e, Greek lambda) * -> V(Greek lambda)} d (Greek-lambda) ->where -> (capital-Greek-phi)(subscript v) = lumens ->(capital-Greek-phi)(subscript e, Greek lambda) = watts per nanometer -> lambda = nanometers -> V(Greek lambda)= the spectral luminous efficiency -> K(subscript m) = the maximum spectral luminous -> efficiency in lm/W I am wondering if V(Greek lambda) is the relative spectral luminous efficiency. If it were not relative then K(subscript m) multiplier should not occur in the above equation. Doubt II -------- -> 3.10.4 Luminous efficacy of radiant flux. The quotient ->of the total luminous flux by the total radiant flux. It ->is expressed in lm/W. ->3.11 Luminous efficacy of a source of light. The quotient ->of the total luminous flux emitted by the total lamp power ->input. It is expressed in lm/W. I just want to make sure that the Luminous efficacy of a source of light has the input power in the denominator, not the output power. Further can efficacy and efficiency be used interchangeably ? -------------------------------------------------------------- From holly@cam.nist.gov Thu Sep 17 11:20:38 1992 Return-Path: Date: Thu, 17 Sep 92 13:50:16 -0400 From: holly@cam.nist.gov (Holly_Rushmeier) To: globillum@miro.berkeley.edu Subject: sumant's questions Status: RO hi sumant -- Thanks for taking the time to read things so carefully. In response to your points: ------------------------------------------------------------------- Doubt I ------- -->(capital-Greek-phi)(subscript v) = -->K(subscript m) * integral over all wavelengths (Greek lambda) --> {(capital-Greek-phi)(subscript e, Greek lambda) * --> V(Greek lambda)} d (Greek-lambda) -->where --> (capital-Greek-phi)(subscript v) = lumens -->(capital-Greek-phi)(subscript e, Greek lambda) = watts per nanometer --> lambda = nanometers --> V(Greek lambda)= the spectral luminous efficiency --> K(subscript m) = the maximum spectral luminous --> efficiency in lm/W --I am wondering if V(Greek lambda) is the relative spectral --luminous efficiency. If it were not relative then --K(subscript m) multiplier should not occur in the above --equation. I made a mistake typing the last line, it should read: K(subscript m) = the maximum spectral luminous efficacy in lm/W ^^^^^^^^ Doubt II -------- --> 3.10.4 Luminous efficacy of radiant flux. The quotient -->of the total luminous flux by the total radiant flux. It -->is expressed in lm/W. -->3.11 Luminous efficacy of a source of light. The quotient -->of the total luminous flux emitted by the total lamp power -->input. It is expressed in lm/W. --I just want to make sure that the Luminous efficacy of a --source of light has the input power in the denominator, not --the output power. Paragraph 3.11 does say that the denominator is the total lamp power INPUT. My interpretation of the significance of this is that it takes into account losses to convection and conduction (i.e. when you plug in a lamp its temperature is increased and some energy leaves the lamp by mechanisms other than radiation) as well as radiation outside of the visible band. (Please someone correct me if this is not the point of this definition .) --Further can efficacy and efficiency be used interchangeably ? My impression of the standard is that a differentiation is made between efficacy and efficiency. Efficacy measures how effectively light is produced from energy input in absolute terms, and therefore has units (lumens/watt) and is not limited in value to the range 0 to 1. Efficiency measures how effectively light is produced relative to a standard -- i.e., "efficiency" is inherently relative. Efficiency is dimensionless and is limited to the range 0 to 1. I did ask one of the people here who works in lighting research, and this apparently is the way the terms are commonly used these days. Just to confuse things however, there is a note in the standard just after paragraph 3.11 saying that the term luminous efficiency has been used extensively in the past for the concept defined in 3.11 as luminous efficacy. -------------------------------------------------------------- From holly@cam.nist.gov Fri Sep 18 07:55:43 1992 Return-Path: Date: Fri, 18 Sep 92 10:24:16 -0400 From: holly@cam.nist.gov (Holly_Rushmeier) To: globillum@miro.berkeley.edu Subject: RP-16-1986, Para. 7-3 Status: RO Continuation of -- Summary of applicable definitions from ANSI/IES RP-16-1986 "Nomenclature and Definitions for Illuminating Engineering" ______________ my comments __________________________________ On the subject of reflectance, the standard carefully differentiates between the term "reflectance" which is non-dimensional quantity ranging from zero to one and is denoted by a Greek rho, and the term "reflectance distribution function" which has units, of a sort (one over steradian), may take on any postive value, and which is denoted by f. Although I haven't used this terminology and notation myself in the past, after reading the standard, Pat Hanrahan's intro. to the Radiosity notes, and some recent Siggraph papers, I think it would be worthwhile to make these distinctions in the future. In particular I think that using an f in place of a rho for BRDF would make it easier for people to accept that it can take on values greater than one. ____________________ begin summary of standard _____________ 7.3.3 Reflectance, (Greek-rho) = (capital-Greek-phi)(subscript-r)/ (capital-Greek-phi)(subscript-i) (of a surface or medium). The ratio of the reflected flux to the incident flux. Reflectance is a function of: (1) Geometry: (a) of the incident flux; (b) of collection for the reflected flux. (2) Spectral distribution: (a) characteristic of the incident flux; (b) weighting function for the collected flux. (3) Polarization: (a) of the incident flux; (b) component defined for the collected flux. Notes: (i) Unless the state of polarization for the incident flux and the polarized component of the reflected flux are stated, it shall be considered that the incident flux is unpolarized and that the total reflected flux (including all polarizations) is evaluated. (ii) Spectral reflectance depends only on the beam geometry and the character of the reflecting surface (and on polarization). Luminous reflectance also is a function of the spectral distribution of the incident flux. (iii) If no qualifying geometric adjective is used, reflectance for hemispherical collection is meant... (iv) Certain of the reflectance terms are theoretically imperfect and are recognized only as practical concepts to be used when applicable Physical measurements of the incident and reflected flux are always biconical in nature. Directional reflectances... cannot exist since one component is finite while the other is infinitesimal; here the reflectance-distribution function (see Paragraph 7.3.3.17) is required. However, the concepts directional and hemispherical reflectances have practical application in instrumentation, measurements, and calculations when including the aspect of the nearly zero or nearly 2(Greek-pi) conical angle would increase complexity without appreciably affecting the immediate results. (v) In each case of conical incidence or collection, the solid angle is not restricted to a right cone, but may be of any cross section including rectangular, ring, or a combination of two or more solid angles. ... 7.3.3.1-7.3.3.10 (Definitions of Bihemispherical, Hemispherical-conical, hemispherical-directional, conical-hemispherical, biconical, conical-directional, directional-hemispherical, directional-conical, bidirectional and hemispherical reflectances. All of these are defined as the ratio of reflected to incident flux. Hemispherical refers to flux in all directions, conical refers to flux within a specified cone, and directional refers to a specific direction. For directional quantities, the incident flux is collimated, and for reflected flux the size of the solid angle of the collecting element must be specified). 7.3.3.11 Regular(specular) reflectance. The ratio of all the flux leaving a surface or medium by regular(specular) reflection to the incident flux. 7.3.3.12 Diffuse reflectance. The ratio of the flux leaving a surface or medium by diffuse reflection to the incident flux. ... 7.3.3.13 Spectral reflectance = (Greek-rho)(Greek-lambda) = (capital-Greek-phi) (subscript r Greek-lambda) / (capital-Greek-phi) (subscript i Greek-lambda). The ratio of the reflected flux to the incident flux at a particular wavelength Greek-lambda, or within a small band of wavelengths (capital-Greek-delta Greek-lambda) about Greek lambda. ... 7.3.3.17 Bidirectional reflectance-distribution function (BRDF), f(subscript r), The ratio of the differential luminance of a ray dL(subscript r)(Greek-theta subscript r, Greek-phi subscript r) reflected in a given direction (Greek-theta subscript r, Greek-phi subscript r) to the differential luminous flux density dE(subscript i)(Greek-theta subscript i, Greek-phi subscript i) incident from a given direction of incidence (Greek-theta subscript i, Greek-phi subscript i) that produces it ... Notes: (i) This distribution function is the basic parameter for describing (geometrically) the reflecting properties of an opaque surface element (negligible internal scattering). (ii) It may have any positive value and will approach infinity in the specular direction for ideally specular reflectors. (iii) The spectral and polarization aspects must be defined for complete specification, since the BRDF as given above only defines the geometric aspects. (7.3.3.18 defines the reflectance factor R -- this compares the reflected flux to the flux reflected by a perfect surface -- I don't think this is useful in our application). From sumant@saathi.ncst.ernet.in Mon Sep 21 01:03:43 1992 Return-Path: From: sumant@saathi.ncst.ernet.in To: globillum@miro.berkeley.edu Cc: holly@cam.nist.gov Subject: Re:Nomenclature and Definitions for Illuminating Engineering Date: Mon, 21 Sep 92 12:55:57 +0530 Status: RO Hello Dr Holly_Rushmeier, Thank U for clarifying my earlier doubts. A few more on the RP-16-1986, Para. 7-3. 1) ----> 7.3.3 Reflectance, ....... ----> ............. ----> If no qualifying geometric adjective is used, reflectance ----> for hemispherical collection is meant ^^^^^^^^^^^^^^^^^^^^^^^^ Is "hemispherical collection" for both incoming and outgoing directions? 2) ----> 7.3.3.17 Bidirectional reflectance-distribution function(BRDF),....... ----> ^^^^^^^^^^^^ The definition of BRDF ideally makes it a density function. I believe "Bidirectional reflectance-density function" makes appropriate expansion for BRDF and confirms to its usage in MonteCarlo sampling. (Note : In Monte Carlo sampling there is a distinction between density function,f(x), and distribution function,F(x), where f(x) = dF(x)/dx.) As U are discussing standard nomencetures and definitions I thought it will be appropriate to bring in this discussion here. I solicit comments from you and other globilluminators on this point. ------ sumant pattanaik From holly@cam.nist.gov Tue Sep 22 08:17:04 1992 Return-Path: Date: Tue, 22 Sep 92 10:38:58 -0400 From: holly@cam.nist.gov (Holly_Rushmeier) To: globillum@miro.berkeley.edu Subject: RP-16-1986, 7.4 & 7.5 Status: RO Continuation of -- Summary of applicable definitions from ANSI/IES RP-16-1986 "Nomenclature and Definitions for Illuminating Engineering" ______________ my comments __________________________________ This message wraps up the end of section 7, and covers transmission and absorption. The standard refers to the BSSRDF, which is defined in "Reference 20". Reference 20 is the NBS Monograph 160 by Nicodemus et al. cited in both the Radiosity and Global Illumination course notes at Siggraph. I'll explain how to order 160 in a subsequent mail message. I think the treatment of terminology in a participating medium is inadequate. First, I think the coefficients should be defined in terms of radiance, not flux. Second, I think that the attenuation coefficient should be defined as the sum of an absorption coefficient and a scattering coefficient -- recognizing that the quantity of energy travelling along a path can be reduced either by absorption or out-scatter. In response to Sumant's comments, I believe "collection" implies outgoing directions. For example, if a "directional reflectance" were reported, it should be inferred that it is the flux reflected in all directions leaving the surface divided by the flux incident from a particular direction. Also in Sumant's comments, someone has finally suggested that we should adopt a term that differs from the standard. In general I think we can/should be deviate from the standard in some instances, since computer graphics and illumination engineering are not identical fields. Is anyone going to respond to Sumant's suggestion, either specifically or in general? ____________________ begin summary of standard _____________ 7.4 Transmission. A general term for the process by which incident flux leaves a surface or medium on a side other that (sic) the incident side, without change in frequency. Note: Transmission through a medium is often a combination of regular and diffuse transmission. ... 7.4.1 Regular transmission. That process by which incident flux passes through a surface or medium without scattering. 7.4.2 Diffuse transmission. That process by which the incident flux passing through a surface or medium is scattered. 7.4.3 Transmittance, (Greek-tau) = (capital-Greek-phi)(subscript-t)/ (capital-Greek-phi)(subscript-i) (of a medium). The ratio of the transmitted flux to the incident flux. It should be noted that transmittance refers to the ratio of flux emerging to flux incident; therefore, refections at the surface as well as absorption within the material operate to reduce the transmittance. Transmittance is a function of: (1) Geometry: (a) of the incident flux; (b) of collection for the transmitted flux. (2) Spectral distribution: (a) characteristic of the incident flux; (b) weighting function for the collected flux. (3) Polarization: (a) of the incident flux; (b) component defined for the collected flux. Notes: ((i)-(iv) and (vi) basically the same notes as for reflectance) (v) These concepts must be applied with care, if the area of the transmitting element is not large compared to its thickness, due to internal transmission across the boundary of the area. ... (vii) The following breakdown of transmittance quantities is applicable only to the transmittance of thin films with negligible internal scattering so that the transmitted radiation emerges from a point that is not significantly separated from the point of incidence of the incident ray that produces the transmitted ray(s). The governing considerations are similar to those for application for the bidirectional reflectance-distribution function (BRDF), rather than the bidirectional scattering-surface reflectance-distribution function (BSSRDF), as discussed in Reference 20. ... 7.4.3.1-7.4.3.9 and 7.4.3.11 (Definitions of Bihemispherical, Hemispherical-conical, hemispherical-directional, conical-hemispherical, biconical, conical-directional, directional-hemispherical, directional-conical, bidirectional and hemispherical transmittances. All of these are defined as the ratio of transmitted to incident flux. Hemispherical refers to flux in all directions, conical refers to flux within a specified cone, and directional refers to a specific direction. For directional quantities, the incident flux is collimated, and for reflected flux the size of the solid angle of the collecting element must be specified. 7.4.3.10 defines a luminous transmittance as any of the other transmittances with the transmitted and incident fluxes weighted by the luminous efficiency V(Greek-lambda).) 7.4.3.12 Regular transmittance. The ratio of the regularly transmitted flux leaving a surface or medium to the incident flux. 7.4.3.13 Diffuse transmittance. The ratio of the diffusely transmitted flux leaving a surface or medium to the incident flux. ... 7.4.3.14 Spectral transmittance = (Greek-tau)(Greek-lambda) = (capital-Greek-phi) (subscript t Greek-lambda) / (capital-Greek-phi) (subscript i Greek-lambda). The ratio of the transmitted flux to the incident flux at a particular wavelength Greek-lambda, or within a small band of wavelengths (capital-Greek-delta Greek-lambda) about Greek lambda. ... 7.4.3.15 Filter. A device for changing, by transmission or reflection, the magnitude and/or the spectral composition of the flux incident on it. Filters are called selective (or colored) or neutral, according to whether or not they alter the spectral distribution of the incident flux. 7.4.3.16 Bidirectional transmittance-distribution function (BTDF), f(subscript t), The ratio of the differential luminance of a ray dL(subscript t)(Greek-theta subscript t, Greek-phi subscript t) transmitted in a given direction (Greek-theta subscript t, Greek-phi subscript t) to the differential luminous flux density dE(subscript i)(Greek-theta subscript i, Greek-phi subscript i) incident from a given direction of incidence (Greek-theta subscript i, Greek-phi subscript i) that produces it ... Notes: (i) This distribution function is the basic parameter for describing (geometrically) the transmitting properties of a thin scattering film (with negligible internal scattering) so that the transmitted radiation emerges from a point that is not significant separated from the point of incidence of the incident ray(s). The governing considerations are similar to those for application of the bidirectional reflectance-distribution function (BRDF), rather than the ... BSSRDF... (ii) It may have any positive value and will approach infinity in the direction for regular transmission (possibly by refraction without scattering). (iii) The spectral and polarization aspects must be defined for complete specification, since the BTDF as given above only defines the geometric aspects. 7.5 Absorption. A general term for the process by which incident flux is converted to another form of energy, usually and ultimately to heat. Note: All of the incident flux accounted for by the process of reflection, transmission and absorption. 7.5.1 Absorptance (Greek-small-alpha) = (capital-Greek-phi) (subscript a) / (capital-Greek-phi) (subscript i). The ratio of the absorbed flux to the incident flux. Note: The sum of the hemispherical reflectance, the hemispherical transmittance, and the absorptance is one. 7.5.2 Coefficient of attenuation (at a point in a given direction), (Greek-mu). The decrement in flux per unit distance in a given direction within a medium. It is defined by the relation (capital-Greek-phi)(subscript x) = (capital-Greek-phi)(subscript o) e (raised to the minus Greek-mu*x power), where (capital-Greek-phi)(subscript x) is the flux at any distance x from a reference point having flux (capital-Greek-phi)(subscript o). More generally, (capital-Greek-phi)(subscript x) = (capital-Greek-phi)(subscript o) exp [- the integral from o to x Greek-mu(x) dx] where the coefficient varies from point to point; Greek-mu = Greek-mu(x) along the path.) ... From holly@cam.nist.gov Tue Sep 22 08:31:54 1992 Return-Path: Date: Tue, 22 Sep 92 11:02:09 -0400 From: holly@cam.nist.gov (Holly_Rushmeier) To: globillum@miro.berkeley.edu Subject: NBS 160, etc. Status: RO Since a number of people have asked me about it, here is the info. on ordering NBS Monograph 160 , "Geometrical Considerations and Nomenclature for Reflectance," by F.E. Nicodemus et al. NBS 160 can be ordered from the National Technical Information Service (NTIS). Besides citing the above NBS/NIST designation, you will need an order number, which is this case is PB273651. Orders should be sent to NTIS, Springfield,VA 22161. NTIS will accept American Express, check, money order, VISA, or Mastercharge. For information call, (703) 487-4650, orders can be placed at (800) 336-4700, and you can fax the NTIS at (703) 321-8547. In this case the cost for the publication is $19, plus $3 handling. All NBS/NIST publications are available at depository libraries for government publications. For those of you in the US, your local library should be able to identify the closest depository library (for example I think the Georgia Tech lib. is a depository lib.). ------------------ In general, for NBS/NIST publications, begin by calling NIST Publications and Program Inquiries at (301)975-3058. They will tell you whether you get the document from the Government Printing Office (GPO), NTIS or for old stuff, by photocopy from the Library of Congress. They will also give you the required order number. ------------------- BTW, F.E. Nicodemus no longer works here in Gaithersburg. Someone told me he now lives in Los Altos, CA. _________________________________ This doesn't have to deal with the standard directly, but there have been a couple of recent articles in the Journal of Illumination Engineering Society that some of you may be interested in: R.M.N. Saraijii and R.G. Mistrick, "Calculation Methods, Error Tendencies, and Guidelines for Finite Element Flux Transfer" Winter 1992 (Vol. 21, No.1) pp. 92-102. -- discusses errors in various types of form factor calculations -- D.L. DiLaura "On the Development of a Recursive Method for the Solution of Radiative Transfer Problems," Summer 1992, pp. 108-112. -- discusses avoiding discretization for finite element (radiosity-type) methods by representing spatially varying exitances (radiosity) as complex finite Fourier series, the method is limited to surfaces which are all either parallel or perpendicular to one another -- ____________________________________ -- Holly (ps -- Is anybody at Cornell getting this? -- I keep getting bounced mail from there). From holly@cam.nist.gov Thu Sep 24 06:44:34 1992 Return-Path: Date: Thu, 24 Sep 92 09:06:35 -0400 From: holly@cam.nist.gov (Holly_Rushmeier) To: globillum@miro.berkeley.edu Subject: RP-16-1986 , sect. 9 Status: RO Continuation of -- Summary of applicable definitions from ANSI/IES RP-16-1986 "Nomenclature and Definitions for Illuminating Engineering" ______________ my comments __________________________________ Section 8 deals with Testing Procedures, and has definitions about devices to make physical measurements such as photometer, reflectometer, and light meter. I don't think any of these relate directly to image synthesis. Section 9 deals with Lighting Calculations. It would be nice to have some short, well defined terms to refer to calculation methods to save the space listing all sorts of equations, references and/or pseudocode. It would seem that using illumination engineering terminology would help along these lines. Section 9 does have some useful terms, but a lot of it doesn't apply to image synthesis. This is because the most common methods used in illumination engineering are based on calculating a single number for a simplified description of an environment to use as a measure of the effectiveness of the design. Besides not making calculations at the level of spatial detail required in image synthesis, most of the methods are geared to very minimal computing resource (e.g. like a slide rule and a pencil). This is partly for historical reasons, and partly because most people doing lighting design have extremely small computing budgets. Anyway, in the standard there are definitions of a zonal factor method and a zonal-cavity interreflectance method, in which the zones are solid conic angles from the light source. These methods are different from the zonal method from heat transfer for calculating transfer in a participating medium, and the zones are volumes of the medium. The zonal-cavity method (illumination engr.) isn't applicable to image synthesis, but the zonal method (a.k.a. zone method, zoning method) is, so I would use the heat transfer interpretation of zone in this case. Also, what many of us would call radiosity methods are referred to as flux transfer theory. I don't think switching to this term would clarify anything. On the other hand, the standard differentiates between a form factor (between two finite surfaces) and a configuration factor (between a differential and a finite surface). I think this terminology would be useful. One other note -- another place to find NBS 160 is in the "Radiometry" volume of the new three volume set "Physics-Based Vision", by Wolff,Shafer & Healy (Jones & Bartlett pubs.) Check if your library has or is getting this series. ------------------- begin summary -------------------------- 9.1 Laws of illumination 9.1.1 Inverse-square law. A law stating that the illuminance E at a point on a surface varies directly with the intensity I of a point source, and inversely as the square of the distance d between the source and the point. If the surface at the point is normal to the direction of the incident light, the law is express (sic) by E = I/d**2. Note: For sources of finite size having uniform illuminance this gives results that are accurate within one percent when d is at least five times the maximum dimension of the source as viewed from the point on the surface. Even though practical interior luminaires do not have uniform luminance, this distance d is frequently used as the minimum for photometry of such luminaires, when the magnitude of the measurement error is not critical. 9.1.1.1 Point source. A source of radiation whose dimensions are sufficiently samll, compared with the distance between the source and the irradiated surface, that these dimensions can be neglected in calculations and measurements. 9.1.2 Cosine law. A law stating that the illuminance on any surface varies as the cosine of the angle of incidence. The angle of incidence (Greek theta) is the angle between the normal to the surface and the direction of the incident light. The inverse-square law and the cosine law can be combined as E =(I cos(Greek theta))/d**2 .... 9.5 Light distribution 9.5.1 Direct component. That portion of the light from a luminaire that arrives at the work-plane without being reflected by room surfaces. .... 9.5.4 Indirect component. That portion of the luminous flux from a luminaire that arrives at the work-plane after being reflected by room surfaces. ... 9.5.7 Interflection (Also called interreflection.) The multiple reflection of light by the various room surfaces before it reaches the work-plane or other specified surface of a room. 9.5.7.1 Interflected component. (Also called interreflectance.) That portion of the luminous flux from a luminaire that arrives at the work-plane after being reflected one or more times from room surfaces, as determined by the flux transfer theory (Paragraph 9.5.7.2). 9.5.7.2 Flux transfer theory. A method of calculating the illuminance in a room by taking into account the interreflection of the light flux from the room surfaces based on the average flux transfer between surfaces. 9.5.7.3 Form factor, f(subscript 1-2). The ratio of the flux directly received by surface 2 (and due to lambertian surface 1) to the total flux emitted by surface1. It is used in flux transfer theory. f(subscript 1-2) = (capital-Greek-phi)(subscript 1->2)/ (capital-Greek-phi)(subscript 1) Also the ratio of the average illuminace on surface 1 to the causative exitance of lambertian surface 2. f(subscript 1-2) = E(subscript 1)/M(subscript 2) Note: In the literature this term is also called angle factor, configuration factor, geometrical factor, I-factor, illumination factor and shape modulus. 9.5.7.4 Configuration factor, c(subscript 1->2). The ratio of illuminance on a surface at point 1 (due to the flux directly received from lambertian surface 2) to the exitance of surface 2. It is used in flux transfer theory. C(subscript 1-2) = E(subscript 1)/M(subscript 2) Also the ratio of the differential flux directly received by surface 2 (and due to element 1) to the total differential flux emitted by differential lambertian surface element 1. C(subscript 1-2) = d(capital-Greek-phi)(subscript 1->2)/ d(capital-Greek-phi)(subscript 1) Note: In the literature this term is also called angle factor, illumination factor, point configuration factor and sky factor. 9.5.7.5 Wrong way "law". An informal recognition in the equations E(subscript 2) = c(subscript 2-1) M(subscript 1) and E(subscript 2) = f(subscript 2-1) M(subscript 1) that the configuration factor and form factor flux transfer is opposite to the actual cause-effect flux transfer as indicate by the subscripts. From holly@cam.nist.gov Fri Sep 25 08:57:03 1992 Return-Path: Date: Fri, 25 Sep 92 10:18:40 -0400 From: holly@cam.nist.gov (Holly_Rushmeier) To: globillum@miro.berkeley.edu Subject: RP-16-1986 -- the final chapter Status: RO Conclusion of -- Summary of applicable definitions from ANSI/IES RP-16-1986 "Nomenclature and Definitions for Illuminating Engineering" The remaining sections of RP-16-1986, 10. "Interior Lighting Applications", 11. "Exterior Light Applications" and 12. "Nonlighting Applications" contain a lot of interesting information, but, as I read it, no definitions that apply to image synthesis. Section 13 contains several useful tables , such as conversion factors and numerical values for the luminous efficiency function. At the end of the document there is also a list of useful references on vision and lighting. I have put together a 3 page Latex document with the snappy title "Suggested Units, Symbols, and Defining Equations for Computer Graphics Global Illumination Based on ANSI/IES RP-16-1986." I can send the document, or the PostScript version of it to anyone who would like to see the actual Greek characters. (I'm no expert with Latex, but the output looks ok. Thanks to Filippo Tampieri for sending me a template to get started). Finally, I would like to emphasize that NONE of my mail messages are in any way official, and only represent my own personal opinions. Only the IES can issue official interpretations of RP-16-1986. My purpose in posting all of this is to provide suggested notation and terminology to improve communication in our area. I am NOT proposing that when papers are reviewed that they should be judged by conformance to this terminology -- any terminology that is clearly defined and used consistently within a paper is legitimate. -- Holly From greg Fri Sep 25 10:46:07 1992 Return-Path: Date: Fri, 25 Sep 92 10:45:55 PDT From: greg (Gregory J. Ward) To: globillum@miro.berkeley.edu, holly@cam.nist.gov Subject: Re: RP-16-1986, sect. 3 Status: R I just wanted to add my 2 cents to the discussion of luminous efficacy. (Sumant brought up the question of its relation to efficiency -- sorry to backtrack like this.) Luminous efficacy is defined in terms of lumens per watt. Holly correctly pointed out that this number includes losses due to inefficiencies in the lamp or fixture or whatever, but there is something else that needs to be pointed out. Namely, the lumen is defined in terms of *human visual response*. That is to say, the lumen is tied to physical units by the visual response curve, V(lambda), and thus efficacy does not address so much the ability of a lamp to turn electric energy into radiation, but its ability to turn electric energy into VISIBLE light. In fact, if we were to judge a lamp solely on its ability to turn electricity into radiation, the incandescent bulb would be considered one of the best, as it gives off most of its energy in the near to far infrared band, and loses a relatively small amount to convection and condunction. Unfortunately, most of us don't see light in the infrared, so it doesn't do us a whole lot of good (unless of course our goal is to stay warm). The maximum theoretically possible luminous efficacy for any source is (by definition) 683 lumens/watt. If a lamp were 100% efficient at turning input power into light at the peak of the V(lambda) spectral sensitivity curve (ie. 555 nanometers), then it would have this efficacy. Note, however, that the light coming off such a lamp would be an eerie yellow-green color, which would not make for good dining ambiance. This brings up another point, which is that efficacy is not the only goal for a lamp manufacturer. If the efficacy is achieved by putting too much of the light energy into the middle of the visible spectrum at the expense of taking too much away from the red and blue ends, the resulting illumination will result in poor color rendering. It won't be possible to tell one color from another, simply because the light needed to show off the reds and blues will be missing in the first place! Low pressure sodium lamps and, to some extent, high pressure sodium lamps (both popular in modern street lighting applications) have this high efficacy, low color rendering characteristic. (Perhaps our courts should employ such lighting...) An ideal source that distributed its light evenly over the visible spectrum and wasted nothing would have an efficacy of around 180 lumens/watt. The best commercial fluorescent lighting systems currently produce about 90 lumens/watt. In some sense, this means we are at about 50% efficiency in doing what we want to do. It's interesting to note that the luminous efficacy of solar radiation is also about 90 lumens/watt. In this case, the power in the denominator is not input power but energy content. That is to say, we could allow 90 lumens of sunlight into our space and we would have an associated solar heat gain of 1 watt. If we were running an air conditioner in our building, this watt would have to be removed by our HVAC system at some cost. This cost would be comparable to the cost of removing the heat from a high-efficiency fluorescent system, but at least we didn't have to pay for the watt to produce the 90 lumens in the first place. The luminous efficacy of skylight radiation is better still at about 120 lumens/watt, and if the infrared component of sunlight is filtered out using selective glazing, the efficacy of sunlight can also be improved to around 130 lumens/watt. This helps make the case for using daylight instead of electric light in interior spaces dominated by cooling (like LA!). Well, I think I've used up more than 2 cents of your time, so I'm off. -Greg From Ken_Turkowski@gateway.qm.apple.com Thu Oct 15 01:12:45 1992 Return-Path: Date: 15 Oct 1992 00:47:50 -0800 From: "Ken Turkowski" Subject: Re: standards To: "Holly Rushmeier" Cc: "Global Illumination" Status: R Reply to: RE>standards Thanks, Holly, I got a copy of ANSI/IES RP-16-1986. I applaud your effort in advancing standards in global illumination. As you might remember from previous e-mails back in June, I have been trying to develop an object oriented representation of light sources and optical properties of materials that can be used in both traditional and global illumination rendering. Hall's book presents physically-based reflection models that can be used to generate parameters familiar to those used in traditional rendering. The more difficult task is to provide instance variables and virtual functions that make sense for all subclasses of a Light base class. Soon, I hope to throw out some ideas about generalized lights. Keep me (get me) on the distribution list, Ken Turkowski (turk@apple.com) From bobl@cs.ubc.ca Thu Oct 15 14:46:40 1992 Return-Path: Date: Thu, 15 Oct 92 14:46:38 -0700 From: bobl@cs.ubc.ca To: greg@hobbes.lbl.gov Subject: "globillum" mailing list Status: RO I understand there's a "globillum" mailing list for global illumination cognoscenti. Is it possible to sign up? If so, how? Thanks muchly. - Bob Lewis bobl@cs.ubc.ca From holly@cam.nist.gov Wed Oct 28 12:25:14 1992 Return-Path: Date: Wed, 28 Oct 92 14:58:58 -0500 From: holly@cam.nist.gov (Holly_Rushmeier) To: globillum@miro.berkeley.edu Subject: An Experiment Status: R Hi Globillumers-- Besides terminology, another subject we have discussed here is the possibility of establishing some reference solutions for use in testing etc. Since it will be a while before we can agree on the "ultimate" method for calculating an image, I thought perhaps we could try the consensus route to establishing reference solutions. The idea is we could develop a suite of test images by taking turns specifying the input and format of the image. Below I have written out a simple, first test case. It is basically the empty,diffuse,gray test case that Greg posted radiosity values for on hobbes.lbl.gov. I have tried to structure the description so that the only variable is how you choose to calculate the radiance at each pixel. Here is what I propose: 1. Using this description, generate an image. Submit it by Dec. 1, 1992 by placing it by anonymous ftp on tiber.nist.gov (129.6.2.23) into the directory pub/holly. Be sure that the permissions on the file are set so that it is universally readable. Also, send me email that you have placed an image there so I will be sure to pick it up. 2. I will collect the results and compute an average image, and a standard deviation image (i.e. for each pixel I will compute the average value from all respondents, and the sample standard deviation in values from all respondents). I will also compute other statistics that the group feels would be relevant. 3. The combined results will be made available to everyone via anonymous ftp. 4. Someone else defines another (probably more challenging) test case and collects the results. I am putting this message, along with a sample image I computed in pub/holly. The sample image is in the simple format describe below, as well as a few other popular formats. ============================================================== =============== Begin Test Case Description ================== ============================================================== Geometry and Properties +++++++++++++++++++++++ The geometry is an empty rectangular room extending from (0,0,0) to (10,3,6). The sole light source is in the center of the ceiling, at y = 3.0. The light source is square and 0.5 units per side. All surfaces are Lambertian. Here is an off-style file definition of the geometry. There are 12 points and 7 polygons. The x,y,z values of each of the points are listed first. Each polygon is defined by number of vertices (4 in this case for all polygons) and the indices of those vertices. That is, the first polygon is defined by the points (0,3,0),(10,3,0),(10,0,0) and (0,0,0). I have defined the light source slightly below the ceiling -- if you can, the ceiling should have a hole in it so the light source can be perfectly flush at y = 3.0. The first four polygons are the walls, and they are 50 % reflective. The fifth polygon is the ceiling, which is 70 % reflective. The sixth is the floor which is 30 % reflective. The seventh is the light source, for which the emitted radiance is 10 w/m^2-steradian, and which is 0% reflective. _______________________________________________________________ 12 7 0.00 0.00 0.00 10.00 0.00 0.00 10.00 3.00 0.00 0.00 3.00 0.00 0.00 0.00 6.00 0.00 3.00 6.00 10.00 3.00 6.00 10.00 0.00 6.00 4.75 2.99 2.75 5.25 2.99 2.75 5.25 2.99 3.25 4.75 2.99 3.25 4 3 2 1 0 /* rho = 0.5 */ 4 4 5 3 0 /* rho = 0.5 */ 4 7 6 5 4 /* rho = 0.5 */ 4 1 2 6 7 /* rho = 0.5 */ 4 3 5 6 2 /* rho = 0.7 */ 4 1 7 4 0 /* rho = 0.3 */ 4 11 10 9 8 /* rho = 0., emitted radiance = 10 w/m^2-steradian */ Generating an Image +++++++++++++++++++ View from: (9., 1.75, 1.) View to: (1., 1.75, 6.) i.e.unnormalized vector indicating view direction is (-8, 0,5) "Up" direction: (0,1,0) Field of view: 45 degrees Image resolution: 50 x 50 pixels. Sample the center of the pixel only (i.e. no sampling at various locations in the pixel and filtering for antialiasing). Scaling of radiances: Use simple linear scaling of radiances to the range 0-255 by multiplying by 8000 and clipping values above 255. The value 8000 assumes you use 10 for the light source radiance, and was chosen to have the approximate average radiance value map to 128. (i.e., if you for some reason always set your light source value to 1, you would multiply all of the values by 80000, etc.) Do not include any gamma correction in the mapping to 0-255. Output format: binary file, one byte/pixel for a total of 50x50 bytes. Start with lower left hand corner, write results row by row, with the last value being the upper right hand corner.If writing things out in this format seriously holds up your entry, please send in what you can, and give me a description of the format. NOTE: If you compare radiance values you compute to the data in the directory on hobbes.lbl.gov remember that file has results for radiosities which are PI times the radiance for a Lambertian surface. From holly@cam.nist.gov Mon Nov 2 11:06:01 1992 Return-Path: Date: Mon, 2 Nov 92 12:03:55 -0500 From: holly@cam.nist.gov (Holly_Rushmeier) To: globillum@miro.berkeley.edu Subject: notes on experiment Status: RO Hi -- Just a few notes to encourage you all to submit your version of the test image: -- If you are concerned about getting credit for submitting an image, I will include you on a list of contributors that accompanies the results. -- If on the other hand you are concerned about anonymity, I will keep your name off of any publicly accessible files. -- The original "samp" files I posted were somewhat noisy. I computed a higher quality solution that is now available as pub/holly/hollysentry.simple_format. -- There is one other entry besides mine, and they aren't exactly the same, so we definitely need more entries. -- Timing is not an issue -- both of the entries so far took cpu days to compute. -- If you can compute an image, but aren't confident in the results, send it in anyway. I will put it in a separate category to be used to get an idea of the range of values computed by different methods. If there is some aspect of the scene/image description that is making it difficult for you to generate an image, please let me know. Also, assuming there are more entries, what sort of statistics would people be interested in to summarize the results? -- Holly From erich@eye.com Tue Nov 17 15:10:18 1992 Return-Path: Date: Tue, 17 Nov 92 15:55:28 -0500 From: Eric Haines To: globillum@miro.berkeley.edu Subject: radiosity cows and triceratops Status: RO I am just about ready to release the updated global illumination and ray tracing research article/book bibliographies. If you have found any obscure papers in the past year that deal with these subjects, please let me know the full reference and any relevant keywords. I have all this year's SIGGRAPH, Eurographics rendering workshop, Graphics Interface and CGI papers, and will be getting the Eurographics proceedings papers soon. If there are other conference papers worth including, please let me know - I don't track the engineering or computational geometry oriented conferences so am undoubtedly missing a few references at this point. I can send you the latest bibs if you need them right now; otherwise wait a few weeks until the new ones are out. Incidentally, if you've ever wanted to do radiosity studies on cows (after all, there's a form factor equation for a cow), you may wish to FTP to: avalon.chinalake.navy.mil [129.131.31.11] There are some high-quality models in /pub/objects/obj/Viewpoint in Wavefront format, including a bust of Beethoven, a tommy gun, an ornate lamppost, a bunch of cars, a triceratops, a tennis shoe, some foot bones, and of course a cow. Also, I made a budget awk converter for obj2nff, it's in the converters file area there (be nice: don't download during 7am-6pm PST). Enjoy, Eric Haines, erich@eye.com From holly@cam.nist.gov Tue Nov 17 16:18:24 1992 Return-Path: Date: Tue, 17 Nov 92 16:53:52 -0500 From: holly@cam.nist.gov (Holly_Rushmeier) To: globillum@miro.berkeley.edu Subject: consensus image Status: RO So far I have three (3) entries for the test image I proposed. I am hoping there will be a flood of data coming in during the next two weeks. Remember, the address for anonymous ftp to leave off your results, and/or pick up the problem description and sample images is 129.6.2.23 (tiber.nist.gov), directory pub/holly. -- Holly From salesin@cs.washington.edu Sun Nov 22 16:02:43 1992 Date: Sun, 22 Nov 92 15:47:16 -0800 From: salesin@cs.washington.edu (David Salesin) Return-Path: To: globillum@miro.berkeley.edu Subject: Global illumination -- what for? Cc: derose@cs.washington.edu, per@cs.washington.edu Status: R Globillumers, I am giving a talk on global illumination algorithms to my department on Tuesday, and one question comes to mind that I am not sure I could answer adequately if asked. The question is this: Suppose we could completely solve the global illumination problem; that is, suppose we had an algorithm that gave perfectly accurate solutions with tight error bounds, did perfect discontinuity meshing and reconstruction, handled arbitrary BRDFs, and was really, really fast. What good would it be? Who would really use it? Certainly, lighting designers and architects could use such a thing, but could anyone else benefit? How "important" a problem is global illumination, anyway? Other than intellectual curiosity, are there any really good reasons for studying it? Thanks, I look forward to getting your input... David From fournier@cs.ubc.ca Sun Nov 22 22:27:31 1992 Return-Path: Date: 22 Nov 92 22:07 -0800 From: Alain Fournier To: Cc: , , Subject: Global illumination -- what for? Status: R If you are interested in the "seamless" merging of real images and computer-generated images (which I call CAR for computer augmented reality), then an accurate solution for global illumination is essential. Of course that only begs the next question: what is CAR for? I'll let you answer this one... From holly@cam.nist.gov Mon Nov 23 06:49:57 1992 Return-Path: Date: Mon, 23 Nov 92 09:14:53 -0500 From: holly@cam.nist.gov (Holly_Rushmeier) To: globillum@miro.berkeley.edu Subject: Re:Global illumination -- what for? Status: R Re: Who would really use an accurate global illumination solution? Well, here's my two cents: -- People that need to take visibility into account for safety reasons -- e.g. determining the visibility of exit signs through smoke, visibility of road signs in rain and fog, visibility of radio towers through smog, visibility of buoys in the water (a great Pacific NW application. Some people here at NIST did a study on this one and wanted to use simulations, but in the absence of any good software tools had to limit themselves with what they could do with photography and rowing around a lake). The physical experiments for these applications are tough, because you need a range of subjects with various types of vision, and then you have to wait around for the full range of extreme weather conditions you are interested in. -- Designer's for whom appearance under many lighting conditions is important, e.g. the Siggraph paper from the people at Toyota about predicting the appearance of cars under different weather conditions. I think the most important applications for precise radiative transfer solutions involve non-human sensors, i.e. the interpretation of satellite images, the design of machine vision systems, and design of various weapons systems. Chris Borel (LANL) and N. Goel (SUNY Bing.) are both on this list, and both have done work simulating what plants will look like under various lighting conditions from satellites. Steve Shafer at CMU has been working for quite awhile in the area of using at least some aspects of global illumination solutions for machine vision. At Georgia Tech we have been working on getting simulations that are good enough that they could be incorporating in a CAD system, so that you could test how difficult it would be to assemble a group of parts while they were still in the design phase. And, of course people have been doing radiosity type solutions for a long time to test models of missile sensors. (I'm sure Boeing does some of this.) In all of these applications you can get some data from physical experiments. But, the experiments can be expensive and difficult to control. Accurate simulations let you examine a much wider range of conditions. Furthermore, images that just "look good" are worthless for non-human sensors, since they just operate on the incident electromagnetic radiation, and don't do the sophisticated processing that the human visual system does. Then there are applications that are more speculative or open to question. If we are going to use "virtual reality" systems to train people by putting them into the actual environment they are going to be working in, how accurate does the rendering system have to be? It would seem like some applications -- like training to perform operations in outer space -- would require very accurate illumination. -- Holly From levoy@blueridge.berkeley.edu Mon Nov 23 09:14:23 1992 Return-Path: Date: Mon, 23 Nov 92 08:43:47 -0800 From: levoy@blueridge.stanford.edu (Marc Levoy) To: salesin@cs.washington.edu Cc: globillum@miro.berkeley.edu, derose@cs.washington.edu, per@cs.washington.edu Subject: Global illumination -- what for? Status: R Recall that global illumination is a special case of radiative heat transfer. An efficient, accurate solution to the first would undoubtedly have implications for the second. If participating media are included, I know of potential applications to global climate modeling and radiation dose calculations for cancer treatment. There are of course many others. From alan@cs.bris.ac.uk Mon Nov 30 13:32:44 1992 Return-Path: Via: uk.ac.bristol.compsci; Mon, 30 Nov 1992 16:52:04 +0000 Date: Mon, 30 Nov 92 16:51:50 GMT From: Alan Chalmers To: globillum@miro.berkeley.edu Subject: Interactive radiosity Status: R Dear all I am trying to get together information regarding any INTERACTIVE systems which use either radiosity and/or raytracing for building walkthroughs or interior building design. I'll summarize any info for the net. Many thanks Alan Chalmers From holly@cam.nist.gov Wed Dec 2 12:34:58 1992 Return-Path: Date: Wed, 2 Dec 92 14:58:03 -0500 From: holly@cam.nist.gov (Holly_Rushmeier) To: globillum@miro.berkeley.edu Subject: Results Status: R Hi Globillumers -- Well, here are the results for the reference image experiment. The bad news is that there were not a large number of participants. The good news is that we got remarkable agreement on the resulting image using four distinctively different approaches. The four entries were from -- Raphael Compagnon (COMPAGNON@eldp.epfl.ch) using SUPERLITE to calculate radiances, and "Radiance" to find the visible surface at each pixel Chris Christou (cgc@physiology.oxford.ac.uk) using a radiosity solution to get a radiosity for each surface, ray-tracing to find surface visible through each pixel and then gathering the radiosity result to calculate the pixel value me using my own Monte Carlo path tracing program Greg Ward (greg@hobbes.lbl.gov) using "Radiance" Let R = (max value - min value) reported for each pixel, R = 0 for 607 pixels = 1 for 1425 pixels = 2 for 341 pixels = 3 for 79 pixels = 4 for 20 pixels = 5 for 8 pixels = 6 for 4 pixels = 7 for 4 pixels = 8 for 7 pixels = 9 for 2 pixels = 12 for 2 pixels = 14 for 1 pixel Under pub/holly on tiber.nist.gov, I have posted an image fin_res in a number of different formats. The red channel in fin_res is the minimum value reported at each pixel, the green is the average value, ane the blue is the maximum value. Since tiber isn't meant to be an archive -- it's supposed to be used for transferring data via anonymous ftp to people outside of NIST -- I can only plan on leaving the results there for about a month. -- Holly From @cornellc.cit.cornell.edu:fxt@graphics Wed Dec 2 13:08:06 1992 Return-Path: <@cornellc.cit.cornell.edu:fxt@graphics> From: Filippo Tampieri Subject: describing physical light sources To: globillum@miro.berkeley.edu Date: Mon, 30 Nov 92 17:08:33 EST Mailer: Elm [revision: 70.30] Status: RO Hi everyone, I am trying to find out what standards are used to describe commercial light sources and their spectral and directional distributions. I noticed that the radiance software reads an IES format, but could not find specs for it. Are there any widely available publications that describe this format? I would be very grateful if anyone could point me the some references or could provide any useful information. Thank you, Filippo Tampieri fxt@graphics.cornell.edu Program of Computer Graphics Cornell University From marini@imiucca.csi.unimi.it Thu Dec 3 02:55:03 1992 Date: Thu, 3 Dec 92 11:18:48 +0100 From: D. Marini (DSI) Return-Path: To: fxt@graphics.csi.unimi.it, globillum@miro.berkeley.edu Subject: Re: Describing real light sources Status: R Ciao Filippo come stai? Vedo che stai continuando a occuparti di fotorealismo. Anche noi siamno su questa strada. Abbiamo acsquisito un po' di dati da dicoumocumnenti tecnici di produttori di lampade (Targettim, Philips etc.) ma sono molto approssimati. Abbiamo messo a punto un primo metodo per simulare la distrubiwion e spaziale, e stiamo provando a d applicare a un caso reale con misure fotometiche friche in collaborawione con architetturqa.a>. Non conosco file con dati, ma le pubblicawinoi dei produttori contengono molti parapmetri. Che fai di bello? teniamoici in contatto,m  , visto anche il comune interesse scientifico. Presoto diti faro avere un draft di un nuovo metodio di ray casting che stiamo pvorovando e che puo andare verso un reay castingi interattivvo per modella modellazione CSG. Saluti ed auguri Daniele P.S. I realize at the end of my reply that it ziwill be broadcasted to globillum, I apologize for using italian, just to stay in contact with an old friend. . From @mail-a.bcc.ac.uk:plewis@ps.ucl.ac.uk Thu Dec 3 08:50:40 1992 Return-Path: <@mail-a.bcc.ac.uk:plewis@ps.ucl.ac.uk> Via: uk.ac.bcc.mail-a; Thu, 3 Dec 1992 15:34:45 +0000 To: globillum@miro.berkeley.edu Cc: plewis@ps.ucl.ac.uk, mikeb@uk.ac.ucl.geography Subject: Re: Global illumination -- what for? Date: Thu, 03 Dec 92 15:25:01 +0000 From: Lewis Source-Info: amalthea.ps.ucl.ac.uk Status: R (i) firstly, could the postie for the group please sign me onto globillum (I've been meaning to get round to this for a while but...) - I've been getting some globillum stuff forwarded by anewton@uk.ac.ucl.ps & he keeps on telling me to sort out mailing for myself... (ii) secondly, my contribution to the who needs global irrad. solutions... >Re: Who would really use an accurate global illumination >solution? >I think the most important applications for precise radiative >transfer solutions involve non-human sensors, i.e. the >interpretation of satellite images, the design of machine >vision systems, and design of various weapons systems. >Chris Borel (LANL) and N. Goel (SUNY Bing.) are both on this >list, and both have done work simulating what plants will >look like under various lighting conditions from satellites. I'm also involved in similar work for vegetation modelling for satellite simulation, using MC ray tracing & have been working in this field for that last 4 years. Accurate simulations of irradiance conditions are vital to simulating canopy-scale BRDF given (a) viewing conditions (of the satellite) (b) atmospheric conditions (sun position, atmospheric constituents) (c) canopy structure & radiometric properties, primarily in order to understand the information content of data we're getting from remotely-sensed imagery (i.e. to see what information is extractable from such data & how we might optimise the conditions for obtaining such info), as well as to develop techniques for extracting relevant info. I look forward to finally being signed onto globillum Lewis Warning: ridiculously long SIGNATURE truncated  +------->8-------------8<-----cut-and-keep------>8--------------8<-----------+ LEWIS plewis@uk.ac.ucl.ps | Dept. Geography | 10k OFF University College London | next email 26 Bedford Way, London WC1H 0AP| with this coupon (071)387 7050 x5557 | +------->8-------------8<----re-cycled-email---->8--------------8<------------+ From atc@cs.utexas.edu Wed Jan 13 10:28:27 1993 Return-Path: From: atc@cs.utexas.edu (Alvin T. Campbell III) Date: Wed, 13 Jan 1993 12:03:15 -0600 To: globillum@miro.berkeley.edu Subject: new address Cc: atc@deveel.aero.org Status: R I am now working at The Aerospace Corporation in El Segundo, California. This is in the Los Angeles area. Please update your address for me. Here is my new data: e-mail: atc@deveel.aero.org phone: (310) 336-1788 Please keep me posted on goings-on in the global illumination area. My new job involves global illumination, heat transfer, animation, and scientific visualization. I would like to get involved in the Southern California graphics research community. If anyone on this list is in the LA area, I would appreciate information on local SIGGRAPH meetings, seminars, and the like. --A. T. From holly@cam.nist.gov Wed Jan 13 14:36:21 1993 Return-Path: Date: Wed, 13 Jan 93 17:15:16 -0500 From: holly@cam.nist.gov (Holly_Rushmeier) To: globillum@miro.berkeley.edu Subject: NBS 160 Status: R I got a hold of a few copies of NBS 160 (in the original brown and yellow DoC cover). I can probably get a few more, so if you wanted a copy and haven't gotten one yet send me a paper mailing address. (NBS 160 is "Geometrical Considerations and Nomenclature for Reflectance", published in 1977. It predates the current IES/ANSI standard for terminology, but has quite a useful discussion about how reflectance is defined). -- Holly From holly@cam.nist.gov Thu Jan 14 14:55:51 1993 Return-Path: Date: Thu, 14 Jan 93 17:35:36 -0500 From: holly@cam.nist.gov (Holly_Rushmeier) To: globillum@miro.berkeley.edu Subject: in the mail Status: R Hi -- I sent out copies of NBS 160 to everyone who had sent me email by 5:00 EST today (Thurs.) I quickly ran out of the nifty yellow and brown ones, so some of you will be getting the semi-nifty, but quite readable, second printing yellow and black ones. Please let me know if you don't get your copy in a reasonable amount of time ( I sent them first class or airmail for overseas). I can still send out more -- I have additional yellow and black copies. I'll be out of the office for about a week, so there will be a little delay in getting things mailed out. -- Holly From erich@eye.com Tue Jan 19 07:54:52 1993 Return-Path: Date: Tue, 19 Jan 93 10:23:03 -0500 From: Eric Haines To: globillum@miro.berkeley.edu Subject: New ray tracing and radiosity bibliographies available Status: R At long last I finally got hold of what articles were in the Eurographics '92 proceedings, so have updated the ray tracing and radiosity bibliographies and put them for FTP at princeton.edu:pub/Graphics/Papers/Ra[dy]Bib.01.93.Z (my thanks to Craig Kolb for storing these). If you want more information about these and related reference collections, see the FAQ for comp.graphics, item #16, or write me. Also, of course, let me know of any references not listed. Enjoy, Eric Haines (erich@eye.com) From holly@cam.nist.gov Mon Mar 1 06:21:40 1993 Return-Path: Date: Mon, 1 Mar 93 08:55:23 -0500 From: holly@cam.nist.gov (Holly_Rushmeier) To: globillum@miro.berkeley.edu Subject: S&H, 3rd edition Status: RO Hi -- I just found out that a new, 3rd edition of Siegel & Howell "Thermal Radiation Heat Transfer" has been out since Sept. I don't have a copy myself, but two additions to this version are some citations to papers in computer graphics and a discussion of finite elements in radiative transfer. Its nice to see that some of the graphics research is cycling back into the heat transfer community. -- Holly From spencer@cgrg.ohio-state.edu Mon Mar 1 06:46:08 1993 Return-Path: Date: Mon, 1 Mar 93 09:25:09 EST From: spencer@cgrg.ohio-state.edu (Stephen N. Spencer) To: holly@cam.nist.gov Cc: globillum@miro.berkeley.edu Subject: re: S&H, 3rd edition Status: RO that entry would be: @Book{siegel-1992-thermal, author = "Robert Siegel and John R. Howell", title = "Thermal Radiation Heat Transfer", publisher = "Hemisphere Publishing Corporation", year = "1992", address = "Washington, D.C.", edition = "3rd", keywords = "heat, radiation, absorption, transmission, materials, thermal", } steve From holly@cam.nist.gov Tue Mar 2 12:15:58 1993 Return-Path: Date: Tue, 2 Mar 93 14:57:23 -0500 From: holly@cam.nist.gov (Holly_Rushmeier) To: globillum@miro.berkeley.edu Subject: Life with Radiosity Cc: holly@cam.nist.gov Status: RO Hi -- I am putting together a course called "Making Radiosity Practical" for this summer's Siggraph course. I would like to pack in as much practical information as possible. In particular, I am looking for information that might not be available in technical papers. There will be the usual formal sections in the notes, but I would also like to include a section of short impressions, tips and anecdotes on using radiosity. I know a lot of you have implemented radiosity algorithms. It would be helpful if you sent your brief tips or stories that would be helpful to someone new in the area. This could range from the more serious (like saving additions by storing cumulative delta form factors in the hemi-cube) to the more frivolous (adaptive meshing via strategically located one-sided area rugs). You will be credited for your contribution in the notes (or in the case of more embarrassing anecdotes or sleazy tricks I am willing to protect your anonymity). You can either email your response direct to me, or I'm sure everyone would enjoy it if you posted to globillum. Hoping to hear from you, Holly holly@cam.nist.gov From holly@cam.nist.gov Fri Mar 26 07:49:27 1993 Return-Path: Date: Fri, 26 Mar 93 10:10:37 -0500 From: holly@cam.nist.gov (Holly_Rushmeier) To: globillum@miro.berkeley.edu Subject: Round 2 Status: RO Hi, again, globillumers, As you may recall, when I posted the reference image problem last fall, I suggested that after we got results that someone else propose another test problem. Attached is a new test problem from Nick Holliman. It is more challenging since it is now a non-empty room, and all the surfaces in the image are illuminated indirectly. Since Nick doesn't have ftp access, I am posting this and collecting entries. (My entry is currently churning away on my machine). Since I wasn't inundated with files last time, this time you should submit the result in any image format that is convenient for you, just let me know what it is. You can put them on tiber.nist.gov using anonymous ftp, under pub/holly/CASE2. In the same directory you will find Nick's results in sgi .rgb format and in ppm format (ppm is ascii and I also put the man page for the ppm format in CASE2). If you are interested in participating, please try to send your entry by June 1, 1993. I haven't had any complaints from the system people here, so I have left the results from the first test image under pub/holly/CASE1. -- Holly _____________________________________________________________ ______________________________________________________________ From: Nick Holliman Date: Mon, 22 Mar 93 11:55:44 GMT To: holly@cam.nist.gov Subject: Partitioned room model Status: RO Holly, Here's the partitioned room and a view point producing an image of the dark region of the room, where the surfaces receive indirect light only. I kept to the same assumptions you suggested for the original model. I am not too famliar with the off format but I guess it uses a right hand co-ord system and orders polygon vertices clockwise. I translated to this from a file with counter clockwise vertices so I hope it works ok. I will mail you my converged solution in a btoa conversion of a rgb file later today. Nick. Geometry -------- 20 /* Number of vertices */ 11 /* Number of polygons */ 0 0.0 0.0 0.0 1 4.9 0.0 0.0 2 4.9 0.0 4.0 3 5.1 0.0 4.0 4 5.1 0.0 0.0 5 10.0 0.0 0.0 6 10.0 0.0 6.0 7 0.0 0.0 6.0 8 0.0 3.0 6.0 9 10.0 3.0 6.0 10 10.0 3.0 0.0 11 5.1 3.0 0.0 12 5.1 3.0 4.0 13 4.9 3.0 4.0 14 4.9 3.0 0.0 15 0.0 3.0 0.0 16 2.25 2.99 2.25 17 2.75 2.99 2.25 18 2.75 2.99 1.75 19 2.25 2.99 1.75 8 0 1 2 3 4 5 6 7 /* Floor, rho = 0.3 */ 8 8 9 10 11 12 13 14 15 /* Ceiling, rho = 0.7 */ 4 15 14 1 0 /* Wall, rho = 0.5 */ 4 11 10 5 4 /* Wall, rho = 0.5 */ 4 7 8 15 0 /* Wall, rho = 0.5 */ 4 6 9 8 7 /* Wall, rho = 0.5 */ 4 5 10 9 6 /* Wall, rho = 0.5 */ 4 1 14 13 2 /* Wall, rho = 0.5 */ 4 3 12 11 4 /* Wall, rho = 0.5 */ 4 13 12 3 2 /* Wall, rho = 0.5 */ 4 16 17 18 19 /* Light, emmitted radiance 10 w/m^2-sr */ View ---- >From : 4.80 1.40 5.90 To : 7.80 1.40 2.40 Up : 0.0 1.0 0.0 Field of View : 60 degrees Image Resolution : 50x50 pixels Scaling of radiance values for display -------------------------------------- Linear scaling by 500,000 and clip values over 255. From Scopigno@seins.usc.es Wed May 5 07:53:53 1993 Return-Path: X400-Received: by mta iris-dcp in /PRMD=iris/ADMD=mensatex/C=es/; Relayed; Wed, 5 May 1993 15:38:29 UTC+0200 X400-Received: by /PRMD=iris/ADMD=mensatex/C=es/; Relayed; Wed, 5 May 1993 14:35:56 UTC Date: Wed, 5 May 1993 14:35:56 UTC From: Scopigno Subject: To: globillum@miro.berkeley.edu Content-Identifier: KU-JZNTKA X400-Content-Type: P2-1984 (2) X400-Mts-Identifier: [/PRMD=iris/ADMD=mensatex/C=es/;SEINS/930505143602Z/000] X400-Originator: Scopigno@SEINS.usc.es X400-Recipients: non-disclosure:; Status: R May I join the globillum list? Moreover, does anyone know the form of the integration function that characterizes the sensor response of a consumer videocamera (like Grundig VS-C55 VHS color PAL, or similar devices)" I am interested in the function which relates the light signal input to the PAL composite output (possibly including pickup parameters gamma or antigamma correction, no. of linearities, white balance, RGB filtering, etc. , the typicla parameters of a CCD device). Thanks in advance for your help. sincerely yours Elena Gonzales Rodriguez Engeneering Dept. Universidad de Vigo Spain From holly@cam.nist.gov Thu May 13 10:48:51 1993 Return-Path: Date: Thu, 13 May 93 13:34:02 -0400 From: holly@cam.nist.gov (Holly_Rushmeier) To: globillum@miro.berkeley.edu Subject: stuff Status: R Hi -- I have a few things I wanted to mention: -- I am still hoping for more solutions to the second test image that Nick Holliman proposed (you can get the problem definition from tiber.nist.gov under pub/holly/CASE2). There is a fair amount of diversity in the current soluions, so it would be helpful to have more entries. -- Did anyone ever respond to Elena Rodriguez's question about video cameras? I don't know anything about PAL or Grundig recorders, but I doubt that there is published quantitative information about the relationship between light source input and pixel values that result after you convert from video to RGB. We have a Sony Super Pro 2000 here, and there is essentially no quantitative data with it. I suppose you could set up your own calibration tests -- has anybody done this with a consumer video camera? -- There were a couple of interesting papers in the most recent issue of the IES journal (Winter 1993): "A New Method of Generating Accurate Color Renderings of Architectural Spaces" by M. Smith, which describes a simple method of converting illumination simulation results to RGB values based on some tests done comparing images and scale models. "Near-Field Photometry: A New Approach" by I. Ashdown, which describes a new device for measuring light source distributions. _______________________________ -- Holly From greg Fri May 14 15:39:20 1993 Return-Path: Date: Fri, 14 May 93 15:39:07 PDT From: greg (Gregory J. Ward) To: Scopigno@seins.usc.es, globillum@miro.berkeley.edu Subject: R: video camera calibration Cc: Bob_Clear@macmail.lbl.gov, vincent Status: R Our group has been working a few years now on a "luminance mapper", ie. a video camera connected to a digitizer board for the purpose of obtaining an image of absolute luminance measurements. Robert Clear is in charge of the project (bobc@hobbes.lbl.gov) and Vincent Berrutto is the research associate who has done much of the work (vincent@hobbes.lbl.gov). We have been working with a black and white Hitachi KP-140 security camera connected to a TARGA M8 digitizer board. The spectral response of the camera has been corrected to the photopic curve with a pair of color filters. Readings are within 10% of those of a good photometer, and usually within 5%. The main thing we learned in this project is that video cameras and equipment often "play around" with the gain and gamma response in unpredictable ways. The reason we ended up with the KP-140 camera is that it has internal switches for disabling Automatic Gain Control (AGC) and gamma correction. Using this camera, we were able to get a linear response from the camera over its useful dynamic range. Similarly, many modern digitizer cards "enhance" the video signal in various ways before capturing an image. It is impossible in most cases to figure out what the captured values correspond to in terms of real luminance afterwards. The image may look nice, but it's useless as data. The TARGA M8 card for the PC (if it's still available) has proven reasonably reliable in producing repeatable data points. We have not looked at color cameras yet or even examined the video signal too closely. We only looked at the combined system and performed overall calibrations. We would be happy to supply you with the results if you wish to use the same system in your own work. Greg Ward Lighting Systems Research Group Lawrence Berkeley Laboratory From holly@cam.nist.gov Sun Jun 6 13:45:54 1993 Return-Path: Date: Sun, 6 Jun 93 16:27:54 -0400 From: holly@cam.nist.gov (Holly_Rushmeier) To: globillum@miro.berkeley.edu Subject: question,request&update Status: R Hi -- Once again, I have a few different things to mention -- A question: Whenever people here look at my Monte Carlo images with noise in them, they immediately tell me that it should be easy to get rid of that noise in post-processing with the right filter. I have never found a filtering process that reduces the noise without adding some new objectionable artifact. Has anyone had success reducing noise in MC solutions with a post-process? A request: In the next few months there are a lot of conferences going on with a lot of Globillum papers. I don't think anyone has the resources to get to all of these events. It would be great if people would post information about papers they heard and/or presented. Last month I attended Graphics Interface 93, and there were at least 5 Globillum related papers: 1. "An Adaptive Discretization Method for Progressive Radiosity" Lalonde (lalonde@cs.ubc.ca) 2. "Geometric Simplification for Indirect Illumination Calculations" Rushmeier,Patterson & Veerasamy (holly@cam.nist.gov) 3. "Computing Illumination from Area Light Sources by Approximate Contour Integration' Vedel (vedel@dmi.ens.fr) 4."Spatially Nonuniform Scaling Functions for High Contrast Images" Chiu, Herf, Shirley,Swamy,Wang & Zimmerman (shirley@cs.indiana.edu) 5. "Common Illumination between Real and Computer Generated Scenes" Fournier, Gunawan, Romanzin (fournier@cs.ubc.ca) I put the abstracts for these papers under pub/holly/GI93abstracts on tiber.nist.gov if you want to get more info about them via anonymous ftp. Finally, an update: I am waiting on some information on one of the test case 2 entries, and then I will post the results. So, there is still time to enter. A volunteer has already come forward for test case 3. -- Holly From holly@cam.nist.gov Wed Jun 23 13:14:24 1993 Return-Path: Date: Wed, 23 Jun 93 15:55:44 -0400 From: holly@cam.nist.gov (Holly_Rushmeier) To: globillum@miro.berkeley.edu Subject: Case 2 - Results Status: R Hi -- Finally here are the results for the second test case. The results showed excellent agreement, despite the difficulty of computing an image in which all of the illumination was indirect. There are two images summarizing the results on tiber.nist.gov under pub/holly/CASE2 Case2a.ppm which has results for the original scaling factor of 500,000; and Case2b.ppm which has results for a scaling factor 250,000. In each image r is the minimum value reported, g the average and b the maximum. Thanks to the following people for participating: Nick Holliman Using radiosity (special thanks for setting the problem) Graham Jones Using radiosity type method presented at 4th Eurographics workshop Arjan Kok Using a variation of progressive radiosity Christophe Vedel Using the technique described in "Improved Storage and Reconstruction of Light Intensities on Surfaces", 3rd Eurographics Workshop on Rendering (Bristol) Greg Ward Using Radiance (I also submitted an entry, using vanilla Monte Carlo path tracing, allowing up to 102,400 samples per pixel and still getting noise in the image!!). Just to give you an idea of the results, I am attaching a summary of the range (R=max value -minvalue) over each of the images. Case 3 will be coming along soon. -- Holly =================================================================== =================================================================== CASE2a Results with original scaling factor of 500,000 : R = 0 for 579 pixels R = 1 for 64 pixels R = 2 for 13 pixels R = 3 for 1 pixels R = 4 for 15 pixels R = 5 for 2 pixels R = 6 for 10 pixels R = 7 for 4 pixels R = 8 for 12 pixels R = 9 for 7 pixels R = 10 for 3 pixels R = 11 for 11 pixels R = 12 for 16 pixels R = 13 for 12 pixels R = 14 for 29 pixels R = 15 for 29 pixels R = 16 for 30 pixels R = 17 for 43 pixels R = 18 for 57 pixels R = 19 for 71 pixels R = 20 for 125 pixels R = 21 for 112 pixels R = 22 for 174 pixels R = 23 for 212 pixels R = 24 for 186 pixels R = 25 for 115 pixels R = 26 for 56 pixels R = 27 for 51 pixels R = 28 for 57 pixels R = 29 for 65 pixels R = 30 for 57 pixels R = 31 for 54 pixels R = 32 for 45 pixels R = 33 for 28 pixels R = 34 for 14 pixels R = 35 for 12 pixels R = 36 for 6 pixels R = 37 for 8 pixels for 37= 154 there were no pixels with that large a difference. Case2b: with scaling factor of 250,000 R = 0 for 36 pixels R = 1 for 13 pixels R = 2 for 34 pixels R = 3 for 94 pixels R = 4 for 186 pixels R = 5 for 250 pixels R = 6 for 292 pixels R = 7 for 237 pixels R = 8 for 206 pixels R = 9 for 154 pixels R = 10 for 128 pixels R = 11 for 122 pixels R = 12 for 86 pixels R = 13 for 58 pixels R = 14 for 51 pixels R = 15 for 67 pixels R = 16 for 56 pixels R = 17 for 46 pixels R = 18 for 60 pixels R = 19 for 73 pixels R = 20 for 65 pixels R = 21 for 51 pixels R = 22 for 30 pixels R = 23 for 20 pixels R = 24 for 19 pixels for 24= 96 there were no pixels with that large a difference From kouhia@nic.funet.fi Thu Jul 15 16:32:44 1993 Return-Path: From: Juhana K Kouhia To: globillum@miro.berkeley.edu Subject: Another paper Date: Fri, 16 Jul 1993 01:58:13 +0300 Status: R I have put an another thesis available from weedeater.math.yale.edu from /incoming directory: Guy Moreillon Calcul d'interreflexions diffuses (Radiosite) July 1993, French language I got this months ago and forget to put it available. Juhana Kouhia From holly@cam.nist.gov Tue Jul 20 14:17:53 1993 Return-Path: Date: Tue, 20 Jul 93 16:53:02 -0400 From: holly@cam.nist.gov (Holly_Rushmeier) To: globillum@miro.berkeley.edu Subject: radiosity method definition Status: R Over time I have heard the term "radiosity method" applied to a lot of different rendering procedures. Some times it is used for anything that can be used for a "walk through", some times for any method that can simulate "color bleeding". Generally, I don't see much point over arguing over what is a radiosity method and what isn't (i.e. is Radiance a radiosity method, or radiosity-like method?) However, for the purpose of standing up in front of a lot of people to talk about radiosity methods, I would like to come up with a reasonably short but informative definition of radiosity methods. Here is what I have -- please take your best shot at correcting/improving it: What is radiosity? Radiosity is the radiant energy/(time-area) leaving a surface. What is the radiosity method? There is no single radiosity method. Radiosity methods are a class of methods for solving the global illumination problem for image synthesis. Radiosity methods are distinguished by the following features: -- objects in the environment are discretized -- a solution is obtained by solving simultaneous equations -- the quantities of light are computed in object space, rather than screen space The "classic" radiosity method assumes environments composed only of Lambertian, opaque surfaces with the radiosity of each surface being uniform. In the "classic method" a full set of simultaneous equations is solved for radiosities of all of the surfaces in the environment. ---- Thanks, Holly From Paul.Heckbert@hostess.graphics.cs.cmu.edu Tue Jul 20 19:13:49 1993 Return-Path: Date: Tue, 20 Jul 93 21:50:21 EDT From: Paul.Heckbert@hostess.graphics.cs.cmu.edu To: globillum@miro.berkeley.edu Subject: Re: radiosity method definition Status: R sounds good to me. I was going to say "the radiosity method simulates global illumination by solving a system of equations whose unknowns are the light at various parts of the scene. The scene can be discretized and the system can be solved in a variety of ways." From don@cs.princeton.edu Wed Jul 21 00:42:16 1993 Return-Path: Date: Wed, 21 Jul 1993 03:24:42 -0400 From: Don Mitchell To: globillum@miro.berkeley.edu Subject: radiosity method Status: R The global-illumination problem is to compute a solution to the rendering equation, an integral equation. I think that means you either use finite element methods (FEM), which is what I think of as "radiosity methods" or you use Monte Carlo methods (MC) which end up being advanced types of "ray-tracing methods". FEM and MC approaches to radiation transfer go way back, nuclear engineering, thermal engineering, and illumination engineering. I think graphics had done a lot that is new and unique, and it would be interesting to discuss that and distinguish our results from earlier engineering work. From FEDA@eigcl1.una.ac.at Thu Jul 22 01:21:21 1993 Return-Path: Date: Thu, 22 Jul 93 09:59:50 +0200 From: FEDA@eigcl1.una.ac.at To: "globillum@miro.Berkeley.EDU"@email.una.ac.at Subject: Radiosity method definition Status: R The "classical" radiosity equation can be obtained from the general rendering equation by using two major assumptions: 1: the scene is discretized into patches with constant radiosity 2: the radiosity of each patch is direction independent (diffuse) It turned out that the second assumption is not necessary, since extended versions of the radiosity algorithm are able to simulate directional diffuse and specular transfers. Galerkin methods are based on a modified version of assumption 1: the radiosity of a patch is not constant, but approximated by a set of basis functions. In my opinion, radiosity methods are characterized by a discretized scene and a piecewise approximation of the radiosity function. This piecewise approximation of the radiosity function has to be computed by solving a set of modified radiosity equations. The view-independence is simply a result of this definition. Radiance is no radiosity method, because no radiosity equation is solved. Note that Monte Carlo methods can be used for form factor approximation. Therefore it is not correct to say MC methods are generally no radiosity methods! Martin ------------------------------------------------------------------------ Martin Feda, Institute for Computer Graphics, TU Vienna, Austria ------------------------------------------------------------------------ From Paul.Heckbert@hostess.graphics.cs.cmu.edu Tue Jul 27 09:34:21 1993 Return-Path: Date: Tue, 27 Jul 93 12:06:14 EDT From: Paul.Heckbert@hostess.graphics.cs.cmu.edu To: globillum@miro.berkeley.edu Subject: Global Illumination meeting at SIGGRAPH Status: R Let's get together for a "global illumination meeting" at SIGGRAPH again this year. I propose Friday, August 6 at 12:10 pm. Look under "globillum" on the Birds-of-a-Feather board or the electronic message board at SIGGRAPH for a meeting place. If you have colleagues/friends working on global illumination, feel free to bring them. Also, if you have papers, theses, or pictures that you'd like to share, bring copies of those too! Also at SIGGRAPH: Holly Rushmeier is chairing a course on Radiosity on Monday, I'm chairing a course on Global Illumination on Tuesday, and the papers sessions Thursday look like a whole day of Global Illumination-related talks! -Paul ph@cs.cmu.edu From glassner@parc.xerox.com Tue Aug 17 23:32:39 1993 Return-Path: From: Andrew Glassner To: globillum@miro.berkeley.edu Subject: Nicodemus Eq. C10 Date: Tue, 17 Aug 1993 23:17:39 PDT Status: RO In the famous monograph by Nicodemus et. al., Appendix C contains a very clear discussion of diffuse and specular reflection in terms of BRDF's and reflectances. But I don't understand one of the terms in Equation C.10 (pg. 44)- specifically, why he takes the delta function of (sin^2(theta_r)-sin^2(theta_i)) rather than simlpy (theta_r - theta_i). To make matters move confusing, when Pat Hanrahan mentions this forumulation in the Cohen/Wallace radiosity book (it's out now, and every serious rendering person should have a copy) he uses a difference of cosines and includes an additional cosine corection term! If you don't have the monograph nearby, the point is to find a BRDF that satisfies perfect specular reflection. You have a hemisphere centered around a point P, where the XY plane is the tangent plane to the surface, and the Z axis is the normal. The polar coordinate system associated with this puts theta as the angle between a vector and the Z axis, and psi is the angle between the projection onto the base plane and the X axis. That is, for a unit vector V, cos theta = (V . Z), and cos psi = ((V - (V . Z)Z) . X). If your outgoing direction is (theta_r, psi_r), then you know your specular input is coming from (theta_r, psi_r + pi) or (theta_r, psi_r - pi). You want to pick out this direction as you sweep (theta_i, psi_i), so I'd form three delta functions (pretend & is a Greek lower-case delta): d-theta = &(theta_r - theta_i) d-psi-1 = &(psi_r - psi_i - pi) d-psi-2 = &(psi_r - psi_i + pi) So that when you form d-theta * (d-psi-1 + d-psi-2) you only get a non-zero result when you're sitting on the incident direction. We all agree on d-psi-1 and -2, but d-theta varies: Nicodemus: d-theta = 2 &(sin^2(theta_r) - sin^2(theta_i)) (note the extra 2) Hanrahan: d-theta = &(cos(theta_r) - cos(theta_i))/cos(theta_i) (note the extra 1/cos(theta_i)) Can anyone suggest a consistent interpretation? -Andrew From holly@cam.nist.gov Wed Aug 18 05:46:14 1993 Return-Path: Date: Wed, 18 Aug 93 08:37:06 -0400 From: holly@cam.nist.gov (Holly_Rushmeier) To: Andrew Glassner , globillum@miro.berkeley.edu Subject: Re: Nicodemus Eq. C10 Status: R In response to Andrews's point about the delta functions for specular reflection: You want to define the delta function for the thetas so that when you integrate over the incident hemisphere you only get a non-zero value at theta_r = theta_1. Since you are integrating over cos(theta_i)sin(theta_i) d theta_i, and this is equal to (1/2)d (theta_i)**2, you end up with the extra factor of 2 and the theta**2 in the delta function. In the new radiosity book, I think there is a sin(theta_i) missing in the integration over the hemisphere in equation (2.30) on page 31. -- Holly From holly@cam.nist.gov Wed Aug 18 06:25:47 1993 Return-Path: Date: Wed, 18 Aug 93 09:17:05 -0400 From: holly@cam.nist.gov (Holly_Rushmeier) To: Robert van Liere , globillum@miro.berkeley.edu Subject: Re: Nicodemus Eq. C10 Status: R "Radiosity and Realistic Image Synthesis" by Michael F. Cohen and John R. Wallace (with a chapter by Pat Hanrahan and a forward by Donald P. Greenberg) published by Academic Press ISBN 0-12-178270-0 US address: Academic Press Professional 955 Massachusetts Ave. Cambridge MA 02139 United Kingdom: Academic Press Limited 24-28 Oval Road London NW1 7DX From holly@cam.nist.gov Wed Aug 18 07:15:17 1993 Return-Path: Date: Wed, 18 Aug 93 10:06:44 -0400 From: holly@cam.nist.gov (Holly_Rushmeier) To: Andrew Glassner , globillum@miro.berkeley.edu Subject: Re: Nicodemus Eq. C10 Status: R After I wrote my first response I started wondering why this hadn't been noticed in the Siggraph radiosity course notes. The reason is that in the notes the version of (2.30) is correct, in that it uses sin(theta_i) d theta_i = - d(cos(theta_i)) In other words, the expression for the specular reflectance is correct, but the d theta_i in (2.30) should be d(cos(theta_i)). Overall, my personal preference is to treat specular reflectance as a special case, and not to bother squeezing it into the BRDF form. The pure specular case illustrates that BRDF is not bounded (i.e. it isn't a per cent reflectance). Otherwise I can't see the advantange of this formulation. -- Holly From glassner@parc.xerox.com Wed Aug 18 09:17:22 1993 Return-Path: From: Andrew Glassner To: glassner@parc.xerox.com, globillum@miro.berkeley.edu, holly@cam.nist.gov Subject: Re: Nicodemus Eq. C10 Date: Wed, 18 Aug 1993 08:54:41 PDT Status: R I agree that having delta functions in the BRDF has dubious practical value. But as an example it demonstrates why the "D" is in there in the name, and is a good motivational step for getting to the reflectance and reflectance factor. Thanks for the perfect answer, Holly! From Francois.Sillion@imag.fr Wed Aug 18 14:45:32 1993 Return-Path: From: Sillion Francois Date: Wed, 18 Aug 1993 23:31:36 +0200 Organization: IMAG Institute, University of Grenoble, France To: Andrew Glassner , globillum@miro.berkeley.edu Subject: Re: Nicodemus Eq. C10 Status: R Andrew, Both formulations (Nicodemus' and Hanrahan's) are correct ! It's all a question of normalization : as you note in your message, the Dirac delta distribution is zero everywhere but at the origin. At that point it does not have a value in the usual sense, and is sometimes considered to take an "infinite" value. In fact the Dirac distribution is really uniquely determined by its normalization condition, that the integral of the distribution equal one. Note this is a one-dimensional integral over the entire domain of real numbers. In the case of the reflectance, the reason why a Dirac distribution is used is to limit the ideal specular reflection to the exact mirror direction. But the normalization needed is different: what must be physically ensured is that the total energy flux reflected according to the specified reflectance be equal to the incident energy flux (ignoring the scalar "specular reflectance" thrown in front of the delta functions). This reflected energy flux is equal to the integral over the reflected hemisphere of the reflected radiance, times cos (theta_r), times the differential solid angle d_omega. Therefore the ratio of the reflected energy flux to the incident flux is integral (over hemisphere) rho(theta_r, phi_r) cos( theta_r) d_omega and the exact form of rho(theta_r, phi_r) must ensure that this integral equals one. if you spell out d_omega = sin(theta_r) d theta_r d phi_r, you see that the integration over phi_r is trivial, and a factor of &(phi_r - phi_i - pi) in rho works just fine. But as for theta_r, the integral is that of rho * cos(theta_r) * sin(theta_r) d theta_r it's easy to see that cos(theta_r) sin(theta_r) d theta_r = ( d sin^2(theta_r) ) / 2 Thus the expression in Nicodemus' paper, where a change of variable in the integral brings us back to the usual Dirac integral. As for Hanrahan's expression, consider the change of variable u=cos(theta): since d cos(theta_r) = - sin(theta_r) d theta_r, you see that using &( cos(theta_r) - cos( theta_i) ) there is only a cosine term left under the integral that makes it different from the Dirac integral. This is precisely why Hanrahan divides his reflectance by cos( theta_i) (remember, at the point of interest, cos(theta_i) = cos( theta_r) ! Well, I hope this lengthy explanation helped you at least a bit. Take care ! --Francois -- From holly@cam.nist.gov Fri Aug 20 10:27:46 1993 Return-Path: Date: Fri, 20 Aug 93 13:17:50 -0400 From: holly@cam.nist.gov (Holly_Rushmeier) To: globillum@miro.berkeley.edu Subject: Description File Format Status: R Hi -- I have placed the description file format that Greg Ward developed (and that I mentioned at the globillum meeting at SIGGRAPH) on tiber.nist.gov as a shar file called Description.File.Format.shar. I can email a copy to anyone who doesn't have ftp. This file format is part of a project to develop guidelines for manufacturers of products like furniture and lighting fixtures to provide the data that is needed for lighting simulation and rendering. It is important for the format to be complete, and for it to be independent of the rendering technique to be used. Please check through it and see if the current description meets these criteria. Manufacturers are only going to be interested in providing this data if they can see that it is going to promote the exposure of their products. If as a community we can settle on a format and use it in many different freely available and commercial rendering packages, we can make it worthwhile to companies to provide the data. -- Holly From pmh@fs.princeton.edu Wed Aug 25 12:12:49 1993 Return-Path: From: Pat Hanrahan Date: Wed, 25 Aug 93 14:47:38 EDT To: globillum@miro.berkeley.edu Subject: Re: Nicodemus Eq. C10 Status: R Sorry for not replying sooner and clearing this up. Francois and Holly are obviously both right. The two formulations are equivalent. Actually Don Mitchell suggested the formulation I used; we both thought it was more "obvious" that way than the way that Nicodemus wrote it. (There is a classic story about von Neumann. He's teaching a class on advanced math for quantum mechanics and is working through a proof on the board. Halfway through he skips a couple steps and says the derivation is obvious. Somebody raises their hand and says it's not obvious to him. At which point, von Neumann pauses, thinks for a few minutes, walks out of the room and paces the halls for five minutes. He comes back and declares, "yes, it is obvious" and then proceeds with the lecture.) I can't figure how I introduced in the rewrite of the notes. By the way, I am producing a much longer, expanded version of those notes. I'd be interested in peoples comments on what I wrote. Yours, Pat From uselton@nas.nasa.gov Wed Aug 25 13:16:26 1993 Return-Path: Date: Wed, 25 Aug 93 13:03:18 -0700 From: uselton@nas.nasa.gov (Samuel P. Uselton) To: pmh@fs.princeton.edu Cc: globillum@miro.berkeley.edu Subject: von Neumann story (was Nicodemus Eq. C10) Reply-To: uselton@nas.nasa.gov Status: R About the von Neumann story...... I first heard this basic story in 1968 told by an SMU math prof, about one of his profs. I pretty sure the subject was NOT von Neumann. I've always regarded the story as a generic campus myth (as in urban myths). Does anyone have (1) more evidence for von Neumann or (2) heard the same story about someone else? Sam Uselton uselton@nas.nasa.gov From holly@cam.nist.gov Thu Sep 9 13:43:33 1993 Return-Path: Date: Thu, 9 Sep 93 16:34:03 -0400 From: holly@cam.nist.gov (Holly_Rushmeier) To: globillum@miro.berkeley.edu Subject: lighting newsgroup Status: R I just noticed the attached CFD for a group called sci.lighting, and it looks like a group that would be of interest to many people on this list. So far objections to the group seem to be placement -- sci.engr.lighting and misc.consumers.house.lighting have been suggested since many people feel lighting is engineering, not science (and one person thought it would be misread as sci.lightning). Does anybody subscribe to the mailing list mentioned in the CFD? I have tried to get in touch with Jonathan Hardis since he is at NIST also, but he is away and his phone mail is full. -- Holly From: cbelcher@kuhub.cc.ukans.edu Newsgroups: sci.engr,sci.optics,sci.psychology,ieee.general Subject: RFD: sci.lighting Message-ID: <1993Sep9.055440.53407@kuhub.cc.ukans.edu> Date: 9 Sep 93 10:54:39 GMT Organization: University of Kansas Academic Computing Services Lines: 46 Xref: cam sci.engr:5057 sci.optics:2688 sci.psychology:11871 REQUEST FOR DISCUSSION (respond to news.groups) Proposed name: sci.lighting Status: unmoderated This is the official request for discussion on creation of a new newsgroup, the desirability of which has already been discussed at some length in a mailing list called "lighting", maintained by Jonathan Hardis at NIST (lighting@garnet.nist.gov). The consensus of that group (which has about 150 subscribers) is that a newsgroup is desirable, because each user has more control over how and when to read the postings to a newsgroup than to a distribution mailing list. It is felt that the current traffic on the mailing list would substantially shift to the newsgroup, where the discussions would benefit from the input from a wider audience. The object of sci.lighting is to provide a forum for the discussion of all aspects of the science and art involved in the creation of lighting methods and solutions for safe, productive, and enjoyable use of the built environment, and in theater and film and related fields. The term "built environment" includes not only architecture, but also transportation media such as roadways and aviation-related construction. This statement is intended to be as broad as possible in its inclusion of all topics related to natural and manufactured light. A representative list of some of the broad categories of topics which would be appropriate for discussion in sci.lighting follows. The fact that a topic does not appear on the list does not indicate that that topic could not be discussed. Eye, vision and visibility Color Manufactured light sources Daylight availability/application Psychological and nonvisual concerns Luminaires Control strategies/technology Quantity and quality assessment Light and energy conservation/management Lighting economics -- Clay Belcher, PhD, P.E. CBELCHER@KUHUB.CC.UKANS.EDU Associate Professor voice: (913) 864-3434 Architectural Engineering fax: (913) 864-5099 University of Kansas ___________________________ Marvin Hall Lawrence, KS 66045 Visualize Whirled Peas USA From erich@eye.com Mon Sep 13 14:00:46 1993 Return-Path: Date: Mon, 13 Sep 93 16:41:11 -0400 From: Eric Haines To: globillum@miro.berkeley.edu Subject: new papers Status: RO I finally got the Graphics Interface '93 Proceedings. Though I believe these paper titles may have been listed earlier, I thought I'd give the full reference to each. For those of you new to this mailing list, I maintain a "radiosity" (really global illumination except for classical ray tracing) bibliography, newest one available on request. I also maintain a separate ray tracing bibliography. If you are going to Eurographics this year and have a few spare minutes, please send me the relevant references of papers in these fields so I can update these free bibliographies for us all. Eric Haines erich@eye.com All references from: %J Proceedings of Graphics Interface '93 %I Canadian Information Processing Society %C Toronto, Ontario %D May 1993 Here they are (without the above): %A K. Chiu %A M. Herf %A P. Shirley %A S. Swamy %A C. Wang %A K. Zimmerman %T Spatially Nonuniform Scaling Functions for High Contrast Images %P 245-253 %K sampling, antialiasing %A Alain Fournier %A Atjeng S. Gunawan %A Chris Romanzin %T Common Illumination between Real and Computer Generated Scenes %P 254-262 %K compositing %A Paul Lalonde %T An Adaptive Discretization Method for Progressive Radiosity %P 78-86 %K mesh generation, progressive refinement %A Holly E. Rushmeier %A Charles Patterson %A Aravindan Veerasamy %T Geometric Simplification for Indirect Illumination Calculations %P 227-236 %K monte carlo, progressive refinement, ray tracing %A Christophe Vedel %T Computing Illumination from Area Light Sources by Approximate Contour Integration %P 237-244 Here are the ray tracing related papers (though this first one is of general interest): %A David P. Dobkin %A Don P. Mitchell %T Random-Edge Discrepancy of Supersampling Patterns %P 62-69 %K sampling, antialiasing %A Alain Fournier %A Pierre Poulin %T A Ray Tracing Accelerator Based on a Hierarchy of 1D Sorted Lists %P 53-61 %K efficiency %A Jon Genetti %A Dan Gordon %T Ray Tracing With Adaptive Supersampling in Object Spac %P 70-77 %K sampling, antialiasing, penumbrae From Paul.Heckbert@hostess.graphics.cs.cmu.edu Tue Sep 14 10:50:35 1993 Return-Path: Date: Tue, 14 Sep 93 13:33:58 EDT From: Paul.Heckbert@hostess.graphics.cs.cmu.edu To: globillum@miro.berkeley.edu, nic@informatik.uni-rostock.de Subject: paper by Nico Guenther Status: R In case you didn't see this on Usenet, check out the following: ------------------------------------------------------------- Newsgroups: comp.graphics.algorithms From: nic@informatik.uni-rostock.de (Nico Guenther) Subject: ANALYTICAL ILLUMINATION, new approach Organization: University of Rostock, CS Dept. (Germany) Date: Mon, 13 Sep 1993 12:28:33 GMT Hi, researchers in computer graphics. I post here to guide your attention to an article about analytical illumination techniques, commonly known as radiosity. As u know radiosity was developed from thermal engineering under some sharp constraints. Hence this technique is limited to planar, opaque and ideal diffuse surfaces in origin. After the last few years a number of investigations were made to extend radiosity in some directions. All these improvements base on the original formula designed by Cohen and Greenberg. Hence the philosophy off all improvements is to add special parts to the basic double-area-integral formula to involve special effects. That means that all extensions of basic radiosity theory stay particular solutions. What IMHO is needed is an analytical theory of global illumination without all the restrictions. Such a theory should work in general. Having this theory we can make certain assumptions to fit it into our needs, i.e. make assumptions for special geometrical surfaces or for certain optical properties. This theory is described and explained in an article availbale via anonymous ftp from ftp.informatik.uni-rostock.de in pub/graphics named illu.tar.Z and illu.ps.Z It is obvious that a general theory is very formal and therefore unsuitable to practice. However all applications to real environments may be derived out of this theory. Some examples are given in the above article. In addition to that analytical illumination must pay strong attention to physics. Though if u hate physics, do *not* read this. For all who are interested in understanding, I'll try to explain everything best I can. Please send me your comments on what is hard to understand or to follow. I need your comments and/or questions to find out which parts of theory must be explained more detailed, which figures are misleading, which mathematical approaches are to complicated, .... (I sent an extended abtract of this theory to 4th EG workshop on rendering. The referees did not understand all things correctly, because they were poorly explained. Unfortunately they did not wrote what was misunderstood.) OK, that's it. I'll be appreciated about any comment, but remember: *Some* physics is necessary and some mathematics too. AND be always aware of the following fact: The aim of this theory is *not* to create nice looking pictures. I'm sure u all know nice looking pics out of former particular solutions of analytical illumination. Please email comments and critical hints directly to nic@informatik.uni-rostock.de Best regards Nico ps. The article is written in LATEX. If someone can not use LATEX, and can't print postscript, she/he can email me and I'll send a printout via air mail. pps. Sorry to all EG93 visitors who were interesting in reading this. Last week there was some trouble addressing our ftp-server. From: nic@informatik.uni-rostock.de (Nico Guenther) Subject: ps-file created (ANALYTICAL ILLUMINATION) To: ph@hostess.graphics.cs.cmu.edu Date: Tue, 14 Sep 93 13:03:57 MET Hi Paul, ... I would appreciate of any comments or hints to make things easier to understand. Since I studied physics, everything is clear to me. Please email me all questions and/or comments. Best regards Nic (nic@informatik.uni-rostock.de) From holly@cam.nist.gov Sat Sep 18 11:31:03 1993 Return-Path: Date: Sat, 18 Sep 93 14:22:05 -0400 From: holly@cam.nist.gov (Holly_Rushmeier) To: globillum@miro.berkeley.edu Subject: part. media & sci.lighting Status: RO Once a again a few different things: 1. I am writing a short survey paper on computer graphics techniques for computing radiative transfer in participating media for a heat transfer workshop I am going to. Its clear that the hierarchical approach would be really useful in a zonal (i.e. radiosity for volumes) method, and I have heard people say that they have implemented such an approach. Does anybody have any references for results? If you haven't written anything formal, could you send me email about what you did which I can list as a "Personal Communication." (I would try to implement something myself but I need to get this paper done in the next two weeks. As it is I have been busy rewriting Monte Carlo ray tracing stuff for some combustion problems. Say what you will about radiosity vs. Monte Carlo, if you need to modify your code in a hurry for a new application Monte Carlo is definitely the way to go.) 2. In the discussion of the proposed "sci.lighting" newsgroup the main objection has been that it is too high up in the news group hierarchy. People who are concerned about Usenet but have nothing to do with lighting at all have proposed "sci.tech.lighting" or "sci.applied.lighting". People involved in lighting feel this would discourage some posters who might want to discuss the aesthetic aspects of lighting. If you have an opinion one way or another please post to "news.groups". 3. Just a reminder that on tiber.nist.gov under pub/holly you can pick up "Description.File.Format.shar". Please send comments on the format to Greg Ward or myself. Also, under pub/holly/CASE3 you can find the third proposed test scene (the one with a sphere). If you have trouble seeing stuff listed on tiber, try "ls -l", and if still nothing shows up please let me know. ---- Holly (BTW, October 14 is World Standards Day). From holly@cam.nist.gov Tue Oct 26 06:03:13 1993 Return-Path: Date: Tue, 26 Oct 93 08:42:36 -0400 From: holly@cam.nist.gov (Holly_Rushmeier) To: globillum@miro.berkeley.edu Subject: CFV sci.engr.lighting Status: R As a result of comments received during the discussion period that there are too many news groups relatively high in the news group hierarchy, it was decided that the group should be sci.engr.lighting, rather than sci.lighting. Anyway, the voting period has started, and here is the description of how to vote from the posting in news.groups: >From cam!dove!uunet!bounce-back Tue Oct 26 08:19:46 EDT 1993 Article: 73444 of news.groups Path: cam!dove!uunet!bounce-back From: rdippold@qualcomm.com (Ron "Asbestos" Dippold) Newsgroups: news.announce.newgroups,news.groups,sci.energy,sci.physics,alt.architecture,sci.astro,sci.engr,sci.psychology Subject: CFV: sci.engr.lighting Message-ID: Date: 25 Oct 93 23:01:16 GMT Expires: 16 Nov 1993 00:00:00 GMT References: <26lf4cINNkug@rodan.UU.NET> Sender: tale@uunet.uu.net Reply-To: voting@qualcomm.com (Ron Dippold Voting Alias) Followup-To: poster Organization: Usenet Volunteer Votetakers Lines: 67 Approved: tale@uunet.uu.net Xref: cam news.announce.newgroups:3693 news.groups:73444 sci.energy:18279 sci.physics:54708 sci.astro:38411 sci.engr:5466 sci.psychology:12570 NNTP-Posting-Host: rodan.uu.net FIRST CALL FOR VOTES (of 2) unmoderated group sc.engr.lighting Newsgroups line: sci.engr.lighting Light, vision & color in architecture,trans,media, etc. Votes must be recieved by 15 Nov 1993, 23:59:59 UTC. This vote is being conducted by a neutral third party. For voting questions only, contact rdippold@qualcomm.com. For questions about the proposed group, contact Clay Belcher The CFV will be sent to the mailing list "Lighting@Garnet.NIST.gov" after it appears in news.announce.newgroups. CHARTER The object of sci.engr.lighting is to provide a forum for the discussion of all aspects of the science and art involved in the creation of lighting methods and solutions for safe, productive, and enjoyable use of the built environment, and in theater and film and related fields. The term "built environment" includes not only architecture, but also transportation media such as roadways and aviation-related construction. This statement is intended to be as broad as possible in its inclusion of all topics related to natural and manufactured light. A representative list of some of the broad categories of topics which would be appropriate for discussion in sci.engr.lighting follows. The fact that a topic does not appear on the list does not indicate that that topic could not be discussed. Eye, vision and visibility Color Manufactured light sources Daylight availability/application Psychological and nonvisual concerns Luminaires Control strategies/technology Quantity and quality assessment Light and energy conservation/management Lighting economics Light Pollution It is expected that the list will be gatewayed to the group sometime in the future. STANDARD VOTING INFO You should send MAIL (posts to a group are invalid) to voting@qualcomm.com Your mail message should contain one and only one of the following statements: I vote YES on sci.engr.lighting or I vote NO on sci.engr.lighting Anything else may be rejected by the automatic vote counting program. If you later change your mind you may also send an "abstain" vote in the same manner, using "abstain" in place of "yes" or "no". The votetaker will respond to received ballots with mail acks. Standard Guidelines for voting apply - one vote per person, no more than one vote per account. 100 more YES votes than NO votes and 2/3 of all votes being YES are the requirements for group creation. Read news.groups for more information on group creation. From holly@cam.nist.gov Thu Nov 18 06:36:25 1993 Return-Path: Date: Thu, 18 Nov 93 09:14:42 -0500 From: holly@cam.nist.gov (Holly_Rushmeier) To: globillum@miro.berkeley.edu Subject: case 3 and other notes Status: R A few things -- 1. If you are interested in submitting an image for "case 3" the deadline is November 24. 2. I have noticed that a number of people have picked up the proposed description file format, but I haven't heard any comments about it. Apparently the Inventor format is becoming popular. As I read it though, it isn't designed for BRDF data or photometric descriptions of light sources, so it isn't really useful accurate illumination simulations. 3. The news group sci.engr.lighting passed, so it should be showing up on your news reader soon. 4. In response to my inquiry about hierarchical methods for participating media, there is a paper on this topic: Neeta Bhate, "Application of Rapid Hierarchical Radiosity to Participating Media", Proceedings of the First Bilkent Computer Graphics Conference on Advanced Techniques in Animation, Rendering and Visualization, July 12-14, 1993 Ankara, Turkey, pp. 43-53. The paper discusses specific issues related to applying the hierarchical method to participating media ,and gives timing results for an implemention. 5. If you are a US citizen finishing up a Ph.D., please consider applying to the NRC/NIST post-doc program. The application requires writing a proposal which will be reviewed by an NRC panel. Applications are due January 15. The post-doc would start in Fall of 1994. Base salary is $45,500. I can send more details to anyone who is interested. -- Holly From @alijku11.edvz.uni-linz.ac.at:wrzl@gup.uni-linz.ac.at Mon Jan 10 05:16:05 1994 Return-Path: Date: Mon, 10 Jan 94 11:41:53 +0100 From: Wolfgang Stuerzlinger To: globillum@miro.berkeley.edu Subject: Realistic Image Synthesis position available Cc: wrzl@alijku11.edvz.uni-linz.ac.at Status: RO Realistic Image Synthesis Post-Doc At the Department of Graphics and Parallel Processing at the University of Linz, Austria a Post-Doc position is available. We are looking for persons working in the field of realistic image synthesis. Due to some legislative changes (Austria will join the EU (former EC) in 1995 along with Sweden) we have to occupy this position as soon as possible. The department consists of 11 persons mainly working in the following areas: - Realistic image synthesis Extending the Radiosity method, parallelisation of Radiosity, material models, Raytracing, Monte Carlo Raytracing. - Visualisation of scientific data Volume visualisation, parallelisation of volume visualisation, medical applications. - Multimedia applications. - Various other computer graphics applications. - Parallel monitoring and debugging for distributed memory machines Trace recording and replay, graphical debugging of parallel programs. - Parallel algorithms Numerical and graphical algorithms on distributed memory machines. Available hardware includes various SUN/SGI/IBM workstations and 19" X-Terminals connected to the Internet. For parallel processing we own an nCube2 with 64 processors (a 4 MB memory) connected with a hypercube topology network and we have access to various other parallel computers. The post-doc position is for 1 to 2 years, and the payment is fixed at 440.000 AS per year. Required is a letter of application stating which special field and/or project(s) the person intends to work on. Furthermore the applicant should supply a curriculum vitae and a list of publications including a copy of the 2 "best" papers, and a list of persons, who would supply references. Knowledge of the german language is not a requirement. Applications should be sent to: Prof. Jens Volkert Department for Graphics and Parallel Processing (GUP) University of Linz Altenbergerstrasse 69 A-4040 LINZ AUSTRIA EUROPE I will be happy to provide any further details (wrzl@gup.uni-linz.ac.at) --- Wolfgang Stuerzlinger, Johannes Kepler University, Linz, Austria wrzl@gup.uni-linz.ac.at (Austria - mountains, no kangaroos :-) From mfc@princeton.edu Fri Jan 14 09:17:19 1994 Return-Path: From: Michael Cohen Date: Fri, 14 Jan 94 11:41:17 -0500 To: ph@graphics.cs.cmu.edu, globillum@miro.berkeley.edu, glab@cs.princeton.edu Subject: Radiosity Book Cc: salesin@cs.washington.edu, holly@cam.nist.gov, 72060.Z420@compuserve.com, wei@princeton.edu, rs@princeton.edu, johnw@eye.com Status: R The radiosity book has almost sold out its first printing and Academic Press has indicated it wants to do a second printing ASAP. This means we have a chance to make corrections. If any of you have read it and have marked up any mistakes you have found (of course I don;t think there are any ;-)) it would be greatly appreciated if you could send them to us. Thanks, Michael and John From @explorer.dgp.toronto.edu:dret@dgp.toronto.edu Mon Jan 17 15:25:29 1994 Return-Path: <@explorer.dgp.toronto.edu:dret@dgp.toronto.edu> From: George Drettakis To: globillum@miro.berkeley.edu Subject: Yet another Illumination Ph.D. Cc: dret@dgp.toronto.edu Date: Mon, 17 Jan 1994 17:55:17 -0500 Status: R Hi everybody, I just finished the final version of my PhD thesis. It is available by anon ftp at dgp.toronto.edu:pub/dret/PhD. There are postscript files (for single and double-sided printers) and tiff files for all the colour images. It will soon also be available as CSRI Technical Report 293 (ftp only at ftp.csri.toronto.edu:csri-technical-reports/293). I welcome all comments or suggestions at either dret@dgp.toronto.edu or George.Drettakis@imag.fr It can be quoted either as "Ph.D. thesis, Dept. of Computer Science, University of Toronto", or as : "CSRI Technical Report no. 293, University of Toronto". Thanks, George Drettakis Dynamic Graphics Project Computer Systems Research Institute Phone +1 (416) 978 5473 University of Toronto FAX +1 (416) 978-0458 Toronto, Ontario CANADA M5S 1A4 e-mail: dret@dgp.toronto.edu or dret@dgp.utoronto.ca --------------------- Here is the info: Title: Structured Sampling and Reconstruction of Illumination for Image Synthesis Degree: Ph.D., University of Toronto, Department of Computer Science Author: George Drettakis Abstract: An important goal of image synthesis is to achieve accurate, efficient and consistent sampling and reconstruction of illumination varying over surfaces in an environment. A new approach is introduced for the treatment of diffuse polyhedral environments lit by area light sources, based on the identification of important properties of illumination structure. The properties of unimodality and curvature of illumination in unoccluded environments are used to develop a high quality sampling algorithm which includes error bounds. An efficient algorithm is presented to partition the scene polygons into a mesh of cells, in which the visible part of the source has the same topology. A fast incremental algorithm is presented to calculate the backprojection, which is an abstract representation of this topology. The behaviour of illumination in the penumbral regions is carefully studied, and is shown to be monotonic and well behaved within most of the mesh cells. An algorithm to reduce the mesh size, and an algorithm which selects between linear and quadratic interpolants are presented. The results show that the mesh size and the degrees of the interpolants can be reduced without significant degradation of image quality. The preceding algorithms are combined into a complete structured sampling approach that allows accurate and efficient representation of illumination using interpolating polynomials for scenes with occlusion. Images with accurate shadows can be produced from the structured representation using either ray-casting or polygon rendering hardware. Finally, it is shown that our methodology generalises easily to the global illumination problem. An iterative solution to a Galerkin finite element approach is proposed, and it is shown how the structured algorithms provide a good initial approximation for the iteration, enhance efficiency for numerical integration and allow adaptive mesh modification. The structure-driven global illumination algorithm thus promises significant improvement over previous higher-order finite element solutions. From erich@eye.com Tue Jan 25 13:28:13 1994 Return-Path: Date: Tue, 25 Jan 1994 15:58:51 -0500 From: Eric Haines To: globillum@miro.berkeley.edu Subject: new (well, a little old) references Status: R I just turned up some obscure radiosity related references (attached) using a free computer science thesis database search facility. The facility is easy to use, send "help" to elib@cs.stanford.edu The database is hardly complete, and seems to start somewhere from 1991 on (and the older ones are mostly Stanford/UCB based), but the price is right. Also, in case you've given up reading comp.graphics and related newsgroups, there's also a Net News searching & subscription facility at netnews@db.stanford.edu Send "help" in the body of the message for more info. Some of the attached references were followed up by journal articles, but I include them all for completeness. Eric Haines p.s. please send me any references about ray tracing or radiosity that I might be missing from my own free on-line bibliographies. These are at princeton.edu:/pub/Graphics/text (or thereabouts) as RadBib and RTBib or somesuch. If you've published a thesis, tech report, or lesser-known journal article I may well not have it. %A Daniel Lischinski %A Filippo Tampieri %A Donald P. Greenberg %T Improving Sampling and Reconstruction Techniques for Radiosity %I Department of Computer Science, Cornell University %R Technical report 91-1202 %D 1991 %K shadow, mesh generation %A J. P. Singh %A C. Holt %A T. Totsuka %A A. Gupta %A J. L. Hennessy %T Load Balancing and Data Locality in Hierarchical N-body Methods %I Computer Systems Laboratory, Stanford University %R CSL-TR-92-505 %D 1992 %K parallelism, hierarchical N-body %A J. P. Singh %T Parallel Hierarchical N-body Methods and Their Implications for Multiprocessors %I Computer Systems Laboratory, Stanford University %R PhD thesis, CSL-TR-93-565 %D 1993 %K parallelism, hierarchical N-body %A Kevin P. Smith %T Fast and Accurate Radiosity-based Rendering %I Computer Science Division, University of California, Berkeley %R UCB/CSD 91/635 %D 1991 %A Seth J. Teller %T Computing the Antipenumbra of an Area Light Source %I Computer Science Division, University of California, Berkeley %R UCB/CSD 91/666 %D 1991 %K Discontinuity meshing From Paul.Heckbert@hostess.graphics.cs.cmu.edu Thu Feb 3 10:35:06 1994 Return-Path: Date: Thu, 3 Feb 94 11:56:25 EST From: Paul.Heckbert@hostess.graphics.cs.cmu.edu To: globillum@miro.berkeley.edu Subject: POSTDOC IN PARALLEL GRAPHICS Status: R POSTDOC AVAILABLE AT CARNEGIE MELLON UNIVERSITY IN HIGH PERFORMANCE COMPUTING GRAPHICS A postdoctoral position is available at Carnegie Mellon University for researchers to work on a project titled "High Performance Computing Graphics". The goal of the project is to explore the use of high performance computers for applications in realistic image synthesis and computer vision. Specifically, we will explore: (1) parallel radiosity methods for applications in interactive architectural design, attempting to make radiosity algorithms operate at near real-time, and (2) the use of fast, parallel stereo vision for applications in teleconferencing. A variety of high performance systems are available to this project, including an iWarp machine designed and built by CMU and Intel, an Intel Paragon, as well as Silicon Graphics workstations with fast graphics, all interconnected by a high speed (HIPPI) network, which also includes a Cray C90 and a Cray T3D operated by the Pittsburgh Supercomputing Center (PSC). As a senior member of the project team, the postdoc will have freedom to steer the project. The term of employment will be two years, preferably starting early in 1994. Qualifications: A PhD in computer science or related field. Considerable research experience in computer graphics and/or computer vision Preferably a background in parallel systems or network supercomputing. Send curriculum vitae and one or two research papers to: Paul Heckbert Computer Science Dept. Carnegie Mellon University 5000 Forbes Ave Pittsburgh PA 15213-3891 USA office: 412-268-7899 fax: 412-621-5117 email: ph@cs.cmu.edu From shirley@cs.indiana.edu Wed Feb 2 17:57:18 1994 Return-Path: Date: Wed, 2 Feb 1994 20:22:59 -0500 From: "peter shirley" To: globillum@miro.berkeley.edu Subject: Simple databases available for rendering Status: RO Hello fellow global illumination fans. This is a note about some simple databases to test rendering that I have put together. They are in the spirit of (but not quite as neat as) the ray tracing test scenes put together by Eric Haines. They are greyscale and diffuse and mostly quadrilaterals, so expect something designed for ease of use in arbitrary renderers. Anyway, if you use them and experience any problems, please let me know by email. ============================================================================ Some sample databases for rendering calculations are available by anonymous ftp. There are eleven scenes each with a sample image from a particular viewpoint. Ten of the scenes have all quadrilaterals, and one also has a sphere. The scenes are achromatic. Nine are all diffuse, one has a specular surfaces, and one has a glass object. The scenes range in complexity from an empty room with six quadrilaterals, to a 100 room scene with 41800 quadrilaterals. More scenes may be supplied later. If you want other types of scenes or need help converting our geom files to your own format, contact Peter Shirley at shirley@cs.indiana.edu. The data is available via anonymous ftp at moose.cs.indiana.edu (129.79.254.191) in pub/RW5. This directory contains a README file and several subdirectories (one of which has compressed tar files for the other directories). The README file is attached at the end of this note. Peter Shirley shirley@cs.indiana.edu ======================== README file ======================================= This file contains descriptions of what is in the various scene description files. The files do not make reference to viewing parameters, but some example images produced using Monte Carlo are supplied for reference. The scenes are further documented in some postscript files in subdirectory "doc": scenes0to5.ps : scenes 0 through 5. scenes6to8.ps : scenes 6 through 8. scenes9to10.ps : scenes 9 and 10. tableAndChair.ps : table and chair models used in test scenes viewing.ps : viewing system for sample images. The sample images of the files are in tiff, ppm, jpeg, and SGI rgb form. These are in subdirectories tiff, ppm, jpeg, and rgb. Scene0 is computed to 18 levels of reflection and the rest are calculated to 5 levels of reflection. The geometry files are in subdirectory geometry. The directories doc, geometry, jpeg, ppm, rgb, and tiff are available in tar form in subdirectory tarfiles. ------------------------------------------------------------------------ MATERIAL PROPERTIES All surfaces are supplied with achromatic information only. Each surface is one of four material types: diffuse, specular, transparent-dielectric, or diffuse-luminaire. This is of course a gross simplification, but is intended for ease of use. For diffuse and specular surfaces, a simple reflectance is given. For dielectric, a refractive index is given. For luminaires, a diffuse reflectance and an emitted radiance is given. For example, here are the notations for the material types: d 0.3 // diffuse surface, reflectance 0.3 s 0.3 // specular surface, reflectance 0.3 t 1.4 // transparent dielectric, refractive index 1.4 l 0.3 0.8 // diffuse luminaire, reflectance 0.3, emitted radiance 0.8 The emitted radiance can be considered to be a spectral radiance at a particular wavelength. The values have been chosen so that most of the radiance values in the scene will be between 0 and 1. ------------------------------------------------------------------------ SURFACE GEOMETRY Two basic geometries are supported: quadrilaterals and spheres. Quads follow the right-handed vertex ordering convention andu are planer. A diffuse quad with reflectance 0.2 and vertices on the XY plane with a surface normal facing along the +Z axis is: q 0 0 0 1 0 0 1 1 0 0 1 0 d 0.2 ^ ^ ^ ^ ^ ^ | | | | | | | | | | | diffuse reflectance = 0.2 | | | | vertex 4 = (0, 1, 0) | | | vertex 3 = (1, 1, 0) | | vertex 2 = (1, 0, 0) | vertex 1 = (0, 0, 0) quad A sphere is supplied with a center and a radius. For example, a sphere with center at the origin and a radius of 1.2 that is a dielectric with refractive index 1.6 is: s 0 0 0 1.2 t 1.6 ------------------------------------------------------------------------ SCENE0 (all quads-- scene0.geom) There are several files that are based on the simple room geometry in this file. This is an axis-aligned room with rectangular walls and a square floor/ceiling. The room is three meters high, and six meters on a side. In scene0, all surfaces are emitters with emitted radiance 0.25 and diffuse reflectance 0.5. This is a convenient debugging scene because the final radiance of all points on all surfaces is 0.5 = 0.25(1 + 0.5 + 0.25 + 0.125 + ...). Note that this is true for all surface geometries that have this material properties, so more complex scenes can be built-up. ------------------------------------------------------------------------ SCENE1 (all quads-- scene1.geom) This is the same geometry as scene 0, but the floor and walls (bottom, left, right, front, back) are diffuse reflectors with reflectivity 0.5, and the ceiling is a diffuse emitter with reflectance 0.5 and emitted radiance 0.5. ------------------------------------------------------------------------ SCENE2 (all quads-- scene2.geom) This is the same room as scenes 0 and 1, but all surfaces are diffuse reflectors with reflectance 0.5, except the floor which is specular with reflectivity 0.5. ------------------------------------------------------------------------ SCENE3 (all quads-- scene3.geom) The same room geometry as scenes 0-2, but the walls and ceiling are diffuse reflectors with reflectivity 0.7, the floor is a diffuse reflector with reflectivity 0.3, and a one meter square light fixture has been added with center (0, 2.8, 0) and emitted radiance 18.. ------------------------------------------------------------------------ SCENE4 (all quads-- scene4.geom) The same as scene3, but the fixture is 0.1 meters across and has emitted radiance 1800. ------------------------------------------------------------------------ SCENE5 (quads with one sphere-- scene5.geom) The same as scene3, but has a glass sphere with refractive index 1.5, center (0, 1, 0) and radius 1. ------------------------------------------------------------------------ SCENE6 (all quads-- scene6.geom) Scene 3 with a table and chairs added. ------------------------------------------------------------------------ SCENE7 (all quads-- scene7.geom) Scene 4 with a table and chairs added. ------------------------------------------------------------------------ SCENE8 (all quads-- scene8.geom) Four lights, 36 chairs, and a table. ------------------------------------------------------------------------ SCENE9 (all quads-- scene9.geom) 100 interconnected rooms hovering in black space, with 100 lights. ------------------------------------------------------------------------ SCENE10 (all quads-- scene10.geom) 100 interconnected rooms hovering in black space, with 100 lights and 100 table-chair sets. ------------------------------------------------------------------------ TABLE (all diffuse quads-- table.quad) The table is all diffuse quads with reflectance 0.3. (there are no lights in this file) ------------------------------------------------------------------------ CHAIR (all diffuse quads-- chair.geom) The chair is all diffuse quads with reflectance 0.3. (there are no lights in this file) ------------------------------------------------------------------------ TABLE AND CHAIRS (all diffuse quads-- tableAndChairs.geom). The table and 4 chairs is all diffuse quads with reflectance 0.3. (there are no lights in this file) ------------------------------------------------------------------------ VIEWING The viewing system for the examples is shown in viewing.ps. The parameters are lookfrom (viewer eye position), lookat point (lookat minus lookfrom is the gaze vector), the view-up vector vup (vup is not necessarily perpendicular to the gaze vector). The vertical field-of-view (vfov) is specified in degrees. From glassner@parc.xerox.com Mon Feb 7 13:53:55 1994 Return-Path: From: Andrew Glassner To: globillum@miro.berkeley.edu Subject: Call For Exercises Date: Mon, 7 Feb 1994 13:05:56 PST Status: R >> CALL FOR EXERCISES! << I'm finishing up a rendering textbook called "Principles of Digital Image Synthesis". It will have exercises at the end of every chapter, as in most texts. It occurred to me a couple of nights ago that there are probably a lot of great exercises in the world that people have developed for homework, tests, and so on, that their creators might like to share with the rest of the graphics community. I'm appending a partial table of contents of the book below, so you can see what topics are addressed. This is a very abbreviated list, intended mostly to convey the flavor of the topics. If you would like to donate one or more exercises, I'd love to see them. Of course, you will be credited as the author of any exercises we use. I need these by February 17 in order to have the time to read them over and include them in the manuscript. -Andrew Glassner / glassner@parc.xerox.com ------------------------------------------------------------------- Principles of Digital Image Synthesis (selected topics) by Andrew S. Glassner to be published by Morgan-Kaufmann publishers, July 1994 Unit I: The Human Visual System and Color Chapter 1: The Human Visual System structure and optics of the eye, perception, visual phenomena, depth perception, color sensitivity and matching, illusions Chapter 2: Color Spaces RGB, La*b*, Lu*v*, HSL, HSV, etc. Chapter 3: Displays structure of the CRT, phosphor interactions, monitor design, gamut mapping Unit II: Signal Processing Chapter 4: Signals and Systems signals, linearity, filters, complex exponentials, useful signals (box, delta, sinc, etc.), convolution, 2D signals Chapter 5: Fourier Transforms basis functions, fourier series, fourier transform, filtering, space-frequency duality, discrete-time fourier transform, 2D fourier transforms Chapter 6: Wavelets short-term fourier transform, scale and resolution, dilation equation, Haar wavelets, decomposition and reconstruction, compression, multiresolution analysis, 2D wavelets Chapter 7: Monte Carlo Integration basic ideas, confidence, blind MC (crude, rejection, stratified, quasi, weighted), informed MC (importance, control variates, antithetic variates), multidimensional MC Chapter 8: Uniform Sampling and Reconstruction sampling theorem, reconstruction, 2D sampling, 2D reconstruction, box reconstruction, supersampling, Chapter 9: Nonuniform Sampling and Reconstruction variable sampling density, aliasing and noise, non-uniform sampling, bias, stratified sampling, duality of aliasing and noise Chapter 10: Survey of Sampling and Reconstruction Techniques general procedure, uniform and non-uniform sampling, initial sampling, refinement, interpolation and reconstruction, Unit III: Matter and Energy Chapter 11: Light wave nature, double-slit experiment, polarization, photoelectric effect, wave/particle duality, index of refraction, geometric optics Chapter 12: Energy Transport The rod model, flux, scattering, particle transport in 3D, particle counting, 3D transport, boundary conditions, the integral form of the transport equation Chapter 13: Radiometry radiometric terms and units, relationships, photometry, reflectance, BRDFs Chapter 14: Materials atomic structure, electron distributions, molecular structure, blackbodies, photon distributions, phosphors Chapter 15: Shading survey of shading models, empirical, isotropy, physically based, Fresnel's formulas, anisotropy, programmable, volume scattering, texture, hierarchies of scale, color Chapter 16: Integral Equations classification, operators, solution methods, symbolic methods, quadrature, numerical methods, projection methods (Nystrom, polynomial collocation, galerkin, etc.), Monte Carlo, singularities Chapter 17: The Radiance Equation the radiance equation, solution methods, ray tracing, radiosity, visibility and shading Chapter 18: Vision, Images, and Pictures interaction of rendering and the visual system and displays Appendices: A. Linear Algebra B. Probability C. Historical Notes D. Constants and Units E. Reference Data From shirley@cs.indiana.edu Sat Feb 19 05:53:32 1994 Return-Path: Date: Sat, 19 Feb 1994 08:26:04 -0500 From: "peter shirley" To: globillum@miro.berkeley.edu Subject: volume addition to databases for Euro Rend Workshop Status: RO There has been an addition of two sample density volumes (128^3 and 64^3) to the databases Georgios Sakas and I have prepared for the 5th Eurographics Workshop in Rendering to held in Darmstadt, Germany on 13-15 June, 1994 (The deadline for paper submission is 5 April, 1994). The databases are available via anon ftp from moose.cs.indiana.edu (129.79.254.191) in directory pub/RW5. This directory also contains a README file and a call for participation (call.ps and call.txt). I have appended the change to the README file to this note. I hope to see you all in Germany this summer! Peter Shirley shirley@cs.indiana.edu ----------------------------------------------------------------------- CLOUD VOLUME FILES (subdirectory volume) The two files contain the same 3D cloud in 2 different resolutions. A 'cloud' has been modeled as a density distribution in 3D space, i.e. as a 3D voxel matrix. Each voxel of the cloud represents a 'density' value within the range [0,255]. There are different ways to interpret this 'density': some authors use it as material density between a lower density (usually vacuum, empty space, air, etc.) and a higher density (usually vapor), whereas others employ a a model using number of particles per unit space. In any case, both models work fine and the parameters can be easily converted between the two methods, so this will not be a real problem. Both files have a 12 bytes long header -- which must be skipped -- followed by the actual cloud data. Both clouds are identical in their structure and differ only in the 'level of detail': the file cloud.64 contains 64 x 64 x 64 unsigned chars: <12 bytes header> <64 x 64 x 64 bytes of cloud data> the file cloud.128 contains 128 x 128 x 128 unsigned chars. <12 bytes header> <64 x 64 x 64 bytes of cloud data> NOTE: in order to save space, files have been compressed using the UNIX 'compress' command. In order to receive the original data copy both files cloud.64.Z and cloud.128.Z fiert, and then use the UNIX 'uncompress' command on your local copies. ***************************************************************************** DO NOT FORGET TO CHANGE the ftp-mode to 'binary' BEFORE copying the compressed files !!!!!!!!!!!!! ***************************************************************************** From erich@eye.com Mon Mar 7 16:19:21 1994 Return-Path: Date: Mon, 7 Mar 1994 10:04:03 -0500 From: Eric Haines To: globillum@miro.berkeley.edu Subject: Radiosity Books Status: R I thought I would repost here a note I put on comp.graphics.algorithms, since it's of interest. ------ In reply to a request for information about radiosity In article <1994Mar4.150331.9307@afterlife.ncsc.mil>, wrote: > > Radiosity and Realistic Image Synthesis, > Michael F. Cohen and John R. Wallace, > Academic Press, 1993, ISBN 0-12-178270-0 Then I (Eric Haines) added: This is the best one out there (since there currently aren't any others). I definitely recommend it (me, biased? just because I carpool with one of the authors and went to school with the other?). However, there are two more books soon to come out: Francois Sillion & Claude Puech, "Radiosity and Global Illumination," approx 250 pages, Morgan Kaufmann, ISBN 1-55860-277-1, $49.95, to come out Spring 1994 I don't know a lot about this one other than it appears to be somewhat like Cohen & Wallace's, more of a theory-based book with practical matters covered in general terms. The other is: Ian Ashdown, "Radiosity: A Programmer's Perspective," John Wiley & Sons, to come out Summer 1994 (by SIGGRAPH) Ian's book sounds exciting, as it's meant to be a hands on book with code. Here's what he wrote me (I was going to save this for the Ray Tracing News, but what the hey): Part I Radiosity Models Light Chapter 1 Measuring Light Chapter 2 Radiosity Theory Part II Tools of the Trade Chapter 3 Building an Environment Chapter 4 A Viewing System Part III Radiosity and Realism Chapter 5 Form Factor Determination Chapter 6 Solving the Radiosity Equation Chapter 7 Meshing Strategies Chapter 8 Looking to the Future Appendix A Photometric and Radiometric Definitions Appendix B Eigenvector Radiosity Appendix C Memory Management Issues Appendix D Color Quantization Techniques Appendix E AutoCAD DXF File Format The 512-page book will include 7,500+ lines of documented C++ source code for a fully functional and mostly platform-independent radiosity renderer. Approximately 1,200 lines of C and C++ are used to provide a user interface for Microsoft Windows in 16-bit and 32-bit versions (Windows 3.1 and Win32/Windows NT). I make it very clear in my book that the industry bible is "Radiosity and Realistic Image Synthesis". What I have attempted to provide is an inexpensive ($40) radiosity testbed for personal desktop computers. In it I have implemented a standalone 3-D viewing system with Gouraud shading, color dithering, gamma correction and so forth (Chapters 3 and 4), a review of form factor determination methods and three implementations (hemi-cube, cubic tetrahedron and ray casting), a review of iterative techniques for solving the radiosity equation (with an implementation of progressive refinement radiosity, including the ambient lighting term and positive overshooting), meshing techniques (with an adaptive subdivision implementation), and a review of other radiosity techniques. Despite the title, the underlying mathematics are complete and self-contained. The appendices are still in question - I may not have room to include them in the book (although they will be on the accompanying diskette). Eigenvector radiosity is still partly under development. It presents an efficient direct method (as opposed to an iterative method such as Southwell relaxation) using eigenvalues and eigenvectors for solving the radiosity equation. *end quote from Ian* -- Eric From shirley@cs.indiana.edu Tue Mar 29 17:12:11 1994 Return-Path: Date: Tue, 29 Mar 1994 19:24:20 -0500 From: "peter shirley" To: globillum@miro.berkeley.edu Subject: Reminder-- rendering workshop submissions Status: R (I am sending this in case your siggraph submission just came back in a body bag like mine did :^} ). There is one week left until the submission deadline for the 5th Eurographics Workshop on Rendering in Germany this summer. Attached is some information about the workshop. Latex style files are avaliable by anonymous ftp on: moose.cs.indiana.edu (129.79.254.191) in pub/RW5style and some scene files with sample solutions are in the same machine in pub/RW5. We will be accepting postscript submissions by email. Hope to see you in Darmstadt! ******************************************************************************* 5th Eurographics Workshop on Rendering Call for Contributions Darmstadt, Germany 13-15 June 1994 ******************************************************************************* Aims and Scope: Following four successful workshops (Rennes-1990, Barcelona-1991, Bristol-1992, Paris-1993) we announce the fifth workshop on rendering techniques. In the recent years the workshop has been well established as a major international forum in exchanging experience and knowledge between people from universities, research and industry interested in the different aspects of rendering techniques. Main topics include (but are not restricted to): - Radiosity - Ray tracing - Illumination models - Colour, texture - Sampling, filtering, anti-aliasing - Parallel solutions for rendering Two special themes of this workshop are: - Illumination & rendering of participating media (volume objects, clouds, ...) - Rendering of architectural & CAD models (illumination simulation, real-time rendering, walkthroughs, handling of large datasets, ...) We encourage also papers describing on-going research and providing new techniques, perspectives and applications in the field. Discussions and evaluation of current techniques and future trends greatly contribute to the attractivity of the workshop. Thus, the presentation of the papers to the plenum will be followed by a discussion introduced by an expert of the field. Internationally renowned speakers from research and industry will also present invited papers. Contributions: Authors are requested to send five copies of an extended abstract (4-6 pages) or a full unpublished paper (ca. 10 pages) to the workshop office. Poster presentations are also possible. Please include your telephone, fax and e-mail address. Submissions missing the deadline will still be considered, but with a lower priority. Full versions of all papers will be distributed among the participants as workshop proceedings. Invitations to submit revised versions of the full papers to be published as a book will depend on the quality of the contributions. In order to better compare results of different techniques, a set of test databases will be made available via anonymous ftp. Schedule: 5 April 1994 Submission deadline 5 May 1994 Notification of acceptance for presentation 30 May 1994 Full-paper deadline for the workshop proceedings 13-15 June 1994 Workshop Organization: The workshop is organized by the Fraunhofer Institute for Computer Graphics in Darmstadt in association with Eurographics. The fee will be about 300 DM for EG-members (and 425 DM for non-members), including lunch, coffee breaks, and workshop proceedings. As social event we plan a visit in Heidelberg. A presentation of the research group of Darmstadt (with three different institutions and about 130 staff researchers in Germany, USA and Portugal) including demos and information about activities will also be organized. Papers Chairmen: Georgios Sakas (D), Peter Shirley (USA) Organizing Chairman: Stefan Haas Papers Program Committee: K. Anjyo (J), K. Bouatouch (F), A. Chalmers (UK), M. Cohen (USA), A. Fournier (CAN), S. Green (UK), P. Heckbert (USA), F. Jansen (NL), W. Krueger (D), E. Nakamae (J), L. Neumann (H), S. Pattanaik (IN), C. Puech (F), X. Pueyo (E), W. Purgathofer (A), H. Rushmeier (USA), H.-P. Seidel (D), Ph. Slusallek (D), F. Sillion (F), A. de Sousa (P), G. Ward (USA) Office: Stefan Haas, Fraunhofer-IGD, Wilhelminenstr. 7, 64283 Darmstadt, Germany. Tel: ++49/6151/155-133, fax:++49/6151/155-199, email: haas@igd.fhg.de For detailed information, rendering databases, and authors toolkit including latex styling formats contact haas@igd.fhg.de, gsakas@igd.fhg.de or shirley@cs.indiana.edu From shirley@cs.indiana.edu Mon Apr 4 08:42:41 1994 Return-Path: Date: Mon, 4 Apr 1994 08:10:18 -0500 From: "peter shirley" To: globillum@miro.berkeley.edu Subject: Electronic submission for 5th Rendering Workshop Status: RO Reminder: submissions for the rendering workshop are due tomorrow. We will accept email postscript. Send your submissions to gsakas@igd.fhg.de and CC it to me (shirley@cs.indiana.edu) to be on the safe side. Pete Shirley shirley@cs.indiana.edu PS: Latex style files are avaliable by anonymous ftp on: moose.cs.indiana.edu (129.79.254.191) in pub/RW5style From wp@eibyte.una.ac.at Sun Apr 17 23:45:08 1994 Return-Path: X-Vms-To: EMAIL::"globillum@miro.berkeley.edu" To: globillum@miro.berkeley.edu From: wp@eibyte.una.ac.at Subject: search for complex scenes Date: Mon, 18 Apr 1994 08:19:46 +0200 Status: R Dear all! We are currently developing a very promising radiosity method for VERY complex scenes, i.e. for a huge number of patches (over 1 million), which shall behave linearly with the number of patches. Unfortunately, we are very bad artists and unable to model "nice" and complex scenes for testing and demonstrating purposes. So this mail is to ask all of you: *************************************************************************** *Do you know of any available scene descriptions for our purposes? How can* *we access them? Do you yourself happen to have such scenes? Would you be * *willing to offer us their use? Or do you have any ideas, who else might * *be able to help us? * *************************************************************************** We are a completely non-commercial institute and need the scenes only for testing/publishing purposes for scientific journals/proceedings. We will, of course, always acknowledge the origin of any scene description we use. Thanks for your help! ------------------------------------------------------------------- Werner Purgathofer Tel: +43 (1) 58801 4548 Institute of Computer Graphics Fax: +43 (1) 5874932 Technical University Vienna email: Karlsplatz 13 / 186 purgathofer@eigvs4.una.ac.at A-1040 Vienna / Austria ------------------------------------------------------------------- From shirley@cs.indiana.edu Tue Apr 19 09:26:14 1994 Return-Path: Date: Tue, 19 Apr 1994 10:30:41 -0500 From: "peter shirley" To: globillum@miro.berkeley.edu Subject: survey for rendering workshop Status: R At the 1992 workshop in Bristol, Michael Cohen made an informal survey on the degree to which rendering problems are solved. For the 1994 workshop in Darmstadt we are doing the survey again (along with a few additional questions). We hope this will provide some qualitative derivative information about where rendering is going, and help stimulate discussion at the workshop. Feel free to copy this to other rendering researchers (this is an informal survey). Please answer the following questions and mail your response to shirley@cs.indiana.edu. Peter Shirley & Georgios Sakas 5th Eurographics Workshop on Rendering ============================================================================= 1) Define image synthesis 2) What are the key issues that are still unanswered or not answered well in image synthesis? Rate each issue as unsolved (0) to solved (5). (a) dealing with environmental complexity (b) dealing with human perceptual issues (c) rendering caustics (d) dealing with color (e) parallelization (f) local reflection models (g) the hidden surface problem (h) mapping results to display devices (i) participating media (j) time/space complexity of image synthesis algorithms (k) implementation issues for image synthesis 3) To what extent (0-5) do you agree with the following statement: "the MAIN problem remaining in image synthesis is simply that we cannot model, with sufficient detail, the environments we want to create images of". 4) How far has the image synthesis field come in solving the image synthesis problem? (0-5). 5) How far does the graphics community as a whole think the field has come in solving the image synthesis problem? (0-5). 6) What is the most important problem to work on in image synthesis? 7) How many years have you worked in image synthesis? 8) Additional comments From greg Tue Apr 19 09:44:47 1994 Return-Path: Date: Tue, 19 Apr 94 09:44:31 PDT From: greg (Gregory J. Ward) To: shirley@cs.indiana.edu Subject: Re: survey for rendering workshop Status: R Hi Pete, Here's my survey. I hope you'll distribute the results, as I won't make it again to this year's workshop. (Damned skinflint government!) 1) Define image synthesis The synthesis of images. OK, OK -- the creating of images synthetically. No, wait. I got it! The imaging of synthetic environments. I would define image synthesis as light and camera simulation in a computer model of a (more or less) physical environment. 2) What are the key issues that are still unanswered or not answered well in image synthesis? Rate each issue as unsolved (0) to solved (5). 3 (a) dealing with environmental complexity 2 (b) dealing with human perceptual issues 2 (c) rendering caustics 3 (d) dealing with color 3 (e) parallelization 3 (f) local reflection models 4 (g) the hidden surface problem 4 (h) mapping results to display devices 2 (i) participating media 2 (j) time/space complexity of image synthesis algorithms 2 (k) implementation issues for image synthesis 3) To what extent (0-5) do you agree with the following statement: "the MAIN problem remaining in image synthesis is simply that we cannot model, with sufficient detail, the environments we want to create images of". Cannot or will not? I'd agree with the assertion that most people are unwilling to spend the time at it, but I wouldn't put it outside the realm of possibility. I guess I'd have to agree at level 3 with the statement as written. 4) How far has the image synthesis field come in solving the image synthesis problem? (0-5). About 2. 5) How far does the graphics community as a whole think the field has come in solving the image synthesis problem? (0-5). Probably 3 or 4. 6) What is the most important problem to work on in image synthesis? Creating a standard scene description language for physically-based rendering. Renderers should be a commodity, and we need some kind of standard to make this happen. RIB is not it, nor is Inventor, or any of the many other non-physical description languages out there. Geometry is well-understood and people generally agree on how to describe surfaces and volumes, but materials and light behavior have so far been treated with rampant disrespect. 7) How many years have you worked in image synthesis? Almost 10. 8) Additional comments There is a new project being organized by a couple of guys in Australia that could lead to a very powerful public-domain rendering environment, if we are willing to pitch in and help. Contact Llew Mason and Matt West at "mwest@tartarus.uwa.edu.au" for more information. Have fun in Darmstadt (sniff!). -Greg From globillum-Request@hostess.graphics.cs.cmu.edu Fri Jun 17 15:14:47 1994 Return-Path: Date: Fri, 17 Jun 94 17:57:46 EDT From: Paul.Heckbert@hostess.graphics.cs.cmu.edu To: globillum@cs.cmu.edu Subject: Change of address for "globillum" Status: R Hello "globillum" (global illumination mailing list) readers. I'm the keeper of the "globillum" mailing list, in case I've never introduced myself. The globillum mailing list itself will now be kept on a computer here at Carnegie Mellon, not at Berkeley, where it was located previously. The new address to mail a message to everyone in the group is: globillum@cs.cmu.edu and the address to send messages to have your address changed, added, or removed from the "globillum" list is: globillum-request@cs.cmu.edu If you use the old Berkeley address (globillum@miro.berkeley.edu), it might stop working next week, since they're reconfiguring machines there. While I'm on the subject of mailing lists, would one of you please please please be willing to maintain the mailing list in the future? Although it doesn't take much work, I haven't had the time to do a very good job the past few years. To volunteer, please email me. -Paul Heckbert ph@cs.cmu.edu From globillum-Request@hostess.graphics.cs.cmu.edu Thu Jun 23 04:47:30 1994 Return-Path: Via: uk.ac.bristol; Thu, 23 Jun 1994 12:31:48 +0100 Date: Thu, 23 Jun 94 11:31:11 GMT From: Alan Chalmers To: globillum@cs.cmu.edu Subject: Eastern Europe Directory Status: R The latest version of the Eastern Europe Computer Graphics Contacts Directory (as it appeared at the Spring School on Computer Graphics in Bratislava in June) is now available. If you would like a copy just email me and I will send it in uuencoded compressed postscript format. Best wishes Alan Chalmers From globillum-Request@hostess.graphics.cs.cmu.edu Mon Jul 11 15:45:37 1994 Return-Path: Date: Mon, 11 Jul 94 15:20:36 PDT From: "Gregory J. Ward" To: globillum@cs.cmu.edu Subject: Siggraph and a new format Cc: 72060.2420@compuserve.com, TCVC@ucs.indiana.edu, holly@cam.nist.gov Status: R Hi All, Well, it's getting on towards Siggraph, and those of us who attend usually try to get together for lunch at some point to talk about what we're up to and what we wish we were doing instead. Since I'm going this year, I thought I'd start the ball rolling and suggest a time we could meet. How about Wednesday, July 27th, around noon? To avoid network chaos, please send mail to me directly and I will collect votes. If you can meet on Wednesday and want this time rather than some other, let me know. If you can't meet on Wednesday but want to meet, please write and suggest which other days would work for you. If you don't want to meet or aren't available for lunch during the week or if you aren't coming to Siggraph this year, there is no need to respond to this mail. Please send your responses to . I will try to stick to the Wednesday date even if some of you can't make it, but if there is a majority of votes for some other day then I will change it and announce the change in a subsequent e-mail to the group. Regardless of the outcome, we will have to post the exact location and time of the meeting on the bulletin board at the conference, since we won't know where to go until we're there. (Someone tell me if they have information on how to book a room in advance.) ----------------------- In other news, I've been working on yet another file format for scene information. (This one's different -- really!) I was asked to develop a standard for light fixture geometry by members of the Illuminating Engineering Society (IES) Computer Committee, and I decided to make the exercise a little more general so that the new format would be broadly applicable. The chief advantage over other formats is that it is physically valid and it comes with a standard parser that makes writing translators a breeze. This parser only gives you those entities you know how to handle, e.g. it converts spheres into polygons if you can't handle spheres. I have set up an ftp site for the parser, and included several models and an object library, all taken from Radiance. If you have Mosaic, you can access the URL "file://hobbes.lbl.gov/www/mgf/HOME.html". If you don't have Mosaic, use anonymous ftp to hobbes.lbl.gov and check out the README file in the /www/mgf/ directory. -Greg From dk@crystald.com Tue Jul 12 01:33:24 1994 Return-Path: From: dk@crystald.com Date: Mon, 11 Jul 94 16:26:04 pst To: "Gregory J. Ward" Subject: Re: Siggraph and a new format Status: R Hi All, Well, it's getting on towards Siggraph, and those of us who attend usually try to get together for lunch at some point to talk about what we're up to and what we wish we were doing instead. Since I'm going this year, I thought I'd start the ball rolling and suggest a time we could meet. How about Wednesday, July 27th, around noon? Hi Greg, The *only* time that I have already booked at Siggraph is Wednesday at noon. Any other time is fine, although my schedule will be filling up... -dave From spencer@cgrg.ohio-state.edu Tue Jul 12 04:54:25 1994 Return-Path: Date: Tue, 12 Jul 94 07:54:08 -0400 From: spencer@cgrg.ohio-state.edu (Stephen N. Spencer) To: "Gregory J. Ward" Subject: Siggraph and a new format Status: R Wednesday lunch works for me. Wednesday evening is *out*, though: I have two meetings after 5:30 already. Stephen From shirley@graphics.cornell.edu Tue Jul 12 06:28:02 1994 Return-Path: From: Peter Shirley Subject: Re: Siggraph and a new format To: greg@hobbes.lbl.gov (Gregory J. Ward) Date: Tue, 12 Jul 1994 09:27:45 -0400 (EDT) Status: R I think I can make it wednesday! > > ----------------------- > In other news, I've been working on yet another file format for scene > information. (This one's different -- really!) I was asked to > develop a standard for light fixture geometry by members of the > Illuminating Engineering Society (IES) Computer Committee, and > I decided to make the exercise a little more general so that the > new format would be broadly applicable. The chief advantage over > other formats is that it is physically valid and it comes with > a standard parser that makes writing translators a breeze. This > parser only gives you those entities you know how to handle, e.g. > it converts spheres into polygons if you can't handle spheres. sounds very cool. > > I have set up an ftp site for the parser, and included several models > and an object library, all taken from Radiance. If you have Mosaic, you > can access the URL "file://hobbes.lbl.gov/www/mgf/HOME.html". If you > don't have Mosaic, use anonymous ftp to hobbes.lbl.gov and check out > the README file in the /www/mgf/ directory. > > -Greg > From 72060.2420@compuserve.com Tue Jul 12 07:56:16 1994 Return-Path: <72060.2420@compuserve.com> Date: 12 Jul 94 10:50:26 EDT From: Ian Ashdown <72060.2420@compuserve.com> To: Greg Ward Subject: Lunch Status: R > How about Wednesday, July 27th, around noon? Sounds good to me. -Ian From Paul.Heckbert@hostess.graphics.cs.cmu.edu Tue Jul 12 09:03:18 1994 Return-Path: Date: Tue, 12 Jul 94 11:59:31 EDT From: Paul.Heckbert@hostess.graphics.cs.cmu.edu To: GJWard@lbl.gov Subject: siggraph meeting Status: R Wednesday at noon is ok with me. If that doesn't work out, I suggest Friday at 11:45. My experience with SIGGRAPH is that mid-week, while the exhibition is open, is when things are most hectic. By Friday, things have calmed down a lot, and it's mostly the hard-core people who are still around. But Weds. would be fine with me. thanks for taking the lead on this From dorsey@graphics.cis.upenn.edu Tue Jul 12 09:05:29 1994 Return-Path: From: dorsey@graphics.cis.upenn.edu (Julie Dorsey) Posted-Date: Tue, 12 Jul 1994 12:05:08 -0400 (EDT) Subject: siggraph To: GJWard@lbl.gov Date: Tue, 12 Jul 1994 12:05:08 -0400 (EDT) Status: R Greg, Wednesday, July 27th at noon is good for me. I'm looking forward to seeing your papers. -Julie Dorsey From dorsey@graphics.cis.upenn.edu Wed Jul 13 16:23:41 1994 Return-Path: From: dorsey@graphics.cis.upenn.edu (Julie Dorsey) Posted-Date: Wed, 13 Jul 1994 19:23:21 -0400 (EDT) Subject: Re: siggraph To: greg@hobbes.lbl.gov (Gregory J. Ward) Date: Wed, 13 Jul 1994 19:23:21 -0400 (EDT) Status: RO > > I'm glad you can make it Wednesday. How's your new job? I really like it at Penn, but my husband just finished a PhD in history and found a job at the University of New Hampshire (~50 miles from Boston). I just accepted a position in the architecture school at MIT for the fall. It will be hard to leave here, as I'm just starting to feel settled, but the MIT job seems like an ideal solution to our two-body problem. See you soon. I hope your siggraph preparations are not too frantic! -Julie From globillum-Request@hostess.graphics.cs.cmu.edu Mon Jul 18 10:54:21 1994 Return-Path: Date: Mon, 18 Jul 94 10:27:13 PDT From: "Gregory J. Ward" To: globillum@cs.cmu.edu Subject: Siggraph get-together Status: R Dear Globillumers, Well, I guess I've got all the votes I'm going to get regarding our annual Siggraph meeting. Including myself, there were 9 votes in favor of the Wednesday noon meeting time, one vote against and (I assume) many abstainers. So, Wednesday it will be. We will post something on the bulletin board when we have more specifics (i.e. where), under some obvious name like "Globillum". Please come if you can, and bring whatever show and tell materials you want to share with the group. See you there, -Greg From globillum-Request@hostess.graphics.cs.cmu.edu Tue Aug 2 06:06:50 1994 Return-Path: From: Peter Shirley Subject: Terminolgy, almost done! To: globillum@cs.cmu.edu Date: Tue, 2 Aug 1994 08:53:02 -0400 (EDT) Status: RO Now that Siggraph is over, I am about to send out the results of the terminology survey. There are two loose ends I would like to clear up first. Any help is appreciated. 1) Does anybody have a recent list of CR keywords and categories? Those are those things you see at the start of many papers-- e.g. "I.3.7 [Computer Graphics: Three-Dimensional Graphics and Realism". 2) If your mother-tongue is not english, is there a direct (or used) equivalent to the following terms? rendering realistic rendering photorealistic rendering image synthesis realistic image synthesis photorealistic image synthesis Thanks Pete "worries to much about words" Shirley shirley@barn.graphics.cornell.edu From globillum-Request@hostess.graphics.cs.cmu.edu Fri Aug 5 10:55:44 1994 Return-Path: Date: Fri, 5 Aug 94 13:40:24 EDT From: Paul.Heckbert@hostess.graphics.cs.cmu.edu To: globillum@cs.cmu.edu Subject: about the globillum mailing list Status: R If you ever want an up-to-date list of who's on the globillum mailing list, ftp from host hostess.graphics.cs.cmu.edu the file /usr/ph/ftp/globillum/glob.mailrc . I update this file every time I change the mailing list. This file also contains non-electronic mailing addresses for some people. To join, leave, or change an address in the globillum mailing list, email to globillum-request@cs.cmu.edu -Paul Heckbert ph@cs.cmu.edu From globillum-Request@hostess.graphics.cs.cmu.edu Wed Aug 31 06:35:26 1994 Return-Path: From: Peter Shirley Subject: Terminology survey results To: Global Illumination Mailing List Date: Wed, 31 Aug 1994 09:18:01 -0400 (EDT) Status: R Hello. Enclosed are the (long overdue!) results of my survey on which (if any) of the following terms were preferred to describe making computed images that relate to how things look in the real world (I don't want to say "realistic :^}). I make no explicit suggestions of what this survey is useful for, but I hope everyone will remember how much easier it is to write a paper now that we all have the same term for "radiance". Many people thought rendering was the same as "scan conversion" or rasterizing. Others thought that rendering and image synthesis are synonymous. It is clear that there is not agreement on what rendering means. It is also clear that some think that the "realistic" is implicit in "image synthesis". One thing is for sure-- there is no global agreement! Thanks to all that responded. Pete Shirley graphics.cornell.edu TERM VOTES rendering 3 realistic rendering 6 photorealistic rendering 3 image synthesis 4 realistic image synthesis 16 photorealistic image synthesis 9 (other term) 2 (no pref) 2 ----------- 45 * rendering 12 * image synthesis 29 * 7 realistic * 22 photorealistic * 12 there were three "other term" votes that also expressed a preference among the six offerings, so I counted them as one of the first six categories. The other terms listed were: physically based image synthesis photosimulation virtual image idealistic image synthesis pseudorealistic image synthesis ============================================================================ Here are some translations of the english terms into other languages: >From Christophe Schlick (French): rendering = rendu realistic rendering = rendu realiste photorealistic rendering = rendu photorealiste image synthesis = synth\`ese d'images realistic image synthesis = synth\`ese d'images r\'ealistes photorealistic image synthesis = synth\`ese d'images photor\'ealistes >From Wolfgang Stuerzlinger (German): (photo-)realistic = (Photo-)realistisch no Problem rendering = leisten, abgeben, wiedergeben, machen, ... retranslated: service, give, interpret/translate, make :-( images synthesis = Bild Synthese = Bild Generierung retranslated: picture/image synthesis/generation better alternative >From Per Christensen (Danish): most of the words have direct translations: realistic = realistisk photorealistic = foto-realistisk (this seem like a rather contrived word, even in English) image synthesis = billed-syntese (this is commonly used) Now, as for "rendering" I don't know how to translate it (I've heard the word used/abused untranslated by CG people in Denmark -- where "people" includes myself :-) ). ============================================================================ I also give the ACM CR classifications that are relevant (those crazy numbers and letters at the beginning of siggraph papers...thanks to Pat Hanrahan and Andrew Glassner for sending me these-- they were so hard to get hold of that I will resend them in a separate message). There are some useful categories related to quadrature, integral equations, etc. COMPUTING REVIEWS CLASSIFICATION SCHEME Copyright 1992, by the Association for Computing Machinery, Inc. (many terms deleted) I. Computing Methodologies I.3 COMPUTER GRAPHICS I.3.3 Picture/Image Generation Antialiasing Bitmap and framebuffer operations Digitizing and scanning Display algorithms Line and curve generation Viewing algorithms I.3.7 Three-Dimensional Graphics and Realism Animation Color, shading, shadowing, and texture fractals Hidden line/surface removal Radiosity Raytracing Virtual reality Visible line/surface algorithms ============================================================================ Selections from books on the subject (I wont say what the subject is called)-- this is from a quick browsing-- I hope the authors will correct me if I am mistaken : DIGITAL IMAGE SYNTHESIS by Glassner (coming soon!) Uses realistic image synthesis (but says rendering is a synonym. I like the use of the word digital-- we would have very differnt algorithms if we didn't have limited precision for screen radiance and feature size. RADIOSITY AND REALISTIC IMAGE SYNTHESIS by Cohen and Wallace You can tell from the title... RADIOSITY AND GLOBAL ILLUMINATION by Sillion and Puech: Defines "image synthesis" as the "computation of a picture" in the inroduction. This is consistent with the first two books. AN INTRODUCTION TO RAY TRACING ed. by Glassner Uses both "realistic and photorealistic" in preface, and uses "image syntesis" in the intro which is defined to be "creating a 2-D picture of a 3-D world. Rendering is used in some places in the book as well. From globillum-Request@hostess.graphics.cs.cmu.edu Thu Sep 8 11:31:30 1994 Return-Path: Date: Thu, 8 Sep 94 11:11:16 PDT From: "Gregory J. Ward" To: globillum@cs.cmu.edu Subject: New version of MGF Status: R Fellow Globillumers, About a month and a half ago, I announced a new format called MGF (for Materials and Geometry Format) for exchanging scene data. I have since updated this standard to version 0.7 (still in prerelease) and announced it to the world via comp.graphics and sci.engr.lighting. If you have seen those announcements already, then you may want to skip the rest of this, but I realize that a lot of people either don't get network news or suffer from information overload and don't read it regularly. To remind you, MGF was developed by myself with help from Rob Shakespeare, Ian Ashdown and Holly Rushmeier. It will probably end up being the standard for representing light fixture geometry as part of a new IES (Illuminating Engineering Society) standard for luminaire data, but that's still down the road aways. In the meantime, I am trying to get people to play with the parser and scene/object library to work out problems in the specification and the code, and in hopes of simplifying and promoting data exchange between us research types. Here is a reprint of a recent posting... ------------------------------------------------------------------------- Announcing MGF: Materials and Geometry Format Here we have yet another proposal for a standard graphics scene representation, but with a few notable differences: 1) The material descriptions are physically-based and therefore usable for lighting simulation: radiosity and ray-tracing methods for global illumination. 2) The package includes an ANSI-C parser that makes writing a translator to any native format quick and painless. It also includes a nice library of objects and scenes culled from the Radiance distribution. 3) Use of the parser and library is free. The language was designed by the author and some other lighting and computer graphics experts/enthusiasts. It includes what it needs to include plus a little bit. It is by no means the ultimate scene description, and future attempts to improve the format must be weighed against the benefits of keeping things simple. Also, enhancements to the standard will be made in such a way that they do not place new demands on the programmers who support it. This will be accomplished by updating the parser along with the standard, so each programmer need only support those entities s/he knows how to translate. The parser will translate the rest. Some other basics about MGF: o It is a compact, human-readable ASCII format o It's syntax permits it to be embedded in TCL (I think) o It is strictly boundary-representation (for now) o It is mostly polyhedral, but supports a few conics o Vertices may be named, may have normals, and may be shared o Colors and materials may also be named and put in libraries o It supports full-spectral colors and arbitrary basis functions o It supports one-sided and two-sided surfaces o It supports rigid-body transformations and instancing o Materials may reflect, transmit and emit light To pick up the parser by anonymous ftp, look in the /www/mgf directory of hobbes.lbl.gov (128.3.12.38), or from WWW access the URL: ftp://hobbes.lbl.gov/www/mgf/HOME.html (By the way, we'd welcome links to other WWW sites, as we're isolated at the moment.) Comments are welcome. -Greg Ward Lighting Research Group Lawrence Berkeley Laboratory Berkeley, California GJWard@Lbl.Gov From globillum-Request@hostess.graphics.cs.cmu.edu Fri Sep 23 08:10:02 1994 Return-Path: From: Nico Guenther Subject: A remark on LAMBERT's law To: globillum@cs.cmu.edu Date: Mon, 5 Sep 1994 09:32:02 +0200 (MET DST) Status: RO Dear globillumers, last week I've got the SIGGRAPH-CD, and among the papers one called Generalization of Lambert's Reflectance Model by Michael Oren and Shree K. Nayar. In this paper it is shown, that the Lambert law (the way it is used in Computer Graphics) does not correctly reproduce real diffuse surfaces (like clay). That's right, and I agree. Based on this knowledge a complicated generalization somewhat analogous to the microfacet illumination model is involved. I believe, there is no need to complicate a good and simple law further, because the Lambert law as used in physics is right. However it is misinterpreted in computer graphics (and in thermal engineering - see Siegel and Howards book about Radiative Heat Transfer - too). I intended to publish a (complete) paper concerning the misinterpretation and misuse of good old Lambert in CG. However I think it is time to make the uncomplete pre-version available for discussion. (This version was published in July this year in Rostocker Informatik Berichte(1994) 15.) The paper "Illumination along convex edges" and the pictures can be ftp-ed from ftp.informatik.uni-rostock.de under /pub/graphics/edge_illu.ps.Z and edge_pictures.tar.Z. (The subdir is nearly empty because of a ftp-server-crashdown last week.) Although the final picture of "my" ;-) Lambert interpretation is missing, all important facts are included (I hope so). I know that the facts are somewhat exotic for most CG people, and it may be hard to believe in this. Just read it, and maybe we can have an interesting discussion about it. OK, I'm anxious for the responses. Greetings. Nico (nic@informatik.uni-rostock.de) From globillum-Request@hostess.graphics.cs.cmu.edu Fri Sep 23 09:22:57 1994 Return-Path: Date: 23 Sep 94 12:05:56 EDT From: Ian Ashdown <72060.2420@compuserve.com> To: Global Illumination Subject: Radiosity history Status: RO Paul Heckbert asked me to forward this bit of radiosity history and personal flaming on my part to globillum. It provides evidence that we are not the first to travel this way ... >> I never did find a copy of Moon and Spencer's 1948 "Lighting Design," >> which has the first-ever examples of synthetic images created using >> radiosity techniques. > That's a great bit of trivia that I never heard before! Please share > that with the globillum mailing list! Actually, I included it as an anecdote in an upcoming article entitled "Radiosity Online: A Bibliography" that is scheduled to be published in the next issue of Computer Graphics. I also discuss it briefly in my forthcoming book. Neither discussion, however, gives all the details. For the record, then: The Illuminating Engineering Society of North America has had a long tradition of publishing the best papers from its annual conferences in the Journal of the IES (formerly "Illuminating Engineering"). While most of these papers hold little interest these days, there are still a few gems awaiting rediscovery. One of these papers is: O'Brien, P. F. and J. A. Howard 1959. "Predetermination of Luminances by Finite Difference Equations," Illuminating Engineering 14(4):209- 218 (April). whose abstract reads: Luminous flux transfer in an enclosure may be described by a system of linear simultaneous equations which are a finite difference representation of the Fredholm integral equation. Many techniques of numerical analysis, including analogue and digital computers, are applicable to the solution of these equations. The development of this method for the analysis and synthesis of lighting systems is now being prosecuted actively on a world-wide basis. Truncation errors, an inherent feature of the finite difference equations, can be reduced to acceptable levels. Additional numerical methods need to be explored for applicability to the analysis of lighting systems. The paper is interesting in its own right as an early investigation of the radiosity method. The references, however, are even more interesting. The authors note, for example, that the radiosity equation (which they refer to as simply "the fundamental equation of radiant flux transfer") was first presented by Ziro Yamauti in 1926 and H. Buckley in 1927. There are also interesting papers such as: Centeno, M. and A. Zagustin 1953. "Interflectance in Two Dimensions," Universidad Central de Venezula, Caracas. Radiosity in flatland, perhaps? Perhaps the best part of O'Brien and Howard's paper, however, is the ensuing discussion. The IESNA has had an equally long tradition of publishing the discussions and questions from the floor that follow a paper's presentation. These discussions are sometimes more valuable than the paper itself. For example, Dr. Domina Eberle Spencer had this to say about O'Brien and Howard's paper: The names of O'Brien and Howard are comparatively new to the IES. Their contribution in applying the analogue method to a solution of the basic integral equations of interflection theory by use of the finite difference approach is valuable. However, perhaps due to their comparatively brief association with the Society, they have fallen into several conceptual errors. They say that the "numerical method ... has been developed in the lighting literature only recently." May I remind the authors that nearly thirty years ago Moore and Manning and White were applying such methods to just such problems, and in 1934, the finite difference or numerical approach to the interflection problem was treated in Professor Higbie's excellent book. The new thing about the numerical method is not the method, but the proficiency with which it has recently been applied. The authors also suggests that synthesis of a lighting system is a new idea. The word "synthesis" as applied to illuminating engineering is perhaps new, but the procedure is not. The first application that Professor Moon and I made of the interflection method was to finding what methods could be used to synthesize the optimum lighting environment. We found that for nearly all shapes of rooms, the best way to satisfy the 3:1 adaptation brightness ratio was to make the entire ceiling a source of light. This, as far as we are concerned, was the beginning of luminous ceilings. The practical development of luminous ceilings has merely been a long struggle to realize the synthetic photographs which were exhibited by Professor Moon and myself at the 1946 National Technical Conference. Subsequently, we wrote an entire book on the subject, which the authors cite in their references. Dr. Spencer continues on, ending with: ... If the authors undertake the very commendable task of solving interflection problems with semi-specular surfaces or containing fog, they would do well to think enough about photometric concepts to understand the difference between the visually meaningful concept of brightness and the visually meaningless concept of emittance. The radiosity equation and Fredholm integrals of the second kind in 1926, synthetic photographs in 1946, semispecular surfaces and participating media in 1959 ... we should heed Dr. Spencer's admonishment to O'Brien and Howard that "... they have fallen into several conceptual errors." Until we conduct a thorough investigation of the illumination engineering literature, we should be careful about saying who developed what! Even better, we may discover long-forgotten ideas that are practical with the aid of modern "analogue and digital computers." I had the pleasure of meeting Dr. Spencer at the 1993 IESNA Annual Conference in Houston, Texas. She told me how she and Dr. Parry Moon created their synthetic photographs. In the absence of computers, they calculated the form factor and luminance of each patch by hand, cut out paper squares from Munsell color charts and pasted them together to form their images, which were then photographed. These photographs were reproduced in: Moon, P. and D. E. Spencer 1948. Lighting Design, Addison-Wesley, Cambridge, MA. The framed originals, Dr. Spencer told me, still hang in her office at the Department of Mathematics, University of Conneticut. In these days of instant communications via the Internet (hah!), we tend to forget that there remains an astounding amount of information and ideas available only on paper. More often than not, this information is held in storage by a few university libraries as back issues of obscure journals. This is *not good*. For those convinced that radiosity research began in 1984, consider this isolated quote from a paper written in 1943: The result is an application of the Hilbert-Schmidt theory of integral equations, which leads to the interesting conclusion that the [radiosity equation] kernel has an infinite number of eigenvalues, associated with which is one eigenfunction in the form of a hyperbolic cosine and a set of trigonmetric eigenfunctions. The solution of the inhomogeneous equation is written by means of Schmidt's formula, and it is found that for engineering purposes all the terms but the first can be neglected. The paper in question is: Moon, P. 1943. "New Methods of Calculating Illumination," Journal of the Optical Society of America 33(2):115-122 (February) where the above is added almost as an afterthought. (Does anyone know what this means?) There are no less than 48 references, of which only one is familiar -- Lambert's seminal treatise on photometry from 1760! Consider also that the Russian Academy of Sciences has been publishing important treatises on photometry and radiometry -- in Russian -- for over a century. I think we have a lot of reading to do ... Ian Ashdown, P. Eng. Research and Development Manager Ledalite Architectural Products 9087A - 198th Street Langley, B.C., Canada V3A 4P8 *** That's me -- radiosity's self-appointed gadfly! *** From globillum-Request@hostess.graphics.cs.cmu.edu Fri Sep 23 11:38:21 1994 Return-Path: X400-Received: by mta cs.ubc.ca in /PRMD=/ADMD=/C=/; Relayed; Fri, 23 Sep 1994 10:31:00 UTC-0700 X400-Received: by /PRMD=ca/ADMD=telecom.canada/C=ca/; Relayed; Fri, 23 Sep 1994 10:31:00 UTC-0700 Date: Fri, 23 Sep 1994 10:31:00 UTC-0700 X400-Originator: fournier@cs.ubc.ca X400-Recipients: non-disclosure:; X400-Content-Type: P2-1984 (2) X400-Mts-Identifier: [/PRMD=ca/ADMD=telecom.canada/C=ca/;940923103100] Content-Identifier: 3590 From: Alain Fournier To: Nico Guenther Cc: return Subject: A remark on LAMBERT's law Status: R I think we have a semantic problem here. A law (like Lambert's Law, or the ideal gas law, for example) only applies to whatever obeys it. If it looks like a tautology, it is because it is one. An ideal gas IS a gas which obeys the ideal gas law, a diffuse reflector IS a reflector which obeys Lambert's law (at least according to most optics text, see eg Born & Wolf), and therefore one should not speak of a "non-Lambertian diffuse reflector", unless one redefines what "diffuse" means, or (worse) rewrite Lambert's law but keeps the same name. From globillum-Request@hostess.graphics.cs.cmu.edu Sat Sep 24 13:10:43 1994 Return-Path: X-Authentication-Warning: bechtel.Colorado.EDU: Host localhost.Colorado.EDU didn't use HELO protocol To: globillum@cs.cmu.edu Subject: "Radiosity History" Date: Sat, 24 Sep 94 14:00:44 -0600 From: dilaura@bechtel.colorado.edu Status: RO Ian Ashdown has sent me a copy of his note (broadcast on globillum) concerning the history of radiative transfer applied to illuminating engineering. I might add the following. 1) Moon and Spenser book "Lighting Design" is a rarity but is availble from University Microfilms International, Zeeb Road, Ann Arbor, MI. I got my copy of "Lighting Design" from UMI, and although it is a xerox copy of the original it is quite serviceable. 2) A study of this book, and papers that Moon and Spencer published in The Franklin Journal, shows that their approach was to approximate the kernal that resulted from a statement, in integral equation form, of the radiative transfer problem. They didn't like, nor use, the finite element method applied to this problem. 3) The first extensive use of the finite element method to the radiatvie transfer problem in lighting was, indeed, O'Brien. He wrote of it as the "network" method, lifting an analogy from circuits. His work first appeared in CIE publications and in JOSA in the early 1950's. 4) To be blunt, many of us in the lighting engineering industry wondered what all the fuss was about when the computer graphics community started talking about "radiosity". This (silly) word is superfluous, since there has long been international agreement about terms needed in radiometric and photometric work. The ISO has the (individual governments' ceded) authority to establish such vocabulary. It looks to the CIE (international lighting commission) to do this. The latest edition of the International Lighting Vocabulary is now available. Folks at NIST know how to get ahold of it. 5) The finite element formulation of the raditive transfer problem has been used by lighting engineers for almost 50 years to solve the practical engineering problems that they have faced: typically and commonly to predict the average illuminance a lighting system produces in a room; less typically and only recently more common, to predict the illuminance a lighting system produces at a point in a room. This formulation has been used to design a lighting system, i.e. synthesize, not just to analyze. The advent of the PC produced early versions of software that increased the number of elements so that reasonably useful "synthetic pictures" could be produced. The method wasn't changed, just the size of the problem. This took place in 1982. 6) Concern with the (recent) history of technology is perhaps the fooling away of time by scholars. Perhaps. This point of view might be supported by G. Ward's recent musings about why isn't anyone really using "radiosity". For any one that really needs pictures (to show a client, to solve a lighting problem, and in general to reduce uncertainty) which are photo- graphic in their realism and accurate in their numbers, program like Radiance appear to by the industry's choice. If such pictures aren't needed, then other software IS used by the industry, and it is based on radiative transfer. So knowing our history might just be a (small) part of knowing our discipline well; and as Ian suggested might hold information and techniques that may have a new life on modern computing hardware. David L. DiLaura Senior Instructor - Civil and Architectural Engineering Assoc. Dean for Undergraduate Academic Affiars University of Colorado Boulder, CO 80309 dilaura@bechtel.colorado.edu From globillum-Request@hostess.graphics.cs.cmu.edu Sun Sep 25 09:50:41 1994 Return-Path: X-Authentication-Warning: bechtel.Colorado.EDU: Host localhost.Colorado.EDU didn't use HELO protocol To: globillum@cs.cmu.edu Subject: Post Script Date: Sun, 25 Sep 94 10:44:41 -0600 From: dilaura@bechtel.colorado.edu Status: RO P.S. I believe the deepest thinker (not tinkerer) in radiative transfer was Rudolf Preisendorfer. His book "Radiative Transfer on Discrete Spaces" is difficult, profound and insightful. His formalisms establish an approach to practical problems that put our work on firm mathematical and physical ground. It was published by Pergamon Press; now out of print, but available from UMI. Rudy started this work back in the 1950's when he was wrestling with the radiative transfer problems that arise in predicting light levels, contrasts, and visibilities under water. He was a Scripps for a very long time. Highly recommended. D. DiLaura From globillum-Request@hostess.graphics.cs.cmu.edu Fri Oct 7 17:21:08 1994 Return-Path: Date: Sat, 8 Oct 94 00:39:22 +0100 From: Eduardo Bustillo Iceta To: globillum@cs.cmu.edu Status: R Subject: New free radiosity program I'm a recently graduated mechanical engineering student from Spain. As part of my end of studies project I have developed a radiosity program with the following main characteristics: -Monte Carlo integration to compute diffuse illumination: This permits to have refracted shadows, specular and diffuse reflections, blurry reflections, translucency, texture mapping and any geometry of light sources. -Adaptive subdivision: Objects with big radiosity gradients inside are dynamically subdivided during the radiosity process. -Ray tracing: A postprocess of ray tracing is used to calculate the image. The main characteristics of the algorithm used are: -Depth of field. -Stochastic anti-aliasing. -Optional 3D glasses stereo view. -Acceleration techniques: Three different user selectable techniques are incorporated: -Binary Object Partitioning -Adaptive voxel subdivision (with optimal coordinate system selection) -Z-Buffer for first ray acceleration -Geometry input: It reads 3D Studio v2 geometry files so the only geometric entity supported is the triangle. -Completely written in ANSI C: This way it may be compiled in any system. Actually, my work was done in a PC but I've tried and succeeded in compiling it with no modifications on a DEC OSF/1 and a HP-UX server. If anyone wants a copy of my program (it's free), please feel free to contact me. I am also planning to go to the US in November for about three months. The objective of my visit is to improve my english though I would like to do something interesting at the same time. If anyone knows some interesting seminar or someone who could give me a job related to 3D computer graphics (I'd work for free, of course), I would appreciate very much the information. Eduardo Bustillo Iceta Particular de Basterra 1 48990 Getxo (VIZCAYA) SPAIN Internet address: epabuice@s835cc.bi.ehu.es From globillum-Request@hostess.graphics.cs.cmu.edu Thu Nov 3 09:40:19 1994 Return-Path: Date: Thu, 3 Nov 94 17:34:49 +0100 From: barbara pela Reply-To: barbara pela To: globillum@cs.cmu.edu Subject: old papers by Fock and Yamauti Status: R Hello, Does anyone have a copy of these old papers? Are they in english? %0 Journal Article %A Fock, V.A. %D 1924 %T The Illumination from Surfaces of Arbitrary Shape %B Transactions of the Optical Institute, Leningrad %V 28 %P 1-11 %J Transactions of the Optical Institute, Leningrad %K illuminance, Stoke's theorem %O analytic illuminance determination using Stoke's theorem (historical interest) %0 Report %A Yamauti, Ziro %D 1932 %T Theory of Field of Illumination %I Researches of the Electrotechnical Laboratory, Ministry of Communications %@ 339 %K vector flux, light fields Barbara. From globillum-Request@hostess.graphics.cs.cmu.edu Thu Nov 3 11:14:26 1994 Return-Path: Date: Thu, 3 Nov 94 13:44:59 EST From: Peter Schroder To: barbara.pela@cen.jrc.it Cc: globillum@cs.cmu.edu Subject: old papers by Fock and Yamauti Status: R Date: Thu, 3 Nov 94 17:34:49 +0100 From: barbara pela %0 Journal Article %A Fock, V.A. %D 1924 %T The Illumination from Surfaces of Arbitrary Shape %B Transactions of the Optical Institute, Leningrad %V 28 %P 1-11 %J Transactions of the Optical Institute, Leningrad %K illuminance, Stoke's theorem %O analytic illuminance determination using Stokes' theorem (historical interest) This one's in russian. It derives the double application of Stokes' theorem to the illumination kernel (note that this is not the first time [or the last] that this double contour form was derived). There appears to be a German translation of this which appeared in the same year. I say `appears' since I can't read the russian (but can read the German), but from the looks of the formulas and the figures it seems to treat the same material: @Article{fock24, author = "V. A. Fock", title = "Zur Berechnung der Beleuchtungsst{\"a}rke", journal = "Zeitschrift f{\"u}r Physik", year = "1924", volume = "28", OPTnumber = "", pages = "102--113", month = "September/October", OPTnote = "" } The earliest reference I know of with regards to the double contour integration trick is given in a textbook(!) from 1900: @Book{herman, author = "Robert Alfred Herman", title = "A Treatise on Geometrical Optics", publisher = "Cambridge University Press", year = "1900", OPTeditor = "", OPTvolume = "", OPTseries = "", OPTaddress = "", OPTedition = "", OPTmonth = "", OPTnote = "" } In fact he gives as a homework exercise a computation which has been published many years later as a unique new derivation... He simply derives this form without any reference. From the treatment it sounds like he considers it so self evident that he sees no need to give a reference. Might that mean there are even earlier references to the double contour form? I don't know, but I'd love to know. Herman also gives a most magnificent form for the integral which I haven't seen anyone use (yes, Michael, you still owe me a buck for loosing a bet on this :-)): [...] Herman gives the following form in Exercise 15, Chaper IX of his book Geometrical Optics (1900) \begin{eqnarray*} \int_{\partial{A}_1} \int_{\partial{A}_2} \cos \theta_1 \cos \theta_2 \,\, dx_2\, dx_1 & = & \int_{\partial{A}_1} \int_{\partial{A}_2} -\frac{(\vec{r}\cdot d\vec{x}_1)(\vec{r} \cdot d\vec{x}_2)} {\r^2} \end{eqnarray*} [...] A most amazing little gem. It does not become infinite and is much better behaved numerically (well, almost, it's derivative becomes infinite for r->0). Still a remarkable form. Not to mention the derivation of which is a most enjoyable exercise for the interested reader. :-) [hint: change the second application of Stokes' theorem.] Peter From globillum-Request@hostess.graphics.cs.cmu.edu Thu Nov 3 14:43:31 1994 Return-Path: X-Authentication-Warning: bechtel.Colorado.EDU: Host localhost.Colorado.EDU didn't use HELO protocol To: globillum@cs.cmu.edu Subject: Contour Integration Date: Thu, 03 Nov 94 15:27:43 -0700 From: dilaura@bechtel.colorado.edu Status: R Colleagues: At the risk of appearing vain, and prompted by barbara's recent request for copies of old papers by Fock and Yamaouti, may I announce that this important method has recently been applied to non-diffuse sources? I and a recent graduate student of mine presented a paper at the Illuminating Engineering Society conference in Miami Florida this past August, describing our results. We showed the process for replacing the area integral over a homogenous source (homogeneous, not diffuse) with a contour integral over its edges. I have recently worked through the details of extending this to the problem of replacing the double area integrals with double contour integrals for non-diffuse sources. In practical terms, this permits very rapid calculation of illuminances from real area sources, such as architectural luminaires. The IES papers shows that the computer time investment for the new contour integral method is approximatley 10-15 times less than the (usual) current process of discritizing an area source and applying the so-called inverse square cosine law to calculate the illuminances. The double contour integration for non-diffuse sources apparently allows the determination of non-diffuse form factors. It isn't clear yet what value this will have. I do think it will lead to cleaner and much faster approach to the non-diffuse radiative tranfer problem between surfaces. David L. DiLaura, FIEs Senior Instructor Civil and Architectural Engineering Dept. Univeristy of Colorado Boulder, CO 80309 (303) 492 4168 (voice) (303) 492 7317 (fax) From globillum-Request@hostess.graphics.cs.cmu.edu Thu Nov 3 18:47:40 1994 Return-Path: Date: Fri, 4 Nov 94 11:28:23 JST From: Mikio Shinya To: barbara.pela@cen.jrc.it Subject: Re: old papers by Fock and Yamauti Cc: globillum@cs.cmu.edu Status: R %0 Report %A Yamauti, Ziro %D 1932 %T Theory of Field of Illumination %I Researches of the Electrotechnical Laboratory, Ministry of Communications %@ 339 %K vector flux, light fields I found Yamauchi's paper in the Library. (BTW, the Electrotechnical Laboratory is the root of NTT laboratories). Here's the abstract: The theorie of the illumination field are treated mathematically by using the method of vector analysis. There is proposed the ``illumination vector'' to be distinguished from the field intensity which is the vector generally used. The field due to a luminous source of various emissive nature is treated in the first place and the various principal theorems to calculate the illumination are included and rearranged systematically, which have been heretofore by various authorities and the author. The field in the system of interreflecting surfaces is discussed in the second place. The fundamental integral equations are shown when the surfaces in the system are of both diffused reflection and transmission. Mikio Shinya NTT Human Interface Laboratories shinya@nttarm.ntt.jp From globillum-Request@hostess.graphics.cs.cmu.edu Tue Nov 8 14:31:46 1994 Return-Path: From: fxt@lightscape.com Subject: Hiring at Lightscape Technologies (fwd) To: globillum@cs.cmu.edu Date: Tue, 8 Nov 94 14:00:25 PST Mailer: Elm [revision: 70.85] Status: R Hi everyone: I thought you may know of someone who could be interested in the following message and/or help me circulate it. Thank you, Filippo Tampieri Lightscape Technologies, Inc. 4030 Moorpark Ave., Suite 219 San Jose, CA 95117 fxt@lightscape.com > > > We are planning to hire several new people in the near future. We > are looking for people in the product development area with > experience in any or all of the following areas: > > Event-driven GUI > Object-oriented > Microsoft Windows/Windows NT interface > Iris Inventor > Applications for Entertainment/Special effects > Multiprocessing > > For R&D we are looking for people with experience in the following: > Computational Geometry > Meshing for radiosity > Lighting/Materials/Physically-based rendering > Monte Carlo rendering > > We are also looking for a support manager, a quality assurance manager, > and a technical writer. > > Feel free to forward this to anyone outside the company. > Anyone interested should send or fax resumes to: > > Rod Recker > Lightscape Technologies, Inc. > 4030 Moorpark Ave. > Suite 219 > San Jose, CA 95117 > > fax (408) 246-0255 > > From globillum-Request@hostess.graphics.cs.cmu.edu Thu Nov 24 10:47:18 1994 Return-Path: From: Graham Jones Date: Thu, 24 Nov 1994 18:49:59 +0000 To: globillum@cs.cmu.edu Subject: Material BRDF functions. Status: RO Hello folks, We are beginning to do some work on incorporating materials with non diffuse reflection properties into our work on radiosity. Can anybody give me some pointers to where I might find BRDF's for some real materials, some real data would be even better. Any help would be greatly appreciated ---- Graham Jones Robotics Research Group, E-mail: grj@physiol.ox.ac.uk Department of Engineering Science, University of Oxford, Tel: +44-(0)865-272543 Parks Road, Fax: +44-(0)865-273908 Oxford, OX1 3PJ. From greg Sun Nov 27 14:00:39 1994 Return-Path: Date: Sun, 27 Nov 94 13:59:47 PST From: greg (Gregory J. Ward) To: globillum@cs.cmu.edu, grj@physiol.ox.ac.uk Subject: Re: Material BRDF functions. Status: R I have posted a compressed tar file of BRDF measurements we took with our imaging gonioreflectometer (see Siggraph '92 article for details) on the anonymous ftp account of hobbes.lbl.gov in the /xfer directory. The file is called "brdfs.tar.Z", and make sure to set binary mode before retrieving it. The data format is simple. A short information header describing the material and measurement is followed by 5 columns. The first column is the incident polar angle (measured in degrees from normal). The second column is the incident azimuthal angle (measured in degrees from the predominant axis). The third column is the reflected polar angle and the fourth column is the reflected azimuthal angle. Finally, the fifth column is the BRDF at that point, in steradian^-1. I make no guarantees about this data. In particular, the data is rather noisy and I don't expect it has better than +/-3 degree geometric accuracy or better than +/-5% value accuracy. -Greg From globillum-Request@hostess.graphics.cs.cmu.edu Wed Nov 30 09:25:24 1994 Return-Path: From: zzcgung Subject: Wavelet radiosity question To: globillum@cs.cmu.edu Date: Wed, 30 Nov 1994 16:59:33 +0000 (GMT) Cc: w.t.hewitt@mcc.ac.uk Status: R Hi, I wonder if anyone could answer a couple of questions I have on wavelet radiosity? I sent this off to comp.graphics.algorithms, but have had no response. I would mail the authors direct, but don't have their email addresses .... maybe people here can help? I've been reading Steve Gortler et al's SIGGRAPH 93 paper, and Peter Schr\"{o}der's Eurographics Workshop on Rendering 93 paper. Here is their (flatland) algorithm (everyone know TeX ?): b ~ radiosity, e ~ emitted radiosity, g ~ gathered radiosity, <> ~ inner product, \phi_{i,j}, \psi_{i,j} ~ smooth and detail functions from non-standard wavelet basis Their pseudo-code: 1: = ; 2: K = projectKernel; 3: while ( not converged ) 4: (, ) = Pull(); 5: (, ) = Gather(, , K); 6: = Push (, ); 7: = + ; 8: Display ( ); OK, so this is just repeatedly applying the projected kernel to operate on projected radiosity vector, until convergence. ( b = e + Ke + K^2 e + K^3 e + ............ ) I have two questions: a) why (line 7) do I keep adding the emitted radiosity to my current radiosity estimate, surely this should be: 7: += ; b) why do I have to Push everything to the finest level of the hierarchy before continuing with the next Jacobi iteration? I can see why I have to do this for display, but couldn't this Pull/Push come outside of the loop? I suspect that the answer may be that I can't simply add together coefficients of the functions higher up the basis function hierarchy and get the same answer as adding them together at the finest level (\phi_{L,j}). BUT, I can do this for the Haar basis, so I'm confused - is this just a simple case? question (b) is essentially: is "Push( + , + )" equal to " + " ?????? Any help much appreciated Neil ------------------------------------------------------------------------------- Neil Gatenby, Computer Graphics Unit, Dept of Computer Science, University of Manchester, Oxford Road, Manchester M13 9PL, England Tel:(+44)61 275 6095; Fax:(+44)61 275 6040; Email:n.gatenby@mcc.ac.uk ------------------------------------------------------------------------------- Strive to Survive, Causing Least Suffering Possible.... From globillum-Request@hostess.graphics.cs.cmu.edu Wed Nov 30 11:47:02 1994 Return-Path: Date: Wed, 30 Nov 94 14:22:10 EST From: Peter Schroder To: zzcgung@afs.mcc.ac.uk Cc: globillum@cs.cmu.edu, w.t.hewitt@mcc.ac.uk Subject: Wavelet radiosity question Status: R From: zzcgung Date: Wed, 30 Nov 1994 16:59:33 +0000 (GMT) 7: = + ; OK, so this is just repeatedly applying the projected kernel to operate on projected radiosity vector, until convergence. ( b = e + Ke + K^2 e + K^3 e + ............ ) I have two questions: a) why (line 7) do I keep adding the emitted radiosity to my current radiosity estimate, surely this should be: 7: += ; This is just the rule for the evaluation of the von Neumann series: (1-K)B=B^e -> B=\sum K^n B^e the latter then expands into: B:=B^e (n=0) B:=B^e+KB=B^e+KB^e (n=1) B:=B^e+KB=B^e+K(B^e+KB^e)=... (n=2) This has nothing to do with wavelets or anything. It's just the evaluation of the von Neumann series. b) why do I have to Push everything to the finest level of the hierarchy before continuing with the next Jacobi iteration? I can see why I have to do this for display, but couldn't this Pull/Push come outside of the loop? The PushPull in the inner loop is only neccessary for the non-standard realization of the operator. The reason is that the over representation (averages on all levels of the hierarchy) needs to be consolidated before you can continue. More intuitively, when a child somewhere in the subdivision tree is sending out radiosity this needs to make some contribution to the radiosity at higher (coarser) levels of averaging. Similarly if a parent has received some irradiance than that is also received irradiance at its children and needs to be communicated to them. If you use the standard realization of the operator you don't have to do this. In this case the individual levels of basis functions are linearly independent (sometimes even orthogonal). The price you pay is that you can't get away with O(n) links but O(n log n). The intuitive reason for the latter is that a given receiver basis function will have to get the contributions from all basis functions on the source (log n levels). Whereas for the non-standard operator realization we can have a full (albeit more or less coarse) description of what is going on at each level. In some sense a given level acts as a proxy for all coarser levels. It is not clear to me which one is faster, but PushPull is such a small percentage of the overall running time that I have been reluctant to try do away with it at the cost of intruducing links accross levels. Others have used the standard realization but its very hard to actually compare the cost of two rather different implementations. I prefer the simplicity of the code for the non-standard realization (but am open to being convinced otherwise). It would be an interesting experiment to see just what the difference is in a single implementation so the numbers are actually comparable. Hope this helps. Peter From globillum-Request@hostess.graphics.cs.cmu.edu Mon Dec 19 15:36:34 1994 Return-Path: From: Daniel Kartch Subject: LaTeX2e siggraph document class (beta version 0.6) To: globillum@cs.cmu.edu Date: Mon, 19 Dec 1994 18:09:08 -0500 (EST) Status: R As promised, here's the beta release of the siggraph document class. All bug reports, comments, and suggestions are welcome. +----------------------------------------------------------------------------+ | Daniel Kartch Program of Computer Graphics | | dan@graphics.cornell.edu 580 Theory Center Bldg. | | Office: (607) 255-6704 Cornell University | | Fax: (607) 255-0806 Ithaca, NY 14853 | +----------------------------------------------------------------------------+ # This is a shell archive. Remove anything before this line, # then unpack it by saving it in a file and typing "sh file". # # Wrapped by Daniel Kartch on Mon Dec 19 18:00:30 1994 # # This archive contains: # README siggraph.dtx siggraph.ins # LANG=""; export LANG PATH=/bin:/usr/bin:$PATH; export PATH echo x - README cat >README <<'@EOF' SIGGRAPH class, version 0.6(beta), December 19, 1994 Written by Daniel Kartch Program of Computer Graphics Cornell University dan@graphics.cornell.edu This distribution provides a document class for formatting papers according to the specifications for submission to the annual ACM Siggraph conference. It contains two files: siggraph.dtx siggraph.ins To install it, run siggraph.ins through latex, then place the resulting siggraph.cls file somewhere where TeX can find it. To generate the user's guide, run siggraph.dtx through latex. This is a beta release and hasn't been thoroughly tested yet. Please send me any bug reports, suggestions for improvement, or other comments. I will do my best to fix any problems before the Siggraph submission deadline, but I make no promises. The likelihood of my responding to any given comment is directly proportional to the amount of time before the deadline that the comment is received. This package is distributed in the hope that it will be useful, and to promote compatibility of documents created at different sites, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Please see the siggraph.dtx file for copyright and distribution information. @EOF chmod 664 README echo x - siggraph.dtx cat >siggraph.dtx <<'@EOF' % \iffalse meta-comment % % file: siggraph.dtx % version: 0.6(beta) % date: December 19, 1994 % % Provides `siggraph' document class for use with LaTeX2e. % Formats a document according to ACM Siggraph conference proceedings % specifications. % %% %% Copyright (C) 1994 Daniel Kartch %% Program of Computer Graphics %% Cornell University %% dan@graphics.cornell.edu %% %% This file is distributed in the hope that it will be useful, %% but WITHOUT ANY WARRANTY; without even the implied warranty of %% MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. %% % % This file may be freely copied in whole or in part under the following % conditions: % 1) Unmodified copies may be freely distributed separately or as part % of larger packages. % 2) You may make modified copies of this file for you own personal use, % but you may not distribute modified copies. You may place modifications % in a siggraph.cfg file (see the documentation), and distribute that % file individually or along with this source. However, if you do % so, the .cfg file must contain code to issue a warning when it is % invoked by LaTeX that states: % a) The fact that it is being loaded and it is not part of the % standard distribution % b) What it does (briefly) % c) That it can be disabled by removing or renaming the .cfg file % 3) Excerpts from this file may be freely used and distributed as part % of other macro packages. % % Portions of this file (namely the \@maketitle macro and the commands to % set up 9pt type) are modified versions of those provided with the standard % LaTeX files article.cls file and size10.clo, and their distribution may % be further restricted by the LaTeX copyright. (Probably not, but better % safe than sorry.) % %% %% NOTE: %% This is a beta release and hasn't been thoroughly tested yet. Please %% send me any bug reports, suggestions for improvement, or other comments. %% I will do my best to fix any problems before the Siggraph submission %% deadline, but I make no promises. The likelihood of my responding to %% any given comment is directly proportional to the amount of time before %% the deadline that the comment is received. %% % \fi % % \CheckSum{457} %% \CharacterTable %% {Upper-case \A\B\C\D\E\F\G\H\I\J\K\L\M\N\O\P\Q\R\S\T\U\V\W\X\Y\Z %% Lower-case \a\b\c\d\e\f\g\h\i\j\k\l\m\n\o\p\q\r\s\t\u\v\w\x\y\z %% Digits \0\1\2\3\4\5\6\7\8\9 %% Exclamation \! Double quote \" Hash (number) \# %% Dollar \$ Percent \% Ampersand \& %% Acute accent \' Left paren \( Right paren \) %% Asterisk \* Plus \+ Comma \, %% Minus \- Point \. Solidus \/ %% Colon \: Semicolon \; Less than \< %% Equals \= Greater than \> Question mark \? %% Commercial at \@ Left bracket \[ Backslash \\ %% Right bracket \] Circumflex \^ Underscore \_ %% Grave accent \` Left brace \{ Vertical bar \| %% Right brace \} Tilde \~} %% % % \iffalse % \begin{macrocode} %<+class>\NeedsTeXFormat{LaTeX2e}[1994/06/01] %<+class>\ProvidesClass{siggraph} %<*driver> \ProvidesFile{siggraph.drv} % [1994/12/19 v0.6(beta) %<+class> Siggraph proceedings document class] %<*driver> ] % % \end{macrocode} % % \section{Driver for this document} % % The following contains the driver for generating this document. % It can be extracted from the |.dtx| file with the \dst{} program. % % \begin{macrocode} %<*driver> \documentclass{ltxdoc} \GetFileInfo{siggraph.drv} %\DisableCrossrefs \RecordChanges \OnlyDescription % comment out for full source description \CodelineIndex \begin{document} \DocInput{siggraph.dtx} % \PrintIndex \PrintChanges \end{document} % % \end{macrocode} %\fi % % \newenvironment{mylist}{% % \begin{list}{\labelitemi}{% % \addtolength{\leftmargin}{2em}% % \setlength{\itemindent}{-1em}% % \setlength{\parsep}{0in}% % \setlength{\itemsep}{0.5ex}}}{\end{list}} % % \title{The |siggraph| Document Class Users' Guide\thanks{% % This file has version number \fileversion{} dated \filedate{}.}} % % \author{Daniel Kartch\thanks{dan@graphics.cornell.edu}} % % \date{\filedate} % % \maketitle % % \begin{abstract} % This document class modifies the standard |article| class to conform to % the specifications for papers published in the proceedings of the annual % ACM Siggraph conference. % It sets all the necessary layout parameters and handles the differences % in format between a paper being submitted for blind review and a camera % ready copy of an accepted paper. % Several additional features are also provided. % % \vspace{\baselineskip} % \begin{quote} % NOTE: This class is distributed in the hope that it will be useful, % and to promote compatibility of documents created at different sites. % However it is provided WITHOUT ANY WARRANTY; without even the implied % warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. % Please see the |siggraph.dtx| source file for copyright and distribution % information. % \end{quote} % \end{abstract} % % \section{Introduction} % % This document describes the |siggraph| document class, for use with \LaTeXe{}. % It is intended as a replacement for the various versions of the old % |siggraph.sty| file that have been floating around for years. % It loads in the |article| class and modifies several parameters % to comply with the layout specifications for a paper submitted to % the ACM Siggraph conference. % Currently, these specifications are: % \begin{mylist} % \item $\frac{3}{4}$ inch margins on top and sides, 1 inch margin on bottom % \item two column mode with 2 pica column separation % \item space for copyright is 4.5 pica % \item 9 point type on 10 point baselines % \item titles and section headings are bold sans serif % \item 1 em paragraph indentation % \item no page numbers % \end{mylist} % % The class also allows the user to specify whether the paper is being % submitted for blind review or as a final, camera-ready document. % Based on this specification, it will put the appropriate information % in the title block on the first page. % It will also automatically generate a cover sheet for papers being % submitted for review. % Mechanisms are also provided to allow the user to introduce conditional % text based on this choice. % % \vspace{\baselineskip} % \begin{quote} % This is a beta release and hasn't been thoroughly tested yet. Please % send me any bug reports, suggestions for improvement, or other comments. % I will do my best to fix any problems before the Siggraph submission % deadline, but I make no promises. The likelihood of my responding to % any given comment is directly proportional to the amount of time before % the deadline that the comment is received. % \end{quote} % % \section{Usage} % % To use this class, specify % \begin{verbatim} \documentclass{siggraph} \end{verbatim} % at the beginning of your document. % Any options which can be used with the |article| class can be used here, % with the following exceptions and caveats: % \begin{mylist} % \item The |landscape| and |titlepage| options are disabled. % \item Although |twocolumn| mode is the default, the |onecolumn| option % is still enabled. However, I strongly recommend against using % it. Studies of printed material have shown that, for good % legibility, a line of printed material % should contain no more that ten to twelve words, and at the % 9 point type size used by this class, that limit will be greatly % exceeded in one column mode. I didn't disable the option because % it has been pointed out to me that some people prefer to use % it when submitting their paper for review. If you insist on % using it, I recommend increasing the type size. % \item By default, the document will use 9 point type, which is the % size required by Siggraph for camera ready copies. The |10pt|, % |11pt|, and |12pt| options will override this. % \end{mylist} % % In addition, the following options are provided: % \begin{mylist} % \item[|review| and |cameraready|] These specify whether the paper is % to be formatted as a submission for review or a camera-ready % final copy. The default is |cameraready|. The exact effects % of these options will be discussed later. % \item[|version1994|] The submission specifications may some day change, and % this class will therefore also need to be modified. However, % we will still want older documents to maintain their appearance. % This option says that the paper should be formatted according to % the specifications that were in effect in 1994. Currently, it % doesn't do anything, since these are the only specifications % supported. However, I recommend including it in the options % list so that, if and when new specifications are introduced, % your old papers will not be affected. % \end{mylist} % % \section{Cover Page, Title Block, and Abstract} % % Because, for review papers, the abstract must appear on both the cover % page and the first page, the commands for generating the cover page, title % block, and abstract have been combined into a single command: ^^A % \begin{quote} |\acmopening{|\textit{abstract}|}| \end{quote} % This should be the first text-generating command issued after % |\begin{document}|. % Authors should not use the |\maketitle| command or the |abstract| and % |titlepage| environments. % % \subsection{Data fields} % % In addition to the |\title| and |\author| commands provided by the |article| % class, several other pieces of information can be set. % Each of these commands takes a single argument, the value to which the % corresponding field should be set. % \begin{mylist} % \item |\affiliation| % % If all the authors share an affiliation, it can be set with this % command rather than individually within the author command. % The affiliation will appear centered below the author list. % % \item |\acmcategory| and |\acmformat| % % The paper category (research, systems, ...) and format (short, % long, ...). % % \item |\contactname|, |\contactaddress|, |\contactphone|, |\contactfax|, % |\contactemail| % % These should be used to set the information about the person to % be contacted about the paper. % % \item |\acmpassport| % % The author who will receive compensation if the paper is accepted. % \end{mylist} % % \subsection{Cover page} % % When the |review| option is specified, the |\acmopening| command will % generate a cover sheet. % Placing the |\suppresscover| command in the preamble will prevent this. % The cover sheet will contain: % \begin{mylist} % \item Title % \item Authors % \item Affiliation (if any) % \item Paper category and format % \item Contact information % \item Author to receive compensation % \item Abstract % \end{mylist} % % \subsection{Title block} % % For a camera ready document the title block will contain: % \begin{mylist} % \item Title % \item Authors % \item Affiliation (if any) % \end{mylist} % % If the |review| option is chosen it will instead contain: % \begin{mylist} % \item Title % \item Paper category and format % \end{mylist} % The |review| option will also suppress printing of any information % specified with the |\thanks| command. % % \subsection{Abstract} % % In addition to being printed on the cover sheet (if any), the abstract % will also appear in it's normal position at the beginning of the paper. % % \section{Other Features} % % \subsection{Copyright notice} % % As with the old |siggraph.sty|, this class provides a |\copyrightspace| % command to leave space at the bottom of the first column for the copyright % notice. % This command should be placed after the last footnote that will appear in % the first column. % % \subsection{Conditional text} % % The class also provides the following four commands for writing text % conditional on whether the |cameraready| or |review| option has been % chosen: % \begin{quote}^^A % |\ifcamera{|\textit{thenclause}|}| % % |\ifreview{|\textit{thenclause}|}| % % |\ifcameraelse{|\textit{thenclause}|}{|\textit{elseclause}|}| % % |\ifreviewelse{|\textit{thenclause}|}{|\textit{elseclause}|}| % \end{quote}^^A % The first two will generate the \textit{thenclause} if the |cameraready| % (resp. |review|) option is chosen, otherwise they resolve to a null string. % The second two are the same as the first two but generate the % \textit{elseclause} instead of a null string if the condition is not met. % % These can be used for writing the paper so as to protect anonymity for % a submission for review, without having to worry about going back over it % months later to put the identifying information back in if the paper % is accepted. For example: % \begin{quote}^^A % |In \cite{FooBar1994}, \ifcameraelse{we}{Foo and Bar} showed that ...| % \end{quote} % or % \begin{quote}^^A % |as illustrated in the following \ifcameraelse{three}{two} images:| % % [include generic image] % % |\ifcamera{| [include our logo] |}| % % [include another generic image] % \end{quote} % % \subsection{Configuration file} % % Individual users or sites may wish to modify the behavior of this % class (for instance, to use a particular set of fonts.) % Rather than having people hack the |.cls| file, which can lead to % various incompatible versions at different sites, the class provides % for a configuration file. % After the class has finished loading, it will check to see if a % |siggraph.cfg| file exists in the \TeX{} search path. % If so, it will be input. % Any user-- or site--specific modifications should be placed in this file. % \textit{(See the copyright notice in the |siggraph.dtx| source file for % information on distribution of configuration files.)} % % \StopEventually{} % % \iffalse %<*class> % \fi % % \section{Implementation} % % \begin{quote} % Warning: The implementation is a work in progress and may undergo radical % alterations before the first non-beta release. Do not count on any of % the internal representations remaining the same. Any suggestions for % improving any aspects of the implementation are welcome. % \end{quote} % % \subsection{Initial stuff} % % First off, we need to load in the |ifthen| package and declare the boolean % variable |acm@cameraready|, since we use this in the option handling. % % \begin{macrocode} \RequirePackage{ifthen} \newboolean{acm@cameraready} \newboolean{acm@useninepoint} \setboolean{acm@useninepoint}{true} % \end{macrocode} % % \subsection{Option processing} % % Disable the |titlepage| and |landscape| options. % % \begin{macrocode} \DeclareOption{titlepage}{% \OptionNotUsed% \ClassWarningNoLine{siggraph}{titlepage option not allowed}} \DeclareOption{landscape}{% \OptionNotUsed% \ClassWarningNoLine{siggraph}{landscape option not allowed}} % \end{macrocode} % % Allow |onecolumn|, |10pt|, |11pt|, and |12pt| options, but produce % warnings. % % \begin{macrocode} \DeclareOption{onecolumn}{% \ClassWarningNoLine{siggraph}{One-column mode selected.\MessageBreak% Switching to two-column mode is recommended.}% \PassOptionsToClass{onecolumn}{article}} \DeclareOption{10pt}{% \ClassWarningNoLine{siggraph}{10 point type selected.\MessageBreak% Siggraph camera-ready specifications require 9 point.}% \PassOptionsToClass{10pt}{article}% \setboolean{acm@useninepoint}{false}} \DeclareOption{11pt}{% \ClassWarningNoLine{siggraph}{11 point type selected.\MessageBreak% Siggraph camera-ready specifications require 9 point.}% \PassOptionsToClass{11pt}{article}% \setboolean{acm@useninepoint}{false}} \DeclareOption{12pt}{% \ClassWarningNoLine{siggraph}{12 point type selected.\MessageBreak% Siggraph camera-ready specifications require 9 point.}% \PassOptionsToClass{12pt}{article}% \setboolean{acm@useninepoint}{false}} % \end{macrocode} % % The |review| and |cameraready| options set the |acm@cameraready| flag % % \begin{macrocode} \DeclareOption{review}{\setboolean{acm@cameraready}{false}} \DeclareOption{cameraready}{\setboolean{acm@cameraready}{true}} % \end{macrocode} % % The |version1994| option doesn't need to do anything yet. % % \begin{macrocode} \DeclareOption{version1994}{} % \end{macrocode} % % Pass any remaining options on to the |article| class % % \begin{macrocode} \DeclareOption*{\PassOptionsToClass{\CurrentOption}{article}} % \end{macrocode} % % Set |cameraready| option by default, tell |article| class to % use |twocolumn| mode, and process the options. % % \begin{macrocode} \ExecuteOptions{cameraready} \PassOptionsToClass{twocolumn}{article} \ProcessOptions % \end{macrocode} % % Load in the article class. % % \begin{macrocode} \LoadClass{article} % \end{macrocode} % % \subsection{Page layout} % % Set the margins, header and footer sizes, column separation, and indentation. % Turn off page numbering, and turn on flush-bottom mode. % % \begin{macrocode} \setlength{\textheight}{9.25in} \setlength{\topmargin}{-0.25in} \setlength{\headheight}{0in} \setlength{\headsep}{0in} \setlength{\footskip}{0pc} \flushbottom \pagestyle{empty} \setlength{\textwidth}{7in} \setlength{\oddsidemargin}{-0.25in} \setlength{\evensidemargin}{-0.25in} \setlength{\columnsep}{2pc} \setlength{\parindent}{1em} % \end{macrocode} % % \subsection{Setting up 9pt point type} % % If not overridden, set type size to 9 points. % % \begin{macrocode} \ifthenelse{\boolean{acm@useninepoint}}{ % \end{macrocode} % % The code in this section is a modified version of that found in the % |size10.clo| file from the June 1994 \LaTeX{} distribution, with values % taken from the old |siggraph.sty| file. % % Redefine |\normalsize| to 9 points. % % \begin{macrocode} \renewcommand\normalsize{% \@setfontsize\normalsize\@ixpt\@xpt \abovedisplayskip 9\p@ \@plus2\p@ \@minus4\p@ \abovedisplayshortskip \z@ \@plus3\p@ \belowdisplayshortskip 6\p@ \@plus3\p@ \@minus3\p@ \belowdisplayskip \abovedisplayskip \let\@listi\@listI} % \end{macrocode} % % Redefine |\small| to 8 points. % % \begin{macrocode} \renewcommand\small{% \@setfontsize\small\@viipt\@ixpt \abovedisplayskip 8.5\p@ \@plus3\p@ \@minus4\p@ \abovedisplayshortskip \z@ \@plus2\p@ \belowdisplayshortskip 4\p@ \@plus2\p@ \@minus2\p@ \def\@listi{\leftmargin\leftmargini \topsep 4\p@ \@plus2\p@ \@minus2\p@ \parsep 2\p@ \@plus\p@ \@minus\p@ \itemsep \parsep}% \belowdisplayskip \abovedisplayskip} % \end{macrocode} % % |\footnotesize|, |\scriptsize|, and |\tiny| remain the same as for % 10 point documents. % % \begin{macrocode} \renewcommand\footnotesize{% \@setfontsize\footnotesize\@viiipt{9.5}% \abovedisplayskip 6\p@ \@plus2\p@ \@minus4\p@ \abovedisplayshortskip \z@ \@plus\p@ \belowdisplayshortskip 3\p@ \@plus\p@ \@minus2\p@ \def\@listi{\leftmargin\leftmargini \topsep 3\p@ \@plus\p@ \@minus\p@ \parsep 2\p@ \@plus\p@ \@minus\p@ \itemsep \parsep}% \belowdisplayskip \abovedisplayskip} \renewcommand\scriptsize{\@setfontsize\scriptsize\@viipt\@viiipt} \renewcommand\tiny{\@setfontsize\tiny\@vpt\@vipt} % \end{macrocode} % % All the larger than normal sizes get decremented one step from their % values in 10 point documents. % % \begin{macrocode} \renewcommand\large{\@setfontsize\large\@xpt\@xiipt} \renewcommand\Large{\@setfontsize\Large\@xiipt{14}} \renewcommand\LARGE{\@setfontsize\LARGE\@xivpt{18}} \renewcommand\huge{\@setfontsize\huge\@xviipt{22}} \renewcommand\Huge{\@setfontsize\Huge\@xxpt{25}} % \end{macrocode} % % End 9 point if-then-else conditional % % \begin{macrocode} }{} % \end{macrocode} % % \subsection{Section headings} % % Redefine the section headings to use bold sans serif type. (Otherwise % these are the same definitions given in the |classes.dtx| file.) % % \begin{macrocode} \renewcommand\section{\@startsection {section}{1}{\z@}% {-3.5ex \@plus -1ex \@minus -.2ex}% {2.3ex \@plus.2ex}% {\reset@font\Large\sffamily\bfseries}} \renewcommand\subsection{\@startsection{subsection}{2}{\z@}% {-3.25ex\@plus -1ex \@minus -.2ex}% {1.5ex \@plus .2ex}% {\reset@font\large\sffamily\bfseries}} \renewcommand\subsubsection{\@startsection{subsubsection}{3}{\z@}% {-3.25ex\@plus -1ex \@minus -.2ex}% {1.5ex \@plus .2ex}% {\reset@font\normalsize\sffamily\bfseries}} \renewcommand\paragraph{\@startsection{paragraph}{4}{\z@}% {3.25ex \@plus1ex \@minus.2ex}% {-1em}% {\reset@font\normalsize\sffamily\bfseries}} \renewcommand\subparagraph{\@startsection{subparagraph}{5}{\parindent}% {3.25ex \@plus1ex \@minus .2ex}% {-1em}% {\reset@font\normalsize\sffamily\bfseries}} % \end{macrocode} % % \subsection{Camera-ready/review conditional text} % % Define commands to perform actions conditionally based on whether % the document is being submitted for review or for printing. % % \begin{macrocode} \newcommand{\ifcamera}[1]{\ifthenelse{\boolean{acm@cameraready}}{#1}{}} \newcommand{\ifreview}[1]{\ifthenelse{\boolean{acm@cameraready}}{}{#1}} \newcommand{\ifcameraelse}[2]{\ifthenelse{\boolean{acm@cameraready}}{#1}{#2}} \newcommand{\ifreviewelse}[2]{\ifthenelse{\boolean{acm@cameraready}}{#2}{#1}} % \end{macrocode} % % \subsection{Cover page, title block and abstract} % % Define internal commands to hold the information for the cover page and % title block, plus user commands to set them. Also turn off the |\thanks| % command when producing a review copy. % % \begin{macrocode} \newcommand{\@affiliation}{} \newcommand{\affiliation}[1]{\renewcommand{\@affiliation}{#1}} \newcommand{\acm@category}{} \newcommand{\acmcategory}[1]{\renewcommand{\acm@category}{#1}} \newcommand{\acm@format}{} \newcommand{\acmformat}[1]{\renewcommand{\acm@format}{#1}} \newcommand{\acm@contactname}{} \newcommand{\contactname}[1]{\renewcommand{\acm@contactname}{#1}} \newcommand{\acm@contactaddress}{} \newcommand{\contactaddress}[1]{\renewcommand{\acm@contactaddress}{#1}} \newcommand{\acm@contactphone}{} \newcommand{\contactphone}[1]{\renewcommand{\acm@contactphone}{#1}} \newcommand{\acm@contactfax}{} \newcommand{\contactfax}[1]{\renewcommand{\acm@contactfax}{#1}} \newcommand{\acm@contactemail}{} \newcommand{\contactemail}[1]{\renewcommand{\acm@contactemail}{#1}} \newcommand{\acm@passport}{} \newcommand{\acmpassport}[1]{\renewcommand{\acm@passport}{#1}} \ifthenelse{\boolean{acm@cameraready}}{}{\renewcommand{\thanks}[1]{}} % \end{macrocode} % % Set up a control to determine whether or not to print the cover page. % % \begin{macrocode} \newboolean{acm@cover} \setboolean{acm@cover}{true} \newcommand{\suppresscover}{\setboolean{acm@cover}{false}} % \end{macrocode} % % The following internal macro is used to format the cover page. % % \begin{macrocode} \newcommand{\acm@coverpage}{% \begin{titlepage}% \begin{center}% \vspace*{\fill} {\LARGE\sffamily \@title \par}% \vspace{2\baselineskip}% {\large \begin{tabular}[t]{c}% \@author \end{tabular}\par}% \vspace{1\baselineskip}% {\large \@affiliation \par}% \addvspace{3\baselineskip}% {Category: \acm@category \par}% \vspace{0.5\baselineskip}% {Format: \acm@format \par}% \vspace{3\baselineskip}% \begin{tabular}{ll} Contact: & \acm@contactname \\[1\baselineskip] & \begin{tabular}[b]{@{}l@{}} \acm@contactaddress \end{tabular} \\[1\baselineskip] phone: & \acm@contactphone \\ fax: & \acm@contactfax \\ email: & \acm@contactemail \end{tabular}\par% \vspace{3\baselineskip}% Author to receive compensation: \acm@passport \par% \vspace{4\baselineskip}% \begin{minipage}{5in}% \acm@abstract \end{minipage}% \vspace*{\fill} \end{center}% \end{titlepage}} % \end{macrocode} % % We redefine the \@maketitle command to leave out the date, and either % add the affiliation (for a camera ready paper), or replace the authors % with the paper category and format (for a submission for review). % % \begin{macrocode} \renewcommand{\@maketitle}{% \begin{center}% {\LARGE\sffamily \@title \par}% \vspace{1\baselineskip}% \ifreviewelse{% {Category: \acm@category \par}% \vspace{0.25\baselineskip}% {Format: \acm@format \par}% }{% \large \begin{tabular}[t]{c}% \@author \end{tabular}\par% }% \end{center} \par% \vspace{0.5in}} % \end{macrocode} % % Now we set up the |\acmopening| command to output the cover page, title % block, and abstract, and turn off the page numbering on the first page. % % \begin{macrocode} \newcommand{\acmopening}[1]{% \newcommand{\acm@abstract}{#1}% \ifthenelse{\boolean{acm@cover}}{\ifreview{\acm@coverpage}}{}% \maketitle \thispagestyle{empty} \begin{abstract} #1 \end{abstract}} % \end{macrocode} % % Create the macro to leave space for the copyright. % \begin{macrocode} \newcommand{\copyrightspace}{% \renewcommand{\thefootnote}{}% \footnotetext[0]{\rule[4.5pc]{1in}{0in}}% \renewcommand{\thefootnote}{\arabic{footnote}}} % \end{macrocode} % % \subsection{Configurations file} % % Finally, we load the configuration file if it exists. % % \begin{macrocode} \InputIfFileExists{siggraph.cfg} {\typeout{***************************************^^J% * Local config file siggraph.cfg used *^^J% ***************************************}} {} % \end{macrocode} % % \iffalse % % \fi % % \Finale @EOF chmod 644 siggraph.dtx echo x - siggraph.ins cat >siggraph.ins <<'@EOF' \def\batchfile{siggraph.ins} \input docstrip.tex \keepsilent \generateFile{siggraph.cls}{t}{\from{siggraph.dtx}{class}} @EOF chmod 664 siggraph.ins exit 0 From globillum-Request@hostess.graphics.cs.cmu.edu Tue Jan 3 21:28:17 1995 Return-Path: Date: 04 Jan 95 00:15:45 EST From: Ian Ashdown <72060.2420@compuserve.com> To: Global Illumination Subject: Bibliography - HELP! Status: R HELP! I took over the maintenance of Eric Haines' RADBIB radiosity bibliography earlier this year. Happily, 1994 was a *very* good year for radiosity and global-illumination related books and papers. To date, I've found references to 5 books and 60 papers. My problem is that it is very difficult to track down some of the more obscure papers, especially university technical reports and European conference proceedings. I am therefore asking for a few minutes of your time. The following message (Biblio - 1994 Additions) contains the 1994 additions to the bibliography. (It's over 560 lines long, so download it at your peril.) If you or your graduate students have published *anything* related to global illumination this year, would you please check to see whether I have included it. If not, then I would very much appreciate having you send me the appropriate reference via e-mail. (I would appreciate receiving a copy of your paper even more!) To save you some time, here's the list of publications I've already referenced: * 1994 Illuminating Engineering Society Annual Conference * ACM SIGGRAPH '94 Proceedings * Computer Graphics Forum * Computers & Graphics * Fifth Eurographics Workshop on Rendering * 4th Discrete Geometry for Computer Imagery * IEEE Computer * International Journal of Lighting Research and Technology * LICHT * Proceedings of Pacific Graphics '94 / CADDM '94 * Proceedings of the Winter School of Computer Graphics '94 The current release of the bibliography is available via ftp from: hobbes.lbl.gov as /pub/doc/RadBib94.Z siggraph.org in the database "biblio" through the "biblook" program and through the World Wide Web at the URL: http://siggraph.org/library/bibliography/bibliography.hmtl The next release will be sometime this month. Thanks for your cooperation. Ian Ashdown, President byHeart Software Limited 620 Ballantree Road West Vancouver, B.C. Canada V7S 1W3 From globillum-Request@hostess.graphics.cs.cmu.edu Tue Jan 3 21:50:07 1995 Return-Path: Date: 04 Jan 95 00:16:42 EST From: Ian Ashdown <72060.2420@compuserve.com> To: Global Illumination Subject: Biblio - 1994 Additions Status: RO RADIOSITY / GLOBAL ILLUMINATION BIBLIOGRAPHY - 1994 ADDITIONS *** PAPERS (60) *** %A James Arvo %T The Irradiance Jacobian for Partially Occluded Polyhedral Sources %J Computer Graphics Proceedings, Annual Conference Series, 1994 (ACM SIGGRAPH '94 Proceedings) %P 343-350 %D 1994 %A James Arvo %A Kenneth Torrance %A Brian Smits %T A Framework for the Analysis of Error in Global Illumination Algorithms %J Computer Graphics Proceedings, Annual Conference Series, 1994 (ACM SIGGRAPH '94 Proceedings) %P 75-84 %D 1994 %A H. Bao %A Q. Peng %T An Efficient Form-Factor Evaluation Algorithm for Environments with Curved Surfaces %J Computers & Graphics %V 18 %N 4 %P 481-486 %D April 1994 %A Markus Beyer %T Approximation der Rendering Equation durch Evolutionare Algorithmen %R Diplomarbeit %I Technische Hochschule %C Darmstadt, Germany %D 1994 %A Markus Beyer %A Brigitta Lange %T Rayvolution: An Evolutionary Ray Tracing Algorithm %J Fifth Eurographics Workshop on Rendering %C Darmstadt, Germany %D June 1994 %P 137-146 %A Philippe Blasi %A Bertrand Le Saec %A Christophe Schlick %T An Importance Driven Monte-Carlo Solution to the Global Illumination Problem %J Fifth Eurographics Workshop on Rendering %C Darmstadt, Germany %D June 1994 %P 173-183 %A An-Seop Choi %A Richard G. Mistrick %T A Study of Lighting System Performance in Partitioned Spaces %J 1994 Illuminating Engineering Society Annual Conference Technical Papers %I Illuminating Engineering Society, 345 East 47th Street, New York, NY 10017 %P 453-480 %C Miami, FL %D August 7-11, 1994 %A Per H. Christensen %A Eric J. Stollnitz %A David H. Salesin %A Tony D. DeRose %T Importance-driven Wavelet Radiance %R Technical Report 94-01-05 %I Department of Computer Science and Engineering, University of Washington %C Seattle, Washington %D January 1994 %A Per H. Christensen %A Eric J. Stollnitz %A David H. Salesin %A Tony D. DeRose %T Wavelet Radiance %J Fifth Eurographics Workshop on Rendering %C Darmstadt, Germany %D June 1994 %P 287-302 %A Steven Collins %T Adaptive Splatting for Specular to Diffuse Light Transport %J Fifth Eurographics Workshop on Rendering %C Darmstadt, Germany %D June 1994 %P 119-135 %A David L. DiLaura %A Jeffrey Quinlan %T Non-Diffuse Radiative Transfer I: Planar Area Sources and Point Receivers %J 1994 Illuminating Engineering Society Annual Conference Technical Papers %I Illuminating Engineering Society, 345 East 47th Street, New York, NY 10017 %P 633-660 %C Miami, FL %D August 7-11, 1994 %A George Dretakkis %T Structured Sampling and Reconstruction of Illumination for Image Synthesis %R CSRI Technical Report 293 %I Department of Computer Science, University of Toronto %C Toronto, Ontario %D January 1994 %Z available via anonymous ftp as: ftp.csri.toronto.edu:csri-technical-reports/293 %A George Dretakkis %T Simplifying the Representation of Radiance from Multiple Emitters %J Fifth Eurographics Workshop on Rendering %C Darmstadt, Germany %D June 1994 %P 259-272 %A George Dretakkis %A Eugene Fiume %T A Fast Shadow algorithm for Area Light Sources Using Backprojection %J Computer Graphics Proceedings, Annual Conference Series, 1994 (ACM SIGGRAPH '94 Proceedings) %P 223-230 %D 1994 %A Philip Dutre %A Yves D. Willems %T Importance-Driven Monte Carlo Light Tracing %J Fifth Eurographics Workshop on Rendering %C Darmstadt, Germany %D June 1994 %P 185-194 %A Pavol Elias %A Martin Feda %A Peter Ferschin %A Werner Purgathofer %T Cubic Monte Carlo Radiosity %J Proceedings of the Winter School of Computer Graphics '94 %E V. Skala %C Plzen, Czech Republic %D January 1994 %A Martin Feda %A Werner Purgathofer %T A Median Cut Algorithm for Efficient Sampling of Radiosity Functions %J Computer Graphics Forum (Eurographics '94 Proceedings) %V 13 %N 3 %P C433-C442 %D 1994 %A David A. Forsyth %A Chien Yang %A Kim Teo %T Efficient Radiosity in Dynamic Environments %J Fifth Eurographics Workshop on Rendering %C Darmstadt, Germany %D June 1994 %P 313-323 %A Neil Gatenby %T Incorporating Hierarchical Radiosity into Discontinuity Meshing Radiosity %R PhD thesis %I University of Manchester %C Manchester, UK %D 1994 %A Neil Gatenby %A W. T. Hewitt %T Optimizing Discontinuity Meshing Radiosity %J Fifth Eurographics Workshop on Rendering %C Darmstadt, Germany %D June 1994 %P 249-258 %A Reid Gershbein %A Peter Schroder %A Pat Hanrahan %T Textures and Radiosity: Controlling Emission and Reflection from Texture Maps %R Technical report CS-TR-449-94 %I Princeton University %D March 1994 %A Reid Gershbein %A Peter Schroder %A Pat Hanrahan %T Textures and Radiosity: Controlling Emission and Reflection with Texture Maps %J Computer Graphics Proceedings, Annual Conference Series, 1994 (ACM SIGGRAPH '94 Proceedings) %P 51-58 %D 1994 %A Nicolas Holzschuch %A Francois Sillion %A George Dretakkis %T An Efficient Progressive Refinement Strategy for Hierarchical Radiosity %J Fifth Eurographics Workshop on Rendering %C Darmstadt, Germany %D June 1994 %P 343-357 %A Eric P. Lafortune %A Yves D. Leuven %T A Theoretical Framework for Physically Based Rendering %J Computer Graphics Forum %V 13 %N 2 %D June 1994 %P 97-107 %A Eric P. Lafortune %A Yves D. Willems %T The Ambient Term as a Variance Reducing Technique for Monte Carlo Ray Tracing %J Fifth Eurographics Workshop on Rendering %C Darmstadt, Germany %D June 1994 %P 163-171 %A Eric Languenou %A Kadi Bouatouch %A Michelle Chelle %T Global Illumination in Presence of Participating Media with General Properties %J Fifth Eurographics Workshop on Rendering %C Darmstadt, Germany %D June 1994 %P 69-85 %A Dani Lischinski %T Accurate and Reliable Algorithms for Global Illumination %R PhD thesis %I Cornell University %C Ithaca, NY %D 1994 %A Dani Lischinski %T Incremental Delaunay Triangulation %B Graphics Gems IV %E Paul S. Heckbert %I Academic Press Professional %C San Diego, CA %D 1994 %P 47-59 %A Dani Lischinski %A Brian Smits %A Donald P. Greenberg %T Bounds and Error Estimates for Radiosity %J Computer Graphics Proceedings, Annual Conference Series, 1994 (ACM SIGGRAPH '94 Proceedings) %P 67-74 %D 1994 %A Nelson L. Max %T Efficient Light Propagation for Multiple Anisotropic Volume Scattering %J Fifth Eurographics Workshop on Rendering %C Darmstadt, Germany %D June 1994 %P 87-104 %A Christian Metge %A Rene Caubet %T A Discrete Global Illumination Method %J 4th Discrete Geometry for Computer Imagery %C Grenoble, France %D September 1994 %P 77-88 %A Stefan Muller %A Frank Schoffel %T Fast Radiosity Repropagation for Interactive Virtual Environments Using a Shadow-Form-Factor-List %J Fifth Eurographics Workshop on Rendering %C Darmstadt, Germany %D June 1994 %P 325-342 %A Karol Myszkowski %A Tosiyasu L. Kunii %T Texture Mapping as an Alternative for Meshing During Walkthrough Animation %J Fifth Eurographics Workshop on Rendering %C Darmstadt, Germany %D June 1994 %P 375-388 %A Laszlo Neumann %T New Efficient Algorithms with Positive Definite Radiosity Matrix %J Fifth Eurographics Workshop on Rendering %C Darmstadt, Germany %D June 1994 %P 219-237 %A Laszlo Neumann %T Monte Carlo Radiosity %J Computing %I Springer-Verlag %D submitted for publication 1994 %A Laszlo Neumann %A Martin Feda %A Manfred Kopp %A Werner Purgathofer %T A New Stochastic Radiosity Method for Highly Complex Scenes %J Fifth Eurographics Workshop on Rendering %C Darmstadt, Germany %D June 1994 %P 195-206 %A Jeffry S. Nimeroff %A Eero Simoncelli %A Julie Dorsey %T Efficient Re-rendering of Naturally Illuminated Environments %J Fifth Eurographics Workshop on Rendering %C Darmstadt, Germany %D June 1994 %P 359-373 %A M. Nithisoontorn %T Shooting Algorithm for Illuminance: Comparison of Prediction with Experiment %J International Journal of Lighting Research and Technology %V 26 %N 1 %P 13-18 %D 1994 %A Sumanta N. Pattanaik %A Kadi Bouatouch %T Fast Wavelet Radiosity Method %J Computer Graphics Forum (Eurographics '94 Proceedings) %V 13 %N 3 %P C407-C420 %D September 1994 %A Sumanta N. Pattanaik %A Kadi Bouatouch %T Haar Wavelet: A Solution to Global Illumination with General Surface Properties %J Fifth Eurographics Workshop on Rendering %C Darmstadt, Germany %D June 1994 %P 273-286 %A M. Paulin %A J-P. Jessel %T Adaptive Mesh Generation for Progressive Radiosity: A Ray-tracing Based Algorithm %J Computer Graphics Forum (Eurographics '94 Proceedings) %V 13 %N 3 %D 1994 %P C421-C432 %A Holly Rushmeier %T Rendering Participating Media: Problems and Solutions from Application Areas %J Fifth Eurographics Workshop on Rendering %C Darmstadt, Germany %D June 1994 %P 35-56 %A Christophe Schlick %T A Survey of Shading and Reflectance Models %J Computer Graphics Forum %V 13 %N 2 %P 121-131 %D June 1994 %A Peter Schroder %A Steven J. Gortler %A Michael F. Cohen %A Pat Hanrahan %T Wavelet Projections for Radiosity %J Computer Graphics Forum %V 13 %N 2 %D June 1994 %P 141-151 %A Francois Sillion %T Clustering and Volume Scattering for Hierarchical Radiosity Calculations %J Fifth Eurographics Workshop on Rendering %C Darmstadt, Germany %D June 1994 %P 105-117 %A Jaswinder P. Singh %T Parallel Hierarchical N-Body Methods and their Implications for Multiprocessors %R Technical Report CSL-TR-93-563 %I Computer Systems Laboratory, Stanford University %C Stanford, CA %D February 1993 %A Jaswinder P. Singh %A Annop Gupta %A Marc Levoy %T Parallel Visualization Algorithms: Performance and Architectural Implications %J IEEE Computer %V 27 %N 7 %D July 1994 %P 45-55 %A Brian Smits %T Efficient Hierarchical Radiosity for Complex Environments %R PhD thesis %I Cornell University %C Ithaca, NY %D 1994 %A Brian Smits %A James Arvo %A Donald Greenberg %T A Clustering Algorithm for Radiosity in Complex Environments %J Computer Graphics Proceedings, Annual Conference Series, 1994 (ACM SIGGRAPH '94 Proceedings) %P 435-442 %D 1994 %A A. James Stewart %A Sherif Ghali %T Fast Computation of Shadow Boundaries using Spatial Coherence and Backprojection %J Computer Graphics Proceedings, Annual Conference Series 1994 (ACM SIGGRAPH '94 Proceedings) %P 231-238 %D 1994 %A W. Sturzlinger %T Adaptive Mesh Refinement with Discontinuities for the Radiosity Method %J Fifth Eurographics Workshop on Rendering %C Darmstadt, Germany %D June 1994 %P 239-248 %A W. Sturzlinger %A C. Wild %T Parallel Progressive Radiosity with Parallel Visibility Computations %J Proceedings of the Winter School of Computer Graphics '94 %E V. Skala %C Plzen, Czech Republic %D January 1994 %P 66-74 %A Seth Teller %A Celeste Fowler %A Thomas Funkhouser %A Pat Hanrahan %T Partitioning and Ordering Large Radiosity Computations %J Computer Graphics Proceedings, Annual Conference Series, 1994 (ACM SIGGRAPH '94 Proceedings) %P 443-450 %D 1994 %A P. R. Tregenza %T Daylighting Computation: Radiosity Method Using Triangular Patches %J International Journal of Lighting Research and Technology %V 26 %N 1 %P 1-7 %D 1994 %A Clemens Tropp %T Eine Praxisorientierte Software fur Realitatsgetreure 3D-Lichtsimulation (Practically Oriented Software for Highly Realistic 3-D Light Simulation) %J LICHT %V 7/8 %D 1994 %P 578-580 %I Pflaum Verlag GmbH & Co. KG %C Munchen, Germany %O ISSN 0024-2861 %A Eric Veach %A Leonidas Guibas %T Bidirectional Estimators for Light Transport %J Fifth Eurographics Workshop on Rendering %C Darmstadt, Germany %D June 1994 %P 147-162 %A Gregory J. Ward %T The RADIANCE Lighting Simulation and Rendering System %J Computer Graphics Proceedings, Annual Conference Series, 1994 (ACM SIGGRAPH '94 Proceedings) %P 459-472 %D 1994 %A Gregory J. Ward %T Applications of RADIANCE to Architecture and Lighting Design %J 1994 Illuminating Engineering Society Annual Conference Technical Papers %I Illuminating Engineering Society, 345 East 47th Street, New York, NY 10017 %P 633-660 %C Miami, FL %D August 7-11, 1994 %P 777-791 %A Wei Xu %A Donald S. Fussell %T Constructing Solvers for Radiosity Equation Systems %J Fifth Eurographics Workshop on Rendering %C Darmstadt, Germany %D June 1994 %P 207-217 %A Wei Xu %A Donald S. Fussell %T A Fast Solver of Radiosity Equation Systems %J Proceedings of Pacific Graphics '94 / CADDM '94 %C Beijing, China %D August 1994 *** BOOKS (5) *** %E P. Brunet %E F. W. Jansen %B Photorealistic Rendering in Computer Graphics %I Springer-Verlag %C Berlin, Germany %D 1994 %O Proceedings of the Second Eurographics Workshop on Rendering, Barcelona, Spain, May 1991 %A Ian Ashdown %B Radiosity: A Programmer's Perspective %I John Wiley & Sons %C New York %D 1994 %O ISBN 0-471-30444-1 (without diskette) %O ISBN 0-471-30488-3 (with MS-Windows diskette) %A William Parsons Newhall, Jr. %B PC Graphics Unleashed %E SAMS Publishing (various editors) %I SAMS Publishing %C Indianapolis, Indiana %D 1994 %P 501-575 (Chapter 18) %O ISBN 0-672-30570-4 (includes CD-ROM) %A William Parsons Newhall, Jr. %B From Ray Tracing to Radiosity %I SAMS Publishing %C Indianapolis, Indiana %D 1995 (to be published) %O ISBN 0-672-30497-X (includes CD-ROM) %A Francois Sillion %A Claude Puech %B Radiosity and Global Illumination %I Morgan Kaufmann %C San Francisco %D 1994 %O ISBN 1-55860-277-1 *** END OF 1994 ADDITIONS *** From globillum-Request@hostess.graphics.cs.cmu.edu Mon Jan 9 02:43:07 1995 Return-Path: From: Martin Lob Subject: Re: Terms and Symbols To: globillum@cs.cmu.edu Date: Sat, 7 Jan 95 15:08:43 MET Cc: Peter Shirley Organization: Cophos Development Team, Zumtobel Licht, Dornbirn, Austria Phone: +43-5572-390-1383 Status: RO Peter Shirley wrote ... | From: Peter Shirley | Subject: Terms and Symbols | To: globillum@cs.cmu.edu | Date: Thu, 22 Dec 1994 11:32:04 -0500 (EST) | | I am writing a Siggraph submission and am having my usual angst | over symbols used for radiometric quantities. If you don't think | this is important, imagine reading a linear algebra text | that uses xA = b for a linear system! Unfortunately, we have | nothing as standard as Ax=b in graphics. Here is what I have | seen used often in rendering: | | IES Heat Transfer other | power \Phi ?? | radiant exitance M B | irradiance E H \phi | radiant intensity I ?? | radiance L I | field (incoming) radiance L_f ?? | surface (outgoing) radiance L_s ?? | emitted radiance ?? ?? L, L_e | | My biggest worry is about irradiance and radiant exitance. I try | to use IES symbols when possible because they have an ANSI document | for terms and symbols, but I can't bring myself to use E (for one reason | because I am using expected values in the same paper). Should I | use H, and then use B for radiant exitance (radiosity)? If anyone | has words of wisdom for me, please share them. | | Have a happy holiday! | | Pete Shirley | shirley@graphics.cornell.edu | in lighting design we use the following terms: luminance: this is actually what you see (or close to it). symbol: L unit: cd/m2 (candela per square meter) unitUS: fL (footlambert, a unit of luminance equal to 1/pi candela per square foot) illiminance: this is what lighting designers are working most on fiktive surfaces since its independend from the reflection coefficient of the material symbol: E unit: lx (lux) unitUS: fc (footcandle, a unit of illuminance when the foot is taken as a unit length) luminous flux: the time rate of flow of light symbol: P (phi) unit: lm (lumen) luminous intensity: the luminous flux per unit solid angle in the direction of question symbol: I unit: cd unit: lm/sr (lumen per steradian) All these terms could be found in the IES Lighting Handbook 1984 Reference Volume. There are much more of these terms and symbols, but this is the collection we use most. Actually in our radiosity algorithm we store E on all of our surfaces. I hope i haven't wasted yor time, and a happy new year to all of you! Martin Lob ml@cophos.co.at -- \|/ ml@cophos.co.at at work: --O-- /|\ l Tel.: +43/5572/390-1383 ___ ___ m mmm mmm l Fax : +43/5572/390-650 / __\ /__ \ mm m m l Schweizerstr. 30 / / \ / \ m m m l A-6850 DORNBIRN | | \ m m martin . lob . Austria | | | | Prediction is very difficult, especially of the future! | | n_u__n___ From globillum-Request@hostess.graphics.cs.cmu.edu Mon Jan 9 14:40:58 1995 Return-Path: From: Daniel Kartch Subject: LaTeX2e siggraph document class To: globillum@cs.cmu.edu Date: Mon, 9 Jan 1995 17:12:46 -0500 (EST) Status: R With the submission deadline two days away, here's an updated version of the LaTeX2e siggraph class, containing a few bug fixes and modifications. +----------------------------------------------------------------------------+ | Daniel Kartch Program of Computer Graphics | | dan@graphics.cornell.edu 580 Theory Center Bldg. | | Office: (607) 255-6704 Cornell University | | Fax: (607) 255-0806 Ithaca, NY 14853 | +----------------------------------------------------------------------------+ # This is a shell archive. Remove anything before this line, # then unpack it by saving it in a file and typing "sh file". # # Wrapped by Daniel Kartch on Mon Jan 9 16:55:47 1995 # # This archive contains: # README siggraph.ins siggraph.dtx # LANG=""; export LANG PATH=/bin:/usr/bin:$PATH; export PATH echo x - README cat >README <<'@EOF' SIGGRAPH class, version 0.6.3(beta), January 9, 1994 Written by Daniel Kartch Program of Computer Graphics Cornell University dan@graphics.cornell.edu This distribution provides a document class for formatting papers according to the specifications for submission to the annual ACM Siggraph conference. It contains three files: README - this file siggraph.dtx - documented source code siggraph.ins - installation driver To install it, type latex siggraph.ins Then place the resulting siggraph.cls file somewhere where TeX can find it. To generate the user's guide, type latex siggraph.dtx makeindex -s gglo.ist -o siggraph.gls siggraph.glo latex siggraph.dtx This is a beta release and hasn't been thoroughly tested yet. Please send me any bug reports, suggestions for improvement, or other comments. I will do my best to fix any problems before the Siggraph submission deadline, but I make no promises. The likelihood of my responding to any given comment is directly proportional to the amount of time before the deadline that the comment is received. This package is distributed in the hope that it will be useful, and to promote compatibility of documents created at different sites, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Please see the siggraph.dtx file for copyright and distribution information. ============================================================================= CHANGE HISTORY: v0.6.1 Made titles bold Minor fixes in user's guide v0.6.2 Fixed missing affiliation in title block v0.6.3 Fixed onecolumn mode Put page numbers back in for review option @EOF chmod 664 README echo x - siggraph.ins cat >siggraph.ins <<'@EOF' \def\batchfile{siggraph.ins} \input docstrip.tex \keepsilent \generateFile{siggraph.cls}{t}{\from{siggraph.dtx}{class}} @EOF chmod 664 siggraph.ins echo x - siggraph.dtx cat >siggraph.dtx <<'@EOF' % \iffalse meta-comment % % file: siggraph.dtx % version: 0.6.3(beta) % date: January 9, 1995 % % Provides `siggraph' document class for use with LaTeX2e. % Formats a document according to ACM Siggraph conference proceedings % specifications. % %% %% Copyright (C) 1994,1995 Daniel Kartch %% Program of Computer Graphics %% Cornell University %% dan@graphics.cornell.edu %% %% This file is distributed in the hope that it will be useful, %% but WITHOUT ANY WARRANTY; without even the implied warranty of %% MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. %% % % This file may be freely copied in whole or in part under the following % conditions: % 1) Unmodified copies may be freely distributed separately or as part % of larger packages. % 2) You may make modified copies of this file for you own personal use, % but you may not distribute modified copies. You may place modifications % in a siggraph.cfg file (see the documentation), and distribute that % file individually or along with this source. However, if you do % so, the .cfg file must contain code to issue a warning when it is % invoked by LaTeX that states: % a) The fact that it is being loaded and it is not part of the % standard distribution % b) What it does (briefly) % c) That it can be disabled by removing or renaming the .cfg file % 3) Excerpts from this file may be freely used and distributed as part % of other macro packages. % % Portions of this file (namely the \@maketitle macro and the commands to % set up 9pt type) are modified versions of those provided with the standard % LaTeX files article.cls file and size10.clo, and their distribution may % be further restricted by the LaTeX copyright. (Probably not, but better % safe than sorry.) % %% %% NOTE: %% This is a beta release and hasn't been thoroughly tested yet. Please %% send me any bug reports, suggestions for improvement, or other comments. %% I will do my best to fix any problems before the Siggraph submission %% deadline, but I make no promises. The likelihood of my responding to %% any given comment is directly proportional to the amount of time before %% the deadline that the comment is received. %% % \fi % % \CheckSum{469} %% \CharacterTable %% {Upper-case \A\B\C\D\E\F\G\H\I\J\K\L\M\N\O\P\Q\R\S\T\U\V\W\X\Y\Z %% Lower-case \a\b\c\d\e\f\g\h\i\j\k\l\m\n\o\p\q\r\s\t\u\v\w\x\y\z %% Digits \0\1\2\3\4\5\6\7\8\9 %% Exclamation \! Double quote \" Hash (number) \# %% Dollar \$ Percent \% Ampersand \& %% Acute accent \' Left paren \( Right paren \) %% Asterisk \* Plus \+ Comma \, %% Minus \- Point \. Solidus \/ %% Colon \: Semicolon \; Less than \< %% Equals \= Greater than \> Question mark \? %% Commercial at \@ Left bracket \[ Backslash \\ %% Right bracket \] Circumflex \^ Underscore \_ %% Grave accent \` Left brace \{ Vertical bar \| %% Right brace \} Tilde \~} %% % % \iffalse % \begin{macrocode} %<+class>\NeedsTeXFormat{LaTeX2e}[1994/06/01] %<+class>\ProvidesClass{siggraph} %<*driver> \ProvidesFile{siggraph.drv} % [1995/01/09 v0.6.3(beta) %<+class> Siggraph proceedings document class] %<*driver> ] % % \end{macrocode} % % \section{Driver for this document} % % The following contains the driver for generating this document. % It can be extracted from the |.dtx| file with the \dst{} program. % % \begin{macrocode} %<*driver> \documentclass{ltxdoc} \GetFileInfo{siggraph.drv} %\DisableCrossrefs \RecordChanges \OnlyDescription % comment out for full source description \begin{document} \DocInput{siggraph.dtx} \end{document} % % \end{macrocode} %\fi % % \newenvironment{mylist}{% % \begin{list}{\labelitemi}{% % \addtolength{\leftmargin}{2em}% % \setlength{\itemindent}{-1em}% % \setlength{\parsep}{0in}% % \setlength{\itemsep}{0.5ex}}}{\end{list}} % % \changes{v0.6.1}{1994/12/26}{Minor modifications to user's guide} % % \title{The |siggraph| Document Class Users' Guide\thanks{% % This file has version number \fileversion{} dated \filedate{}.}} % % \author{Daniel Kartch\thanks{dan@graphics.cornell.edu}} % % \date{\filedate} % % \maketitle % % \begin{abstract} % This document class modifies the standard |article| class to conform to % the specifications for papers published in the proceedings of the annual % ACM Siggraph conference. % It sets all the necessary layout parameters and handles the differences % in format between a paper being submitted for blind review and a camera % ready copy of an accepted paper. % Several additional features are also provided. % % \vspace{\baselineskip} % \begin{quote} % NOTE: This class is distributed in the hope that it will be useful, % and to promote compatibility of documents created at different sites. % However it is provided WITHOUT ANY WARRANTY; without even the implied % warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. % Please see the |siggraph.dtx| source file for copyright and distribution % information. % \end{quote} % \end{abstract} % % \section{Introduction} % % This document describes the |siggraph| document class, for use with \LaTeXe{}. % It is intended as a replacement for the various versions of the old % |siggraph.sty| file that have been floating around for years. % It loads in the |article| class and modifies several parameters % to comply with the layout specifications for a paper submitted to % the ACM Siggraph conference. % Currently, these specifications are: % \begin{mylist} % \item $\frac{3}{4}$ inch margins on top and sides, 1 inch margin on bottom % \item two column mode with 2 pica column separation % \item space for copyright is 4.5 pica % \item 9 point type on 10 point baselines % \item titles and section headings are bold sans serif % \changes{v0.6.1}{1994/12/26}{Made titles bold} % \item no page numbers (|cameraready| mode only) % \changes{v0.6.3}{1995/01/06}{Put page numbers back in for review option} % \end{mylist} % Also set by the class but not part of the siggraph specifications are: % \begin{mylist} % \item 1 em paragraph indentation % \item |flushbottom| mode % \end{mylist} % % The class also allows the user to specify whether the paper is being % submitted for blind review or as a final, camera-ready document. % Based on this specification, it will put the appropriate information % in the title block on the first page. % It will also automatically generate a cover sheet for papers being % submitted for review. % Mechanisms are also provided to allow the user to introduce conditional % text based on this choice. % % \vspace{\baselineskip} % \begin{quote} % This is a beta release and hasn't been thoroughly tested yet. Please % send me any bug reports, suggestions for improvement, or other comments. % I will do my best to fix any problems before the Siggraph submission % deadline, but I make no promises. The likelihood of my responding to % any given comment is directly proportional to the amount of time before % the deadline that the comment is received. % \end{quote} % % \section{Usage} % % To use this class, specify % \begin{verbatim} \documentclass{siggraph} \end{verbatim} % at the beginning of your document. % Any options which can be used with the |article| class can be used here, % with the following exceptions and caveats: % \begin{mylist} % \item The |landscape| and |titlepage| options are disabled. % \item Although |twocolumn| mode is the default, the |onecolumn| option % is still enabled. However, I strongly recommend against using % it. Studies of printed material have shown that, for good % legibility, a line of printed material % should contain no more that ten to twelve words, and at the % 9 point type size used by this class, that limit will be greatly % exceeded in one column mode. I didn't disable the option because % it has been pointed out to me that some people prefer to use % it when submitting their paper for review. If you insist on % using it, I recommend increasing the type size. % \changes{v0.6.3}{1995/01/09}{Fixed onecolumn option} % \item By default, the document will use 9 point type, which is the % size required by Siggraph for camera ready copies. The |10pt|, % |11pt|, and |12pt| options will override this. % \end{mylist} % % In addition, the following options are provided: % \begin{mylist} % \item[|review| and |cameraready|] These specify whether the paper is % to be formatted as a submission for review or a camera-ready % final copy. The default is |cameraready|. The exact effects % of these options will be discussed later. % \item[|version1994|] The submission specifications may some day change, and % this class will therefore also need to be modified. However, % we will still want older documents to maintain their appearance. % This option says that the paper should be formatted according to % the specifications that were in effect in 1994. Currently, it % doesn't do anything, since these are the only specifications % supported. However, I recommend including it in the options % list so that, if and when new specifications are introduced, % your old papers will not be affected. % \end{mylist} % % \section{Cover Page, Title Block, and Abstract} % % Because, for review papers, the abstract must appear on both the cover % page and the first page, the commands for generating the cover page, title % block, and abstract have been combined into a single command: ^^A % \begin{quote} |\acmopening{|\textit{abstract}|}| \end{quote} % This should be the first text-generating command issued after % |\begin{document}|. % Authors should not use the |\maketitle| command or the |abstract| and % |titlepage| environments. % % \subsection{Data fields} % % In addition to the |\title| and |\author| commands provided by the |article| % class, several other pieces of information can be set. % Each of these commands takes a single argument, the value to which the % corresponding field should be set. % \begin{mylist} % \item |\affiliation| % % If all the authors share an affiliation, it can be set with this % command rather than individually within the author command. % The affiliation will appear centered below the author list. % % \item |\acmcategory| and |\acmformat| % % The paper category (research, systems, ...) and format (short, % long, ...). % % \item |\contactname|, |\contactaddress|, |\contactphone|, |\contactfax|, % |\contactemail| % % These should be used to set the information about the person to % be contacted about the paper. % % \item |\acmpassport| % % The author who will receive compensation if the paper is accepted. % \end{mylist} % % \subsection{Cover page} % % When the |review| option is specified, the |\acmopening| command will % generate a cover sheet. % Placing the |\suppresscover| command in the preamble will prevent this. % The cover sheet will contain: % \begin{mylist} % \item Title % \item Authors % \item Affiliation (if any) % \item Paper category and format % \item Contact information % \item Author to receive compensation % \item Abstract % \end{mylist} % % \subsection{Title block} % % For a camera ready document the title block will contain: % \begin{mylist} % \item Title % \item Authors % \item Affiliation (if any) % \changes{v0.6.2}{1995/01/05}{Fixed missing affiliation in title block} % \end{mylist} % % If the |review| option is chosen it will instead contain: % \begin{mylist} % \item Title % \item Paper category and format % \end{mylist} % The |review| option will also suppress printing of any information % specified with the |\thanks| command. % % \subsection{Abstract} % % In addition to being printed on the cover sheet (if any), the abstract % will also appear in it's normal position at the beginning of the paper. % % \section{Other Features} % % \subsection{Copyright notice} % % As with the old |siggraph.sty|, this class provides a |\copyrightspace| % command to leave space at the bottom of the first column for the copyright % notice. % This command should be placed after the last footnote that will appear in % the first column. % % \subsection{Conditional text} % % The class also provides the following four commands for writing text % conditional on whether the |cameraready| or |review| option has been % chosen: % \begin{quote}^^A % |\ifcamera{|\textit{thenclause}|}| % % |\ifreview{|\textit{thenclause}|}| % % |\ifcameraelse{|\textit{thenclause}|}{|\textit{elseclause}|}| % % |\ifreviewelse{|\textit{thenclause}|}{|\textit{elseclause}|}| % \end{quote}^^A % The first two will generate the \textit{thenclause} if the |cameraready| % (resp. |review|) option is chosen, otherwise they resolve to a null string. % The second two are the same as the first two but generate the % \textit{elseclause} instead of a null string if the condition is not met. % % These can be used for writing the paper so as to protect anonymity for % a submission for review, without having to worry about going back over it % months later to put the identifying information back in if the paper % is accepted. For example: % \begin{quote}^^A % |In \cite{FooBar1994}, \ifcameraelse{we}{Foo and Bar} showed that ...| % \end{quote} % or % \begin{quote}^^A % |as illustrated in the following \ifcameraelse{three}{two} images:| % % [include generic image] % % |\ifcamera{| [include our logo] |}| % % [include another generic image] % \end{quote} % % \subsection{Configuration file} % % Individual users or sites may wish to modify the behavior of this % class (for instance, to use a particular set of fonts.) % Rather than having people hack the |.cls| file, which can lead to % various incompatible versions at different sites, the class provides % for a configuration file. % After the class has finished loading, it will check to see if a % |siggraph.cfg| file exists in the \TeX{} search path. % If so, it will be input. % Any user-- or site--specific modifications should be placed in this file. % \textit{(See the copyright notice in the |siggraph.dtx| source file for % information on distribution of configuration files.)} % % \StopEventually{\PrintChanges} % % \iffalse %<*class> % \fi % % \section{Implementation} % % \begin{quote} % Warning: The implementation is a work in progress and may undergo radical % alterations before the first non-beta release. Do not count on any of % the internal representations remaining the same. Any suggestions for % improving any aspects of the implementation are welcome. % \end{quote} % % \subsection{Initial stuff} % % First off, we need to load in the |ifthen| package and declare the boolean % variable |acm@cameraready|, since we use this in the option handling. % % \begin{macrocode} \RequirePackage{ifthen} \newboolean{acm@cameraready} \newboolean{acm@useninepoint} \setboolean{acm@useninepoint}{true} % \end{macrocode} % % \subsection{Option processing} % % Disable the |titlepage| and |landscape| options. % % \begin{macrocode} \DeclareOption{titlepage}{% \OptionNotUsed% \ClassWarningNoLine{siggraph}{titlepage option not allowed}} \DeclareOption{landscape}{% \OptionNotUsed% \ClassWarningNoLine{siggraph}{landscape option not allowed}} % \end{macrocode} % % Allow |onecolumn|, |10pt|, |11pt|, and |12pt| options, but produce % warnings. % % \begin{macrocode} \newcommand{\acm@columnmode}{twocolumn} \DeclareOption{onecolumn}{% \ClassWarningNoLine{siggraph}{One-column mode selected.\MessageBreak% Switching to two-column mode is recommended.}% \renewcommand{\acm@columnmode}{onecolumn}} \DeclareOption{10pt}{% \ClassWarningNoLine{siggraph}{10 point type selected.\MessageBreak% Siggraph camera-ready specifications require 9 point.}% \PassOptionsToClass{10pt}{article}% \setboolean{acm@useninepoint}{false}} \DeclareOption{11pt}{% \ClassWarningNoLine{siggraph}{11 point type selected.\MessageBreak% Siggraph camera-ready specifications require 9 point.}% \PassOptionsToClass{11pt}{article}% \setboolean{acm@useninepoint}{false}} \DeclareOption{12pt}{% \ClassWarningNoLine{siggraph}{12 point type selected.\MessageBreak% Siggraph camera-ready specifications require 9 point.}% \PassOptionsToClass{12pt}{article}% \setboolean{acm@useninepoint}{false}} % \end{macrocode} % % The |review| and |cameraready| options set the |acm@cameraready| flag % % \begin{macrocode} \DeclareOption{review}{\setboolean{acm@cameraready}{false}} \DeclareOption{cameraready}{\setboolean{acm@cameraready}{true}} % \end{macrocode} % % The |version1994| option doesn't need to do anything yet. % % \begin{macrocode} \DeclareOption{version1994}{} % \end{macrocode} % % Pass any remaining options on to the |article| class % % \begin{macrocode} \DeclareOption*{\PassOptionsToClass{\CurrentOption}{article}} % \end{macrocode} % % Set |cameraready| option by default, tell |article| class to % use |twocolumn| mode, and process the options. % % \begin{macrocode} \ExecuteOptions{cameraready} \ProcessOptions % \end{macrocode} % % Load in the article class with the selected column mode. % % \begin{macrocode} \PassOptionsToClass{\acm@columnmode}{article} \LoadClass{article} % \end{macrocode} % % \subsection{Camera-ready/review conditional text} % % Define commands to perform actions conditionally based on whether % the document is being submitted for review or for printing. % % \begin{macrocode} \newcommand{\ifcamera}[1]{\ifthenelse{\boolean{acm@cameraready}}{#1}{}} \newcommand{\ifreview}[1]{\ifthenelse{\boolean{acm@cameraready}}{}{#1}} \newcommand{\ifcameraelse}[2]{\ifthenelse{\boolean{acm@cameraready}}{#1}{#2}} \newcommand{\ifreviewelse}[2]{\ifthenelse{\boolean{acm@cameraready}}{#2}{#1}} % \end{macrocode} % % \subsection{Page layout} % % Set the margins, header and footer sizes, column separation, and indentation. % Turn off page numbering, and turn on flush-bottom mode. % % \begin{macrocode} \setlength{\textheight}{9.25in} \setlength{\topmargin}{-0.25in} \setlength{\headheight}{0in} \setlength{\headsep}{0in} \setlength{\footskip}{0.5in} \flushbottom \ifcamera{\pagestyle{empty}} \setlength{\textwidth}{7in} \setlength{\oddsidemargin}{-0.25in} \setlength{\evensidemargin}{-0.25in} \setlength{\columnsep}{2pc} \setlength{\parindent}{1em} % \end{macrocode} % % \subsection{Setting up 9pt point type} % % If not overridden, set type size to 9 points. % % \begin{macrocode} \ifthenelse{\boolean{acm@useninepoint}}{ % \end{macrocode} % % The code in this section is a modified version of that found in the % |size10.clo| file from the June 1994 \LaTeX{} distribution, with values % taken from the old |siggraph.sty| file. % % Redefine |\normalsize| to 9 points. % % \begin{macrocode} \renewcommand\normalsize{% \@setfontsize\normalsize\@ixpt\@xpt \abovedisplayskip 9\p@ \@plus2\p@ \@minus4\p@ \abovedisplayshortskip \z@ \@plus3\p@ \belowdisplayshortskip 6\p@ \@plus3\p@ \@minus3\p@ \belowdisplayskip \abovedisplayskip \let\@listi\@listI} % \end{macrocode} % % Redefine |\small| to 8 points. % % \begin{macrocode} \renewcommand\small{% \@setfontsize\small\@viipt\@ixpt \abovedisplayskip 8.5\p@ \@plus3\p@ \@minus4\p@ \abovedisplayshortskip \z@ \@plus2\p@ \belowdisplayshortskip 4\p@ \@plus2\p@ \@minus2\p@ \def\@listi{\leftmargin\leftmargini \topsep 4\p@ \@plus2\p@ \@minus2\p@ \parsep 2\p@ \@plus\p@ \@minus\p@ \itemsep \parsep}% \belowdisplayskip \abovedisplayskip} % \end{macrocode} % % |\footnotesize|, |\scriptsize|, and |\tiny| remain the same as for % 10 point documents. % % \begin{macrocode} \renewcommand\footnotesize{% \@setfontsize\footnotesize\@viiipt{9.5}% \abovedisplayskip 6\p@ \@plus2\p@ \@minus4\p@ \abovedisplayshortskip \z@ \@plus\p@ \belowdisplayshortskip 3\p@ \@plus\p@ \@minus2\p@ \def\@listi{\leftmargin\leftmargini \topsep 3\p@ \@plus\p@ \@minus\p@ \parsep 2\p@ \@plus\p@ \@minus\p@ \itemsep \parsep}% \belowdisplayskip \abovedisplayskip} \renewcommand\scriptsize{\@setfontsize\scriptsize\@viipt\@viiipt} \renewcommand\tiny{\@setfontsize\tiny\@vpt\@vipt} % \end{macrocode} % % All the larger than normal sizes get decremented one step from their % values in 10 point documents. % % \begin{macrocode} \renewcommand\large{\@setfontsize\large\@xpt\@xiipt} \renewcommand\Large{\@setfontsize\Large\@xiipt{14}} \renewcommand\LARGE{\@setfontsize\LARGE\@xivpt{18}} \renewcommand\huge{\@setfontsize\huge\@xviipt{22}} \renewcommand\Huge{\@setfontsize\Huge\@xxpt{25}} % \end{macrocode} % % End 9 point if-then-else conditional % % \begin{macrocode} }{} % \end{macrocode} % % \subsection{Section headings} % % Redefine the section headings to use bold sans serif type. (Otherwise % these are the same definitions given in the |classes.dtx| file.) % % \begin{macrocode} \renewcommand\section{\@startsection {section}{1}{\z@}% {-3.5ex \@plus -1ex \@minus -.2ex}% {2.3ex \@plus.2ex}% {\reset@font\Large\sffamily\bfseries}} \renewcommand\subsection{\@startsection{subsection}{2}{\z@}% {-3.25ex\@plus -1ex \@minus -.2ex}% {1.5ex \@plus .2ex}% {\reset@font\large\sffamily\bfseries}} \renewcommand\subsubsection{\@startsection{subsubsection}{3}{\z@}% {-3.25ex\@plus -1ex \@minus -.2ex}% {1.5ex \@plus .2ex}% {\reset@font\normalsize\sffamily\bfseries}} \renewcommand\paragraph{\@startsection{paragraph}{4}{\z@}% {3.25ex \@plus1ex \@minus.2ex}% {-1em}% {\reset@font\normalsize\sffamily\bfseries}} \renewcommand\subparagraph{\@startsection{subparagraph}{5}{\parindent}% {3.25ex \@plus1ex \@minus .2ex}% {-1em}% {\reset@font\normalsize\sffamily\bfseries}} % \end{macrocode} % % \subsection{Cover page, title block and abstract} % % Define internal commands to hold the information for the cover page and % title block, plus user commands to set them. Also turn off the |\thanks| % command when producing a review copy. % % \begin{macrocode} \newcommand{\@affiliation}{} \newcommand{\affiliation}[1]{\renewcommand{\@affiliation}{#1}} \newcommand{\acm@category}{} \newcommand{\acmcategory}[1]{\renewcommand{\acm@category}{#1}} \newcommand{\acm@format}{} \newcommand{\acmformat}[1]{\renewcommand{\acm@format}{#1}} \newcommand{\acm@contactname}{} \newcommand{\contactname}[1]{\renewcommand{\acm@contactname}{#1}} \newcommand{\acm@contactaddress}{} \newcommand{\contactaddress}[1]{\renewcommand{\acm@contactaddress}{#1}} \newcommand{\acm@contactphone}{} \newcommand{\contactphone}[1]{\renewcommand{\acm@contactphone}{#1}} \newcommand{\acm@contactfax}{} \newcommand{\contactfax}[1]{\renewcommand{\acm@contactfax}{#1}} \newcommand{\acm@contactemail}{} \newcommand{\contactemail}[1]{\renewcommand{\acm@contactemail}{#1}} \newcommand{\acm@passport}{} \newcommand{\acmpassport}[1]{\renewcommand{\acm@passport}{#1}} \ifthenelse{\boolean{acm@cameraready}}{}{\renewcommand{\thanks}[1]{}} % \end{macrocode} % % Set up a control to determine whether or not to print the cover page. % % \begin{macrocode} \newboolean{acm@cover} \setboolean{acm@cover}{true} \newcommand{\suppresscover}{\setboolean{acm@cover}{false}} % \end{macrocode} % % The following internal macro is used to format the cover page. % % \begin{macrocode} \newcommand{\acm@coverpage}{% \begin{titlepage}% \begin{center}% \vspace*{\fill} {\LARGE\sffamily\bfseries \@title \par}% \vspace{2\baselineskip}% {\large \begin{tabular}[t]{c}% \@author \end{tabular}\par}% \vspace{1\baselineskip}% {\large \@affiliation \par}% \addvspace{3\baselineskip}% {Category: \acm@category \par}% \vspace{0.5\baselineskip}% {Format: \acm@format \par}% \vspace{3\baselineskip}% \begin{tabular}{ll} Contact: & \acm@contactname \\[1\baselineskip] & \begin{tabular}[b]{@{}l@{}} \acm@contactaddress \end{tabular} \\[1\baselineskip] phone: & \acm@contactphone \\ fax: & \acm@contactfax \\ email: & \acm@contactemail \end{tabular}\par% \vspace{3\baselineskip}% Author to receive compensation: \acm@passport \par% \vspace{4\baselineskip}% \begin{minipage}{5in}% \acm@abstract \end{minipage}% \vspace*{\fill} \end{center}% \end{titlepage}} % \end{macrocode} % % We redefine the \@maketitle command to leave out the date, and either % add the affiliation (for a camera ready paper), or replace the authors % with the paper category and format (for a submission for review). % % \begin{macrocode} \renewcommand{\@maketitle}{% \begin{center}% {\LARGE\sffamily\bfseries \@title \par}% \vspace{1\baselineskip}% \ifreviewelse{% {Category: \acm@category \par}% \vspace{0.25\baselineskip}% {Format: \acm@format \par}% }{% \large \begin{tabular}[t]{c}% \@author \end{tabular}\par% \vspace{1\baselineskip}% \@affiliation\par% }% \end{center} \par% \addvspace{0.5in}} % \end{macrocode} % % Now we set up the |\acmopening| command to output the cover page, title % block, and abstract, and turn off the page numbering on the first page. % % \begin{macrocode} \newcommand{\acmopening}[1]{% \newcommand{\acm@abstract}{#1}% \ifthenelse{\boolean{acm@cover}}{\ifreview{\acm@coverpage}}{}% \maketitle \ifcamera{\thispagestyle{empty}} \begin{abstract} #1 \end{abstract}} % \end{macrocode} % % Create the macro to leave space for the copyright. % \begin{macrocode} \newcommand{\copyrightspace}{% \renewcommand{\thefootnote}{}% \footnotetext[0]{\rule[4.5pc]{1in}{0in}}% \renewcommand{\thefootnote}{\arabic{footnote}}} % \end{macrocode} % % \subsection{Configurations file} % % Finally, we load the configuration file if it exists. % % \begin{macrocode} \InputIfFileExists{siggraph.cfg} {\typeout{***************************************^^J% * Local config file siggraph.cfg used *^^J% ***************************************}} {} % \end{macrocode} % % \iffalse % % \fi % % \Finale @EOF chmod 644 siggraph.dtx exit 0 From globillum-Request@hostess.graphics.cs.cmu.edu Thu Jan 12 20:59:01 1995 Return-Path: Date: 12 Jan 95 23:49:31 EST From: Ian Ashdown <72060.2420@compuserve.com> To: Global Illumination Subject: Radiosity bibliography update Status: R *** RADIOSITY BIBLIOGRAPHY UPDATED *** Ledalite Architectural Products and 3D/Eye, Inc. have updated their on-line bibliography of radiosity-related articles, papers and books. The bibliography now contains over 660 references, and is intended as a resource for students and researchers in the computer graphics and illumination engineering communities. The bibliography can be obtained via anonymous ftp from Lawrence Berkeley Laboratory's as: /pub/doc/RadBib.shar.Z Over 110 references have been added to the previous release (RadBib94.Z). Net surfers without ftp capabilities may obtain a free copy as an ASCII text file on a 3.5-inch MS-DOS diskette by sending a request to: Ian Ashdown, P. Eng. Research & Development Manager Ledalite Architectural Products Inc. 9087A - 198th Street Langley, B.C. V3A 4P8 Canada e-mail: Ledalite@mindlink.bc.ca Thanks to Greg Ward of Lawrence Berkeley Laboratory for providing space for the bibliography. Ian Ashdown, P. Eng. Research & Development Manager ------------------------------ Ledalite Architectural Products, Inc. 9087A - 198th Street Langley, B.C. V3A 4P8 Canada Tel: (604) 888-6811 Fax: (604) 888-0566 email: Ledalite@mindlink.bc.ca From globillum-Request@hostess.graphics.cs.cmu.edu Mon Jan 23 07:24:37 1995 Return-Path: From: Nico Guenther Subject: Color quantization To: globillum@cs.cmu.edu Date: Mon, 23 Jan 1995 16:09:17 +0100 (MET) Status: RO Hi, some days ago Ian Asdown posted a pointer to some color quanti techniques. Concerning 24->8 bit quantization one has to take care of the following: Usually quantization techniques are linear ones; however our audio-visual system uses a nonlinear scale (see Weber-Fechner-law in acoustics). Hence the visual image quality of 8bit images can be improved by a simple procedure 1st - nonlinear color scaling 2nd - color quantization 3rd - invers scaling to 1st 4th - rendering Some work concerning these problems was done in 1993 as MS at CS dep. of university of Rostock. A: Joern Trilk T: Nichtlineare Farbskalierung fuer die realistische Bilddarstellung K: you see, in German This work includes visual comparison of different scaling functions like log Weber-Fechner, Cornsweet, Paeth, ... and the corresponding C-code. In addition to that you can find a good reference list (mostly in English). Maybe this is for some use to you. Nico (nic@informatik.uni-rostock.de) From globillum-Request@hostess.graphics.cs.cmu.edu Tue Jan 31 09:14:56 1995 Return-Path: From: Holly E Rushmeier Date: Tue, 31 Jan 1995 11:41:01 -0500 To: Henrik Wann Jensen , globillum@cs.cmu.edu Subject: image comparisons Status: R Hi -- We have also been looking at the image comparison problem. I don't have any good suggestions right now, but our approach is to try to build on the work on image metrics for evaluating the effects of lossy compression. Here are some references. I'm not familiar with these papers in any depth, so you have to make your own assessments of their usefulness: Mannos & Sakrison, "The Effects of a Vision Fidelity Criterion on the Encoding of Images", IEEE Trans. on Information Theory, vol. it-20, July 1974, pp. 525-536. Saghri, Cheatham, & Habbi "Image quality measure based on a human visual system model", Optical Engineering, July 1989, vol 28, no. 7, pp. 813-818. Nill, " A Visual Model Weighted Cosine Transform for Image Compression and Quality Assessment", IEEE Transactions on Communications, vol. com-33, no. 6, June 1985, pp. 551-557 Even if you can't find these particular papers, you can probably draw some inspiration for methods to test out by rifling through the literature on evaluating lossy compression methods. I think incorporating even simple-minded human visual models would give useful results, and keep the metric from going beserk in dark areas, etc. -- Holly From globillum-Request@hostess.graphics.cs.cmu.edu Tue Jan 31 05:54:24 1995 Return-Path: Date: Tue, 31 Jan 1995 17:25:53 +0100 From: Henrik Wann Jensen To: globillum@cs.cmu.edu Status: RO Hi All, For some time I have been using a brute force Path Tracing method to validate the results from other global illumination methods. The results are images in which the pixel values are represented as either pure float (one per. wavelength) or as Greg Wards real pixels. My question is: How can I compare these images? I have primarily been using a squared sum of pixel differences. This means that the two images being compared are subtracted giving a difference image. The pixel values in the difference image are squared and added together giving some number (=error) indicating the "distance" between the two images. This method is relatively good but it gives pour ratings to images which have just a few pixels with a large distance (these images could perhaps be corrected using a noise reduction filter). Furthermore the method doesn't say much about the visual quality of the image being validated -- sometimes a little noise does look good... The error (number) also depends on the brightness of the image and images which has problems in dark areas (like shadows) gets a smaller error than images with problems in bright areas. It has no meaning (or very little meaning) comparing the error resulting from the computation of different images. etc.... Alternative methods could be: Maximum pixel difference, Average pixel difference etc. I would like some kind of normalized squared sum of pixel differences. It should, however, not "go berserk" in very dark areas with relatively large (but still invisible errors). And even better if the method gave the error 42 using the same global illumination method on two different images then the "looks of the error" would be the same on the two images (is this impossible?). That was my first two cents :-) - Henrik Wann Jensen From globillum-Request@hostess.graphics.cs.cmu.edu Tue Jan 31 10:29:49 1995 Return-Path: X-Msmail-Message-Id: 4291C4D3 X-Msmail-Conversation-Id: 4291C4D3 From: Don Mitchell To: globillum@cs.cmu.edu Date: Tue, 31 Jan 95 10:09:41 TZ Subject: image quality metrics Status: R I've played with Mannos and Sakrison's method. The wisdom at Bell Labs seemed to be that numerical image-quality metrics were a sort of holy grail that has never been completely achieved. Be careful. There is so much going on in our subjective response! Methods like M&S can take into account the logarithmic response to contrast and the basic color and spatial frequency dependance. Oh wait, the color response stuff is in another paper by Werner Frei (I'll try to find that reference). But there are other things like visual masking that are hard to model -- the visibility of noise depends a lot on the context. Don't be afraid to do subjective testing. Well, be a little afraid, because its a pain in the neck to organize it, but I think letting expert observers make judgements means more than assigning a mysterious number (which ultimate is based on some fit to some set of subjective-testing data anyway!). From globillum-Request@hostess.graphics.cs.cmu.edu Tue Jan 31 11:01:50 1995 Return-Path: Date: Tue, 31 Jan 1995 10:46:49 -0800 From: greg@taligent.com To: globillum@cs.cmu.edu Subject: Re: image quality metrics Status: R >>>>> "DM" == Don Mitchell writes: DM> I've played with Mannos and Sakrison's method. The wisdom at Bell DM> Labs seemed to be that numerical image-quality metrics were a sort DM> of holy grail that has never been completely achieved. DM> ... DM> Don't be afraid to do subjective testing. Well, be a little DM> afraid, because its a pain in the neck to organize it, but I think DM> letting expert observers make judgements means more than assigning DM> a mysterious number (which ultimate is based on some fit to some DM> set of subjective-testing data anyway!). I would agree completely. I did a lot of work on the perceptual brightness of light sources for my thesis, and perceptual testing seems to be the only reliable (well, pretty reliable anyhow) way to test image quality. It is a pain to design a good test, though. The up side is that you don't usually need too many subjects. -Greg. From globillum-Request@hostess.graphics.cs.cmu.edu Tue Jan 31 13:15:17 1995 Return-Path: From: Barry Carlton Ruff Date: Tue, 31 Jan 1995 15:50:56 -0500 To: globillum@cs.cmu.edu Subject: Image comparison/quality Status: R More image comparison/quality thoughts... The textbook "Flat-Panel Displays and CRTs" has an excellent chapter entitled "Image Quality: Measures and Visual Performance" by Harry Snyder. He characterizes a number of pixel error measures of image quality ( primarily based on mean square error, some weighted by properties of the human visual system ). The real strength of the chapter though is it's coverage of techniques that use the Modulation Transfer Function of display systems to obtain spatial information that can be compared with characteristics of our visual capabilities. I agree with Holly there is a lot of info in the compression literature on this topic. I recommend also scanning the the displays literature and television journals specifically, the Society for Information Display and the Society for Motion Picture and Television Engineers ( SID and SMPTE ) both hold a high stake in developing metrics for measuring image quality. Here are a few more references: Glenn, William. Digital Image Compression Based on Visual Perception and Scene Properties. SMPTE Journal May 1993: p.392-397 Hall, Charles; Hall, Ernest. A Nonlinear Model for the Spatial Characteristics of the Human Visual System. IEEE Transactions on Systems, Man, and Cybernetics. March 1977 vSMC-7(no. 3): p.161-170 Poynton, Charles. "Gamma" and It's Disguises: The Nonlinear Mappings of Intensity in Perception, CRTs, Film and Video. SMPTE Journal. December, 1993 p.1099-1108 Statistical comparison of image data is useful but to obtain measures of image quality perceptual models will have to be incorporated. As mentioned subjective ratings may be an alternative presently but herein lies some pitfalls as well. Experimental design must be controlled to assure subjects are rating actual quality as opposed to simply preference. ( there's no accounting for taste ) I have used a pair-wise comparison where subjects are presented both a reference image and a test image and are then asked to rank their impression of the test against the reference this works out well. Perception Based Rendering, coming soon to a machine near you... Barry Ruff Lighting Research Center Rensselaer Polytechnic Institute From globillum-Request@hostess.graphics.cs.cmu.edu Tue Jan 31 15:26:36 1995 Return-Path: Date: Tue, 31 Jan 1995 15:14:21 -0800 From: Steve Worley To: globillum@cs.cmu.edu Subject: More image comparison thoughts Status: RO I think that a single universal image "error" metric doesn't exist, simply because one type of image deviation may be trivial for one application but horrible for another. The diversity of uses for an error metric make a universal measure impossible. Consider two images which are identical except one image has been shifted over one pixel to the right. If these images were a before and after version of a test of a compression method, you'd want to use a human perception metric of difference. Put the images side by side and any viewer would probably say "Fantastic!". But if the images were comparisons of one radiosity method with a "truth" image from extreme oversampled Monte Carlo, you'd probably look for mean squared and maximum pixel differences of some sort. Here the offset registration causes very large errors in the two images, especially at sharp horizontal intensity changes. So error metrics should be tailored to the application. I would feel that a new global illumination method would best be measured against a "known" image by simple mean squared pixel intensity differences, probably independently at each wavelength. These differneces should be in actual intensity differences if possible, not cruddy quantized 0-255 RGB values. This is a more physical, direct measurement, showing any differences at a very low level. When testing a new algorithmic method for light transport, these importances are probably the most important. A visual metric might be better for determining speedups for a specific renderer. Say I'm trying to add Greg Ward's cool method of estimating shadow coverages of hundreds of light sources to a current commerical renderer. The users of the renderer are logo pilots and general animators. If the image doesn't LOOK different, and rendering is much faster, I'm likely to have happy customers. Even if the accuracy of rendering has decreased considerably (maybe the shadow boundaries are a lot noisier, with changes of +- 10% in the correct RGB values) it doesn't matter as long as peopele viewing the image don't notice or at least notice much. Unlike pixel by pixel mean-squared differences, trying to come up with a metric for human vision is a lot trickier. One group that probably put the most work into this topic were the nameless engineers who crafted NTSC in the 50's. They had an insanely small bandwidth to pack as much image quality as they could into. They exploited our vision's weak points by allocating their bandwidth carefully. I would think that a better VISUAL metric would come from pixel by pixel differences in YUV space rather than RGB space, and weighting Y errors much more than U and U more than V, as NTSC does. This doesn't solve some problems, though: think about the case where you increase each pixel's intensity 5% uniformly. Visually the image doesn't change much, but the pixel by pixel differences all have a 5% absolute error in them. Oops. Maybe some global gamma/contrast/brightness tweaking should attempt to "match" the two images first, THEN use pixel by pixel differences. But what about nonlinear spacial intensity changes, like the ones Rushmier, Ward, and Shirley have played with? Arggh.. there's an awful lot to account for! So forming a quantitative VISUAL difference metric is, simply, a pain. I will buy dinner for anyone who can come up with a good model or two and actually compare these to human experimentation where people rate image "differences" by eye. But luckily, the more sterile question of validating an algorithm can use less subjective measures. Simple pixel by pixel mean, mean squared, and maximum errors, are enough to quickly tell wether the two algorithms agree or disagree. Especially in radiation transport, we do know how to use the right units for measurements of light flux though a solid angle, and that's all we're trying to compute accurately. Anyway, just some thoughts to keep this thread going. I'm glad I discovered this list... -Steve Worley spworley@netcom.com From globillum-Request@hostess.graphics.cs.cmu.edu Wed Feb 1 08:17:48 1995 Return-Path: Date: Wed, 1 Feb 1995 19:44:50 +0100 From: Henrik Wann Jensen To: globillum@cs.cmu.edu Subject: Image comparison Status: R Hi everyone, Thanks for all the replies and an interesting discussion... I can see that it is difficult to compute just one number/error related to the 'perceptual difference' between two images. Subjective testing avoids this difficulty, but I agree with Holly that subjective testing cannot replace an error metric. Firstly, subjective testing is, well, subjective. I am used to looking at and seeing errors in a computer generated image therefore I will probably catch more errors than a person who is not working with computer graphics. I also find it quite unsatisfactory to write in a paper: ".. as we can see it looks good..". Furthermore I like to examine the effects of different parameters in my software by plotting a graph showing the convergence/error (currently the RMS-error) as a function of one of these parameters -- this is not possible with subjective testing. When comparing two images A and B we could extract a number of features from the difference image C=A-B. For instance we could examine whether C contains edges that aren't in the reference image A. We could also test whether C is noisy in areas where A is smooth etc. These features could be weighted and added together to give an error metric. I guess someone has tried this before... A good error metric could initially be used to speed up current global illumination algorithms. Perhaps improve methods featuring progressive refinement. Later on we might be able to incorporate the error metric in our algorithms in order to automatically determine when we are finished. Currently the most common stop-criteria within Monte Carlo ray tracing is the variance - which is directly related to the RMS-error. This criteria is unfortunate since we often use more samples than necessary. An example is procedural textures based on Perlins noise function. Since noise is a property of the texture and therefore not disturbing the use of variance as a stop-criteria results in unnecessary oversampling of these textures. If we had an error metric capable of saying whether the noise is disturbing or not then we could do a lot better... - Henrik From globillum-Request@hostess.graphics.cs.cmu.edu Wed Feb 1 10:29:41 1995 Return-Path: X-Msmail-Message-Id: D880BBAE X-Msmail-Conversation-Id: D880BBAE From: Don Mitchell To: globillum@cs.cmu.edu Date: Wed, 1 Feb 95 09:50:08 TZ Subject: error metrics, color Status: R Naturally, you want to have some number to minimize when you are trying various image synthesis methods. RMS error is an obvious one. But I caution against equating that number with "image quality". Variance and RMS error are actually quite poor measure of subjective image quality -- logarithmic weight or cube-root weight would even be a better measure of visible error than summing the square of the error. The spatial frequency effects the visibility of noise, with the maximum response being around 12 cycles per degree. The dependance on color is especially tricky. A common mistake in color quantization is to us Luv or Lab coordinates -- if you look at the SMTPE literature, you'll find they recommend almost the opposite metric, with a strong emphasis on reducing noise in the green channel. This is because there are really two kinds of error being talked about: color-matching error, and visibility of spatial patterns of noise. Luv is about color matching, the eye is quite insensitive to variations in shades of green, for example. But if you are worried about grain noise or dither patterns, the eye is most sensitive to green colored patterns. Getting back to metrics. Simple measures like variance or log-error might be fine for measuring the error in a pixel. But you certainly need more complex metrics if you are looking at global noise characteristics. RMS error was not at all useful in the work I reported in my SIGGRAPH 91 paper on spectrally optimal sampling, but I think the images clearly demonstrated the value of forcing noise into high frequencies. I used the Mannos Sakrison metric at that time and found the results to be poorly correlated with subjective image quality. For me, seeing is believing, and I did not use the M&S numbers. From globillum-Request@hostess.graphics.cs.cmu.edu Thu Feb 2 16:39:15 1995 Return-Path: X-Msmail-Message-Id: 40CF4B1B X-Msmail-Conversation-Id: 40CF4B1B From: Jack Tumblin To: globillum@cs.cmu.edu Date: Thu, 2 Feb 95 16:21:14 TZ Subject: A perceptual image metric (monochrome) Status: RO P. Teo & D. Heeger at Stanford have a promising perceptual image metric. They try to model the response of directionally- selective cells in the striate cortex using modified image pyramids and steerable filters, so that noise patterns that are aligned with nearby image features contribute much less error than misaligned noise. It is rather elaborate, but built on solid results from psychophysics and physiology. Their example pictures are impressive. See: "Perceptual Image Distortion", Teo, Patrick C., and Heeger, David J., pp.982-986 Proceedings of First International Conference on Image Processing, Austin TX, Nov. 1994. It's monochrome, though, and assumes moderate, CRT-like luminances-- not intended for high-dynamic range images. Regards, -Jack Tumblin From globillum-request@imag.fr Tue Feb 7 09:31:03 1995 Return-Path: From: Francois Sillion Subject: IMPORTANT: address change for globillum To: globillum@imag.fr (Global Illumination List) Date: Tue, 7 Feb 1995 15:36:10 +0200 (MET) Reply-To: Francois.Sillion@imag.fr Status: RO Dear fellow globillumers, The 'globillum' mailing list has been in existence for almost five years! Paul Heckbert has offered a great service to our community by setting up and maintaining the list for all this time. He deserves a rest and I will be taking over the maintenance of the list. Before I go on to explain what it means for you, I suggest we all thank Paul for his efforts: (one, two, three...) THANKS A LOT, PAUL ! OK, here's the technical information. The address used to send mail to the entire group has changed: it is now globillum@imag.fr The address used to contact me for matters pertaining to this list (such as adding new members, mail address problems, etc..) is now globillum-request@imag.fr I am appending below a copy of the mailing list in the form of a mailrc file. Please take the time to modify your globillum alias NOW, to avoid unnecessary traffic at the old address. You do not need to include all the aliases in the list in your .mailrc if you only want to contact the group. The prefered way to contact the entire group is always to use the globillum address, to ensure that the most up-to-date list is used. For thos of you using ELM to read/send mail, an elm alias database is also available by ftp (see below). Previous discussions among us (over 800k bytes of it) and a current copy of the mailing list are available via ftp at any time: ftp safran.imag.fr NAME: anonymous PASSWORD: yourlogin cd /pub/sillion/globillum ls prompt mget * quit and if the name server doesn't know the machine number, use ftp 129.88.29.1 Or if you can't ftp, tell me and I'll mail them to you. I hope the transition will be smooth, please let me know if there are any problems. +------------------+---------------------------+--------------------------+ | | iMAGIS / IMAG | Tel: (+33) 76 51 43 54 | | Francois SILLION | B.P. 53 | Fax: (+33) 76 44 66 75 | | ' | F-38041 Grenoble Cedex 09 | Francois.Sillion@imag.fr | +------------------+---------------------------+--------------------------+ The current members list follows in the form of a .mailrc file. # GLOBAL ILLUMINATION MAILING LIST, 2 Feb 95 # append the following to your .mailrc file # # send corrections/additions to globillum-request@imag.fr # (which is forwarded to Francois Sillion) # The preferred way to send mail to everyone on the list is to mail to # globillum (aliased below), where a master copy of list is being maintained. alias globillum globillum@imag.fr alias globillum-request globillum-request@imag.fr # lines beginning with "# #" are people who are not on the list as # individuals, but are members of a group that subscribes alias globillum_explicit \ allison almagro amanatides arvo ashdown baum bhate borel \ bouatouch buckalew cabrero campbell carlton casasayas achalmers \ chen nchristensen pchristensen christou mcohen compagnon \ cornell_students costa jdave delft desousa dilaura dorsey \ drettakis fiume forsyth fournier fussell gatenby george gifford \ glassner goel grant greenberg guenther guibas haines \ hanrahan heal heckbert hedley ivanov jensen jessel gjones kaneda kirk \ kolb kopp kouhia lalonde languenou levoy blewis plewis lightwork \ marini max metge dmitchell newhall anewton nishita patmore \ pattanaik paulin pela pharr poulin puech pueyo purgathofer rekola \ ruff rushmeier salesin schlick pschroeder \ scopigno seron shinya shirley gimagis sillion \ slusallek speer spencer stolfi stollnitz stuerzlinger ksubramanian \ sung tampieri teller tellier townsend \ troutman tumblin turner uselton vanliere \ vanwyk veach vilaplana jwallace cwang ward westin wexler \ winget worley worrall zhang zisserman zumtobel # Mike Allison alias allison mike@documentum.com # Carlos Urena Almagro; ETS Ingenieria Informatica; # Universidad de Granada; 18071 Granada; Spain alias almagro almagro@ugr.es # John Amanatides, York U, Toronto alias amanatides amana@cs.yorku.ca # Jim Arvo, Apollo / Yale alias arvo arvo@graphics.cornell.edu # Ian Ashdown; Ledalite Architectural Products Inc.; Langley, B.C.; Canada alias ashdown 72060.2420@CompuServe.COM alias ashdown2 Ledalite@mindlink.bc.ca # Dan Baum, Silicon Graphics alias baum drb@sgi.com # Neeta Bhate; University of South Florida; Tampa, Florida alias bhate bhate@sol.csee.usf.edu # Chris Borel; SST-8, MS D438; Los Alamos National Lab; Los Alamos, NM 87545 # interests: simulation of lighting under vegetative canopies alias borel cborel@lanl.gov # Kadi Bouatouch; IRISA; Campus de Beaulieu; 35042 Rennes Cedex; France # interests: ray tracing, sampling, realism, physics & perception alias bouatouch kadi@irisa.fr alias bouatouch2 bouatouch@irisa.fr # # Wim F. Bronsvoort; Faculty of Technical Mathematics and Informatics; # Delft University of Technology; Julianalaan 132; 2628 BL Delft; Netherlands alias bronsvoort wim@duticg.twi.tudelft.nl # Chris Buckalew, Cal Poly alias buckalew buckalew@polyslo.calpoly.edu # Alan Cabrero; 514 Computer Center; East Lansing MI 48824 alias cabrero adc@tardis.cl.msu.edu # Alvin T. Campbell III; Applied Research Laboratories; U. of Texas at Austin; # P. O. Box 8029; Austin, TX 78713-8029 # interests: global illumination, heat transfer, animation, scientific vis. alias campbell atc@arlut.utexas.edu # Eloise Carlton, Fujitsu America alias carlton eloisec@ossi.com # Mateu Sbert Casasayas # interests: doing thesis on Monte Carlo radiosity alias casasayas sbert@lsi.upc.es # Alan Chalmers; Dept. of Computer Science; University of Bristol; # University Walk; Bristol; BS8 1TR; United Kingdom # interests: large parallel MIMD computers for radiosity and ray tracing alias achalmers alan@compsci.bristol.ac.uk alias achalmers2 alan@cs.bris.ac.uk # Eric Chen, Apple alias chen chense@apple.com # Niels J. Christensen; Technical U. Denmark; B. 116, DK-2800 Lyngby; Denmark alias nchristensen iftnjc83@vm.uni-c.dk # Per H. Christensen; U. of Washington # interests: light reflection models, image analysis & synthesis alias pchristensen per@cs.washington.edu # Chris Christou, Oxford U. alias christou cgc@physiology.oxford.ac.uk # Michael Cohen, Princeton U. alias mcohen mfc@cs.princeton.edu # Raphael Compagnon, EPFL Switzerland alias compagnon compagnon@eldp.epfl.ch # Antonio Costa; Comp. Graphics & CAD; INESC; # Largo Mompilher 22; 4100 Porto Portugal alias costa acosta@porto.inescn.pt # alias costa acc@asterix.inescn.pt (this address failing 1/95) # Cornell Students, includes Himlan & others; but not Greenberg or Arvo alias cornell_students gi-students@graphics.cornell.edu # Jubin P. Dave; U. of New Hampshire alias jdave jd@kepler.unh.edu # Delft University of Technology graphics group # an alias for Jansen, Bronsvoort, Kok, Post # interests: VLSI for radiosity; ray tracing, texture mapping, CSG alias delft globillum@duticg.twi.tudelft.nl # A. Augusto de Sousa; INESC; Largo Mompilher, 22; 4000 Porto; Portugal alias desousa aa_sousa@inescn.pt # David L. DiLaura; Senior Instructor, Civil and Architectural Engineering; # University of Colorado; Boulder, CO 80309 alias dilaura dilaura@bechtel.colorado.edu # Julie Dorsey; Assistant Professor, Architecture, MIT alias dorsey dorsey@mit.edu # George Drettakis, iMAGIS/IMAG, BP 53 F-38041 Grenoble Cedex 09 France # interests: sampling and filtering techniques for GI, quality & error metrics alias drettakis George.Drettakis@imag.fr # Eugene Fiume, U. of Toronto alias fiume elf@dgp.utoronto.ca # David Forsyth alias forsyth daf@CS.Berkeley.EDU # Alain Fournier, U. of British Columbia, Vancouver BC, Canada alias fournier fournier@cs.ubc.ca # Don Fussell, U. of Texas, Austin alias fussell fussell@cs.utexas.edu # Neil Gatenby, Manchester Computing Centre, Manchester, England # interests: alternatives to hemicube, accurate numerical form factors alias gatenby gatenby@vax3.graphics.manchester-computing-centre.ac.uk # David George, Gain Technology, Palo Alto alias george george@gain.com # Stephen Gifford, Electrical and Computer Engineering Dept, Carnegie Mellon # interests: implemented radiosity/ray tracing hybrid on Connection Machine alias gifford Stephen.Gifford@maps.cs.cmu.edu # Andrew Glassner, Microsoft alias glassner glassner@microsoft.com # Narendra Goel, Wayne State U. alias goel ngoel@pandora.cs.wayne.edu # Chuck Grant, Lawrence Livermore Lab alias grant grant1@llnl.gov alias grant2 grant%delvalle.llnl.gov@lll-lcc.llnl.gov # Don Greenberg c/o Fran Brown, Cornell U. alias greenberg fmb@graphics.cornell.edu # Nico Guenther; Universitaet Rostock; Fachbereich Informatik; # Rostock 18059; Germany # interests: animation of radiosity, physically based approaches, perception alias guenther nic@informatik.uni-rostock.de # Leo Guibas; CS Dept, Stanford U. / DEC Systems Research Center, Palo Alto alias guibas guibas@cs.stanford.edu # Eric Haines, 3D/Eye alias haines erich@eye.com # Pat Hanrahan, Stanford U. alias hanrahan hanrahan@cs.stanford.edu # Brian W. Heal; School of Information Science; Portsmouth Polytechnic; # Mercantile House; Hampshire Terrace; Portsmouth, PO1 2EG; United Kingdom # interests: rendering octree models, post-hidden-surface-removal rendering alias heal healb@csovax.portsmouth.ac.uk # Paul Heckbert; Computer Science Dept.; Carnegie Mellon University; # 5000 Forbes Ave; Pittsburgh PA 15213-3891; USA # interests: finite element & integral equation methods for global illumination alias heckbert ph@cs.cmu.edu # David Hedley alias hedley hedley@cs.bris.ac.uk # # Ted H. Himlan, Cornell # interests: empirical measurements of materials and lights, validation alias himlan thh@graphics.cornell.edu # Alexander Ivanov alias ivanov Alexander.Ivanov@comlab.ox.ac.uk # # Frederik W. Jansen (Erik); Faculty of Technical Mathematics and Informatics; # Delft University of Technology; Julianalaan 132; 2628 BL Delft; Netherlands alias jansen fwj@duticg.twi.tudelft.nl # Henrik Wann Jensen; Institute of Graphical Communication # Technical University of Denmark; Building 116; 2800 Lyngby; Denmark alias jensen igkhwj@unidhp.uni-c.dk # J. P. Jessel; Institut de Recherche en Informatique de Toulouse; # Universite Paul Sabatier; 31062 Toulouse; France # interests: parallel radiosity and ray tracing algorithms on Transputers alias jessel jessel@irit.fr # Graham Jones; Oxford U. alias gjones graham@robots.oxford.ac.uk # Kazufumi Kaneda; Electric Machinery Lab, Hiroshima U. alias kaneda kin@eml.hiroshima-u.ac.jp # Dave Kirk, Caltech alias kirk dk@egg.gg.caltech.edu # # Arjan Kok; Delft U. of Technology; Netherlands # interests: radiosity effects using ray tracing alias kok arjan@duticg.twi.tudelft.nl # Craig Kolb, Stanford (but email address is Princeton) alias kolb cek@cs.princeton.edu # Manfred Kopp; Inst. of Computer Graphics, Technical University of Vienna # Karlsplatz 13/186-2; A-1040 Wien; Austria alias kopp kopp@stellaris.cg.tuwien.ac.at alias kopp2 m.kopp@ieee.org alias kopp3 kopp@eigvs4.una.ac.at # alias kopp kopp@eigvs4.tuwien.ac.at # Juhana Kouhia alias kouhia jk87377@cs.tut.fi # Paul Lalonde, U. of British Columbia alias lalonde lalonde@cs.ubc.ca # Eric Languenou; IRISA; Projet Siames; Campus de Beaulieu; # 35042 Rennes Cedex France # interests: participating media, adaptive radiosity; doing PhD with Bouatouch alias languenou langueno@irisa.fr # Marc Levoy, CS Dept, Stanford U. alias levoy levoy@cs.stanford.edu # Bob Lewis; CS Dept; U. of British Columbia; # 6356 Agricultural Road; Vancouver, BC V6T 1W5; Canada # interests: 3-D texture, ray tracing, radiosity, parallelism alias blewis bobl@cs.ubc.ca # Lewis; Dept. Geography; University College London # 26 Bedford Way; London WC1H 0AP; UK # I don't use a first name, "I'm known just as Lewis" # interests: modeling canopy reflectance, remote sensing alias plewis plewis@ps.ucl.ac.uk # people at LightWork Design; Cooper Bldgs.; Arundel Street; # Sheffield, S1 2NS; UK alias lightwork radios@lightwork.co.uk # Daniele Marini; Eidomatics Lab, Computer Science Dept, Univ. of Milan; Italy # interests: radiosity, ray tracing, parallel processing (Meiko) alias marini marini@imiucca.csi.unimi.it # Nelson Max, Lawrence Livermore Lab alias max max2@llnl.gov alias max2 nelson@ramius.ocf.llnl.gov # Christian Metge; Institut de Recherche en Informatique de Toulouse; # Universite Paul Sabatier; 31062 Toulouse; France # interests: parallel discrete radiosity and ray tracing algorithms # (Transputers, workstation networks) alias metge metge@irit.fr # Don Mitchell, Microsoft alias dmitchell donm@microsoft.com # # Eihachiro Nakamae; Electric Machinery Lab, Hiroshima U. alias nakamae naka@eml.hiroshima-u.ac.jp # William Parsons Newhall, Jr., The American University alias newhall newhall@auvm.american.edu # Andy Newton; Remote Sensing Research, University College London alias anewton anewton@ps.ucl.ac.uk # Tomoyuki Nishita; Electric Machinery Lab, Hiroshima U. alias nishita nis@eml.hiroshima-u.ac.jp # Christopher Patmore; Programming Research Group; Oxford U. # interests: skylight radiosity alias patmore cjp@prg.oxford.ac.uk # Sumant Narayan Pattanaik; IRISA; Rennes; France alias pattanaik sumant.pattanaik@irisa.fr # Mathias Paulin; Institut de Recherche en Informatique de Toulouse; # Universite Paul Sabatier; 31062 Toulouse; France # interests: parallel radiosity and ray tracing algorithms (Transputers, PVM) # shadow accuracy, transfer simulations in dense foliage alias paulin paulin@irit.fr # Barbara Pela, Joint Research Centre, Commission of the European Communities, # Ispra, Italy alias pela barbara.pela@cen.jrc.it # Matt Pharr alias pharr mmp@lux.Stanford.EDU # # Frits Post; Faculty of Technical Mathematics and Informatics; # Delft University of Technology; Julianalaan 132; 2628 BL Delft; Netherlands alias post frits@duticg.twi.tudelft.nl # Pierre Poulin; Dept. IRO, Universite de Montreal, # C.P. 6128, succ. Centre-Ville, Montreal, Quebec, Canada H3C 3J7 # interests: illumination, rendering, realism alias poulin poulin@iro.umontreal.ca # Claude Puech; LIENS; 45, rue d'Ulm; 75230 Paris Cedex 05; France alias puech Claude.Puech@imag.fr # Xavier Pueyo; Dept. Llenguatges i Sistemes Informatics; # Universitat Politecnica de Catalunya; Av. Diagonal, 647 planta 8; # 08028-Barcelona; Spain; # interests: diffuse environments alias pueyo xavier@ima.udg.es alias pueyo2 xavier@lsi.upc.es alias pueyo3 eapueyo@ebrupc51.bitnet # Werner Purgathofer; Institute for Computer Graphics; Techn. Univ. Vienna; # Karlsplatz 13 / 186; A-1040 Wien / Austria # interests: parallel ray tracing and radiosity, BSP, color, animation # [I've had trouble with most of Werner's email addresses! -Paul H.] alias purgathofer purgathofer@eigvs4.una.ac.at alias purgathofer2 purgathofer@eigvs4.tuwien.ac.at alias purgathofer3 wp@eigcl1.una.ac.at # Panu Rekola; Computer Science Dept, Helsinki U. of Tech.; Finland alias rekola pre@cs.hut.fi # Barry Carlton Ruff alias ruff ruffb@rpi.edu # Holly Rushmeier, Computing and Applied Math Lab; # National Institute for Standards and Technology; Gaithersburg, Maryland alias rushmeier holly@cam.nist.gov # David Salesin; U. of Washington alias salesin salesin@cs.washington.edu # # Jodok Schaeffler, Zumtobel, Austria alias schaeffler js@cophos.co.at # Christophe Schlick; LaBRI; U. of Bordeaux; 351 Cours de la Liberation # 33400 Talence; France # interests: ray tracing, radiosity, antialiasing, general reflectance functions alias schlick schlick@labri.u-bordeaux.fr alias schlick2 schlick@geocub.greco-prog.fr # Peter Schroeder alias pschroeder ps@math.scarolina.edu # Roberto Scopigno; CNUCE; Consiglio Nazionale delle Richerche; # Via S.Maria, 36; 56100 Pisa; Italy # interests: volume rendering, user interfaces, parallel processing, geography alias scopigno R.Scopigno@cnuce.cnr.it # Francisco Seron; Dpto. Ingenieria Electrica e Informatica; # Centro Politecnico Superior de Ingenieros; Universidad de Zaragoza; # C/ Maria Luna s/n; E-50015 Zaragoza; Spain alias seron pseron@mcps.unizar.es # Mikio Shinya, pencil tracing alias shinya shinya@nttarm.ntt.jp # alias shinya shinya@nttcvg.ntt.jp # Pete Shirley, Indiana U., on leave at Cornell as of 7/94 alias shirley shirley@graphics.cornell.edu alias shirley2 shirley@iuvax.cs.indiana.edu # Global Illumination group at iMAGIS/IMAG alias gimagis gimagis@safran.imag.fr # Francois Sillion; IMAG; Grenoble; France alias sillion Francois.Sillion@imag.fr # Philipp Slusallek; Universitaet Erlangen; # IMMD IX - Graphische Datenverarbeitung; Am Weichselgarten 9; # W-8520 Erlangen, Germany # interests: CAD, surfaces, doing PhD on physical basis of glob. illum. alias slusallek slusallek@informatik.uni-erlangen.de # Rick Speer alias speer speer@crl.com alias speer2 speer@cs.colorado.edu # Stephen Spencer alias spencer spencer@cgrg.ohio-state.edu # Jorge Stolfi alias stolfi stolfi@dcc.unicamp.br # Eric Stollnitz alias stollnitz stoll@amath.washington.edu # Wolfgang Stuerzlinger, Department of Graphics and Parallel Processing, # Johannes Kepler University, Linz, Austria alias stuerzlinger wrzl@gup.uni-linz.ac.at # K. R. Subramanian; AT&T Bell Labs; Murray Hill, NJ alias ksubramanian krs@allegra.att.com # Kelvin Sung; Dept. of Information Systems and Computer Science; # National University of Singapore; Kent Ridge, Singapore 0511 # Republic of Singapore # interests: fast ray tracing, modular global illumination software alias sung ksung@iscs.nus.sg # Filippo Tampieri; Lightscape Technologies, Inc; San Jose, CA alias tampieri fxt@lightscape.com # Seth Teller; MIT alias teller seth@lcs.mit.edu # Pierre Tellier # LSIIT (Laboratoire des Sciences de l'Image, d'Informatique et de # Teledetection); Departement d'Informatique de l'Universite Louis Pasteur; # 7, rue R. Descartes; 67084 Strasbourg; France alias tellier tellier@dpt-info.u-strasbg.fr # J. Eric Townsend; General Magic # interests: massively parallel based visualization codes, mostly ray tracing alias townsend jet@genmagic.com # Roy Troutman, Lawrence Livermore Lab alias troutman roy@ninja.nersc.gov alias troutman2 roy@ninja.llnl.gov # Jack Tumblin, Georgia Tech alias tumblin ccsupjt@cc.gatech.edu # Doug Turner, Apple alias turner turner@apple.com # Sam Uselton; CSC, NASA Ames, Mountain View, CA alias uselton uselton@nas.nasa.gov # Robert van Liere; Department of Interactive Systems; # Center for Mathematics and Computer Science (CWI); # Kruislaan 413, 1098 SJ Amsterdam, The Netherlands # interests: generalizing radiosity method, parallel methods for radiosity alias vanliere robertl@cwi.nl # Cornelius Skip Van Wyk, Jr; Carnegie Mellon U; Dept of Architecture alias vanwyk vanwyk@cad.cs.cmu.edu # Eric Veach; Stanford U. # interests: hierarchical global illumination, clustering objects, # global illumination methods for "black box" scene representations alias veach ericv@cs.stanford.edu # Josep Vilaplana; Universitat Politecnica de Catalunya; # Departament de Llenguatges i Sistemes Informatics; # Av. Diagonal 647 planta 8; 08028 Barcelona; Spain # interests: hardware and parallel algs for speeding radiosity & ray tracing alias vilaplana vilaplana@lsi.upc.es # John Wallace, 3D/Eye alias jwallace johnw@eye.com # Changyaw Wang; U. of Indiana # interests: rendering and modeling of complex outdoor environments alias cwang wangc@iuvax.cs.indiana.edu # Greg Ward; Lighting Systems Research Group; Lawrence Berkeley Lab; California alias ward gjward@lbl.gov # Stephen H. Westin alias westin westin@dsg42.nad.ford.com # Dan Wexler; Berkeley alias wexler wex@miro.berkeley.edu # Jim Winget, Silicon Graphics alias winget jmw@sgi.com # Steve Worley alias worley spworley@netcom.com # Adam Worrall, University of Bristol Graphics Group # Computer Science Department, The University, Bristol, UK alias worrall Adam.Worrall@bristol.ac.uk # Ning Zhang # interests: radiosity, ray tracing, physically-based illumination models alias zhang zhang@vti.com # Andrew Zisserman; Robotics Research Group; Oxford University; UK # interests: computer vision, radiosity alias zisserman az@robots.oxford.ac.uk # Zumtobel Licht GmbH; Schweizerstr. 30; A-6850 Dornbirn; Austria # interests: lighting design visualization, radiosity # (an alias for global illumination folks at the Zumtobel company) alias zumtobel glbi@cophos.co.at # END OF GLOBAL ILLUMINATION MAILING LIST From globillum-request@imag.fr Thu Feb 9 08:32:17 1995 Return-Path: From: Francois Sillion Subject: ftp files at imag.fr To: globillum@imag.fr (Global Illumination List) Date: Thu, 9 Feb 1995 16:20:50 +0200 (MET) Reply-To: Francois.Sillion@imag.fr Status: RO Following the change of address for the globillum list, some files have been placed for ftp access on node 'imag.fr'. This site is in France, which means easier ftp access for Europeans and... maybe some care required from North America! in particular, it is my experience that ftp transfers are much more reliable across the atlantic during night hours (8 PM EST -- 3 AM EST). Remember this if you want to download files from imag. Regards +------------------+---------------------------+--------------------------+ | | iMAGIS / IMAG | Tel: (+33) 76 51 43 54 | | Francois SILLION | B.P. 53 | Fax: (+33) 76 44 66 75 | | ' | F-38041 Grenoble Cedex 09 | Francois.Sillion@imag.fr | +------------------+---------------------------+--------------------------+ From globillum-request@imag.fr Fri Feb 24 02:20:51 1995 Return-Path: From: Francois Sillion Subject: looking for 3D data of human head To: globillum@imag.fr (Global Illumination List) Date: Fri, 24 Feb 1995 10:35:55 +0200 (MET) Reply-To: Francois.Sillion@imag.fr Status: R Dear all, this is not really a globillum question, but I am sure many of you probably can help me with this request. I am trying to locate a 3D dataset of a human head. I am in fact only interested in the skull at the moment, but I figured I could extract it easily from any of the medical datasets that have been floating around. Unfortunately I haven't been able to do so with the head dataset from the UNC ftp site. More precisely I haven't been able to extract the skull from the data with simple classification tools. Maybe I am doing something wrong, or maybe the MRI data is not well suited to the particular classification I need ? can somebody confirm or deny this? Anyway, my questions are o would somebody have a pre-classified volume dataset of a skull? o would somebody have a volume dataset of a head that seems easy enough to classify so that the skull can be separated? maybe CT data would be better than MRI? Thanks in advance +------------------+---------------------------+--------------------------+ | | iMAGIS / IMAG | Tel: (+33) 76 51 43 54 | | Francois SILLION | B.P. 53 | Fax: (+33) 76 44 66 75 | | ' | F-38041 Grenoble Cedex 09 | Francois.Sillion@imag.fr | +------------------+---------------------------+--------------------------+ From globillum-request@imag.fr Fri Feb 24 06:55:22 1995 Return-Path: Date: Fri, 24 Feb 95 08:14:22 -0500 From: swestin@dsg145.nad.ford.com (Stephen H. Westin) To: Francois.Sillion@imag.fr Cc: globillum@imag.fr Subject: Re: looking for 3D data of human head Reply-To: westin@dsg145.nad.ford.com Status: R > Unfortunately I haven't been able to do so with the head dataset > from the UNC ftp site. More precisely I haven't been able > to extract the skull from the data with simple classification tools. > Maybe I am doing something wrong, or maybe the MRI data is not well > suited to the particular classification I need ? can somebody confirm > or deny this? > > Anyway, my questions are > > o would somebody have a pre-classified volume dataset of a skull? > o would somebody have a volume dataset of a head that seems easy > enough to classify so that the skull can be separated? > maybe CT data would be better than MRI? I think that's exactly correct: CT is best at distinguishing bone, and MRI was developed to look at soft tissue. I have an old friend who used to be involved with nuclear medicine sorts of things, and I'll ask him if he has any skulls lying around. -Steve From globillum-request@imag.fr Mon Feb 27 07:11:15 1995 Return-Path: Date: Mon, 27 Feb 1995 09:13:41 -0500 From: Eric Haines To: globillum@imag.fr Subject: new theses Status: R Globillumer, Here are the abstracts of two new articles on radiosity which may be of interest. These were sent to me automagically by the Elib server at Stanford, which I highly recommend for keeping you informed about various keywords - it's simple to set up and non-intrusive. Send "help" to the address at the bottom of the message if you're interested (there's also a Usenet news searcher that Stanford runs which scans netnews for articles with your keyword and sends you the first 20 lines of each article - handy if you don't have time to read netnews but still would like to track a few special topics. The address for it is netnews@db.stanford.edu). Eric Haines Score : 100 BIB-VERSION:: CS-TR-v2.0 ID:: PRINCETONCS//TR-473-94 ENTRY:: February 21, 1995 ORGANIZATION:: Princeton University, Computer Science Department LANGUAGE:: English TITLE:: Wavelet Methods for Computer Graphics (Thesis) AUTHOR:: Gortler, Steven J. DATE:: January 1995 PAGES:: 183 ABSTRACT:: This thesis discusses how a wavelet basis can be used in the context of two computer graphics applications, realistic rendering and geometric modeling, to produced more efficient and flexible algorithms. The goal of realistic rendering is to simulate the interreflection of light in some geometric environment in order to produce realistic images. Radiosity is a commonly used solution method for this problem. Recently Hanrahan et al. have introduced a hierarchical method that can solve radiosity problems in $O(n)$ time instead of $O(n^2)$. This thesis explores how the hierarchical radiosity algorithm can be formally understood from the context of wavelet theory. When the radiosity problem is expressed with respect to a wavelet basis, the resulting linear system is sparse, with only $O(n)$ significant terms. By casting the hierarchical method in this framework, a variety of wavelet basis functions can be used, resulting in more efficient radiosity methods. This thesis also discusses how wavelets can be used in the context of geometric modeling. Geometric modeling is the study of how geometric shapes can be represented and manipulated by a designer. This thesis explores the use of wavelets to represent parametric curves and surfaces within the context of geometric modeling interfaces. One intuitive modeling interface commonly used in geometric modeling allows the user to directly manipulate curves and surfaces. This manipulation defines some set of constraints that the curve or surface must satisfy (such as interpolation and tangent constraints). Direct manipulation, however, usually leads to an underconstrained problem since there are, in general, many possible surfaces meeting some set of constraints. Therefore an optimization problem must be solved. This thesis discusses how geometric modeling optimization problems can be solved more efficiently by using a wavelet basis. Because the wavelet basis is hierarchical, iterative optimization methods converge rapidly. And because the wavelet coefficients indicate the degree of detail in the solution, they can be used to determine the number of basis functions needed to express the variational minimum, thus avoiding unnecessary computation. An implementation is discussed and experimental results are reported. END:: PRINCETONCS//TR-473-94 Score : 90 BIB-VERSION:: CS-TR-v2.0 ID:: PRINCETONCS//TR-485-95 ENTRY:: February 21, 1995 ORGANIZATION:: Princeton University, Computer Science Department LANGUAGE:: English TITLE:: An Adaptive Gauss Method for Computing Irradiance Coefficients of Galerkin Radiosity System s AUTHOR:: Gershbein, Reid DATE:: February 1995 PAGES:: 10 ABSTRACT:: Computing energy transfer between objects is the most expensive operation in radiosity systems. This energy transfer operation, known as the irradiance operator, is an integral that, in general, must be calculated numerically. We wish to increase the speed of this computation without severely compromising fidelity and perform a study of numerical integration techniques, $Quadrature$ $Methods$. The results of our study show the strengths of $Gauss$ $Quadrature$ $Rules$ and give us insights into greatly reducing the cost of the irradiance operator while maintaining accuracy. An adaptive method for choosing Gauss quadrature rules is presented, and our performance analysis of the new adaptive algorithm shows that it can be up to 10 times faster than previous methods. END:: PRINCETONCS//TR-485-95 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Electronically available reports can be retrieved via ftp (as described in records.) For other reports, local users can access them in the Math/CS Library. Non-Stanford users should either contact the publish- Electronic Library ing institution or arrange with their local library elib@db.stanford.edu for an interlibrary loan from Stanford Green Library. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From globillum-request@imag.fr Tue Feb 28 16:53:26 1995 Return-Path: From: "Holly E Rushmeier" Date: Tue, 28 Feb 1995 19:17:08 -0500 To: globillum@imag.fr Subject: Radiative Heat Transfer Workshop Results Status: R Hi globillumers, For those of you interested in rendering participating media, you might want to check out http://www.sandia.gov/html/frame/NSFFinal_with_graphics_1.html which is "The Use of High-Performance Computing to Solve Participating Media Radiative Heat Transfer Problems - Results of an NSF Workshop" Of particular interest is that the "Volume Rendering Problem" is identified as a "Major Research Thrust". -- Holly From globillum-request@imag.fr Wed Mar 1 03:00:55 1995 Return-Path: From: gatenby@igd.fhg.de Date: Wed, 1 Mar 1995 11:20:48 +0100 To: globillum@imag.fr Subject: polyhedra from polygons Status: R Hi, I wonder if anyone could help? ... I'm interested in generating a polyhedral scene from a set of input polygons which are completely free of connectivity/adjacency information. I would like to process these polygons to produce a collection of polyhedra. Does anyone have any pointers to papers on this topic? Does anyone have any experience of doing this - any advice on a nice compact representation for the polyhedra (I want to identify silhouette edges for disc. meshing radiosity) - i.e. which data structure would you advise - do people REALLY use things as wieldy as the winged edge? Any help much appreciated. Thanks in advance, Neil Gatenby Fraunhofer-Institut fuer Graphische Datenverarbeitung (Fraunhofer Institute for Computer Graphics) Neil Gatenby e-mail: gatenby@igd.fhg.de Fraunhofer-IGD, Wilhelminenstr. 7, 64283 Darmstadt, Germany. From greg Wed Mar 1 10:19:13 1995 Return-Path: Date: Wed, 1 Mar 95 10:16:34 PST From: greg (Gregory J. Ward) To: gatenby@igd.fhg.de, globillum@imag.fr Subject: Re: polyhedra from polygons Status: R Coalescing vertices from disjoint polygons is not particularly difficult, so long as your scenes are reasonably well-behaved. I wrote a translator from Radiance format (http://radsite.lbl.gov/radiance/HOME.html) to MGF (http://radsite.lbl.gov/mgf/HOME.html) which coalesced vertices using a simple hashing scheme. You are welcome to the source code for this -- it is on the above-mentioned servers. As far as connectivity information goes, I know nothing. It's a meshy problem! -Greg From globillum-request@imag.fr Wed Mar 1 21:30:44 1995 Return-Path: Date: Thu, 2 Mar 1995 00:15:59 -0500 To: gatenby@igd.fhg.de, globillum@imag.fr From: bwade@graphics.cornell.edu (Bretton Wade) Subject: Re: polyhedra from polygons Status: RO At 5:20 AM 3/1/95, gatenby@igd.fhg.de wrote: > Does anyone have any experience of doing this - any advice on a nice > compact representation for the polyhedra (I want to identify silhouette > edges for disc. meshing radiosity) - i.e. which data structure would > you advise - do people REALLY use things as wieldy as the winged edge? Dani Lischinski and Fillipo Tampieri used BSP trees to track discontinuities through space. BSP trees are fairly compact geometry representations that do not require explicit connectivity information, and so might be good for you. They would not be very useful for extracting polyhedra, however. I don't have the references right in front of me, so I hesitate to specify them; but I have them on my desk at work if needed. If you are not familiar with BSP trees, you might want to look at the BSP tree FAQ, which is still under construction: http://www.graphics.cornell.edu/bspfaq/ -- Bretton Wade (bwade@graphics.cornell.edu) http://www.graphics.cornell.edu/~bwade/ From globillum-request@imag.fr Thu Mar 2 04:08:30 1995 Return-Path: Date: Thu, 2 Mar 1995 11:54:39 +0100 From: Henrik Wann Jensen To: globillum@imag.fr Subject: Rendering Complex Scenes Status: RO Dear GlobIllumers, A few years ago a comparison between Radiance and a radiosity implementation on a moderately complex scene lead to the conclusion that Radiance was faster. I have wondered whether it in general is safe to assume that Monte Carlo based ray tracing methods are faster in highly complex scenes (ie. scenes with billions of objects) considering newer radiosity techniques like hierarchical radiosity and radiosity using clustering? I know it depends on the contents of the scene, but if we omit the irradiance gradient method and use path tracing or bidirectional path tracing and continue to increase the number of objects in the scene then I think we would see that the Monte Carlo techniques would render the scene in constant time, while radiosity somehow depends on the number of objects. - Henrik Wann Jensen From globillum-request@imag.fr Thu Mar 2 05:54:58 1995 Return-Path: From: "Seth Teller" Date: Thu, 2 Mar 1995 07:43:50 -0500 Reply-To: seth@theory.lcs.mit.edu To: bwade@graphics.cornell.edu (Bretton Wade), gatenby@igd.fhg.de, globillum@imag.fr Subject: Re: polyhedra from polygons, O(n^2) BSP Status: RO > discontinuities through space. BSP trees are fairly compact geometry > representations that do not require explicit connectivity information, and > so might be good for you. They would not be very useful for extracting > polyhedra, however.... Bretton, with all due respect I must ask you to be more careful about dispensing incorrect and/or misleading information in your replies, in your BSP faq, and elsewhere. A.) BSP trees are arguably not "compact," as they require Omega(n^2) storage and O(n^3) construction time for some 3D inputs. The storage lower bound is tight, see p. 500 of @article{Paterson90, author = "Michael S. Paterson and F. Frances Yao", title = "Efficient Binary Space Partitions for Hidden-Surface Removal and Solid Modeling", journal = "Discrete and Computational Geometry", volume = 5, number = 5, year = 1990, pages = "485--503", comments = "also Xerox PARC tech report CSL 89-6"} Stated differently, this means that there inputs of n polygons in 3d for which *every* BSP tree has size at least O(n^2). Apparently you have not yet corrected your FAQ http://www.graphics.cornell.edu/cgi-bin/bsp?18.txt in this regard. Your statement there that BSP's have a "provable lower bound [of] O(n)" doesn't make any sense. B) A BSP tree, if available, would be an ideal preprocessed data structure from which to abstract a winged-edge, facet-edge, or other adjacency data structure. You don't need a reference to see how; you simply walk the (necessarily convex) leaves of the tree, inducing shared edge pointers wherever two cutting planes of the BSP tree meet two faces of the input polyhedron along a common line in 3-space. Regards, Seth. -- Asst. Prof of EE & CS Synthetic 0 ~ ~ seth@lcs.mit.edu MIT Lab for CS NE43-208 Imagery <\> ~ tel: 617 258 7885 545 Technology Square Group / \ fax: 617 253 6652 Cambridge MA 02139 _______________ web: http://theory.lcs.mit.edu/~seth/ From globillum-request@imag.fr Thu Mar 2 10:37:31 1995 Return-Path: Date: Thu, 2 Mar 1995 13:06:49 -0500 From: Eric Haines To: globillum@imag.fr Subject: references Cc: bloom@cs.cornell.edu, erich@hemlock.eye.com Status: R I've run across a truly amazing site on the WWW (i.e. it's actually useful): http://www.ira.uka.de/ftp/ira/bibliography/index.html which has a collection of all sorts of computer science bibliographies. The nice part is that you can do on-line searches - it just turned up a reference I didn't know about on a topic, so I'm happy with it. You can search all the bibliographies (whew!) for a topic or just some specific ones. Fantastic, and free. Eric Haines From globillum-request@imag.fr Thu Mar 2 14:01:46 1995 Return-Path: X-Msmail-Message-Id: 6E95E378 X-Msmail-Conversation-Id: 6E95E378 From: Don Mitchell To: globillum@imag.fr, ziv@argus.asd.sgi.com Date: Thu, 2 Mar 95 12:21:04 TZ Subject: Re: O(n^2) bps trees Status: R I don't think Seth was being rude. It's important to understand the computational complexity of the algorithms we use, and visibility is a very tricky game in this regard. BSP-trees seem to gather a lot of passionate evangelism and detraction. I believe Apollo built a CAD system with BSP trees which did go O(n^2) -- pretty much in their customers' faces. I've heard other people say they never saw more than O(n) growth. Ziv Gigus has a masters thesis that gives details of experiments and results, and there clearly needs to be more of that in the literature. I seem to recall Ziv reported typical O(N logN) growth in 3D. Ziv, want to comment? What is really needed is an ongoing contest between inputs and algorithms. Something like this happens in the ray-tracing community, with Eric Haines input test scenes. The visibility problem (not just BSP approaches) would benefit from this. Revolutionary new approaches to visibility are being taken in games and PC graphics libraries. I can't divulge proprietary algorithms, so I'll just taunt you a bit. Look forward to some interesting revelations on visiblity in the coming years. :-) John Carmack, at id Software, deserves some special credit for the visibility algorithm used in DOOM. The bspfaq says he is using bps trees, but I believe he has made some novel advances beyond the standard usage. His first insight was that typical building interiors can be treated as a 2D problem instead of 3D. Paterson and Yao point out that the worst-case space complexity of BSP trees is only O(N logN) in 2D. Secondly, Carmack deals with occlusion culling in two interesting ways -- by drawing front to back with an efficient algorithm for knowing when the screen is completely drawn, and by augmenting the BSP-tree with bounding boxes for rapid culling of occluded subtrees. We've been using the term "DOOM trees" to refer to Carmack's work. I think he deserves that honor. :-) -- Don From globillum-request@imag.fr Thu Mar 2 23:57:46 1995 Return-Path: From: Eugene Fiume To: globillum@imag.fr Subject: Re: polyhedra from polygons, O(n^2) BSP Date: Thu, 2 Mar 1995 09:41:32 -0500 Status: RO On Mar 2, 8:11am, "Seth Teller" wrote: and then he wrote: } A.) BSP trees are arguably not "compact," as they require } Omega(n^2) storage and O(n^3) construction time for some } 3D inputs. The storage lower bound is tight, see p. 500 of The existence of such results, and indeed the ease of constructing such worst cases does not mean that these configurations are "common". Worst-case upper bound arguments are nice intellectual exercises and are sometimes even informative. Now, if you attach an argument that this situation readily arises, then you'll have my attention and you'll have properly made your point. Eugene. From globillum-request@imag.fr Fri Mar 3 10:21:06 1995 Return-Path: Date: Fri, 3 Mar 1995 17:01:56 +0100 From: Henrik Wann Jensen To: globillum@imag.fr Subject: Re: Rendering Complex Scenes Status: RO > > > continue to increase the number of objects in the scene then I think > > we would see that the Monte Carlo techniques would render the scene > > in constant time, while radiosity somehow depends on the number of objects. > Oops. I meant a constant number of rays in the Monte Carlo techniques. The intersection time will of course increase since none of ts optimizing schemes for ray tracing are O(1). But still I think the increase in intersection time is relatively small compared to the increased number of energy transfers that should be done in the radiosity algorithm. I will give a small example... Consider a small house with a lawn. Doubling the amount of grass in the lawn does not significantly change the indirect illumination on the house from the lawn. Since the noise in Monte Carlo methods primarilly is caused by indirect illumination this means that the noise-level would not change significantly. Therefore rendering the house using a Monte Carlo method could be done using the same number of rays --- this might be a large number of rays but still.... The radiosity algorithm on the other hand would have to consider the exchange of radiosity between every grass leave and doubling the amount of grass would significantly increase the number of necessary radiosity transfers. Please correct me if I am wrong.... I could reformulate this into a philosophical question. Is path tracing the ultimate rendering method when we consider very complex scenes? And maybe even if we only take the geometry into consideration? > that sounds like a great result, if you could show it experimentally. > Give me 100000 workstations and I will begin :-) - Henrik Wann Jensen From globillum-request@imag.fr Fri Mar 3 11:33:49 1995 Return-Path: X400-Received: by /PRMD=CA/ADMD=CDNnet/C=CA/; Relayed; Fri, 3 Mar 1995 9:55:21 UTC-0800 X400-Received: by /PRMD=ca/ADMD=telecom.canada/C=ca/; Relayed; Fri, 3 Mar 1995 9:55:17 UTC-0800 Date: Fri, 3 Mar 1995 9:55:17 UTC-0800 X400-Originator: fournier@cs.ubc.ca X400-Recipients: non-disclosure:; X400-Content-Type: P2-1984 (2) X400-Mts-Identifier: [/PRMD=ca/ADMD=telecom.canada/C=ca/;950303095517] Content-Identifier: 4003 From: Alain Fournier To: Henrik Wann Jensen (return) Cc: globillum@imag.fr (return) Subject: Re: Rendering Complex Scenes Status: RO "In deserto clamavi" (Latin from memory, pardon the potential barbarisms). Loosely translated, it means "I get no respect". I have long claimed that a good solution for global illumination of complex scenes is to use a "light driven" approach, namely where the light is transported explicitly between cells (sections of the environment), and not between surfaces (as in "radiosity" or path following schemes). The obvious advantage is that you control the process exactly where it should be controlled, as a function of the amount of light transported, not as the level of where it comes from or where it's going (even though you still have some control about that). The other big one is that "clustering", or simplification of the light flux, becomes a simple issue. I claim (somewhat facetiously, but with a basis in truth) that it is the only approach that has asymptotically the complexity of the "Utah approximation" (as Jim Kajiya calls it) with depth-buffer visibility, namely O(N), where N is the number of primitives in the scene. I won't go on about this, but details can be obtained on request. For many reasons (some fair, some not), the community has been unwilling to accept presentation of work in this direction, even in forums (fora) dedicated to works in progress. I think it's our collective loss, since even if one does not believe in a particular approach, one should realize that some of the concepts and techniques used can be relevant to other problems (not necessarily actively considered at the time). To quote Sonny Terry & Brownie McGhee: "We might be fighting a losing battle, but we had fun trying to win". From greg Fri Mar 3 12:06:33 1995 Return-Path: Date: Fri, 3 Mar 95 12:03:24 PST From: greg (Gregory J. Ward) To: fournier@cs.ubc.ca, hwj@hwj.gk.dtu.dk Subject: Re: Rendering Complex Scenes Cc: globillum@imag.fr Status: R I think Alain is onto something -- and maybe it has been used after all. As near as I can figure, the Integra system (sold by Arris in the US) uses a cell-transfer or at least cell-collected transport mechanism similar to the one described. Is Karol out there listening? Care to comment? As to the complexity of radiosity and path tracing approaches, I think in the end everything will be the same. After all, they are solving the same problem. Recent assertions as to the storage and computation required for advanced hierarchical and clustering radiosity methods are similar to those one would compute for a Monte Carlo solution to the same problem. The key difference currently is the problem definition itself -- most radiosity algorithms solve for the irradiance on objects, whereas most Monte Carlo algorithms solve for the pixels in an image. Given this difference, radiosity is bound to win when the number of pixels grows relative to the number of objects, and Monte Carlo will win as the number of objects grows relative to the number of pixels. I cite the additional evidence that most radiosity optimizations these days focus on geometric simplification (i.e. clustering and hierarchy) where current Monte Carlo optimizations focus on improved image sampling and filtering. A system such as the one Dr. Fournier proposes would no doubt concentrate on optimal subdivision and sampling of volumes instead. Looking at how Nature solves this problem, I would have to bet on pure Monte Carlo for the ultimate solution. However, given the finite resources of the computing world, we have to go with whatever bag of tricks gets us closest to what we want in the least amount of time. This, it seems, depends a good deal on the particular problem at hand. Monte Carlo for a forest, radiosity for three boxes. -Greg From globillum-request@imag.fr Fri Mar 3 12:42:40 1995 Return-Path: Date: Fri, 3 Mar 95 14:29:38 EST From: Peter Schroder To: fournier@cs.ubc.ca Cc: hwj@hwj.gk.dtu.dk, globillum@imag.fr Subject: Rendering Complex Scenes Status: R Date: Fri, 3 Mar 1995 9:55:17 UTC-0800 From: Alain Fournier I have long claimed that a good solution for global illumination of complex scenes is to use a "light driven" approach, namely where the light is transported explicitly between cells (sections of the environment), and not between surfaces (as in "radiosity" or path following schemes). The obvious advantage is that you control the process exactly where it should be controlled, as a function of the amount of light transported, not as the level of where it comes from or where it's going (even though you still have some control about that). The other big one is that "clustering", or simplification of the light flux, becomes a simple issue. I couldn't agree more. Once you include clustering into radiosity/radiance algorithms you get exactly this situation. See some of the recent work in this direction from GI and Siggraph. However, even if we get this to work there is still that pesky little problem of visibility. In fact we may have made enough progress on hierarchical numerical schemes at this point that fast and approximate(!) visibility is the most important aspect to attack. Peter From globillum-request@imag.fr Fri Mar 3 12:42:58 1995 Return-Path: Date: Fri, 3 Mar 1995 11:36:43 -0800 From: uselton@nas.nasa.gov (Samuel P. Uselton) To: fournier@cs.ubc.ca Cc: hwj@hwj.gk.dtu.dk, globillum@imag.fr Subject: Rendering Complex Scenes Reply-To: uselton@nas.nasa.gov Status: R Yo Alain! If we can have adaptive gridding of the environment, then I'm with you. Of course adaptive gridding is hard in its own right. (There are folks here at Ames working on exactly that kind of problem!) And it handles the participating media issues properly as well. I'm really surprised to hear you are having trouble finding a venue for this stuff. I'm interested in hearing about some of this "work-in-progress". I'll follow up with private mail. Later, Sam U. uselton@nas.nasa.gov From globillum-request@imag.fr Fri Mar 3 13:40:43 1995 Return-Path: From: Peter Shirley Subject: Re: Rendering Complex Scenes To: hwj@hwj.gk.dtu.dk (Henrik Wann Jensen) Date: Fri, 3 Mar 95 15:47:53 EST Cc: globillum@imag.fr Mailer: Elm [revision: 70.85] Status: RO Kajiya addressed this topic many years ago in a course note that I really liked: Article{kaji88, Author = "James T. Kajiya", Title = {An Overview and Comparison of Rendering Methods}, Journal = {A Consumer's and Developer's Guide to Image Synthesis}, Year = 1988, Pages = {259-263}, Note = {ACM Siggraph '88 Course 12 Notes} } He basically said that path tracing is faster than z-buffer approaches once there are thousands of primitives per pixel (note-- he said z-buffer-- we aren't even talking radiosity here). I think this assumes a static environment where you plan to make many frames in an animation-- this way you don't have to count the O(N) (I assume a uniform grid) setup time for ray tracing. I think AF's method sounds pretty neat. Please don't only share with SU! One thing I wonder about is how to ray trace procedural environments that are too big to be stored. Here I think you must use something other than straight radiosity (the light transport might have less detail than the geometry, so the AF volume idea might still work). Can we encode a spatial subdivision structure in the procedural model so that rays are log(N), where N is the number of "fully expanded" primitive polygons (or whatever the atomic primitive is)? How expressive are the set of primitve objects that can have such friendly properties? As an analogy, Perlin-style solid textures are friendly, while reaction-diffusion textures are not. I think making friendly procedural objects that coexist peacefully with hand-modeled objects is a neat (and hard) area to look at. A start can be found in: Article{ambu86, Author = "Phil Amburn and Eric Grant and Turner Whitted", Title = {Managing Geometric Complexity with Enhanced Procedural Models}, Journal = {Computer Graphics}, Year = 1986, Pages = {189-195}, Volume = 20, Number = 4, Month = {August}, Note = {ACM Siggraph '86 Conference Proceedings} } Does anyone have a bibliography on procedural modeling? From globillum-request@imag.fr Fri Mar 3 15:35:41 1995 Return-Path: Date: Fri, 3 Mar 1995 14:24:28 -0800 (PST) From: "Per H. Christensen" To: Peter Schroder Cc: hwj@hwj.gk.dtu.dk, globillum@imag.fr Subject: Re: Rendering Complex Scenes Status: R On Fri, 3 Mar 1995, Peter Schroder wrote: [...] > there is still that pesky little problem of visibility. In fact we may have > made enough progress on hierarchical numerical schemes at this point that > fast and approximate(!) visibility is the most important aspect to attack. > > Peter Yes, approximate visibility is perhaps the most important and difficult problem now (both for Monte Carlo or finite element methods)! We tried for a while to do some work on this, but got stuck on what we call the "coherence problem": If you divide the environment into cells, approximate visibility information can be computed for each cell. This can be done to a wide range of spatial and directional accuracy. So far so good. But -- when this approximate occlusion information is to be combined from the different cells that are between the "sender" and "receiver", the "coherence problem" arises: Using the approximate occlusion information, we no longer have information whether the patches in each cell are coherent or incoherent with the patches in the other cells. For example, if a beam of light is passing through two cells, with each cell having 50% occlusion within that beam (and in that direction), the total occlusion could be anything from 50% (if all the patches in one cluster are aligned with the patches in the other cluster) to 100% (if the patches in one cluster overlap the "holes" through the other cluster). In the end, we had to go back to the "good old" technique of shooting some number of sample rays and check each ray for intersection along the path. The accuracy can be controlled by the number of rays shot. Even with a hierarchy of cells, this sampling method is very time consuming -- it is easily the most time consuming part of global illumination. There is plenty of room for improvement here! -- Per From globillum-request@imag.fr Sat Mar 4 05:09:50 1995 Return-Path: Date: Sat, 4 Mar 95 08:51:31 EST From: Jorge Stolfi To: Alain Fournier Cc: globillum@imag.fr Subject: Re: Rendering Complex Scenes Reply-To: stolfi@dcc.unicamp.br Status: R > "In deserto clamavi" (Latin from memory, pardon the potential > barbarisms). Loosely translated, it means "I get no respect". > > I have long claimed that a good solution for global illumination > of complex scenes is to use a "light driven" approach, namely > where the light is transported explicitly between cells > (sections of the environment), and not between surfaces (as in > "radiosity" or path following schemes). The obvious advantage > is that you control the process exactly where it should be > controlled, as a function of the amount of light transported, > not as the level of where it comes from or where it's going > (even though you still have some control about that). The other > big one is that "clustering", or simplification of the light > flux, becomes a simple issue. One problem of using volume cells instead of surface patches is that a non-planar assemblage of Lambertian diffusers is in general not a Lambertian diffuser; that is, the amount of light scattered towards a given direction may depend strongly on the incoming direction. In fact, the scattering function can be much more complicated than typical models for non-Lambertian but flat surfaces. For instance, consider a cylindrical tin can, open at one end, painted black on the outside and white on the inside. Depending on where the incident light is coming from, the percentage scattered may vary from 0 to 100% of the incident light; and the outgoing distribution will probably have several peaks, in funny directions. So, I would think that a global illumination model that handles clustering must be a "second-order" model, where the unknowns are flows between pairs of cells, and the coefficient matrix has three-way form factors --- "how much of the light flowing from cell i to cell j is diverted to cell k". Are we ready to tackle this? I believe Leo Guibas and Eric Veach (Stanford) were looking into this approach a couple of years ago. Perhaps you should get in touch with them? --stolfi ------------------------------------------------------------------------ Jorge Stolfi | http://www.dcc.unicamp.br/~stolfi | stolfi@dcc.unicamp.br Computer Science Dept. (DCC-IMECC) | Tel +55 (192) 39-8442 Universidade Estadual de Campinas (UNICAMP) | +55 (192) 39-3115 Campinas, SP -- Brazil | Fax +55 (192) 39-7470 ------------------------------------------------------------------------ Please do not copy this .signature virus into your .signature file! From globillum-request@imag.fr Sat Mar 4 13:35:19 1995 Return-Path: Date: Sat, 4 Mar 1995 15:12:37 -0500 To: globillum@imag.fr From: bwade@graphics.cornell.edu (Bretton Wade) Subject: BSP Trees Status: R Bruce Naylor asked me to forward some of his comments on BSP Tree complexity to this mailing list. His first response to my and Seth's post: >First, Partitionings Trees are a representation of polytopes, >so the phrase "extract a polyhedra from bsp trees" needs to >be restated as "generate a boundary representation from a partitioning >tree". This I do all the time. > >Secondly, with regard to the O(n^2) result of Paterson and Yao, >this is not such an interesting result as it may seem. First, >in terms of worst case complexity, I showed in my thesis (1981) >that there were b-reps for which any tree using only planes of polygons >would be O(n^2). The result of Paterson and Yao is stronger in that >it gives an example for which any tree, including one using planes >not containing polygons, is O(n^2). However, this result is superceded >by a result in Benard Chazelle's thesis (1981), which proves that there >are polyhedra for which any convex decomposition is O(n^2). Since >partitioning trees are a convex decomposition, the fact that trees >can be O(n^2) follows immediately. > >Now in terms of expected case, all empirical evidence indicates >that tree size is O(n) for objects of interest (see my tutorial >in siggraph 94 course notes). And that the "compressed" versions >of trees are typically smaller than the "compressed" version of b-reps. > >The reason for the discrepency between worst and expected case is >the following. All worst case examples violate what I call the >Principal of Locality, that is, that geometric features of >real-world objects are local, i.e. they do not span the space. >The best example of geometry that violates the Locality Principal >is arrangements of hyperplanes, since hyperplanes are infinite. >And in fact, the upperbound for trees containing n hyperplanes >is exactly the bound on the size of arrangements of hyperplane, >which is O(n^d). > >Partitioning Trees capture locality through the ordering of the >hyperplanes. As one descends the tree, the size of the convex regions of >space represented by each tree-node decreases monontonically. >This can be used to create a multi-resolution representation >such that details are added as one descends into the tree. > >One last comment, the best published work on using Partitioning >Trees for radiosity is the paper of Campbell and Fussell in >Sigraph '90. A much fuller exposition is given in Campbell's >Ph.D. thesis, obtained at UT Austin. A different statement of why the O(n ^ 2) figure is not so useful: >In general, spatial search structures are only useful if what >you are "selecting" is a reasonably small subset of the geometry >present. So with non-local features, it is typically not possible >to select a significantly reduced subset, precisely because the >features are effectively global. So returning to the worst case >examples, every search structure using planes by which to partition >space, and so including regular grids and octrees, will also be >of size O(n^2) if one want no more than a constant number of >pieices in each cell of the search structure. What's more, if the >pieces of the b-reps are pushed together slightly so that they touch each >other, and one removes the coincident pieces of the b-rep, then >the number of b-rep polygons will also be O(n^2). > >So I think the O(n^2) result is not nearly as interesting as >some have thought it might be. A statement of the conditions which produce the worst case: >The case that produces O(n^2) is constructed from lines on >a hyperboloid of one sheet. This is a ruled surface with >two pencils of lines that, in essence, cross each other. >There is no way around this case. -- Bretton Wade (bwade@graphics.cornell.edu) http://www.graphics.cornell.edu/~bwade/ From globillum-request@imag.fr Sat Mar 4 16:07:40 1995 Return-Path: From: "Seth Teller" Date: Sat, 4 Mar 1995 18:46:27 -0500 Reply-To: seth@theory.lcs.mit.edu To: globillum@imag.fr Subject: BSP Tree [observed] complexity Status: R Bruce Naylor writes, via Bretton Wade: > the phrase "extract a polyhedra from bsp trees" needs to be > restated as "generate a [b-rep] from a partitioning tree".... i don't know what "needs to be restated" means. nor am i sure from where bruce took the phrase "extract a polyhedr[on] from bsp trees". my globillum post stated: A BSP tree, if available, would be an ideal preprocessed data structure from which to [ex]tract a winged-edge, facet-edge, or other adjacency data structure. my point was that generating robust connectivity information from an unorganized set of polygons seems hard, starting from scratch; but if someone hands you a BSP tree for the input, it becomes straightforward. > .... the O(n^2) result of Paterson and Yao ... is not [as] > interesting as it may seem.... in terms of expected case, > all empirical evidence indicates that tree size is O(n) for > objects of interest (see my tutorial in siggraph 94 course notes). this statement may be true, but it is unsupported by the scant body of empirical evidence in the literature, and seems to be refuted by many anecdotal reports. this is not the way to draw worthwhile conclusions about anything. i add my voice to don mitchell's: a thorough, objective empirical examination of the average case (not worst case) behavior of BSP trees is needed: a joint effort, perhaps using bruce's public-domain code as an agreeable "standard" testbed. i propose that we tabulate: construction time; total BSP complexity; and perhaps minimum achievable BSP complexity, without regard to construction time as a function of: varying model type (desk, plane, building, person, etc.), and increasing complexity (or level of detail) within each type. who will join in this effort? seth. -- Asst. Prof of EE & CS Synthetic 0 ~ ~ seth@lcs.mit.edu MIT Lab for CS NE43-208 Imagery <\> ~ tel: 617 258 7885 545 Technology Square Group / \ fax: 617 253 6652 Cambridge MA 02139 _______________ web: http://theory.lcs.mit.edu/~seth/ From globillum-request@imag.fr Sun Mar 5 17:24:58 1995 Return-Path: From: Peter Shirley Subject: Re: BSP Tree [observed] complexity To: seth@theory.lcs.mit.edu Date: Sun, 5 Mar 1995 19:44:40 -0500 (EST) Cc: globillum@imag.fr Status: RO seth@lcs.mit.edu writes: > > i add my voice to don mitchell's: a thorough, objective empirical > examination of the average case (not worst case) behavior of BSP trees > is needed: a joint effort, perhaps using bruce's public-domain code > as an agreeable "standard" testbed. i propose that we tabulate: > > construction time; > total BSP complexity; > > and perhaps > > minimum achievable BSP complexity, > without regard to construction time > > as a function of: > > varying model type (desk, plane, building, person, etc.), and > increasing complexity (or level of detail) within each type. This is a great idea. Eric Haines started such a database for ray tracing that certainly made comparisons MUCH easier, and I think it is time to pick some models that are more representative of real scenes. Seth, could we use some or all of the Berkeley CS building? Classifying scene properties will be fun-- I like Seth's classifications from the 94 Siggraph paper, but a more extensive categorization is needed. I think BSP trees and ray tracing algorithms would both be good to test on such a database... Pete From globillum-request@imag.fr Sun Mar 5 23:52:31 1995 Return-Path: X400-Received: by /PRMD=CA/ADMD=CDNnet/C=CA/; Relayed; Sun, 5 Mar 1995 23:16:00 UTC-0800 X400-Received: by /PRMD=ca/ADMD=telecom.canada/C=ca/; Relayed; Sun, 5 Mar 1995 23:15:57 UTC-0800 Date: Sun, 5 Mar 1995 23:15:57 UTC-0800 X400-Originator: fournier@cs.ubc.ca X400-Recipients: non-disclosure:; X400-Content-Type: P2-1984 (2) X400-Mts-Identifier: [/PRMD=ca/ADMD=telecom.canada/C=ca/;950305231557] Content-Identifier: 4011 From: Alain Fournier To: globillum@imag.fr (return) Subject: Re: Rendering Complex Scenes Status: RO It is gratifying to have so many thoughtful answers to my global rumination. It shows, though, the power of a paradigm (I must use this word because it's convenient in the context, and "model" is overloaded in computer graphics), in this case the rendering-equation/radiosity/form-factor/diffuse-reflector one. The following is not to say that the relevant posts are wrong (I have respect for most of the posters), but that some interpolations or extrapolations were too influenced by what is (and not helped by my tersity). When we talk about clustering, it should be clear that what we really want to achieve is cluster the light (the illumination), not the objects. In other words we are not (usually) interested in the cause but in the result. This is basic. If I am given a complete description of the light falling on an area (or a volume, generally speaking on a subset of the universe), I do not really care about where it comes from. Of course if my paradigm is to consider exchange of light energy between objects, it is difficult to deal with that, and form factors, or equivalent concepts, are hard to avoid. Essentially I have no model to express the light outside of objects, which is quite paradoxical when you think about it, since "free flight" light is a lot easier to deal with than light at interfaces with matter. Light clustering is handled easily in the light-driven approach, since you have an explicit representation of it. Spatial hierarchy is also handled because a reasonable implementation of the paradigm is to subdivide the scene hierarchically and adaptively as a function of the light transported. We use an octree, as the easiest structure to deal with, and because it fits beautifully with the dyadic subdivisions of our wavelet-based representation of the light flux. There seems to be a "miracle" happening, because we seem to solve an integral equation (the rendering equation) by non-standard ways. But it should be realised that the rendering equation has to be solved in its standard form only if we want to know for each surface element (or volume element) not only its radiance, but in some way where it is getting it from, which is gross overkill. To make the point more clearly, assume that I install a wall in the middle of my environment which collects every photon it receives and reemits it instantly or a some later date with the same wavelength and the same direction on the other side. Each half space is now totally independent by considering the wall to be an emitter with a fairly complex distribution, and a total absorber for incident light. Of course if there are only few objects on both sides of the wall, it is much worse than to compute directly the light exchanged between objects, but if there are huge numbers of objects with complex emitting and reflecting behaviour, it will always reach a point where the description of the light received (and consequently emitted on the other side) by the wall is simpler than the description of the exchange of light between the two sides. This is first because photons do not interact with each other, and because I assume that I can represent the light flux in a compact yet precise way (guess what I will use?). Now of course the problem is that some of the light reaching one side will bounce back to illuminate the other side, and so on.. If we assume that the light effects are linear (not always true in the vast physical world, but if we cannot assume this, "radiosity" and "ray-tracing" are also dead in the water), all we have to do is repeat the process. How many times? Well first we can wait until each side has settled down and only then sent the result to the other side. But then (especially after the emitters on each side have been taken care of) the amount of energy (actually power in a steady state) can only decrease, guaranteeing convergence. How fast? Well, consider a situation where 20% (quite generous) of the light received from one side is sent back to the other side. The fraction left after N trips across is of course 5^-N, which is a respectable convergence rate. Can you say "divide and conquer"? I knew you could. In practice we do not create a single wall, but subdivide adaptively the world according to the amount of undistributed power it has and the complexity of the scene it contains (that's where the octree comes in). Peter Schroeder mentions visibility, and indeed it is a pesky problem. But note that we have only local visibility problems here. We don't care to know if objects not in the same cell can see each other or not. If they can't their light ain't there, but we do not know that explicitly. Note that if we have a closet full of junk that does not receive any light, we do not even look at them (I exaggerate slightly, it depends on where the cells' boundaries fall). Note also that it looks like the old Warnock algorithm for visibility (in spirit, not in practice). Jorge Stolfi mentioned the fact that the light coming from groups of Lambertian diffusers is not distributed like from a single planar Lambertian diffuser. Indeed, but we are not restricted in any way to Lambertian diffusers (which is good, since they are so rare in captivity). In fact the less diffuse the light is the better it is for this approach in some sense (I must point out the Lazlo Neumann (& Neumann) has a wonderful study of various situations for the distribution of reflected light in the standard approaches to global illumination and what to do about it, to appear in TOG soon, I hope). Jorge's last point about 3-way form factors is precisely the reason the light- driven approach is attractive, since we do not have to consider explicitly the exchanges between cells, let alone between objects. Per Christensen's point about "approximate" visibility is well taken. No matter how well you represent the light flux at the cell boundary, an adversary can set up scenes where you are very wrong (the adversary just has to know if there is a band-limit to the representation, and set up two parallel venetian blinds above the limit frequency, which can either block all the light or let about half of it pass). But any method based on finite representations is vulnerable to such tricks. That does not mean that we should not be careful, though. Let me reiterate that in our model the cells do not represent groups of objects, but only provide boundaries at which to represent the light flux. Thank you also to people like Nelson Max and Greg Ward who pointed at the Integra system and Fujimoto as a possible source for a similar approach; Jorge Stolfi also pointed at work by Leo Guibas and Veach. I will follow these leads. I am gathering some old stuff we wrote about this, together with more current stuff. The history is that Eugene Fiume and I started to work on this around 1988 in Toronto (with Marc Ouellette and Chuan Chee), submitted a paper to Siggraph '89, got rejected, resubmitted in 1990, same fate. Paradoxically a paper on a parallel implementation of the scheme (with George Drettakis and Eugene Fiume) was accepted and published at Eurographics '90. At UBC we shifted to a wavelet representation for light flux (with Bob Lewis), submitted a paper to the Eurographics workshop on rendering, again to no avail. We will post a decent draft on the web asap. Note that we have not submitted anything about this to sigwaf this year, so there is no danger of interfering with the blind review process. Last point for now: much to my dismay it makes global illumination amenable to an Object-Oriented approach. From globillum-request@imag.fr Mon Mar 6 00:55:33 1995 Return-Path: Date: Mon, 6 Mar 1995 09:19:33 +0100 To: globillum@imag.fr From: wp@stellaris.cg.tuwien.ac.at (Werner Purgathofer) Subject: Re: Rendering Complex Scenes Status: RO Hello Alain, As you have not cited this in your Eurographics'90 paper, you might have overseen a very related approach by Xu, Peng, and Liang: "Accelerated Radiosity Method for Complex Environments", Eurographics'89 (North Holland). from the abstract: ... An () algorithm (), based on environment localization and the directional form-factor concept, is presented (). First we subdivide the object space into many regions. (). The radiant light energy transfer between different regions is evaluated at their common boundaries. ... Good luck! Werner ------------------------------------------------------------------- Werner Purgathofer Tel. +43(1)58801 4548 Institute of Computer Graphics ( secretary: 4549 ) Technical University of Vienna Fax. +43(1)5874932 Karlsplatz 13 / 186 email: wp@cg.tuwien.ac.at A-1040 Wien / Austria WWW: http://www.cg.tuwien.ac.at ------------------------------------------------------------------- From wpu@stellaris.cg.tuwien.ac.at Mon Mar 20 05:14:02 1995 Return-Path: Date: Mon, 20 Mar 1995 14:05:18 +0100 To: anjyo@hrl.hitachi.co.jp, kadi@irisa.fr, alan@cs.bris.ac.uk, mfc@cs.princeton.edu, feda@stellaris.cg.tuwien.ac.at, glassner@microsoft.com, stuart@lightwork.co.uk, hanrahan@cs.stanford.edu, fwj@duticg.twi.tudelft.nl, G00234@sinet.ad.jp, neum@integra.hu, Sumant.PATTANAIK@irisa.fr, Claude.Puech@imag.fr, xavier@baloo.udg.es, wp@stellaris.cg.tuwien.ac.at, holly@cam.nist.gov, gsakas@igd.fhg.de, salesin@cs.washington.edu, schlick@labri.u-bordeaux.fr, shirley@graphics.cornell.edu, slusallek@informatik.uni-erlangen.de, Francois.Sillion@imag.fr, aasousa@porto.inescn.pt, GJWard@lbl.gov From: wpu@stellaris.cg.tuwien.ac.at (W. Purgathofer, E. Groeller, M. Feda) Subject: Beware of VIDEA! Status: RO Dear colleague, enclosed we send you very shocking information on the "scientific" conference VIDEA'95 organised by the Wessex Institute of Technology. To prevent such cases in the future, please take time and read the enclosed paper. We promise, that you will not be only shocked, but that you will also have much fun! All given information is absolutely true and can be proven by us. Please, forward this mail to all colleagues in technological fields who could be affected by these activities of the Wessex Institute of Technology (can be reached via CMI@ib.rl.ac.uk). Werner Purgathofer, Eduard Groeller, Martin Feda Institute of Computer Graphics, Technical University of Vienna Karlsplatz 13 / 186 email: wpu@cg.tuwien.ac.at A-1040 Wien / Austria WWW: http://www.cg.tuwien.ac.at Begin of enclosed paper: --------------------------------------------------------- | WARNING: Beware of VIDEA! | | Werner Purgathofer, Eduard Groeller, Martin Feda | | TU Wien / Austria | --------------------------------------------------------- Abstract This paper illustrates that there are conferences which will destroy confidence in scientific life if the community does not forbid them. The Wessex Institute of Technology (UK) [1] organizes a whole series of regular conferences on various topics [2]. Our experiences are only with one of these, "VIDEA", but one should probably also be careful with the others. It is an offense against honorable scientists to offer false publication possibilities under a scientifically serious disguise for high fees. Our conclusion is: VIDEA accepts EVERYTHING! And we conclude from that that a publication in the VIDEA proceedings is worth NOTHING AT ALL! And to organize such a conference is simply a fraud. Conferences like VIDEA are a morally dispisable scheme to allow people to buy themselves publications without having to undergo any type of reviewing. It simply increases the flow of worthless data and makes it more difficult for scientists to extract really useful information Introduction Serious conferences usually introduce themselves by distributing a "Call for Papers" including a submission deadline. After having received contributions a technical program committee reviews and evaluates these to come to a decision which of the submitted paper proposals shall be accepted for the conference. Some conferences ask for abstracts first to be able to decide whether a topic is appropriate for their event, and ask for full papers (to be reviewed again) only thereafter. This holds also for a conference called "Visualization and Intelligent Design in Engineering and Architecture" (VIDEA'93). Having accepted to become a member of the program committee for VIDEA'93, one of the authors made two suspicious observations. Firstly, he received exactly zero abstracts and zero papers to review, and was never informed about any program committee meetings nor of any reviewing results. The program for the conference was finished apparently without involvement of the scientific advisory committee. We recognized this by receiving the printed advance program. Secondly, we submitted three papers to this conference, and they were all accepted without any comments, grades, or whatsoever. Meaningless to say that the visit to this conference was very disappointing both in the sense of contents and in the sense of organization. When two of the authors were asked to become members of the program committee for VIDEA'95 (to take place in La Coruna, Spain), we planned to test if any reviews take place at all. We would send them four abstracts that are obviously plain nonsense, that no excuse for accepting them could be taken seriously. This paper reports about this activity. The submitted abstracts We decided to write more than one crazy abstract to make sure that an acceptance cannot be interpreted as accident and so we tried different types of weird papers proposals. The first of four abstracts we produced was simply a completely irrelevant topic, namely how to create footprints on the walls of public rooms. It includes several statements that every reviewer must recognize as joke. The complete text is given in abstract 1. Extended abstract 1: --------------------------------------------------------- The Footprint Function for the Realistic Texturing of Public Room Walls Abstract Today's radiosity methods are able to produce nearly perfect light distributions for interior rooms. Unrealistic appearance now mainly is due to missing texturing of the walls. One important feature of public room walls are footprints in the lower areas. This paper presents a set of simple functions to easily generate a class of footprint textures for such applications. Different randomization techniques ensure the realistic appearance of the results. This technique is of increasing importance for the visualization of architectural objects in the future. Keywords realism, rendering, textures, footprints Introduction Today's radiosity methods are able to produce nearly perfect light distributions of interior rooms. Unrealistic appearance now mainly is due to missing texturing of the walls. One important feature of public room walls are footprints in the lower areas. The Footprint Function The basic footprint function is a combination of trivial, i.e. easy to implement, parametric functions. The footprint is divided into a ball and a heel which can have independent sole textures. The sizes are chosen such that a simulation of shoe sizes 35 to 42 for women profiles and 39 to 46 for men profiles is performed. Randomization Techniques Distribution techniques will be presented that ensure that the lower part of the wall contains significantly more footprints than the higher parts. Especially, no footprints must occur above a certain threshold height, due to physiological limitations of the human being. Additionally, random functions will take care that most footprints remain incomplete and vary in color and shape. Results Preliminary investigations are encouraging. As we have not implemented the new method yet, there are no concrete results, yet. The final paper might include images. Conclusion A footprint function for the realistic imaging of walls is presented. Details of all functions are given to ensure an easy implementation for the reader. References to be included in the final paper. --------------------------------------------------------- (end extended abstract 1) The second abstract describes a correct method which makes no sense at all, that is how to render interior rooms without light. Obviously, the resulting image will be completely black. This was written as in abstract 2. Extended abstract 2: --------------------------------------------------------- Efficient Radiosity for Daylight Simulation in Closed Environments Introduction Radiosity is a useful tool for architects and lighting engineers to simulate illumination in the interior of buildings. Unfortunately, the computation time for radiosity is very high. However, radiosity algorithms can take advantage of special scene properties of specific classes of environments. Exploiting the additional information about the scene structure of a particular class can decrease the computation time significantly. The aim of this paper is to speed up the radiosity computation for the class of closed environments without artificial light sources. Two Restrictions on the Scene Structure The first restriction on the scene is that it is closed. The reason for this restriction is the fact that radiosity is based upon the energy conservation principle, that means that at any time the amount of emitted energy equals the amount of absorbed energy plus the amount of energy leaving the scene. In closed scenes no energy leaves the scene, thus simplifying the radiosity computation. However, this restriction does not impose problems, because radiosity is mostly used for interior scenes. The second restriction is that only daylight can be considered. Radiosity algorithms solve a set of equations, where the radiosities of patches are the unknowns and the emissions are the constant terms. In conventional radiosity all patches are allowed to emit light, i.e. to be an artificial light source. If we assume that no patch has emission, we only have to consider daylight. This allows the use of very efficient solution methods known in numerical mathematics for the set of equations. The second restriction does not limit the range of applications too much as well, because in most cases architects are interested in visualizing their design with daylight conditions. Mathematical Foundation of the New Method Details will be described in the final paper. Benefits The new method reduces the computation time of both the radiosity evaluation and of image generation. Images can be generated at interactive rates even for very complex scenes, making the method suitable for walk-throughs and VR-applications. Since numerical techniques are mainly replaced by analytical formulas, no aliasing effects appear. Conclusion and Future Work The development of radiosity algorithms for special classes of scenes is a promising field of future research. Such algorithms are significantly faster and possibly more accurate than non-specialized algorithms. --------------------------------------------------------- (end extended abstract 2) These first two productions have at least a little bit the structure of a scientific paper abstract. What we also wanted to try was, if VIDEA would accept its own text as abstract. So we copied the complete introduction from the "Call for Papers" and gave this abstract the title of the conference. Minor changes were only made like changing the word "conference" to "paper". The result is given in abstract 3. Extended abstract 3: --------------------------------------------------------- Visualization and Intelligent Design in Engineering and Architecture Abstract In recent years, remarkable advances in computer visualization of objects and physical phenomena have been made. Computer images can now represent real objects very accurately. These techniques can be enhanced by defining any desired path, creating animation, moving computer views and real world video models, as well as sound tracks, resulting in multimedia representations. The development of these techniques has been possible because of the improvements in computer graphic devices, better algorithms and faster processors, which allow workstations and high speed PCs to be suitable platforms for visualization and have greatly improved the ability of high-performance computers to produce computer images, in animated forms, of complex engineering and architecture problems allowing a dynamic analysis of their behavior. Visualization has been essential for the development of new design techniques in engineering and architecture. The integration of computer visualization with other advances in computer computational sciences, such as knowledge based support systems, object bases, advance numerical methods, etc. provide the basis for intelligent design systems. The objective of this paper is to discuss advances in visualization as a tool for intelligent design in engineering and architecture. The paper aims to bring together research in computational mathematics and industrial hardware and software, as well as science, engineering and architecture for developing practical applications in these various fields. A presentation of our results on workstations with graphic peripherals and personal computers will be available to the audience. --------------------------------------------------------- (end extended abstract 3) Last but not least we decided to produce an abstract without any content, just complete nonsense. So we took a dictionary of information processing words and selected randomly some 40 phrases from there and joined them together to a fantastically technical sounding text. The given reference is, of course, the utilized dictionary! We had much fun with abstract 4. Extended abstract 4: --------------------------------------------------------- Distributed Multiprogramming System for Pen Selectors with Error Probability Extended Abstract Controllable connections for input/output supervisor channel adapters with line frequency scanning are often used for unavailable time. This paper describes the use of disturbance voltage with equivalent junction temperature as OP-trade-in for zone packed print. The main advantage over previous methods are the data transmission lines and routine conversion. Addressing, relative to preferred characters, uses a magnetic disk machine to enable incremental programming. The identifier transmission group correlates to non transmitting typewriters. Statistically spoken, manufacturing control and messages are mixed so that the primary supervisor may be located in different physical records. A collection of data is defined as the unit of transfer between the program and format management. The theory is based on arithmetic overflow, qualified names, and axial lead resistors. Using the Sparbuchdrucker-theorem [1] modified by ledger adjustment sales in combination with a secondary operator control station allows the number of single machines to roll over the keyboard. The basic origin coordinates ensure a diminished radix complement. In the future this generalized sequential access method will be the source for forced control field lines. References [1] Fachausdr=FCcke der Informationsverarbeitung, IBM Deutschland GmbH, 1985= . --------------------------------------------------------- (end extended abstract 4) Results All abstracts were sent to the conference in November 1994 and on January 14th, 1995 we received the results. All four abstract have been "reviewed and provisionally accepted"! This means, that the VIDEA conference organizers [3] claim someone has reviewed these abstracts and has found them suitable for the conference! As members of the program committee two of us had nothing to do with reviewing. The acceptance letter also contains information from which can be concluded that final papers will only be printed in the proceedings if the registration fee is paid together with the final paper. Additionally, the letter states "Due to the success of the conference and to be fair, we can only allow each participant to present one paper at the meeting which will be published in the proceedings" which makes sure that every published paper is paid for by a registration fee. The publisher (Elsevier) probably doesn't have the slightest idea that they are printing non-reviewed material as high-quality books. Conclusions We believe that Wessex Institute of Technology (or at least some people there) profit in a very dirty way from the international pressure on scientists to have long publication lists. They pretend to organize scientific conferences by giving them the look of such events. They use the names of the program committee members for economical purposes only. They "sell" publication possibilities to less experienced or naive members of our community and in this way ruin their work by producing a worthless publication. It is very dangerous to tolerate such developments. This would ruin the seriousness of our scientific culture. The effects of this little test definitely must be that this conference of the Wessex Institute of Technology is abandoned and ignored in the future and that the names of its organizers [3] are watched very carefully for their future actions. We will resign from the program committee immediately and try to warn all other program committee members and authors of accepted papers. Another effect of such scandals should be that the length of the publication lists of scientists must not become so important. Rather than that, other evaluation measures that emphasize quality instead of quantity should be internationally further encouraged. Only by reducing the pressure to produce lots of papers can the danger of such unmoral events be reduced. One positive side-effect would be a reduced intellectual pollution in some fields. A third aspect is how scientifically serios institutions can find support in the organization of local conferences. We want to strongly recommend to contact the established scientific associations of your field to ensure serious support, e.g. the national computer societies, or specialized associations for specific fields. They usually can help with publicity, financing, and high quality publications. Important Note We believe that Wessex Institute of Technology is fully responsible for this affair, and that both the university cite where VIDEA shall take place and the publisher who will produce the proceedings are fooled in the same way as the participants. References [1] Wessex Institute of Technology Ashurst Lodge, Ashurst, Southampton, SO40 7AA, UK. Tel +44(703)293223, Fax +44(703)292853, email CMI@ib.rl.ac.uk [2] WIT-conferences in 1995: SQM 95 (Software Quality Management), Seville, Spain COMPUTATIONAL ACOUSTICS, Southampton, UK WATER POLLUTION 95, Porto Carras, Greece MARINA 95 (Planning Design and Operation) St Raphael, France CMEN 95 (Comp. Methods & Experimental Measurements), Capri, Italy STREMA 95 (Structural Repairs & Maintenance of Hist.Buildungs), Crete, Greec= e SDDE 95 (Soil Dynamics and Earthquake Eng.), Crete, Greece SURFACE TREATMENT 95, Milan, Italy VIDEA 95 (Visualization & Intell. Design in Eng. & Architecture), La Coruna, Spain ASE 95 (Appl. of High Performance Computers in Eng.), Milan, Italy BIOMED 95 (Simulation in Biomedicine), Milan, Italy MOVING BOUNDARIES 95, Ljubljana, Slovenia URBAN TRANSPORT 95, Southampton, UK AIENG 95 (Appl.of Artificial Intelligence in Eng.), Udine, Italy CONTACT MECHANICS 95, Ferrara, Italy BEM 17 (Boundary Element Method), Madison-Wisconsin, USA MARINE TRANSPORT 95, Plymouth, UK COASTAL ENGINEERING 95, Cancun, Mexico BETECH 95 (Boundary Element Technology), Liege, Belgium OPTI 95 (Computer Aided Optimum Design of Structures), Miama, USA MARINE TECHNOLOGY 95, Szczecin, Poland AIR POLLUTION 95, Porto Carras, Greece MICROSIM 95 (Sim.&Design of Microsystems & Microstructures), Southampton, UK CMT 95 (Comp.Methods & Testing for Eng. Integrity), Kualar Lumpur, Malaysia [3] Director: Professor C.A. Brebbia, Wessex Institute of Technology --------------------------------------------------------- From globillum-request@imag.fr Mon Mar 20 08:11:28 1995 Return-Path: Date: Mon, 20 Mar 95 10:08:40 -0500 From: swestin@dsg145.nad.ford.com (Stephen H. Westin) To: wpu@stellaris.cg.tuwien.ac.at Cc: globillum@imag.fr Subject: Re: Beware of VIDEA! Reply-To: swestin@dsg145.nad.ford.com Status: RO Werner, I have heard of this sort of thing in the psychological literature, but only journals, not conferences. It certainly seems that there was an intent to deceive here, as a technical committee was recruited and advertised but apparently completely ignored. Thank you for bringing this to our attention. I'm sure that tenure committees will be on the lookout. -Stephen P.S. I can't wait to see the full paper for Abstract 4! From globillum-request@imag.fr Tue Mar 21 01:08:19 1995 Return-Path: From: Eugene Fiume To: globillum@imag.fr Subject: Re: Beware of VIDEA! Date: Mon, 20 Mar 1995 09:46:51 -0500 Status: R Congratulations to Professor Purgathofer et al. for making my day with the most hilarious paper abstract I've read in quite some time. I admit to not quite sharing their sense of moral outrage, which isn't to be taken as condoning the actions of the VIDEA organisers. On a weekly basis, I get invitations to write chapters for books. Some of them are from very reputable people, but a lot of these invitations would charge *you* money for publication; obviously these too are scams. Perhaps there are misguided academics out there who believe that padding their CV's with this kind of filler is helpful, but this is the first thing that is noticed in peer review for grants and in tenure review for ... you know what. Furthermore, and this is consonant with what Alain said a few weeks back, we need more fora (proper plural just to please Fournier) in which half-done and half-baked ideas can be presented and even written up. We do have to identify them as such, and even such a workshop should have a properly functioning review committee. But I would hate to see our outrage with pseudoconferences like VIDEA undermine earnest attempts at promoting new research ideas and fora. Cheers all, Eugene. From globillum-request@imag.fr Wed Mar 29 19:21:45 1995 Return-Path: Date: Wed, 29 Mar 1995 18:53:19 -0800 From: uselton@nas.nasa.gov (Samuel P. Uselton) To: globillum@imag.fr Subject: [elf@dgp.toronto.edu: Re: Beware of VIDEA!] Reply-To: uselton@nas.nasa.gov Status: R From: Eugene Fiume >Congratulations to Professor Purgathofer et al. for making my day with the >most hilarious paper abstract I've read in quite some time. I admit to >not quite sharing their sense of moral outrage, which isn't to be taken >as condoning the actions of the VIDEA organisers. On a weekly basis, >I get invitations to write chapters for books. Some of them are from >very reputable people, but a lot of these invitations would charge *you* >money for publication; obviously these too are scams. I'm afraid I come in on the side of moral outrage here. I agree that reasonably informed review committees are unlikely to pay attention to such listings on a vita (or even *downgrade* a person who would try to misrepresent them). And I have no problem with the idea of more fora for work in progress. The SPIE sponsored Electronic Imaging Symposium has a track ("conference") on Data Visualization that I regard as this sort of forum. The Volume Visualization and Parallel Rendering Symposiums started as this kind of workshop. And the net itself seems to be a good place for some of this activity. My outrage is in empathy for those researchers whose good names have been used by VIDEA to further their misleading activity. At the very least, the "program committee chair" should have notified the rest of the committee that so few papers were received that all were being accepted and no reviews were needed. And the conference should stop using the names of those who did no work. At least upon receipt of such notice the "program committee members" could request that their names be removed from promotional materials. Since they received no such notice, the chance to request removal slips by. The experiment clearly shows that the VIDEA organizers are irresponsible and I certainly wish to avoid having my name associated with them. Sam Uselton uselton@nas.nasa.gov From wp@stellaris.cg.tuwien.ac.at Fri Apr 7 01:49:42 1995 Return-Path: Date: Fri, 7 Apr 1995 10:45:40 +0100 To: anjyo@hrl.hitachi.co.jp, kadi@irisa.fr, alan@cs.bris.ac.uk, mfc@cs.princeton.edu, feda@stellaris.cg.tuwien.ac.at, glassner@microsoft.com, stuart@lightwork.co.uk, hanrahan@cs.stanford.edu, fwj@duticg.twi.tudelft.nl, G00234@sinet.ad.jp, neum@integra.hu, Sumant.PATTANAIK@irisa.fr, Claude.Puech@imag.fr, xavier@baloo.udg.es, wp@stellaris.cg.tuwien.ac.at, holly@cam.nist.gov, gsakas@igd.fhg.de, salesin@cs.washington.edu, schlick@labri.u-bordeaux.fr, shirley@graphics.cornell.edu, slusallek@informatik.uni-erlangen.de, Francois.Sillion@imag.fr, aasousa@porto.inescn.pt, GJWard@lbl.gov From: wp@stellaris.cg.tuwien.ac.at (Werner Purgathofer) Subject: Beware of VIDEA / part 2 Status: RO Dear colleague, you may have recently read the story "Warning: Beware of VIDEA!", and now are curious about its implications. This message contains - selected reactions from WIT and - comments from the authors. You can find the complete responses from WIT and all other reactions from the scientific community on our WWW-server: http://www.cg.tuwien.ac.at/~wp/videa.html Should you have distributed the original story, we ask you to send this follow-up to the same addresses. Thanks! We also want to apologize if you receive this message more than once, it is impossible for us to prevent that. If you have not seen the original story, yet, you can find it on http://www.cg.tuwien.ac.at/~wp/videa.html We promise, that you will not be only shocked, but that you will also have much fun! All given information is absolutely true and can be proven by us: Werner Purgathofer, Eduard Groeller, Martin Feda Institute of Computer Graphics, Technical University of Vienna Karlsplatz 13 / 186 email: wp@cg.tuwien.ac.at A-1040 Wien / Austria WWW: http://www.cg.tuwien.ac.at ----------------------------------------------------- In short: WIT organises a conference (VIDEA'95, 12-14 June) which they claim to be reviewed, but we believe it isn't. After VIDEA'93 we already had some doubts, and so we tested what would happen with four complete nonsense submissions. They were all "provisionally accepted". As members of the Scientific Advisory Committee we were not involved in a reviewing process. We feel that our names were only misused to give the conference a serious appearance. After some general explanations we will comment some of the more severe accusations in Prof. Brebbia's responses (marked with ">"). You can find the complete responses and all other reactions from the scientific community on our WWW-server: http://www.cg.tuwien.ac.at/~wp/videa.html First we want to point out that this should not be a personal attack against anybody. Our aim was only to discourage the organisation of expensive non-reviewed conferences, where participants not only spend a lot of money but also waste their creative work for non-reviewed publications. >Dr Purgathofer and Dr Groeller and their colleagues in > Vienna submitted abstracts to the conference (which > subsequently were found to be a spoof). >These abstracts were provisionally accepted in good > faith as they came from one of the advisory board > members. > > Note: It is relevant to state at this point what the > review process is for the conference. > > Abstracts are reviewed for relevance to the conference > and its technical objectives. Certain weight is also > given to the author, organisation and reputation in > the field. It is obviously not possible at this stage > to assess on the brief information provided, the full > technical merit of the proposed paper. A provisional > acceptance is given at this stage. > >In the case of Prof. Purgathofer and Dr Groeller, one >logically assumed that those abstracts sent by them and >their colleagues had already been assessed by them as they >were members of the Conference Scientific Committee of >VIDEA/95. We don't want to comment the seriousness of accepting submissions purely based on the institution they come from. It is, however, worth noticing that one of the submissions was sent from the fictive "Styrian Advanced Naval Research" institution with an unknown author name, from which it is impossible to recognise a connection to our institute. This abstract was also "reviewed" and provisionally accepted. >In addition they submitted papers of good quality to >VIDEA/93 which were published in the conference book. Maybe one of the initial reasons to publicize our observations was that we had lost three good quality papers into a non-reviewed book. >The authors, being experienced people, >would have been aware that the conference would >provisionally accept abstracts from advisory board members >and their colleagues. They also knew that any spoof >abstracts would be unlikely to be discovered until the >provisional programme was prepared or receipt of the full >papers. If even spoof abstracts are not detected during reviewing, what is the whole process good for? And our experience tells us that all submissions are handled equally at serious conferences, no matter where they come from. >We totally refute the allegation regarding the quality >of the conferences associated with Wessex Institute of >Technology and by implication the researchers and other >institutions associated with the conferences. (...) we >have received many messages of support from colleagues >throughout the world which we very much appreciate. We have also received many messages, and from some of them we can draw the conclusion that many other WIT conferences seem to be organised in a much more scientific manner than VIDEA, but there are also critical comments on other WIT conferences. We hope that in each single case the situation is clear to the involved people. Any damage, however, has to be blamed on the organisers of VIDEA. Another aspect is the "final paper reminder" we received, telling us that the paper cannot be accepted for the proceedings if not sent by 27 March, including a message "We will also require (...) payment to accompany your paper". >(...) The International Scientific Community is well >aware of this and our conference proceedings have always >reached a substantial number of sales, including the >proceedings of VIDEA/93. This is the point were we have to make clear that the first version of our story contains a slight incorrectness. The co-publishers of the VIDEA'93 proceedings were "Computational Mechanics Publications" and "Elsevier". >From this we (wrongly) concluded that Elsevier would also be involved in publishing the '95 proceedings, which Elsevier commented: "The copublication agreement we had with CMP lasted from 1991 to 1993, and we no longer have any involvement with their book publications. I should emphasise that this discontinuation was for commercial reasons alone." >As far as I can remember we have never received a >complaint about the quality of our conference proceedings >but rather numerous messages of congratulation and >complimentary reviews in the scientific literature, >including a message from Dr Groeller, saying >that he found VIDEA/93 interesting and that he wanted >his name to be included in the Scientific Advisory >Committee! First Eduard Groeller was invited by Prof. Brebbia for an invited talk and to become a member of the Scientific Advisory Committee. Due to our experiences with VIDEA'93 he reacted "Due to tight travel budget limitations I can only give an invited talk if travel expenses and conference fees are paid by the organising committee" and was thereafter cancelled from the publized committee without further notice. This was the moment when we decided to test VIDEA for its seriousness. So he wrote a flattery email to Prof. Brebbia, trying to find out why he was removed. The answer was "...your name has been erased because you were unable to attend the meeting. I will now see that it appears in the next Call for Papers". >We do not understand the motives of these people and we >find their action offensive, as it abuses the trust we all >place in our colleagues in the International Scientific >community. (...) If this type of behavior was repeated >by others the foundation of our scientific knowledge >base would be undermined. The key question is, who abuses the trust of the International Scientific community. A few days later Prof. Brebbia wrote: >I understand now why Prof. Purgathofer et al. have >decided to behave so maliciously (...) > (...) a meeting to be held in Dublin >from the June 12-14 1995 which has been co-organized >by Prof. Purgathofer of Vienna Technical University. > (...) his malicious allegations which we >first discovered are prompted by his involvement in >the Dublin meeting on the same dates. >The attitude of Prof. Purgathofer et al. is highly >unethical due to his intents to sabotage VIDEA/95 for >clear personnel gains. Believe it, or not: we have completely overseen this date collision until Prof. Brebbia wrote the above message, because we never planned to attend VIDEA'95 and therefore never looked at the date close enough. Luckily, Werner Purgathofer is only Program Co-Chair for the Dublin event (Eurographics Rendering Workshop) and has nothing to do with its organisation. Especially, any loss/profit has to be carried by others. The Rendering Workshop accepts a limited number of participants on a first come/first serve basis and had never had problems to reach this limit in past years. And the participants lists of VIDEA'93 and the Rendering Workshop'94 are disjoint but three persons, two of which are from our institute. So VIDEA was not even a competing event. And Prof. Brebbia is right: if we would have tried to sabotage VIDEA'95 for this reason, this would have been highly unethical. But how could we be that silly? >All members of the Scientific Advisory Committee were sent >a letter asking them for support and suggestions. >Although we did not specifically mention the reviewing of >abstracts in the letter, they are expected to help during >the review process if necessary. As a member of this committee for the last VIDEA'93 Werner Purgathofer never received anything to review. And here are excerpts from reactions of two other (prominent) Scientific Advisory Committee members. 1) "For VIDEA '95, I don't know why we are in the committee and of course, we did not receive any paper to review." 2) "They have once more put my name on their 'international committee' for this year's event, but I have heard nothing about reviewing papers." Summarizing, there might be areas in which non-refereed conferences are the normal case. This is certainly less true for several Computer Science areas. But the fact is that a conference which is announced to be reviewed ("all abstracts and final manuscripts submitted ... will be refereed ...") must really do so. WIT is selling a product where the declaration of its contents is wrong. And we believe that it is not only our right but our obligation to warn the scientific community of such circumstances. Remains to discuss one remark we received: "[in former days a] standard said, that no member of a program committee (advisory board as well?) should ever submit a paper, or if he did, he should immediately resign from the committee." This would make it quite unattractive to become a member of such a committee. In our opinion the integrity of all involved people should assure that such papers are handled completely equally as all others. Or are we wrong? ----------------------------------------------------- And finally an open letter to Prof. Brebbia: Prof. Brebbia, we believe we should not let this discussion escalate too much. We have learned a lot about you and your conferences during the last weeks. It is clear to us that a manager who has to take care of many things cannot have under control every detail. Although from the reactions we conclude that some of your conferences seem to fulfill the usual standards, you cannot declare that VIDEA does. We want to propose a way out of this dilemma which minimizes harm to people, institutions, and events not involved at all in the discussed topic. If you continue to declare that all your conferences are of equal quality, you will ruin the others also. You know as well as we do that our statements about VIDEA are true and it would be much better for you to confess this now than to get it proven by us during some legal process. At the same time you should do everything to ensure that none of your other conferences is organised in the way VIDEA was. To be fair to you, we have now put on our www-server http://www.cg.tuwien.ac.at/~wp/videa.html not only our story, but also all responses we received during the last 2 weeks, including all of your messages we got a copy of. All this stuff is only anonymised, without any additional censorship. From this, it must become clear to you that every additional step you take in the wrong direction will continue to destroy your image. Regards, Werner Purgathofer, Eduard Groeller, Martin Feda ------------------------------------------------------------------- Werner Purgathofer Tel. +43(1)58801 4548 Institute of Computer Graphics ( secretary: 4549 ) Technical University of Vienna Fax. +43(1)5874932 Karlsplatz 13 / 186 email: wp@cg.tuwien.ac.at A-1040 Wien / Austria WWW: http://www.cg.tuwien.ac.at ------------------------------------------------------------------- From globillum-request@imag.fr Fri Apr 21 09:19:59 1995 Return-Path: From: Peter Shirley Subject: Definition of "Radiosity method"? To: globillum@imag.fr Date: Fri, 21 Apr 1995 11:06:12 -0400 (EDT) Status: R < summary-- I want feedback on a proposed definition for "radiosity method"> Because of some comments in some siggraph reviews I have been researching the definition of "radiosity method". There are four obvious candidates given the usage I have seen: 1. A FE method for lambertian scenes. 2. A solution that somehow uses linear equations to represent light transport in a lambertain scene. 3. A FE method for global illumination (would include Sillion et a. '91). 4. An algorithm that computes view-independent illumination information. I have problems with all of these definitions. For example, if I use definition 1, is Pattanaik's thesis code a radiosity method in an all diffuse scene? Probably not, but I think most of us would want to call it a radiosity method. And how about Sillion and Puech '89? There are mirrors in their work-- is it radiosity? Jim Arvo has proposed a definition I want to float: A radiosity method computes radiosity (or irradiance) for at least some surfaces in the scene. This definition will encompass both FE and MC methods that compute quantities for the diffuse surfaces in a scene. It would not include Sillion et al. '91 (which could be a "radiance" method I suppose). Reactions? Pete From globillum-request@imag.fr Fri Apr 21 09:35:58 1995 Return-Path: From: Francois Sillion Subject: Re: Definition of "Radiosity method"? To: shirley@graphics.cornell.edu (Peter Shirley) Date: Fri, 21 Apr 1995 17:43:15 +0200 (MDT) Cc: globillum@imag.fr (Global Illumination List) Reply-To: Francois.Sillion@imag.fr Status: R < summary-- feedback on a proposed definition for "radiosity method"> I tend to think of a "radiosity method" whenever information is computed and attached to the surfaces, thus it includes illumination maps and 'light path tracing', as well as techniques where lambertian or directional radiant information is exchanged with form factors. In fact, I realize that any method that stores *some* radiant information is for me *a* radiosity method. *The* radiosity method, on the other hand, should be reserved for Lambertian surfaces with form factors etc... I think it is a pity to have inherited such a name (radiosity is not a method, but a radiant quantity), and I personally oppose the use of the similar 'radiance' method. I vote for item # 4 in your list: > Because of some comments in some siggraph reviews I have been > researching the definition of "radiosity method". There are > four obvious candidates given the usage I have seen: > > 1. A FE method for lambertian scenes. > > 2. A solution that somehow uses linear equations to represent light > transport in a lambertain scene. > > 3. A FE method for global illumination (would include Sillion et a. '91). > > 4. An algorithm that computes view-independent illumination information. > +------------------+---------------------------+--------------------------+ | | iMAGIS / IMAG | Tel: (+33) 76 51 43 54 | | Francois SILLION | B.P. 53 | Fax: (+33) 76 44 66 75 | | ' | F-38041 Grenoble Cedex 09 | Francois.Sillion@imag.fr | +------------------+---------------------------+--------------------------+ From greg Fri Apr 21 10:14:20 1995 Return-Path: Date: Fri, 21 Apr 95 10:13:56 PDT From: greg (Gregory J. Ward) To: shirley@graphics.cornell.edu Subject: Re: Definition of "Radiosity method"? Status: R How about "radiosity is some kind of method that has something to do with computing light and stuff." As far as I'm concerned, overuse of the term has made it next to meaningless at this point. It started out as a unit of diffuse radiation leaving a surface, which was pretty useless to begin with, and it went downhill. I vote we drop it. It is not now nor has it ever been descriptive of the finite element flux transfer techniques to which it's been applied. -Greg From globillum-request@imag.fr Fri Apr 21 11:56:03 1995 Return-Path: X-Msmail-Message-Id: F6055F1D X-Msmail-Conversation-Id: F6055F1D From: Andrew Glassner To: globillum@imag.fr, globillum-request@imag.fr Date: Fri, 21 Apr 95 11:08:11 TZ Subject: RE: Definition of "Radiosity method"? Status: R | | 1. A FE method for lambertian scenes. | | 2. A solution that somehow uses linear equations to represent light | transport in a lambertain scene. | | 3. A FE method for global illumination (would include Sillion et a. '91). | | 4. An algorithm that computes view-independent illumination information. | I tempted to agree with Francois in liking #4 the best, but it's too general. It can contain things that we don't want to call radiosity, like systems that decimate the world into cubes and do physical optics, propagating wavefronts from cube to cube. That's so far in spirit from the original use of radiosity that the term becomes so vague as to be useless. I'd reserve "radiosity" for FE methods like #3 (though Francois is right that it's not even such a good word for that). The problem is that as different things are added to the basic ideas of classical radiosity, the term seems to need to grow to accomodate them all. Maybe we can take a cue from the filter folks (with IIR and FIR filters) and refer to view-dependent illumination and view-independent illumination as VDI and VII algorithms; then classical radiosity algorithms are a subclass of the VII algorithms. So Radiance implements a VII method, but it's not radiosity. -Andrew From globillum-request@imag.fr Fri Apr 21 15:38:30 1995 Return-Path: X-Msmail-Message-Id: 3DA7EB16 X-Msmail-Conversation-Id: 3DA7EB16 From: Andrew Glassner To: globillum@imag.fr, globillum-request@imag.fr Date: Fri, 21 Apr 95 14:48:30 TZ Subject: RE: Definition of "Radiosity method"? Status: R I wrote (and I quote): | Maybe we can take a cue from the filter folks (with IIR and FIR filters) | and refer to view-dependent illumination and view-independent | illumination as VDI and VII algorithms; then classical radiosity algorithms are | a subclass of the VII algorithms. So Radiance implements a VII method, | but it's not radiosity. As Seth pointed out, new acronyms are tricky. When I said that Radiance is VII, I meant the part that deposits little diffuse packets on surfaces. This is driven, in part, by a VDI algorithm. Another reason, perhaps, why we ought not to let one term grow to encompass everything. From globillum-request@imag.fr Fri Apr 21 22:22:56 1995 Return-Path: Date: 22 Apr 95 00:56:48 EDT From: Ian Ashdown <72060.2420@compuserve.com> To: Global Illumination Subject: RE: Definition of "Radiosity method"? Status: R Call me a traditionalist, but I prefer to think of radiosity methods (plural) as finite element methods. They were in use as such for over 50 years before they were appropriated for computer graphics applications, and were called "radiosity methods" by Sparrow way back in 1963. It seems rather presumptuous to be fiddling with the basic definition some thirty years later to suit our particular needs. I see no particular problem with incorporating nondiffuse surfaces within the definition of radiosity methods. This allows for Pete's third definition, "an FE method for global illumination." However, adding Monte Carlo ray tracing to the definition (via Jim Arvo's proposal) may not be a good idea. One objection is that this would conflict with the similar definition of "radiative flux transfer" in the illumination engineering community. We lighting nerds clearly (and sometimes passionately) distinguish radiative transfer methods from Monte Carlo ray tracing techniques. The variety of global illumination algorithms we now have clearly calls for some sort of reasoned taxonomy to describe and classify them. Whatever this may be, however, I would argue that we should not attempt to redefine "radiosity methods" beyond that commonly understood within the computer graphics, thermal engineering, illumination engineering, and acoustic engineering communities. - Ian Ashdown From globillum-request@imag.fr Fri Apr 21 23:39:07 1995 Return-Path: X400-Received: by /PRMD=ca/ADMD=telecom.canada/C=ca/; Relayed; Fri, 21 Apr 1995 23:16:32 UTC-0700 Date: Fri, 21 Apr 1995 23:16:32 UTC-0700 X400-Originator: fournier@cs.ubc.ca X400-Recipients: non-disclosure:; X400-Content-Type: P2-1984 (2) X400-Mts-Identifier: [/PRMD=ca/ADMD=telecom.canada/C=ca/;950421231632] Content-Identifier: 4103 From: Alain Fournier To: Ian Ashdown <72060.2420@compuserve.com> (return) Cc: Global Illumination (return) Subject: RE: Definition of "Radiosity method"? Status: R Ah, the thrill of lexicography! We all realize that there will not be any definition that satisfies our understanding of an expression like "radiosity method", or any expression that covers exactly what we mean by any definition that would satisfy our understanding of it, if it were to exist. I hope I made myself clear. But seriously, folks... Things only mean what we say they mean. Take "finite element" for example. There is no way you would know what that means just looking at it, and even after hearing a definition (try one that does not take two pages and/or does not include just about everything that is computed) you still are not too sure what it starts and where it ends. The safest for us is that whenever we use an expression like "radiosity" we briefly say what we mean by it --in the particular context where it is used--. I had to do this recently because I wrote about using "arbitrary" BRDFs within the "classic" radiosity approach. In this context I called the classic radiosity approach "linear radiosity", thus approaching very closely definition 2. of Peter, except that surfaces are not necessarily Lambertian. Obviously "linear" here refers to the system of equations obtained. I actually like the use of the synecdoche for "radiosity", as long as we don't forget that anything that computes illumination in a useful way will have to be able to compute radiosity --the radiometric quantity. Few more things. I agree with Ian that we owe it to the other communities not to change arbitrarily the meaning of expressions they have been using for a while. I disagree with him about needing a taxonomy. To paraphrase Sam Goldwyn ("verbal agreements are not worth the paper they are written on"), taxonomies are usually not worth the theory they are not based on (I have indulged in the past, but I don't have to be consistent). Recently at a "PhD Thesis Proposal" (one of the events we cherish here in our department), the "candidate" was attacked because he used the word "illumination" in his title. The objection was that illumination is a quantity, not a topic or an area of research. Of course it used to be a quantity, but it never was only that, and it is now "deprecated", as they say, as a quantity. The candidate replied too politely. There are times when a graduate student should be able to tell a full prof that he is full of it (OK, maybe that was NOT the time...). In conclusion: we have to be as clear as possible, but not clearer. From globillum-request@imag.fr Sat Apr 22 00:32:34 1995 Return-Path: X-Msmail-Message-Id: D37CFA1E X-Msmail-Conversation-Id: D37CFA1E From: Don Mitchell To: globillum@imag.fr Date: Fri, 21 Apr 95 23:58:08 TZ Subject: radiosity Status: R I think a totalizing definition of radiosity would be easily deconstructed by the inherent contradictions in the binary opposition of radiosity and ray tracing. Wouldn't you agree, Alain? From globillum-request@imag.fr Sat Apr 22 05:12:49 1995 Return-Path: From: Peter Shirley Subject: Clarification on question To: globillum@imag.fr Date: Sat, 22 Apr 95 7:54:59 EDT Mailer: Elm [revision: 70.85] Status: R Thanks for the interesting responses so far! Here are three methods that estimate "radiosity" in a view-ind. manner: 1. Wallace: uses explicit patch-to-patch ray tracing and solves linear system. 2. Airey: uses Malley-style form factor computation using random directional ray shooting. 3. Pattanaik: uses photon-like particle walks and counts collisions with "zones" on the surfaces. I think 1 and 2 are FE methods. Number 3 is probably not under most definitions (e.g. Cohen and Wallace's book). But 2 and 3 are SO close conceptually and in code. The biggest difference is that in 2 a particle can leave the patch from a slightly different location than it hits. I am very uncomfortable with a definition of "radiosity method" that includes only one of 2 or 3. I also think we will confuse heat transer and illumination engineering people if we include methods such as Sillion et al. '91 which might never compute a "radiosity" anywhere. Pete PS-- one thing I AM sure of now-- the is NOT an accepted definition. This is something we should take care of culturally (rather than "officially") or we are doing a great disservice to future graphics people. From globillum-request@imag.fr Sat Apr 22 08:42:16 1995 Return-Path: From: Jim Arvo Subject: the meaning of radiosity To: globillum@imag.fr Date: Sat, 22 Apr 1995 11:23:07 -0400 (EDT) Status: R I'd like to offer a few thoughts on the use of the term "radiosity". The gist of my argument is that the simplest definition of the term seems to be most useful; making it more general or more specific causes problems. I advocate the following definition (which Pete Shirley already tossed out): A "radiosity algorithm" is an algorithm that generates radiosity-like quantities associated with surfaces (i.e. power per unit area, or the photometric equivalent) based on radiative transfer. Note that there is no reference to how this is done, whether all the surfaces are Lambertian, or whether there is any dependence on the view. The latter distinctions can be made by context or by attaching modifiers. As a very crude analogy, consider sorting algorithms. Any algorithm that generates a sorted list of things is a sorting algorithm, regardless of how it is done. If the "how" is important, then we may specify "quick sort", "heap sort", etc. Before getting into the real argument, I'd like to propose some rationale for why we invent terminology in the first place. It seems to me that a bit of terminology will catch on (and improve our lives) if it is 1) unambiguous (makes a clear distinction) 2) convenient (concise and makes a useful distinction) 3) self evident (agrees with intuition and/or common usage) Clearly these will often conflict, so it's not always possible to satisfy them all. In general, we try to satisfy these criteria by using short pithy terms for large classes of things (or extremely fundamental things), and attaching modifiers to call out specific sub-categories. I believe that the above definition of a radiosity algorithm is a good one with respect to these criteria. If the term "radiosity" is made more specific, such as by limiting it to finite element methods, then we shall need to 1) agree upon what a finite element method is, and 2) refrain from calling anything a radiosity method if it is not a finite element method. I believe there are problems on both counts. Consider the method developed by both Pattanaik and Shirley, which estimates radiosities on discrete elements via random walks. Is this a Monte Carlo method or a finite element method? If you focus on the path tracing, it is Monte Carlo. If you focus on (the expected values of) the estimated quantities, it is a Galerkin finite element method. Whether it is classified as a "radiosity" method should not (in my opinion) depend on which aspect you deem most relevant. As a second example, consider Hanrahan's original hierarchical radiosity method -- a Galerkin approach with constant elements. I believe there is universal agreement that this should be called a "radiosity" method. However, the form factors are computed using Monte Carlo, so one could argue that it is actually a Monte Carlo method (after all, it makes calls to "rand", right?). Is it therefore NOT a radiosity method? As a third example, consider an algorithm based on the Nystrom method: that is, a method that replaces the integral operator with a quadrature rule based on point-to-point transfers (i.e. no form factors). This is a deterministic method that is not a finite element method. However, it is very much like a finite element method. I would really like to call it "Nystrom radiosity" if what it computes is radiosity. Does this not seem very appropriate? As a final example, consider a hypothetical algorithm that can transform a simple scene (such as the "Cornell box") into an equivalent problem with an analytic solution. I know of no such algorithm, but I would not hesitate to call it a radiosity algorithm since it solves the same type of problem (albeit, without any type of projection onto an approximating subspace, which is inherent in finite element methods). In view of the above, I feel that including "finite element" in the definition of a radiosity method fails on two counts: 1) it is ambiguous, since it depends on which aspect of the problem you deem most important (sometimes we choose to ignore the Monte Carlo aspect, and sometimes we don't), and 2) it fails to make a useful distinction. Because of an historical accident (finite element methods came along first) it separates methods that seem to belong together because of their *function*. If it's important to distinguish the "how", it's easy to do so by adding a modifier like "finite element", "stochastic", "Nystrom", "analytic", etc. On the other hand, if the term is made more general by including methods that solve for surface radiance functions, then just about everything becomes a radiosity algorithm. I feel that we then lose a very useful distinction. I believe that one of the most fundamental distinctions among global illumination algorithms is whether they generate functions with directional dependence or not. Since the word "radiosity" taken by itself implies that there is no such dependence, the term is self evident only if we preserve that connotation; moreover, doing so agrees with most prior usage. Whether an algorithm is based on Monte Carlo or a finite element method, is view-dependent or view-independent, can be cleared up nicely by attaching the appropriate modifier when context alone is inadequate. Here are a few examples, which I'm sure will cause some controversy. I apologize in advance for leaving out so many references and for using such terse abbreviations -- I've listed just a few obvious examples in order to illustrate. (I hope I got most of these right.) Radiosity: Any method that produces radiosity (or irradiance, or luminosity) as its output. Examples: [Goral 84] [Cohen 85] [Sillion 89] [Rushmeier 90] [Shirley 90] [Pattanaik 90] [Hanrahan 91] [Zatz 93] [Troutman 93] [Gortler 93] [Smits 94] View-dependent radiosity: Solves for radiosities of visible surfaces, or some closely related set of surfaces. Example: [Smits 92], if importance is driven by the view, and not some other criteria. Also includes view-dependent path tracing, such as [Ward 88]. Radiosity with non-diffuse surfaces: ("non-diffuse radiosity" sounds like an oxymoron) One that takes non-diffuse transfers into account, but still produces only radiosities (or irradiances, or luminosities). Examples: [Sillion 89], [Rushmeier 90] Radiosity with participating media: One that solves for both surface radiosities [watts/m^2] and energy densities [watts/m^3] (the natural analogue of radiosity in a volume). Example [Rushmeier 87] Radiance method: An algorithm that produces surface radiance functions (I believe that all are currently view-dependent). Examples: Ward's RADIANCE system, [Kajiya 86] [Wallace 87] [Sillion 91] [Aupperle 93] (Note that this may involve a "radiosity" first-pass with a view-dependent path tracing second-pass). Radiance with participating media: One that solves for radiance functions at surfaces and/or in space, with at least one of them having directional variation. Example: [Max 94] Global illumination method: Any of the above. Now, even if everyone were to agree with the above argument (which is HIGHLY unlikely, I realize :-), we would still not be out of the woods. Should the definition also be more specific about the underlying physics (this was Andrew's point, I believe). What about direct illumination only? What about classical ray tracing (direct illumination plus pure specular chains)? My feeling is that we want to rule these out, but I'm wary of making the definition too specific, so I've not addressed this point (which seems to be a non-problem anyway). -- Jim Arvo From globillum-request@imag.fr Sun Apr 23 14:35:42 1995 Return-Path: Date: Sun, 23 Apr 1995 14:13:54 -0700 (PDT) From: "Per H. Christensen" To: globillum@imag.fr Subject: Re: Definition of "Radiosity method"? Status: R In my opinion, the term "radiosity method" should only be used for a method that *computes radiosity*. Why extend the term "radiosity method" to mean something not computing radiosity? If we want to describe global illumination methods, why not be more specific and describe them as: 1) what they compute (diffuse, glossy, specular, general), 2) the solution method (for example finite elements or Monte Carlo). For example, a more precise term for the classic radiosity method would be "a finite element method for diffuse global illumination". Jim Arvo proposed: > A radiosity method computes radiosity (or irradiance) for > at least some surfaces in the scene. I would favor a definition even more restrictive than this: a method that computes only radiosity, that is, no directional radiance information at all. With this definition of the term "radiosity method", the following classifications result: Pattanaik's thesis code working in a purely diffuse scene would be a radiosity method, I would call it "Monte Carlo solution of diffuse global illumination". If the scene had some non-diffuse reflection, it would not be a radiosity method, since the solution could not be described in terms of just radiosity (but requires radiance). Sillion et al '91 would not be a "radiosity method" since it computes directional radiance. I would describe it as a "finite element method for (general) global illumination". This avoids the term "radiance method" which several people dislike. Sillion and Puech '89 computes radiosity, but intermediate specular reflections are taken into account, I would call it something like "a finite element method for diffuse and specular global illumination". The computation method has nothing to do with whether the result is radiosity or not. Furthermore, whether the solution is view-dependent has nothing to do with whether the method computes radiosity or not. For example, Smits' et al '92 compute view-dependent radiosity solutions (at least the accuracy is view-dependent). Regards, -- Per From globillum-request@imag.fr Mon Apr 24 10:23:48 1995 Return-Path: From: "Holly E Rushmeier" Date: Mon, 24 Apr 1995 11:45:31 -0400 To: globillum@imag.fr Subject: terminology, taxonomy, was defn of "Radioisty" Status: R Hi I am glad this topic came up. I think taxonomies are really useful. They are a useful guide for people who want to use an existing method for their application. I'm prejudiced, but I think a useful taxonomy has been developed in the NIST Guide to Available Mathematical software (http://gams.nist.gov/). It helps people sift through all the various software repositories and find code that will solve their problem. People in the lighting community have recognized the problem in terminology and classifying methods. Michael Smith from Lighting Technologies is heading a CIE technical committee on computer procedures for lighting metrics and visualization. A major problem they hope to address is that users have no idea how to choose a lighting software package based on how it does calculations, because there is no standard vocabularly to talk about how the calculations are done. The committee is supposed to present a report that introduces a standard terminology for describing lighting calculations, gives a survey of algorithms and description of each, prepates a set of guidelines for what method should be used for what application, and produces an extensive set of references. Anyway, the point of all this is that standards for terminology and taxonomies are in the works so it is really worthwhile keeping up the discussion. -- Holly From globillum-request@imag.fr Sun Apr 30 10:30:56 1995 Return-Path: From: Peter Shirley Subject: Another unscientific survey To: globillum@imag.fr Date: Sun, 30 Apr 95 11:09:13 MDT Mailer: Elm [revision: 70.85] Status: R After our most recent discussions, it is clear to me that there is no accepted def'n for a "radiosity method" (in the rendering communit anyway)y. I have no feel for whether there is approximate aggreement however. I would like to get at this by having people on the list answer three questions from which a definition becomes implicit. Question 1: A radiosity method must be a finite element method (agree/disagree). Question 2: A radiosity method must estimate radiosity (radiant exitance), irradiance, or an analogous photometric quantity (agree/disagree). (as opposed to estimating radiance, etc.). Question 3: A radiosity method must compute a view-independent solution (agree/disagree). (for the sake of simplicity, meshing can be based on importance or viewpoint and still be view-independent). Please send responses to shirley@graphics.cornell.edu From globillum-request@imag.fr Sun Apr 30 11:59:58 1995 Return-Path: From: Peter Shirley Subject: READ THIS FIRST-- survey To: globillum@imag.fr Date: Sun, 30 Apr 95 12:43:10 MDT Mailer: Elm [revision: 70.85] Status: R Peter S, Jim A, and Dani L all gave me some valuable debugging on the previous version of the survey. Please answer these FOUR questions instead. After our most recent discussions, it is clear to me that there is no accepted def'n for a "radiosity method" (in the rendering communit anyway)y. I have no feel for whether there is approximate aggreement however. I would like to get at this by having people on the list answer four questions from which a definition becomes implicit. Question 1: A radiosity method must be a finite element method (agree/disagree). Question 2: A radiosity method must estimates a radiometric quantity for Lambertian surfaces only (agree/disagree). Question 3: A radiosity method may account for diffuse-specular-diffuse transfer. Question 4: A radiosity method must compute a radiometric quantity for (at least) every Lambertian surface in the environment (agree/disagree). Please send responses to shirley@graphics.cornell.edu Notes: Question 1 is asking whether Malley '88 MS thesis is a radiosity method (this may be an FE method-- so also is asking whether Pattanaik's particle tracing is a radiosity method). Question 2 is asking whether methods such as Sillion et al. 91 is a radioisty method. Question 3 is really asking whether Sillion and Puech is a radiosity method. Question 4 is really asking whether a diffuse-only Kajiya style path tracer is a radiosity method. -- From globillum-request@imag.fr Mon May 1 09:51:29 1995 Return-Path: From: Michael Cohen Date: Mon, 1 May 1995 12:29:36 -0400 To: globillum@imag.fr Subject: Radiosity Status: R 1. Agree (but of course this begs the question to define FEM) 2. Disagree - it doesn't bother me to have people to use the title of Radiosity Methods with appropriate adjectives for non-diffuse environments. 3. Agree - as I think this is part of the definition of (1) I think about the problem like this. We can (in general) distinguish between two sets of methods. Those that compute coefficients for basis functions that are not defines with reference to the view (although the computation of the coefficients might be). The result would be view independent (although the accuracy might not). I'm happy to have all these called radiosity methods (although I would prefer they were all just called Finite Element Methods). The second set of methods computes coefficients to basis functions that are view dependent, i.e., for the light arriving at some region of the image. These methods I would refer to as Ray Tracing type methods. I realize this also is not a clean line, for example, where does this place Greg's Radiance system. I'd call it Ray Tracing based as although there is some diffuse information deposited in object space, the final computation of a solution is always in image space. -Michael From globillum-request@imag.fr Thu May 18 06:03:54 1995 Return-Path: Date: Thu, 18 May 1995 13:44:10 +0100 From: Henrik Wann Jensen To: globillum@imag.fr Subject: BSDF symbol? Status: RO Dear Global Illuminators, The 1986 ANSI standard "Nomenclature and Definitions for Illuminating Engineering" containes symbol definitions for the BRDF (f_r) and the BTDF (f_t). However, it does not mention something like the BSDF (bidirectional scattering distribution function) f_s where f_s = f_r + f_t Is f_s a valid symbol or is p_bds or p_bd the preferred standard? - Henrik From globillum-request@imag.fr Thu Jun 8 07:24:13 1995 Return-Path: From: Peter Shirley Subject: some terminology notes To: globillum@imag.fr Date: Thu, 8 Jun 95 8:29:35 EDT Mailer: Elm [revision: 70.85] Status: R I will be leading a discussion at the 6th Eurographics Workshop on Rendering on terminology of the field. I have prepared a short informal document to help initiate discussion (see http://www.graphics.cornell.edu/~shirley/dublin.html or ftp://ftp.cs.indiana.edu/pub/shirley/dublin.ps). Let me know if you have any questions, opinions, or suggestions about the document. Pete Shirley From globillum-request@imag.fr Fri Jun 16 07:43:28 1995 Return-Path: From: Peter Shirley Subject: Re: total internal reflection To: erich@eye.com (Eric Haines) Date: Fri, 16 Jun 95 7:31:47 EDT Cc: globillum@imag.fr Mailer: Elm [revision: 70.85] Status: RO I find that it is worth it to let the ray go for at least dozens of bounces before terminating it-- especially for glass panes (like tabletops). This way the sides of panes can take on that colored "look" that makes a big difference in realism. But what happens when it goes further (as Eric asks?). I make it black-- that HAS to be bad. Should we let these rays go for hundreds of bounces? Maybe... From globillum-request@imag.fr Fri Jun 16 09:03:31 1995 Return-Path: Date: Fri, 16 Jun 1995 15:06:20 +0200 From: Phil Dutre To: globillum@imag.fr Subject: Re: total internal reflection Status: RO It's a known problem in the diamond-cutting world, that a bad cut diamond can cause black spots to be visible, due to infinite total internal reflection. So, it's hard to be sure whether a ray will leave a diamond again. Theoretically, this could happen after a few thousand internal bounces. This is also a problem when you want to render an endoscope, used by doctors to look at your intestines. If you model a glass fiber endoscope, and put the eyepoint of the ray tracer in front of it, you may want to go for a large number of bounces to see the things at the other side. So, basically, there is no way to do it correct, unless you let ray bounce an infinite number of times. Philip +---------------------------------------------------------------------------+ | Philip.Dutre@cs.kuleuven.ac.be Department of Computer Science | | http://www.cs.kuleuven.ac.be/~philipd/ Computer Graphics Research Group | | Phone: ++32 16 327094 Katholieke Universiteit Leuven | | Fax: ++32 16 327996 Celestijnenlaan 200A | | Office: C200, K.00.10 B-3001 Heverlee, BELGIUM | +---------------------------------------------------------------------------+ From globillum-request@imag.fr Fri Jun 16 16:29:12 1995 Return-Path: From: Eugene.Fiume@imag.fr (Eugene Fiume) Date: Sat, 17 Jun 1995 01:10:55 -0600 To: Peter Shirley , erich@eye.com (Eric Haines) Subject: Re: total internal reflection Cc: globillum@imag.fr Status: RO Peter remarks } But what happens when it goes further (as Eric asks?). I make } it black-- that HAS to be bad. Should we let these rays go for } hundreds of bounces? Maybe... Back (way back!) when I was interested in proving formal lower bounds for ray tracing I recall sketching something out that took advantage of this phenomenon. But let's go even further back and recall the immortal words in Turner Whitted's paper: For the case of surfaces aligned in such a way that a branch of a tree [of ray tracings] has infinite depth, the branch is truncated at the point where it exceeds the allotted storage. I always have loved the chutzpah of that line. [If Alain Fournier can quote Joyce, I'm allowed to quote Whitted, especially on Bloomsday.] Eugene. From globillum-request@imag.fr Tue Jun 27 04:03:01 1995 Return-Path: From: Francois Sillion Subject: Notations / Terminology To: globillum@imag.fr (Global Illumination List) Date: Tue, 27 Jun 1995 12:10:27 +0200 (MDT) Reply-To: Francois.Sillion@imag.fr Status: R Dear globillum, Those of you who attended the 6th eurographics workshop in Dublin know that there is a plan to create a 'consensus document' summarizing a number of recommendations for terminology (and possibly notations) to be used in our field. The outcome of the discussion in Dublin was that people interested in this discussion should form an informal group and prepare the document, which will then be discussed by all, with the goal of an ultimate publication as guidelines for our community. To get the ball rolling, I would like to hear from you if you are interested in joining the discussion (it could be done over globillum, but I fear that this would generate a lot of noise and bandwith waste, until we have at least a draft of the document..). Also, somebody mentioned that there was already a document (by Holly Rusmeier?) about terminology.. could someone point me to that document? Thanks.. I have also created a WWW page for the EG working group on rendering, which many of you know. The page is almost empty at this point, please check it out if you get a chance and let me know if you have any suggestions or want to contribute something. Any help will be appreciated. For instance if all organizers of previous rendering workshops could send me precise information on how to get the proceedings from their workshop it would help me a great deal. Oh, and finally, there is also a globillum WWW page, with mainly a pointer to the ftp archive of previous discussions. Again, this was put together very quickly, so please send your comments if you have any.. PS: http://safran.imag.fr/Membres/Francois.Sillion/egwkgr.html http://safran.imag.fr/Membres/Francois.Sillion/globillum.html +------------------+---------------------------+--------------------------+ | | iMAGIS / IMAG | Tel: (+33) 76 51 43 54 | | Francois SILLION | B.P. 53 | Fax: (+33) 76 44 66 75 | | ' | F-38041 Grenoble Cedex 09 | Francois.Sillion@imag.fr | +------------------+---------------------------+--------------------------+ From globillum-request@imag.fr Fri Jun 16 17:49:19 1995 Return-Path: From: Peter Shirley Subject: Re: total internal reflection To: Eugene.Fiume@imag.fr (Eugene Fiume) (Eugene Fiume) Date: Fri, 16 Jun 95 20:31:54 EDT Cc: shirley@graphics.cornell.edu, erich@eye.com, globillum@imag.fr Mailer: Elm [revision: 70.85] Status: RO > > of this phenomenon. But let's go even further back and recall the > immortal words in Turner Whitted's paper: > > For the case of surfaces aligned in such a way that a branch of > a tree [of ray tracings] has infinite depth, the branch is > truncated at the point where it exceeds the allotted storage. > > I always have loved the chutzpah of that line. > I recently re-read the Whitted paper and was shocked to see that it suggested randomly perturbing reflection vectors on glossy surfaces. Cook indeed credited him with the idea in the 84 Siggraph paper. That paper was full of gems. P From globillum-request@imag.fr Tue Jun 27 10:48:18 1995 Return-Path: Date: Tue, 27 Jun 1995 12:37:20 -0400 To: globillum@imag.fr From: bwade@graphics.cornell.edu (Bretton Wade) Subject: finite element meshing technology Status: RO http://www-users.informatik.rwth-aachen.de/~roberts/meshgeneration.html It seems to me that a web page like this one could be very useful to us, especially given the recent interests in decimation and meshing of functions. If you know of any other online resources, please send them to me. I'll either forward them to the owner of the page above, or organize them myself. Thanks, Bretton -- Bretton Wade (bwade@graphics.cornell.edu) http://www.graphics.cornell.edu/~bwade/ From globillum-request@imag.fr Wed Jun 28 09:36:43 1995 Return-Path: Date: Wed, 28 Jun 1995 16:28:41 +0200 From: Nicolas Holzschuch To: globillum@imag.fr Subject: Source code for radiosity gradient Status: R At the last EG Workshop on Rendering in Dublin, I presented a paper about "Accurate Computation of the Radiosity Gradient for Constant and Linear Emitters". Since then, I have been cleaning the implementation code for computing the radiosity gradient. It is now ready. You can fetch it at ftp://safran.imag.fr/pub/holzschu/gradient.tar.gz From glassner@microsoft.com Fri Jun 30 21:57:09 1995 Return-Path: X-Msmail-Message-Id: AA9174DF X-Msmail-Conversation-Id: AA9174DF From: Andrew Glassner To: erich@eye.com, greg@hobbes.lbl.gov, musgrave@seas.gwu.edu Date: Fri, 30 Jun 95 11:50:57 TZ Subject: RE: max index of refraction? Cc: erich@hemlock.eye.com Status: R Eric: Good question - I've never run across a reference to this in print. My guess is that it would have something to do with the collapse of matter into plasma or something - what's the index of refraction of a neutron star? Inside a black hole? I would also guess something funny goes on when you start packing matter too closely together. If you find out about this, pass it on. -Andrew From globillum-request@imag.fr Thu Jul 6 18:48:41 1995 Return-Path: To: globillum@imag.fr From: iashdown@ledalite.com (Ian Ashdown) Subject: Shortest radiosity code? Date: Thu, 6 Jul 1995 17:12:19 +0100 Status: R I couldn't resist this one. Chris Borel from the Los Alamos National Laboratory (cborel@lanl.gov) asked me: >In 1993 or so I spent a day to rewrite [my] radiosity code in IDL making use >of IDL's powerful 3-D manipulation and Z-buffer capabilities and came up >with a code of 153 lines doing the same task as the viewfactor FORTRAN code >at about the same speed! The code is not quite finished yet but I wonder >if there is any radiosity code that is shorter than that. I know a ray tracer can be written in one line of C source code, but a radiosity renderer!?! Ian Ashdown, P. Eng. READ THE BOOK! Research & Development Manager Radiosity: A Programmer's Perspective Ledalite Architectural Products Inc. by Ian Ashdown 9087A - 198th Street New York, NY: John Wiley & Sons, 1994 Langley, British Columbia Canada V3A 4P8 (Sneaky Internet Advertising) From globillum-request@imag.fr Thu Jul 6 18:49:28 1995 Return-Path: To: globillum@imag.fr From: iashdown@ledalite.com (Ian Ashdown) Subject: Non-Diffuse Radiative Transfer Date: Thu, 6 Jul 1995 16:20:34 +0100 Status: R Several weeks ago, David DiLaura posted a message saying that he had written a paper called "Non-Diffuse Radiative Transfer 2: Planar Area Sources and Receivers." He indicated where a Postscript copy could be downloaded from for review. If you downloaded and read (and understood!) the paper, the Illuminating Engineering Society of North America has a favor to ask of you. David will be presenting his paper at the 1995 IESNA Annual Conference in New York at the end of this month. Following each presentation is an audience discussion in which the paper is dissected and commented on. In the case of David's paper, there may not be anyone at the conference who will be qualified to discuss his work. If so, this will be unfortunate, because (a) the discussions become part of a presented paper when (and if) it is published in the Journal of the IES; and (b) I feel that this is an important piece of work. If anyone has any comments on the paper, ranging from errors in the text or mathematics to general comments on the usefulness of this approach in global illumination applications, the IESNA would very much like to hear from you. Any comments will be presented to the audience, and so they should be 400 words or less in length. Submissions that David will need to respond to are required by July 12th; otherwise, they will be accepted if received before July 25th. If you can e-mail or fax your comments to me at: e-mail: iashdown@ledalite.com Fax: (604) 888-0566 (Attn: Ian Ashdown) I will ensure that they are presented at the conference (with full credit to the authors, of course). On behalf of the IESNA, thanks! Ian Ashdown, P. Eng. READ THE BOOK! Research & Development Manager Radiosity: A Programmer's Perspective Ledalite Architectural Products Inc. by Ian Ashdown 9087A - 198th Street New York, NY: John Wiley & Sons, 1994 Langley, British Columbia Canada V3A 4P8 (Sneaky Internet Advertising) From globillum-request@imag.fr Fri Jul 7 04:29:37 1995 Return-Path: From: Alain.Fournier@imag.fr (Alain Fournier) Date: Fri, 7 Jul 1995 12:04:57 -0600 To: Peter Schroeder , globillum@imag.fr Subject: Re: Shortest radiosity code? Status: RO Considering that there is an inverse relationship between length of code and running time, I am afraid that "idle printer down the hall" won't be idle any more in this millenium. Remind me not to send any printing job to Peter's place (by the way, can you "nice" a postscript job?). From globillum-request@imag.fr Wed Jul 12 09:09:50 1995 Return-Path: Date: Wed, 12 Jul 1995 16:44:22 +0200 From: Tomas Moller Apparently-To: globillum@imag.fr Apparently-To: Radiosity@prosolvia.se Apparently-To: sampling@prosolvia.se Apparently-To: &@prosolvia.se Apparently-To: reconstruction@prosolvia.se Status: RO Hello GlobIlluminers! I have just joined this mailing list (thanks Francois Sillion) and yesterday I read all previous discussions here. Interesting! I am working on a radiosityprogram for use within VR-applications. I hope to finish my master thesis at the end of this summer. The surfaces that are imported to my program are all NURBS. I have found three references for curved surfaces within radiosity: %T A Progressive Radiosity Algorithm for Scenes Containing Curved Surfaces %J Computer Graphics Forum (Eurographics '93) %D Sept. 1993 %T A New Radiosity Apporach Using Area Sampling for Parametric Patches %J Computer Graphics Forum (Eurographics '93) %D Sept. 1993 %T A Two-Pass Radiosity Method for Bezier Patches %E K. Bouatouch %E C. Bouville %B Photorealism in Computer Graphics (Proceedings Eurographics Workshop on Photosimulation, Realism and Physics in Computer Graphics, 1990) %D 1992 But I have not got hold of these articles. Can anyone help? Anyway, I am sampling (using ray-casting to compute form-factors) uniformly in uv-space on the NURBS, and then I subdivide adaptively if needed. Now I was wondering if there is some other technique for sampling curved surfaces. Has anyone tried sampling uniformly in 3D instead, that is letting the 3D-distance between a pair of neighbour-points be constant all over the surface? Or positioning more sample points in regions of high curvature (although this seems often to be the case when sampling uniformly in the parametric uv-space for my NURBS) ? Or any other? I am using my radiosity solutions for VR-applications which means that I want fast reconstruction of the radiosity functions over the surfaces. Is everyone using Gouraud-shading for fast radiosity- reconstruction? Sampling uniformly in the uv-space implies a texture map, so I am generating a texture map containing the radiosities of each surface. Then I am texture mapping this bitmap onto the surface in order to reconstruct the radiosity function fast. My machine has no performance penalty for texture mapping, so it is fast. Also, another advantage is that you could use the radiosity texture map with any triangulation of the surface. This is not the case when using Gouraud shading. Anyone has any comments, faster methods, better methods? Are these just old ideas? A last question: do most people use discontinuity meshing nowadays or are you still using the traditional methods? Sincerely, Tomas Lund Institute of Technology Sweden From globillum-request@imag.fr Fri Jul 21 21:05:13 1995 Return-Path: Date: Fri, 21 Jul 1995 20:28:27 -0700 (PDT) From: "Per H. Christensen" To: globillum@imag.fr Cc: "Per H. Christensen" Subject: Thesis Status: RO Hi Globillumers! I've just finished my dissertation. It's entitled "Hierarchical Techniques for Glossy Global Illumination" -------------------------------------------------------------------- Abstract: This dissertation concerns efficient computation of realistic images. To compute realistic synthetic images, the effect of global illumination is essential. Ray tracing algorithms solve the global illumination problem for specular interreflections, and radiosity algorithms solve it for diffuse interreflections. But computing a solution is more complicated when the surfaces have glossy reflection. This dissertation describes hierarchical techniques for efficient solution of the glossy global illumination problem. Two types of hierarchy are utilized: wavelets to accurately represent radiance distributions on surface patches, and clusters to approximately represent radiant intensity from groups of surface patches. Without hierarchical techniques, the solution time would be quadratic in the number of patches and $O(b^{1.5})$ in the number of basis functions~$b$. The hierarchical techniques make solution time linear in both the number of patches and in the number of basis functions. This reduction is significant since the numbers of patches and basis functions are large for accurate solutions in realistic environments. Furthermore, directional importance is used to focus refinement of the solution on parts that contribute significantly to a particular view of the scene. Our method is the first finite-element method capable of handling complex glossy scenes. ----------------------------------------------------------------- If you would like to read more than the abstract, go to http://www.cs.washington.edu/homes/per/publication.html and click on "dissertation" or "smaller version". The smaller version is much faster to transfer, but has no color images. -- Per From globillum-request@imag.fr Tue Jul 25 08:21:55 1995 Return-Path: Date: Tue, 25 Jul 95 14:53:28 BST From: Simon Gibson To: globillum@imag.fr Subject: Units of Radiance Status: RO Dear all, Could somebody please tell me how to convert from luminance (cd/m(-2)) to radiance (W/m(-2)/sr). E.g. a surface has a radiance value of 3183 cd/m(-2). What is that in W/m(-2)/sr?? Any help much appreciated. Simon. From globillum-request@imag.fr Thu Jul 27 16:29:11 1995 Return-Path: From: danix@cs.washington.edu (Dani Lischinski) Subject: glossy clustering To: globillum@imag.fr Date: Thu, 27 Jul 1995 16:01:58 -0700 (PDT) Status: RO Dear globillumers, As some of you may know, Per Christensen, Eric Stollnitz, David Salesin and I have been doing some research on extending clustering to glossy global illumination. Last month we submitted a paper "Clustering for Glossy Global Illumination" summarizing our research to ACM TOG. The paper is available online via anonymous ftp from espresso.cs.washinton.edu under pub/danix/clustering (ftp://espresso.cs.washinton.edu/pub/danix/clustering on the WWW). An earlier version of this paper was submitted to Siggraph 95 (and was rejected). Fortunately, the comments of the anonymous reviewers challenged us to substantially improve both the paper and the implementation. The highlights of the results section are: a comparison with RADIANCE on a glossy "sphereflake" model and nice global illumination solutions for an architectural environment with ~8000 initial surfaces, most of which are glossy. If you happen to read the paper and have any comments, please e-mail them to me, or we could discuss them at Siggraph. Thanks, Dani ------------------------------------------------------- Dani Lischinski Department of Computer Science and Engineering University of Washington Box 352350 Seattle, WA 98195-2350 e-mail: danix@cs.washington.edu, phone: 206 543-3368 ------------------------------------------------------- From greg Thu Aug 10 15:00:38 1995 Date: Thu, 10 Aug 95 15:00:36 PDT From: greg (Greg Ward) To: globillum%imag.fr@lbl.gov Subject: Siggraph meeting Status: R Hello Globillumers, Well, we just got out of our annual Siggraph lunch meeting, so I thought I would jot some notes about it while it was still fresh in my overcrowded brain. There were about 20 of us attending, and I won't embarrass myself by mispelling (or forgetting) everyone's name, but instead I'll just mention some of the topics we covered and what was said about them. 1. Sharing models and data To address need for shared models that are usable and useful for global illumination, a new format has been developed called MGF (for Materials and Geometry Format) and models and libraries are now available from: http://radsite.lbl.gov/mgf/HOME.html Or, if you only have ftp access, try: anonymous@hobbes.lbl.gov /www/mgf/ This format supports a reasonable reflectance model, CIE XYZ and spectral colors, and the IES luminaire data format for light sources. A number of models from Radiance and other sources have been collected, and we encourage people with big hearts to add their own models to our collection. Write to me if you have any questions or want to get on the mailing list for how to improve this format to meet our long-term needs. 2. Setting up light sources Dan Wexler pointed out that one of the biggest time sinks in animation and rendering for film is the setting up of light sources, and that methods for making this more interactive were critical to this application. Specifically, he felt that a "deep raster" approach (similar to that developed by Sequin et al and presented at Siggraph 4 years or so ago) was a good way to go. In general, he felt there needed to be more of an emphasis on animation and interaction than there was in our current focus on static environments and generating one really nice image. 3. Image-based rendering Pete Shirley addressed a general question to the group about the relative importance and promise of image-based rendering (ala Quicktime VR) versus polygon-based methods. The overall response seemed to indicate that indeed image interpolation was a significant direction to head in the future, though polygon rendering will continue to be important when object manipulatin is required and for nearby objects. It seemed that at least five people there were actively pursuing such techniques. (Check out this year's Siggraph proceedings on Plenoptic Modeling and Quicktime VR, also Nimeroff et al in Eurographics Rendering Workshop '95.) 4. Visibility processing Several people talked about the difficulty of geometric simplification and other statistical or computational geometry methods for detecting visibility changes or approximating visibility. Christine Piatko of NIST reminded folks that tracking visibility is an O(N^6) problem and not something you want to do explicitly, and there was an interesting paper by Francois Sillion and George Drettakis (similar in some respects to the one Francois presented at EGRW this June) on approximating shadows. Jeff Nimeroff of UPenn also mentioned the work he had done with Julie Dorsey and Holly Rushmeier and presented at EGRW on statistical measures of object visibility for looking at this problem. It was agreed by most that statistical measures or simplification were necessary in large environments, though there is still much work to be done in this area. 5. Calibrated input and output Holly Rushmeier (who by the way is next year's Siggraph papers chair) talked a little about the difficulty of obtaining accurate physical data from real-world scenes, and a number of people lamented about the undetermined nature of image-to-output mappings for computer monitors, printers and film recorders. It was suggested that these devices be measured, which is certainly possible, and that this data be shared with the larger community. (Hear, hear, let's all do it, etc.) Holly and I also reminded people to look at the conference room image measurements and model we have made available on the web site: http://radsite.lbl.gov/mgf/compare.html >From there, you can also pick up an online copy of our EGRW '95 paper on image metrics if you haven't purchased the Springer-Verlag proceedings yet. 6. Getting papers into Siggraph Henrik Wann Jensen of Denmark asked about the lack of papers covering global illumination this year at Siggraph, and if this was a trend or what? Holly answered that there's a bias against incremental work in any field, and that Siggraph tends to accept papers that are new directions rather than the logical next step in a technique previously published. Ian Ashdown of Ledalite said that he had submitted something that reviewers liked except that it didn't have any pretty pictures and was therefore rejected. (No one had anything to say to console him on this.) I made the unsubstantiated claim that it can help to provide evidence of a real-life application along with an incremental improvement in one or more existing algorithms, and Holly agreed that there must be a balance between application and innovation. There is a lot of useful information by the way on next year's Siggraph in New Orleans, and even an early opportunity to suggest new ideas by October 4th. Look for the "new" icons on the web site: http://www.s95.siggraph.org/conferences/siggraph96/siggraph96.html In particular, you should be aware of the new electronic abstract requirement for technical papers. 7. Oracle-assisted rendering Another trend that people discussed (me for one) was the use of oracles to decide when and where to apply which alogrithms (a.k.a. "hacks") to improve the speed and quality of renderings. Some information may be derived from the scene itself, but other assistance will always require the user to help the program to guide the calculation. This is not as bad as it sounds, since users are after all necessary to rendering, so they may as well guide it. I directed people to my EGRW '95 paper on the subject, which I can make available online if people are interested. Although I don't plan to pursue this too much myself, I think it continues to be an interesting and promising direction for investigation. 8. Rendering code available Philipp Slusallek of Erlangen Univ. mentioned to the group that they have a renderer that extends Renderman input to include global illumination calculations (physically-based) and that code is available from him. His address is if you're interested. (He's going to hate me when he gets back.) Remember also about the Blue Moon Ray Tracer, written by Larry Gritz and available at: http://www.seas.gwu.edu/student/gritz/bmrt.html It also does some global illumination calculations, though I'm not in a position to compare the two. As long as I'm plugging other people's code, must mention my own for those of you who have been asleep or locked up for some time: http://radsite.lbl.gov/radiance/HOME.html Well, that's about it I guess. Anyone else who was there and remembers stuff I forgot or points I left out, please pipe in. I tend to do a really bad job at these sorts of summaries, and I neglected to take notes during the meeting, so I'm relying here on my less-than-adequate memory. -Greg From spencer@cgrg.ohio-state.edu Thu Aug 10 15:42:04 1995 From: Stephen Noel Spencer Subject: Re: Siggraph meeting To: greg@theo.lbl.gov (Greg Ward) Date: Thu, 10 Aug 1995 18:42:10 -0400 (EDT) Status: R Just a note -- the URL Greg gave in his message, while currently valid, won't be after the technical conference. The SIGGRAPH 96 Call for Participation is and will continue to be available at: http://www.siggraph.org/ which is the "real" SIGGRAPH information-serving computer. "www.s95" is a local (to LA) mirror of it established solely for the conference. Stephen Spencer From globillum-request@imag.fr Tue Aug 15 20:05:18 1995 To: globillum@imag.fr From: iashdown@ledalite.com (Ian Ashdown) Subject: Radiosity bibliography updated Date: Tue, 15 Aug 1995 19:40:26 +0100 Status: R The latest release (August 15th) of my radiosity bibliography is now available as /pub/doc/RadBib95.Z from hobbes.lbl.gov. Since the last release (April 2nd), I managed to find another 99 papers and theses on radiosity and global illumination, bringing the total number of references to 745. You folks have been very busy this year! If I happened to miss anything or made any errors, *please* send me e-mail with the details. (I strongly suspect that I am missing numerous European references, particularly theses.) ... and as always, my thanks to Greg Ward at Lawrence Berkeley Laboratory for providing the disk space and the decidedly animated handshake. Ian Ashdown, P. Eng. READ THE BOOK! Research & Development Manager Radiosity: A Programmer's Perspective Ledalite Architectural Products Inc. by Ian Ashdown 9087A - 198th Street John Wiley & Sons, 1994 Langley, British Columbia Canada V3A 4P8 (Sneaky Internet Advertising) From globillum-request@imag.fr Tue Aug 15 21:11:13 1995 From: wexler@pdi.com (Dan Wexler) Subject: Cinematography references To: globillum@imag.fr Date: Tue, 15 Aug 1995 20:46:41 -0700 (PDT) Status: RO Last week at SigGraph I mentioned that the Cinematography literature is replete with information concerning real-time global illumination. Here are a couple of my favorite references: American Cinematographer Manual Published by the American Society of Cinematographers (ASC), this is the Foley, vanDam (F&H) of all cameramen and lighting experts. Complete descriptions of all types of cameras, lights, lenses, filters and supports are given along with comparason tables. Techniques for special visual effects (background plates, compositing, miniatures, travelling mattes, optical printers), and special techniques (arial, underwater, arctic, tropical, day for night, stereo 3D, sound, television) are briefly discusses. There's even a section on Computer Graphics. This is a small book that can be found in many good book stores and sells for about $70. ISBN 0-935578-11-0 Millerson, Gerald; "Lighting for Television and Film"; 3rd Ed.; Focal Press; This is a very good introduction on how to light for film and video. Excellent discussions of the aesthetic qualities of light and perception. The basic principals of lighting (key, fill, shadows, balance, direction, continuity) are summarized. Detailed chapters on lighting people, the production process, atmospheric lighting, light sources and equipment, color temperature, picture control, scenery, and visual effects. A great book to learn how to light a scene to achieve a specific mood. First published in '72, third edition revised in '91. ISBN 0-240-51299-5 Malkiewicz, Kris; "Cinematography"; Simon & Schuster; '73 & '89 A shorter, but thorough treatment of the basic techniques. Chapters include Cameras, Films and Sensitometry, Filters and Light, Picture Quality Control, Sound Recording, Cutting and Lab Work, The Basics of Optical Printing, Vehicle and Underwater Cinematography, Production, and Video Transfer. ISBN 0-671-76220-6 Other excellent texts include: Lowell, Ross; "Matters of Light & Depth"; Broad Street Books; '92 ISBN 1-879174-03-0 Brown, Braun & Grondin; "Lighting Secrets for the Professional Photographer"; Writers Digest Books; '90; ISBN 0-89879-412-9 Hart, John; "Lighting for Action"; AMPHOTO; '92; ISBN 0-8174-4225-1 These contain other references, and I will happily send you more if you send me mail. I think I might like the third one because the author makes special mention of Haskell Wexler, who is, of course, not related to me in any way I know of. I am indebted to Jean Cunningham, one of our local lighting experts for most of these references. I cannot emphasize enough how much there is to learn from this body of knowledge. Good lighting with a bad renderer always looks better than bad lighting with a good renderer, IMHO. Daniel Wexler R&D Staff, Pacific Data Images From globillum-request@imag.fr Thu Aug 17 12:37:47 1995 To: globillum@imag.fr From: iashdown@ledalite.com (Ian Ashdown) Subject: Radiosity Bibliography ... OOPS! Date: Thu, 17 Aug 1995 12:15:40 +0100 Status: R The updated radiosity bibliography that was announced on Tuesday had a few problems (such as being truncated to half of its original length). This problem has now been fixed. The revised bibliography is available as /pub/doc/RadBib95.Z from hobbes.lbl.gov. Philipp Slusallek also noted that there are some problems in translating the bibliography from refer to Bibtext, due in part to data entry errors. These will be resolved (I hope) over the next few weeks. Ian Ashdown, P. Eng. READ THE BOOK! Research & Development Manager Radiosity: A Programmer's Perspective Ledalite Architectural Products Inc. by Ian Ashdown 9087A - 198th Street New York, NY: John Wiley & Sons, 1994 Langley, British Columbia Canada V3A 4P8 (Sneaky Internet Advertising) From globillum-request@imag.fr Fri Sep 8 12:59:19 1995 Date: Fri, 8 Sep 1995 12:15:24 -0800 From: "Adam G. Freeman" To: globillum@imag.fr Subject: code Status: R Hello, I'm looking for any pointers to hierarchical, importance-driven and/or discontinuity meshing radiosity code. Thanks, Adam Freeman /| / | / | /| _______________/ |__ / | __/ ------------ | / {@} | /.. | . VVvvvvvvv\ )) | ___///_ / | ___ | o< /o \// AAA^^^^^^/ ___-------- \ | o< )____ __/\\ \_____________\ \------- \| o< \\ \ \__\ From globillum-request@imag.fr Fri Sep 15 11:06:15 1995 From: Francois Sillion Subject: WWW home page for globillum To: globillum@imag.fr (Global Illumination List) Date: Fri, 15 Sep 1995 17:48:41 +0200 (MDT) Reply-To: Francois.Sillion@imag.fr Status: R Please note the change of http address for the globillum list's home page: the new address is http://safran.imag.fr/Membres/Francois.Sillion/GlobillumList.html The reason for the change is that there is now a 'public' page for access to the world, with the old name (since it had been diffused through graphics-related archives already). The difference between the two is mainly access to the main mail alias and discussion archives. The new setup should prevent glitches such as uninformed people sending requests to the entire list.. +------------------+------------------------------------------------------+ | Francois SILLION | iMAGIS/IMAG, B.P. 53, 38041 Grenoble Cedex 9. France | | ' | Tel: (+33) 76 51 43 54 -- Fax: (+33) 76 44 66 75 | +------------------+----------+-------------------------------------------+ | Francois.Sillion@imag.fr | http://safran.imag.fr/~Francois.Sillion | +-----------------------------+-------------------------------------------+ From owner-globillum@imag.fr Sat Sep 30 18:33:42 1995 Return-Path: To: globillum@imag.fr Subject: Springer books Date: Sat, 30 Sep 95 18:13:59 -0700 From: Eric Stollnitz X-Mts: smtp Status: RO Does anybody out there have a copy of the Springer-Verlag book "Photorealistic Rendering Techniques" (in which some of the papers from the Fifth Eurographics Workshop on Rendering appeared)? I'd like to find out whether or not some papers I'm referring to appeared in the book, and get their page numbers... Please send me e-mail if you have the book! --Eric ----------------------------------------------------------------------------- Eric Stollnitz | Department of Applied Mathematics | University of Washington stoll@amath.washington.edu | Box 352420 http://www.amath.washington.edu/~stoll/ | Seattle, WA 98195-2420 ----------------------------------------------------------------------------- From owner-globillum@imag.fr Mon Oct 16 07:55:34 1995 Return-Path: From: Sylvain Petitjean Date: Mon, 16 Oct 1995 10:24:25 +0100 To: globillum@imag.fr Subject: reference Status: R Dear Globillumers, I have been looking for the following reference (taken from the radiosity bib of Ian Ashdown) for some time but to no avail. Can anyone help locate it? %A F. Bresciani %A P. P. Rinaldi %A F. Tapparo %T Applications and Comparisons of Different Mathematical Methods to Compute Form Factors for Radiosity Images %B Workstations for Experiments %I Springer-Verlag %C Berlin, Germany %D 1989 %K form factors Thanks in advance, - Sylvain From owner-globillum@imag.fr Fri Oct 20 11:42:04 1995 Return-Path: From: Philippe Bekaert Subject: initial release of our radiosity code available To: globillum@imag.fr Date: Fri, 20 Oct 1995 18:03:27 +0100 (MET) Cc: Philippe.Bekaert@cs.kuleuven.ac.be (Philippe Bekaert) Status: R Dear Globillumers, I'd like to announce the initial release of the radiosity code developed in our research group (see http://www.cs.kuleuven.ac.be/cwis/research/graphics/graphics-E.shtml). Features: --------- - It does both shooting (progressive refinement radiosity) and gathering. - Hierarchical refinement if you like (for both shooting or gathering) - Importance-driven if you like (for both shooting or gathering) - Formfactor computation by numerical integration. The ray-casting for visibility determination is accelerated by using hierarchical bounding boxes, shadow caching and shaftculling. - handles both triangles and (convex) quadrilaterals. - T-vertex elimination and many other rendering options. - reads Greg Wards MGF scene description files (see http://radsite.lbl.gov/mgf/HOME.html) - a more or less nice user interface and interactive view manipulation. - ... It requires - Motif, - Silicon Graphics' Iris GL (or a clone) or PEX - an ANSI-C compiler (gcc 2.7.0 was used to develop it) and GNU make (or another make which offers the .include feature, unless you change the Makefiles a bit) to compile it. You can obtain this code for free on URL: http://www.cs.kuleuven.ac.be/~philippe/rad.html +----------------------------------+------------------------------------------+ | Philippe Bekaert | Pracu koname presne, rychlo a dobre, ale | | Computer Graphics Research Group | potrebujeme nove stroje (We do the work | | Department of Computer Science | precisely, quick and well, but we need | | K. U. Leuven - Leuven (Belgium) | new machines) - J. Mistrik, Basic Slovak | +----------------------------------+------------------------------------------+ Philippe.Bekaert@cs.kuleuven.ac.be From owner-globillum@imag.fr Thu Nov 2 11:09:34 1995 Return-Path: From: cn1@irz301.inf.tu-dresden.de (Nguyen, D.C.(JuHu)) Subject: [Q] approximation for NFF-materials ? To: globillum@imag.fr Date: Thu, 2 Nov 1995 18:24:04 +0200 (MESZ) Status: R Hi, Im writing a .3DS -> .NFF converter for GX/GENERIC and got a problem w/ the NFF-coefficients for materials : A correct conversion of material coefficients from .3DS -> NFF is not possible, because the diffuse and specular component of object-material in NFF are *uniformly* scaled to Red,Green,Blue. e.g.: ## in 3DS: MatProperies { RGB Ambient; RGB Diffuse; RGB Specular; ... } ## in NFF: MatProperties { RGB Color; float kDiffuse; float kSpecular; ... } Thus, for NFF, Ambient = 0 , Diffuse = Color * kDiffuse, Specular = Color * kSpecular My question is: which approximation should be used to convert the 3 vectors Ambient, Diffuse and Specular in 3DS to the 1 vector Color and the 2 coefficients kDiffuse and kSpecular in NFF ???? Thanks in advance, JuHu -- /\__ Nguyen Duc Cuong (aka JuHu) - CG-student \ "This theory is based /__\ \ EMail : cn1@irz.inf.tu-dresden.de \ on arithmetic overflow!" \__/ WWW : http://www.inf.tu-dresden.de/~cn1/ \ [..VIDEA'95 story..] From greg Thu Nov 2 11:45:04 1995 Return-Path: Date: Thu, 2 Nov 95 11:44:46 PST From: greg (Gregory J. Ward) To: globillum@imag.fr Subject: Re: [Q] approximation for NFF-materials ? Status: R Hello Everyone, I forgot to cc this to the rest of the group, so JuHu doesn't get a million similar answers. (If you have a different answer, by all means...) ------------ Hi JuHu, The common approximation used converts color to scaled luminance, and is: grey = 0.3*red + 0.59*green + 0.11*blue This is based on a sort of generic definition of RGB, since there is no accepted standard for it. -Greg ------------ By the way, it seems like an appropriate time to make another plug for the Materials and Geometry Format, which I developed with a little help from my friends for representing and sharing physically-based scene descriptions for Monte Carlo rendering, radiosity and similar abuses. The web site is: http://radsite.lbl.gov/mgf/HOME.html While you are there, be sure to check out the conference room model done by Holly Rushmeier and others at NIST, who also took photometric images of the actual space for the ultimate comparison. We also have many cool and useful scenes and objects, culled from the Radiance distribution and even a few hand-built examples, including a complete office space with ugly Dilbert-style cubicle workstations. Parsing MGF is easy, thanks to the generic ANSI-C parser included, with more documentation than you can shake a stick at. All here, all now, all free. (Now, you just need some free time to go with it.) -Greg From cn1@irz.inf.tu-dresden.de Thu Nov 2 13:01:34 1995 Return-Path: From: cn1@irz.inf.tu-dresden.de (Nguyen, D.C.(JuHu)) Subject: Re: [Q] approximation for NFF-materials ? To: greg@hobbes.lbl.gov (Gregory J. Ward) Date: Thu, 2 Nov 1995 23:00:51 +0200 (MESZ) Cc: globillum@imag.fr Status: R > > Hello Everyone, > > I forgot to cc this to the rest of the group, so JuHu doesn't get a million > similar answers. (If you have a different answer, by all means...) > > ------------ > Hi JuHu, > > The common approximation used converts color to scaled luminance, and is: > > grey = 0.3*red + 0.59*green + 0.11*blue > > This is based on a sort of generic definition of RGB, since there is no > accepted standard for it. > > -Greg > ------------ Cool! I never hear about this mind-opened formular. Thanx! As far as i undertand, this formula can be used to get kDiffuse and kSpecular. But how to do i get Color ? Eric's idea is : > >My educated guess would be use the Diffuse color in 3DS, set kD to 1.0, and >also set kS to be something like > max_component(Specular) / max_component(Diffuse) >(avoiding division by 0). > I have tested his idea and got better results than my first approximation. -JuHu From owner-globillum@imag.fr Thu Nov 2 18:26:18 1995 Return-Path: To: globillum@imag.fr From: iashdown@ledalite.com (Ian Ashdown) Subject: Re: [Q] approximation for NFF-materials ? Date: Thu, 2 Nov 1995 17:37:18 -0000 Status: R Greg Ward wrote earlier today: > >The common approximation used converts color to scaled luminance, and is: > > grey = 0.3*red + 0.59*green + 0.11*blue > >This is based on a sort of generic definition of RGB, since there is no >accepted standard for it. > Oops! Sorry to disagree here, Greg, but this approximation is out of date. I made this same boo-boo in my book, and got firmly (and rightfully) slapped for it by someone from the University of Manchester. It happens to be that the < 0.30, 0.59, 0.11 > coefficients were established in the early days of NTSC color television. As noted by Charles Poynton in his excellent color FAQ (http://www.inforamp.net/~poynton): The coefficients 0.299, 0.587 and 0.114 properly computed luminance for monitors having phosphors that were contemporary at the introduction of NTSC television in 1953. They are still appropriate for computing video *luma* to be discussed below in Section 11 [i.e., Poynton's FAQ]. However, these coefficients do not accurately compute luminance for contemporary monitors. Backing up a few paragraphs: Contemporary CRT phosphors are standardardized in ITU-R Recommendation BT.709, "Basic Parameter Values for the HDTV Standard for the Studio and for the International Programme Exchange (1990) [formerly CCIR Rec. 709], to be described in Section 17 (ibid). The weights to compute true CIE luminance from *linear* red, green and blue (indicated without prime symbols), for the Rec. 709, are these: y709 = 0.2125 R + 0.7154 G + 0.0721 B So, there you have it. These coefficients are roughly the same as the old NTSC coefficients. However, the differences are quite evident in the resultant gray-scale images, particularly for saturated colors. Ian Ashdown, P. Eng. | READ THE BOOK! Research & Development Manager | Radiosity: A Programmer's Perspective Ledalite Architectural Products Inc. | by Ian Ashdown | John Wiley & Sons, 1994 | Visit http://www.ledalite.com | (Sneaky Internet Advertising) From greg Thu Nov 2 20:51:55 1995 Return-Path: Date: Thu, 2 Nov 95 20:51:39 PST From: greg (Gregory J. Ward) To: iashdown@ledalite.com Subject: Re: [Q] approximation for NFF-materials ? Status: R Thanks for the correction. Actually, I never use the coefficients I quoted myself, but I didn't have any authority on anything else. The fact remains that there is no accepted standard for RGB color space. The values I use myself come from some averaging of computer monitor primaries undertaken by Gary Meyer, and are: grey = .265*red + .670*green + .065*blue Are HDTV primaries the same as typical computer monitors? Anyway, it's all moot if you ask me, and could form the basis of an endless argument. I still need to sign myself up for IES membership, so I can vote in the February meeting.... -G From musgrave@seas.gwu.edu Wed Nov 8 05:30:03 1995 Return-Path: Date: Wed, 8 Nov 1995 08:29:44 -0500 From: Ken Musgrave To: greg@hobbes.lbl.gov Subject: Re: [Q] approximation for NFF-materials ? Status: RO |The common approximation used converts color to scaled luminance, and is: | | grey = 0.3*red + 0.59*green + 0.11*blue Greg: How much confidence do you have in this formulation? I find that, when used for antialiasing as in Rayshade, "it bites." Ken the Cranky From greg Wed Nov 8 10:02:53 1995 Return-Path: Date: Wed, 8 Nov 95 10:02:32 PST From: greg (Gregory J. Ward) To: musgrave@seas.gwu.edu Subject: Re: [Q] approximation for NFF-materials ? Status: R As I told Ian, I don't use this formula myself. I just parroted it because it's the only one I've seen repeatedly and I didn't want to go sticking my neck out with a different set of RGB primaries. The ones I use were from an average set of measurements done by Gary Meyer, a generally reliable source. The resulting coefficients are: grey = 0.265*red + 0.670*green + 0.065*blue This isn't exactly what Ian recommended, but it's close. I don't know about anti-aliasing applications for it -- what do you mean, exactly? -G From owner-globillum@imag.fr Wed Nov 8 13:09:48 1995 Return-Path: From: cn1@irz301.inf.tu-dresden.de (Nguyen, D.C.(JuHu)) Subject: GENERIC To: globillum@imag.fr (Global Illumination List) Date: Wed, 8 Nov 1995 19:36:37 +0200 (MESZ) Status: R Hi, This message was posted to comp.graphics.algorithm, but i'm sure that not all persons on this list have time to read NEWS :). If you are interrested in OO-graphics, then this's the right one for you. -JuHu -- /\__ Nguyen Duc Cuong (aka JuHu) - CG-student \ "This theory is based /__\ \ EMail : cn1@irz.inf.tu-dresden.de \ on arithmetic overflow!" \__/ WWW : http://www.inf.tu-dresden.de/~cn1/ \ [..VIDEA'95 story..] ======================================================================= [ANNOUNCE] A Generic 3D Graphics Kernel V1.3 Current graphic systems (traditional or object-oriented) offer a certain amount of functionality but also prescribe a lot of impli- cations, constraints and may not fit a given task. The result is that in many cases people start from scratch, implement the basic graphics stuff again and again. The objective of the announced project is to develop a generic 3D graphics kernel that may be used to implement an own system by derivating the generic one. By aggregation and inheritance the interfaces and implementation of the generic kernel may be used. The generic kernel shall offer a huge functionality consisting of uncoupled classes that may adaptively be integrated into a specialized system without any run-time and memory overhead. The principal functionality of the system will be [is]: - basic parametric aggregates and related operators [parametric fix-sized vector, dl list, dynamic list, for-each iterators] - elementary graphical data types: vector (2D, 3D, generic), matrices, colors, vertex, etc. and related operators [2D, 3D, nD Vector, 4x4, nxn Matrix, "Phong" Surface, RGB color, different vertex types] - essential scene collections (DAG, tree, binary tree, linear list) [based on above-mentioned aggregates] - basic graphical design patterns such as PHIGS' CSS, or a CGRM environment with its components - basic topological classes w/ covariant extensibility [1D-, 2D-, Polyhedron topology, parametric curve and surface] - abstract and concrete rendering classes (rendering interfaces, camera models, specific rendering primitives, i.e., Quadric for ray-tracing) [ray-tracing and shading interface, perspectivic and orthographic camera model, shader, ray-tracer, quadric, polygon, shading and ray-tracing iterators to be used for cameras and composites, to be platform-independent, the specific shading stuff is encapsulated in a "device driver" with following realizations until now: * OpenGL and X11 * OpenGL and Tk 3.6/4.0 * OpenGL and Windows/NT * OpenGL and Windows/NT and Tk3.6 * OpenGL and Windows/NT and MFC 2.0 NOTE: OpenGL compatible public domain library Mesa has been tested successfully as replacement for OpenGL] - pixel-based output devices [Pixmap, ImageFile] - rendering-independent mathematical stuff, e.g., Splines and free form surfaces [solid textures, bump mappings, interpolated spline curves and surfaces] - basic interaction classes (abstract and concrete, e.g., low-level event types) [2D mouse and spaceball events, socket encapsulation, pixmap update event, callbacks, abstract input device featuring feedback access and hierarchical organization, input server, timer and file input devices] - utility classes (identification, file formats, user interface integration) [string, SGI-, Targa-, RGBA-file format, Tcl language binding (optional), interpretative class system, generic DeltaBlue constraint solver] For papers discussing the need for a generic graphics kernel see ftp://metallica.prakinf.tu-ilmenau.de/pub/PROJECTS/GENERIC/dublin.ps.gz ftp://metallica.prakinf.tu-ilmenau.de/pub/PROJECTS/GENERIC/springer95.ps.gz The generic kernel itself is available by ftp://metallica.prakinf.tu-ilmenau.de/pub/PROJECTS/GENERIC/generic1.3.tar.gz The generic kernel is provided with all sources and may be used for both commercial and non-commercial projects without restrictions. Comments, discussion and extensions are greatly welcome. Derived kernels until now: GX - an extended ray-tracing kernel by Nguyen Duc Cuong GT - an NFF compatible ray-tracing kernel for test purposes basing on GX (GX and GT are parts of the distribution) EGR GF - an object-oriented commercial semantic kernel for European furniture industry (headers included for demonstration purposes) EGR MAF - a distributed Multimedia application framework EGR TIGER - an interpretative OpenGL environment including Motif-like GUI functionality and hi-level OpenGL-based kernel for education Kernels in work: GY - reimplementation of former 3D graphics kernel YART GP - sample implementation of ISO PREMO There is a mailing List: generic@prakinf.tu-ilmenau.de [send mail with subject "subscribe GENERIC mailing list" to ekki@prakinf.tu-ilmenau.de ] Ekki. Special thx goes to Frank Wicht (TU Ilmenau, Germany), Nguyen Duc Cuong (TU Dresden, Germany), Heiko Fischer (EasternGraphics, Ger- many), Pavol Michalik (TU Ilmenau, Germany) and EasternGraphics GmbH, Arnstadt, Germany. **************************************************************** * Ekkehard 'Ekki' Beier * * email: ekki@prakinf.tu-ilmenau.de * * phone: ++49-3677-692775 fax: ++49-3677-694540 * * talk : ekki@metallica.prakinf.tu-ilmenau.de [141.24.11.247] * * www : http://metallica.prakinf.tu-ilmenau.de/ekki.html * * yart/vr: institute@speedy.prakinf.tu-ilmenau.de * * Technical University of Ilmenau * * Department of Computer Graphics * * Am Ehrenberg, PSF 327, D-98684 Ilmenau, GERMANY * **************************************************************** From owner-globillum@imag.imag.fr Mon Nov 13 14:56:36 1995 Return-Path: From: "Holly E Rushmeier" Date: Mon, 13 Nov 1995 15:55:28 -0500 Reply-To: holly.rushmeier@nist.gov To: iashdown@ledalite.com (Ian Ashdown), globillum@imag.fr Subject: Re: Radiosity Bibliography, Take Six Status: R Hi everyone - I did look up the cow paper once, and it is for real. The motivation was designing heating systems for the care of livestock. Here is a summary: "Uses mechanical integrator to measure factors from various wall elements to a cow, and presents some results for size of equivalent sphere that gives same factor as cow. It is found that the sphere origin should be place at one-fourth of the withers-to-pin-bone length back of the withers, at a height above the floor of two-thirds the height of the withers, and the equivalent sphere radius should be 1.8, 2.08 or 1.78 times the heart girth for exchange with the floor and ceiling, sidewalls, or front and back walls respectively. Also discusses exchange between cows and entire bounding walls, floor and ceiling and between parallel cows." I don't think I kept a copy of the paper, so please don't ask me for it. As I recall, the authors were from California, and the paper was initially read at an agricultural meeting held at Cornell. I looked it up in the library at Ga. Tech., but I expect it could be found at other places, such as Cornell (in Mann library if Carpenter doesn't have it) which has a degree program in Agricultural Engineering. Pastorally, Holly On Nov 13, 10:35am, Ian Ashdown wrote: > > Incidentally, has anyone seen this paper? > > %A R. L. Perry > %A E. P. Speck > %T Geometric Factors for Thermal Radiation Exchange between Cows and > their Surroundings > %R Technical Report 59-323 > %I Journal of the American Society of Agricultural Engineering > %D 1959 > %K form factors > %Z a seminal paper in computing cow form factors > > Moo! > Ian Ashdown, P. Eng. | READ THE BOOK! > Research & Development Manager | Radiosity: A Programmer's Perspective > Ledalite Architectural Products Inc. | by Ian Ashdown > | John Wiley & Sons, 1994 > | > Visit http://www.ledalite.com | (Sneaky Internet Advertising) > >-- End of excerpt from Ian Ashdown From owner-globillum@imag.imag.fr Fri Nov 17 15:35:07 1995 Return-Path: From: cn1@irz301.inf.tu-dresden.de (Nguyen, D.C.(JuHu)) Subject: [Q] How to construct a 5D-hyper-octree ? To: globillum@imag.fr (Global Illumination List) Date: Fri, 17 Nov 1995 20:23:49 +0200 (MESZ) Status: R Hi, I am going to implement the "ray-classification" methode in GX for completeness (GX does BSP and ABVH, but not any of the 3 directional techniques: light-buffer, ray-coherence and ray-classification). I have some questions about the construction of the 5D-hyper-octree : 1. Should i map the enviroment (the box, which contains finite objects and the eye) to the unit-cube ? If yes, which methode is the best way to do it ? 2. How do i construct a beam ? As J.Arvo and D.Kirk suggested, one can use cone-beams and bounding spheres for speedup, but i'm confused about the construction of a cone-beam from a 3D-voxel and a 2D-UV-cell. Is this the cone w/ 2 end-points at the centers of 2 bounding-spheres of the voxel and the UV-cell ? 3. I think, the BSP-Tree could be precomputed, and only the 6 2D-faces must be subdivide on the fly. This is faster for animations w/ static scene and a flying-camera. Spatial subdivision is less view-dependent than directional-subdivision, is'n it ? Thanks for any help. JuHu -- /\__ Nguyen Duc Cuong (aka JuHu) - CG-student \ "This theory is based /__\ \ EMail : cn1@irz.inf.tu-dresden.de \ on arithmetic overflow!" \__/ WWW : http://www.inf.tu-dresden.de/~cn1/ \ [..VIDEA'95 story..] From owner-globillum@imag.imag.fr Tue Nov 21 12:37:59 1995 Return-Path: From: Peter Shirley Subject: graphics pages To: globillum@imag.fr Date: Tue, 21 Nov 95 13:48:32 EST Mailer: Elm [revision: 70.85] Status: RO I am updating my list of graphics pages at: http://www.graphics.cornell.edu/~shirley/graphics.html If you know of any I should add, please let me know. Also, if you have online Monte Carlo code or papers, please let me know and I will add you to: http://www.graphics.cornell.edu/~shirley/mc.html Thanks Pete Shirley shirley@graphics.cornell.edu From owner-globillum@imag.imag.fr Tue Dec 5 11:13:35 1995 Return-Path: To: globillum@imag.fr Subject: participating media Cc: blacksha@cs.bris.ac.uk Date: Tue, 5 Dec 95 14:59:16 GMT From: blacksha@cs.bris.ac.uk Sender: blacksha@cs.bris.ac.uk Status: R Dear all, I am a final year student investigating the visualisation of participating media using the particle tracing method. I would be most grateful if anyone could point me in the right direction as to where i might find a description of the properties, and how they might be modelled, of media such as fog & rain, smoke and dust. many thanks, Julian Blackshaw. Email: blacksha@compsci.bristol.ac.uk From owner-globillum@imag.imag.fr Tue Dec 5 12:49:09 1995 Return-Path: From: cn1@irz301.inf.tu-dresden.de (Nguyen, D.C.) Subject: GX/GENERIC page To: globillum@imag.fr (Global Illumination List) Date: Tue, 5 Dec 1995 21:38:51 +0200 (MESZ) Status: R Hi, I've uploaded the GX/GENERIC WWW-page w/ some demos picts and performance-reports. The URLs are: http://www.inf.tu-dresden.de/~cn1/gx.html or http://www.rz.tu-ilmenau.de/~juhu/gx.html -JuHu /\__ Nguyen Duc Cuong (aka JuHu) - CG-student \ "Computers in the future may /__\ \ EMail : cn1@irz.inf.tu-dresden.de \ weigh no more than 1.5 tons" \__/ WWW : http://www.inf.tu-dresden.de/~cn1/ \[ Popular Mechanics 1949 ] From owner-globillum@imag.imag.fr Tue Dec 12 11:03:01 1995 Return-Path: From: Vinnie Codd Subject: RE:Radiosity To: globillum@imag.fr Date: Tue, 12 Dec 1995 12:35:14 +0000 (GMT) Status: R Hello there, I wonder could anyone give me information on Radiosity. I would like information on where to get code to implement the radiosity algorithm eg ftp sites.My project entails solving the radiosity equation for a cubical room with a light source at the centre of the roof and a cube at the centre of the floor.I am using ray-tracing for form factor evaluation and for the final viewing phase.I am using progresive refinement to solve the equation itself.I wonder could anyone give me some information as to where to find code or anything else helpfull for this problem. Vincent Codd(vtcodd@alf2.tcd.ie) From greg Tue Dec 12 11:13:29 1995 Return-Path: Date: Tue, 12 Dec 95 11:12:59 PST From: greg (Gregory J. Ward) To: globillum@imag.fr, vtcodd@tcd.ie Subject: RE:Radiosity Status: R Sounds like you want Ian Ashdown's book: Ashdown, I. 1994. Radiosity: A Programmer's Perspective. New York, NY: John Wiley & Sons, Inc. Softcover, 498 pages, 12 color plates. ISBN 0-471-30444-1 (without diskette) $44.95 US ISBN 0-471-30488-3 (with 3.5-inch MS-DOS diskette) $59.95 US A demo version of his radiosity implementation, called HELIOS, is available from the Ledalite web site: http://www.ledalite.com/ He has also written a nice IES luminaire file parser, which I recommend to anyone who is serious about realistic rendering, available from the same site. If you want some good, physically-based models and solutions to compare to, also check out the following site, which I manage: http://radsite.lbl.gov/mgf/HOME.html Good luck! -Greg From owner-globillum@imag.imag.fr Tue Dec 12 11:14:46 1995 Return-Path: Date: Tue, 12 Dec 1995 15:48:08 +0100 (MET) From: Siegfried Wiesenhofer To: globillum@imag.fr Subject: nomenclature recommendation ? Status: R hi, i' m currently working on my diploma thesis on "numerical simulation of radiation heat transfer". having finished the implementation part i recently started committing the work to paper. now my question: which nomenclature should i use ? heat transfer or global illumination (proposed standard, or ANSI/IES RP-16-1986) ? i am torn between using nomenclature from siegel's & howell's book "thermal radiation heat transfer" (which i think is a standard work on radiative heat transfer), global illumination literature, and the proposed standard for global illumination. any recommendations ? many thanx in advance, siegi <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< v siegfried wiesenhofer ^ v graz university of technology / austria - europe ^ v keywords: siegi, radiosity, jazz, funk, paragliding... ^ v email: sw@sbox.tu-graz.ac.at ^ >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> From greg Tue Dec 12 11:24:12 1995 Return-Path: Date: Tue, 12 Dec 95 11:23:43 PST From: greg (Gregory J. Ward) To: globillum@imag.fr, sw@sbox.tu-graz.ac.at Subject: Re: nomenclature recommendation ? Status: R I recommend that you pick up the following files by Holly Rushmeier from the anonymous ftp account on tiber.nist.gov: pub/holly/symb.tex - LaTeX document pub/holly/symb.ps - printable PostScript of above This summarizes recommended notation from ANSI/IES RP-16-1986, which is the preferred standard for global illumination. Even if you are working within the field of radiative heat transfer, this is a more consistent notation for a broader audience. (Someone, correct me if I'm mistaken.) -Greg P.S. A group of us are still hoping to come up with some standard terminology and put it on the globillum web page, but we're a bit slow. From owner-globillum@imag.imag.fr Fri Dec 15 04:12:06 1995 Return-Path: Date: Fri, 15 Dec 1995 14:43:38 GMT From: sidhu@serc.serc.iisc.ernet.in (Reetinder Singh Sidhu) To: globillum@imag.fr Subject: Analytical Form Factors Status: R Would anyone know the analytic form factor from a differential area to a triangle? I need the formulae for the two cases when the diff. area and the triangle are (1) parallel (2) perpendicular. My aplogies for bothering about such a trivial matter but time is too short for me to work it out and verify it. Reetinder Sidhu From owner-globillum@imag.fr Thu Jan 4 11:10:27 1996 Return-Path: To: globillum@imag.fr From: iashdown@ledalite.com (Ian Ashdown) Subject: Radiosity & Color Quantization bibliographies Date: Thu, 4 Jan 1996 06:27:56 -0000 Status: R Revised and new bibliography releases for: * radiosity and global illumination * color quantization algorithms * edge-based (e.g., winged-edge) boundary representations 1. RADBIB96.TXT This is a comprehensive bibliography of radiosity and related global illumination papers, theses, articles, and books. A total of 49 new references have been added since its last release as RADBIB95.TXT on November 11, 1995, bringing the total to 832 references. Available as RADBIB96.ZIP or RADBIB96.TXT.Z from http://www.ledalite.com/library/rrt.html (courtesy of Ledalite Architectural Products Inc.) Also available as /pub/doc/RadBib96.Z from hobbes.lbl.gov (courtesy of Greg Ward and Lawrence Berkeley Laboratory). This bibliography is in refer format. However, some anonymous but kind soul converted the previous release to bib format, which is available as: ftp.cs.columbia.edu/archives/bibliographies/Graphics/rad.html A refer-format file containing only the new references for RADBIB96.TXT is also available. Send your e-mail request to iashdown@ledalite.com. 2. CQUANT96.TXT This is a comprehensive bibliography of color quantization algorithms. A total of 6 new references have been added since its last release as CQUANT95.TXT on November 11, 1995, bringing the total to 91 references. Available as CQUANT96.ZIP or CQUANT96.TXT.Z from http://www.ledalite.com/library/cgis.html (courtesy of Ledalite Architectural Products Inc.) Also available as /pub/doc/cquant96.Z from hobbes.lbl.gov (courtesy of Greg Ward and Lawrence Berkeley Laboratory). 3. B-REP96.TXT This is a bibliography of edge-based boundary representation papers, theses, articles, and books, and includes 39 references. If you are having trouble locating information on Baumgart's winged-edge data structure for radiosity-based rendering and other finite element method applications, start here. Available as B-REP96.ZIP or B-REP96.TXT.Z from http://www.ledalite.com/library/cgis.html (courtesy of Ledalite Architectural Products Inc.) Also available as /pub/doc/brep96.Z from hobbes.lbl.gov (courtesy of Greg Ward and Lawrence Berkeley Laboratory). My thanks to all of you who have made your conference proceedings, publication lists, and especially papers available online through your Web pages. It has made my self-appointed task of tracking down your contributions to the global illumination literature much easier. Ian Ashdown, P. Eng. | READ THE BOOK! Research & Development Manager | Radiosity: A Programmer's Perspective Ledalite Architectural Products Inc. | by Ian Ashdown | John Wiley & Sons, 1994 Visit http://www.ledalite.com | (Sneaky Internet Advertising) From owner-globillum@imag.fr Wed Feb 7 16:44:37 1996 Return-Path: Date: Mon, 08 Jan 1996 00:38:58 -0800 From: Paolo Bernardelli Organization: Poliedra To: globillum@imag.fr Subject: Materials definition for esterior lighting simulation Status: R For radiosity people ..... Im studing about illumination conditions of monuments and building in exterior and thier visual effect. For this we use Radiance and we need to define some quantity of materials like especially: >plaster >smooth marble ( like white marble called Travertino - All Rome is built with this ) >ashlar marble >wood for windows >nude reinforced concrete >pavement street Where is it possible find this informations with a physical definition ( Like BRDF materials and MGF standard )? As your gruop ingaged this problems? How measure you materials color and unknown elements of materials? Thanks for your attention. Paolo Bernarderlli From owner-globillum@imag.fr Tue Feb 13 14:25:29 1996 Return-Path: From: cn1@irz301.inf.tu-dresden.de (Nguyen, D.C.) Subject: shadow boundaries for ext. lights To: globillum@imag.fr (Global Illumination List) Date: Tue, 13 Feb 1996 22:54:14 +0200 (MESZ) Status: R Hi, Is there any general (not only polygonal) approach to compute the shadow boundaries for volume-lightsoures ? I use Monte-Carlo-technique to compute softshadows and got many problems w/ it. Even with importance sampling, the raytracer requires a lot of shadow-rays to fire to produce an acceptable image. There are too much noises, and some small occluding patches are missed. An analytical solution would be nice, but i only found papers where special solutions for polygonal objects are described. Is it possible to contruct the discontinuity mesh for all types of objects ? Thanks for any help. --JuHu /\__ Nguyen Duc Cuong (aka JuHu) - CG-student \ "Computers in the future may /__\ \ EMail : cn1@irz.inf.tu-dresden.de \ weigh no more than 1.5 tons" \__/ WWW : http://www.inf.tu-dresden.de/~cn1/ \[ Popular Mechanics 1949 ] From owner-globillum@imag.fr Sat Feb 17 11:06:16 1996 Return-Path: To: globillum@imag.fr From: iashdown@ledalite.com (Ian Ashdown) Subject: ANNOUNCE: Free Radiosity Renderer (inc. C++ source code) Date: Sat, 17 Feb 1996 10:27:55 -0800 Status: R Hi, folks. My apologies for cluttering up your mailbox, but rumour has it that some of you (or, more likely, your undergrad students) are actually using the HELIOS radiosity renderer from my book. The following is a self-serving blurb announcing that the complete (and guaranteed 100% free) C++ development package for HELIOS V1.02C is now available for downloading from our Web server. - Ian Ashdown ---------------------------------------------------------------- The C++ source code for HELIOS, a fully-functional radiosity renderer for MS-Windows 3.1, is now available for downloading on the 'net ... "Radiosity" is a computer graphics technique that enables you to synthesize photorealistic images. Whereas ray tracing techniques excel in the rendition of point light sources, specular reflections, and refraction effects, radiosity methods accurately model area light sources, diffuse reflections, color bleeding between surfaces, and detailed shading within shadows. They are in a sense complementary approaches to photorealistic rendering. Folklore had it that you needed a graphics workstation with gigabytes of RAM or even a supercomputer to do radiosity rendering. This is no longer true: You can use your personal desktop computer -- a '386 IBM-PC with a math coprocessor, 4 MB of RAM, and a 256-color SVGA display will do nicely -- to experiment with radiosity methods. A 66-MHz '486DX machine will render a simple scene (540 polygons) in less than three minutes. A more complex scene with 2,700 polygons can be rendered in a little over six minutes. Commercial radiosity renderers are slowly making their way into the marketplace. Take a look, for example, at the incomparable Lightscape Visualization system (http://www.lightscape.com) to see what is available now for Windows NT. (Other interesting sites on the Web for commercial radiosity renderers are http://www.bentley.com/products/masterpiece.html -- download the Microstation MasterPiece Technical Profile -- and the Italian http://www.atma.it/english/rlight.html.) In the meantime, you can download HELIOS to experiment with the possibilities of radiosity rendering using MS-Windows 3.1 or Windows 95. The Web site is: http://www.ledalite.com/lighthouse.html where you will find a demonstration version of HELIOS Version 1.02C (106 KB) and the complete C++ development package (806 KB), including four different executable versions of HELIOS, fully- commented C++ source code (over 12,700 lines), make files for Microsoft Visual C++ 1.5 and Borland C++ 4.5, online help files, two demonstration environments, demo images, and more. (While you are perusing our Web site, you might want to look at http://www.ledalite.com/library/ledapub.html -- we have an eclectic variety of academic papers and articles on computer graphics and related topics available online for downloading.) The HELIOS development package is *not* in the public domain. It is copyrighted material that may be freely copied, redistributed, and/or modified for personal, non-commercial use ONLY, provided the copyright notice is included with all source code files. HELIOS was first developed in: Ashdown, I. 1994. Radiosity: A Programmer's Perspective. New York, NY: John Wiley & Sons, Inc. Softcover, 498 pages, 12 color plates. ISBN 0-471-30444-1 (without diskette) $39.95 US ISBN 0-471-30488-3 (with 3.5-inch MS-DOS diskette) $54.95 US This book provides a detailed explanation of radiosity theory and its associated algorithms (no knowledge of higher mathematics required!) More important, it also includes complete, fully documented, and compiler-independent C++ source code (over 7,500 lines) for HELIOS Version 1.00A, a fully-functional radiosity- based rendering program for MS-Windows 3.1, Windows 95, and Windows NT. The radiosity-related code presented in the book is identical to that now offered online. If you want to fully understand how HELIOS (and radiosity) works, you more or less need to buy the book. You can order "Radiosity: A Programmer's Perspective" from your local bookseller or (in the United States) directly from John Wiley & Sons by calling 1-800-CALL-WILEY. You can also order the book online from http://www.wiley.com. Ian Ashdown, P. Eng. | READ THE BOOK! Research & Development Manager | Radiosity: A Programmer's Perspective Ledalite Architectural Products Inc. | by Ian Ashdown | John Wiley & Sons, 1994 Visit http://www.ledalite.com | (Sneaky Internet Advertising) From owner-globillum@imag.fr Sat Feb 17 19:23:46 1996 Return-Path: To: globillum@imag.fr From: iashdown@ledalite.com (Ian Ashdown) Subject: ANNOUNCE corrigendum Date: Sat, 17 Feb 1996 19:06:38 -0800 Status: R Corrigendum to earlier message: >In the meantime, you can download HELIOS to experiment with the >possibilities of radiosity rendering using MS-Windows 3.1 or >Windows 95. The Web site is: > > http://www.ledalite.com/lighthouse.html > Oops ... make that http://www/ledalite.com/lighthse.html Ian Ashdown, P. Eng. | READ THE BOOK! Research & Development Manager | Radiosity: A Programmer's Perspective Ledalite Architectural Products Inc. | by Ian Ashdown | John Wiley & Sons, 1994 Visit http://www.ledalite.com | (Sneaky Internet Advertising) From owner-globillum@imag.fr Wed Feb 21 13:55:14 1996 Return-Path: Sender: greg@lightscape.com Date: Wed, 21 Feb 1996 12:23:02 -0800 From: Greg Spencer Organization: Lightscape Technologies, Inc. To: globillum@imag.fr Subject: Caught in the Act X-Url: http://www.3d-design.com/bruno/bruno.html Status: RO This is a multi-part message in MIME format. --------------1372500F2847 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I just thought I would provide a bit of appropriate humor to this list. If you would like a good laugh, read the following article on lighting from 3D Design magazine -- it's a wonderful example of how to sound technical without actually having to know anything about the subject you are writing about (or even much about writing). http://www.3d-design.com/bruno/bruno.html -Greg. -- Greg Spencer, Software Engineer Lightscape Technologies., Inc. --------------1372500F2847 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="bruno.html" Caught in the Shadows

Caught in the Shadows

by Joey Bruno

Even the most stunning 3D models are useless without light sources. Put these tips, tricks, and hands-on techniques to the test to get the most from your light sources.

The notion of lighting a 3D scene seems rather simplistic, but it's not. Consider the many ways that shadows are created in 3D programs -- from a simple, single light source to special effect shots with uplighting, whirling spotlights, and laser bolts flying freely. And these effects are not limited to the higher-end workstations or software -- 3D packages selling for as little as $500 offer the ability to create lighting and shadow effects.

So what's the big deal? Why all the fuss about lighting a scene and simulating shadows? Sure you can build some geometry, throw a shadow-casting light source or two in and render away. But if you think that's all there is to it, think again. If your goal is to add realism to your design but you neglect to spend the time setting up the lights within it, you're all but asking for trouble. When it gets down to the final scene, it won't matter that your geometry is perfect or that you've included more special effects than a sci-fi movie. If your lighting and shadows are sloppy, people will notice.

Understand the shadows

A shadow is not a hard, razor-edged entity, nor is it an absolute absence of light. Shadows are created by blocking the in-line flow of light from an object, which can be caused by refraction, diffusion, or complete blockage. Consider for a moment how light itself works. Light does not cast a perfectly straight beam -- it projects in all directions from its source. This scattering effect is referred to as "propagation." Rays of light run three-dimensionally in a radial fashion from their sources. Close to the source, the rays are densely packed. As they move out, they disperse. That's why the effect of light gets weaker the further it moves from its source.

Consider how propagation affects an object. What do these radial light waves do when they strike an object? How about when light waves strike light waves or light waves interact with atmospheric diffusion? The physics get complicated, but in a nutshell, it produces scatter. When light strikes an object, especially the face of an object perpendicular to its source, it "kicks" the light back in the same direction as its source, causing reflections in an object. The greater an object's ability to return this light without interference from its surface characteristics (i.e., less returned diffusion), the shinier it is.

Light rays reach a breaking point at the edge of an object. Edges that are jutting out in space tend to "slice" the beam; part of the beam will strike the object and other parts of the beam will scatter. This scattering light must go somewhere. The energy of the light will tend to make it continue in the direction it was originally traveling. However, it may be a bit off-course because of a diffusion material (probably atmosphere).

The important thing to remember is the energy factor involved. The more energy the photon of light has, the more it will tend to stay on course after diffusion. Remember also that light waves are more dense and compact near their source.

Imagine that you have a crate sitting in a large room and a single light source at the far end of that room. The room should be fairly well lit near the light and the crate should cast somewhat of a shadow. However, this shadow will probably be more of a negative highlight effect with a roughly definable outline of the crate on the floor. Now move the crate closer to the light. The shadow edge will become more defined as you approach the light. because the photons of light are stronger, they tend to travel more closely toward their original path in a straight line. Also, depending on the amount of scattered light in the room, the shadow will have more depth and contrast to the rest of the scene as it approaches the light source.

Prepare yourself

Now, let's talk about 3D models and how to apply some of these techniques to them. First of all, it is a great temptation to make shadows razor-edged with 3D software -- besides, it's a neat effect. 3D lighting and objects tend to be "perfect" in their interaction, which means lights can be absolute, without diffusion or drop off, and have pure color saturation.

Some software packages can help to minimize this temptation by offering raytraced shadows. Raytracing allows the shadowing effects to behave in a more natural (light bouncing) fashion. As long as you don't go crazy with lights and wash everything out, you'll be okay. The problem with creating raytraced shadows on a PC is that the renderings take so long to produce. For a still shot it's not a big deal, but incorporating raytrace rendering into an animation (even a small one) can become a nightmare. Therefore, it's wise to use regular shadows for animation and reserve raytracing for stills. Besides, animation tends to minimize any "goofs" you make in setting up your lights and shadows.

Whether your software has the ability to create raytraced shadows or not, the following can help minimize the effects of improperly used lights and shadows:

ï Plan your shots and decide where lights and (especially) shadows are going to play a role. Don't worry about the shadows on "the other side of that mountain" or "building" unless you're going to be visiting it at some point.

ï Use a variety of lights. Don't make the mistake of using a single, pinpoint light source as the sun or broad daylight. Use a nice, even, ambient lighting set-up and place spotlights for shadows on objects that need them. The exception to this is architectural renderings. These renderings have traditionally been done a certain way, with hard-edged, single-source lighting. It's a matter of tradition over accuracy. However, do offer your clients the choice of both. They might surprise you and break tradition a bit if you can show them good reason.

ï Don't forget about diffusion and remember that light scatters. Go ahead and let your scene have razor sharp edges in its shadows. Now, go to the opposite end of the scene and add a contrasting fill light. Bring the level of the fill light up until you get a nice "washing" effect in the shadows. This is a very realistic effect if done properly and will give you results almost identical to raytracing.

If your software has the ability to project images with a light source (a movie projector of sorts) and you can make matte objects (objects that don't render, yet still affect the scene), try this. Set up all of your lights, then matte out all the objects in the scene. Render from the top and record all the shadows where they strike the ground. Take this image into a paint program and apply some effects to it over time, using the same number of frames that your animation will have. Now take all the lights out of your scene except for one big fill light (an omni light works great for this since it creates good highlights), bring all the objects back so they will render, project your shadow effect from above and move your fill light around. Depending on what you did in the paint program and how you move your fill light, you can make shadows "fall" backwards, which makes all the shadows dissolve into a whirlpool or simply transform into flowers. It's strange, but can be a very neat effect.

And, finally...

Read up on how lighting works. Check out some good books on theatrical lighting from the library or go to a good modeling/hobby shop and pick up a book or two on photographing model railroads. Some of the techniques in these books are pure genius and are easily applied to computer generated graphics.

Or turn to film for inspiration. Watch some old black and white movies or look at some old photos or stills. Movie makers of the past didn't have the luxury of color to give their scenes depth or definition. Take another look at cinema classics like Citizen Kane or Gaslight to see how shadows become a part of the storyline. Make note of the contrasts created using lights and shadows and take the techniques of yesteryear to work with you today.

Joey Bruno has been doing multimedia consulting for more than five years and is the founder of Image One, a multimedia consulting group based in Birmingham, AL. Joey also teaches 3D Studio and multimedia at Virginia College in Birmingham. He can be reached electronically at 102712.107@compuserve.com via the Internet.

--------------1372500F2847-- From owner-globillum@imag.fr Wed Feb 28 15:18:06 1996 Return-Path: From: "Holly E Rushmeier" Date: Wed, 28 Feb 1996 17:16:34 -0500 Reply-To: holly.rushmeier@nist.gov To: globillum@imag.fr Subject: change of address Cc: holly@cam.nist.gov Status: R Hi -- I'm sorry to send this to such a large list, but since I correspond with a lot of you periodically I thought this would be the most efficient way to reach people who might be sending me papers to review, requests for information, etc. I have decided to leave NIST and take a position at IBM Watson Research center. My last day at NIST will be March 26. I will be in at work only a couple of days a week between then and now before starting work April 1 at Watson. I don't have any address info. for up there yet. -- Holly From owner-globillum@imag.fr Thu Mar 14 14:44:22 1996 Return-Path: Date: Thu, 14 Mar 1996 16:58:28 -0500 To: globillum@imag.fr From: "Andrew J. Willmott" Subject: Triangular surface elements for wavelet radiosity Status: R Has anyone else out there implemented wavelet radiosity using triangular patches? Specifically, Flatlets and Multiwavelets. There seem to be a number of different ways to approach the various parts of the problem, and it would be interesting to compare our approach with any others that exist. Cheers, Andrew --- mailto:a.willmott@cs.cmu.edu ------- http://www.cs.cmu.edu/~ajw --- From owner-globillum@imag.fr Sun Mar 17 10:36:25 1996 Return-Path: From: Peter Shirley Subject: Will anyone send me this paper? To: globillum@imag.fr Date: Sun, 17 Mar 96 12:54:38 EST Mailer: Elm [revision: 70.85] Status: R Lately my students and I have been working on approximating light flow in volumes. Reviewers have said that we should reference the Toronto work of the late 80s: Drettakis, et. al, "Titghly coupled multiprocessing for a Global Illumination Algroithm", pp. 387-398, Eurographics '90. And Fournier, et. al, "FIAT LUX: Light Driven Global Illumination", DGP Technical Memo DGP89-1, 1989. I would love to, but I have not read them. AF has given me a high-level idea of the work, but I would love to get hold of the real papers. If anyone is willing to help me, please send copies to: Pete Shirley Program of Computer Graphics 580 Rhodes Hall Cornell University Ithaca, NY 14853 USA Thanks! Pete PS-- are old Eurographics proceedings (pre 1991) available? From owner-globillum@imag.fr Sun Mar 17 15:09:07 1996 Return-Path: From: Eugene Fiume To: Peter Shirley , globillum@imag.fr Subject: Re: Will anyone send me this paper? Date: Sun, 17 Mar 1996 17:38:36 -0500 Status: R On Mar 17, 1:17pm, Peter Shirley wrote: } Subject: Will anyone send me this paper? } } Drettakis, et. al, "Titghly coupled multiprocessing } for a Global Illumination Algroithm", pp. 387-398, } Eurographics '90. } } And Fournier, et. al, "FIAT LUX: Light Driven Global } Illumination", DGP Technical Memo DGP89-1, 1989. } } I would love to, but I have not read them. AF has given } me a high-level idea of the work, but I would love to get } hold of the real papers. If anyone is willing to } help me, please send copies to: You can get a postscript copy of the first off my web page or George's. Start from, for example, http://www.dgp.toronto.edu/people/elf/elf.html and poke around in my "papers" page. I think it goes out to George's node in France to get the paper. As for the second, I can't seem to find the troff source for it. Hmmm. Maybe Alain has it. I know a real paper copy is sitting in a pile somewhere in the bowels of my office. I'll look for it when next I have a chance. Regards, Eugene. From owner-globillum@imag.fr Sat Mar 23 22:13:51 1996 Return-Path: To: globillum@imag.fr From: iashdown@ledalite.com (Ian Ashdown) Subject: Radiosity bibliography update Date: Sat, 23 Mar 1996 20:13:21 -0800 Status: RO Here we go again: it's time for another quarterly update to the global illumination (and radiosity) bibliography, RadBib96. RadBib96 now has 850 references, including 21 new entries that I found over the past three months. The latest version will be posted to our Web site (http://www.ledalite.com/library/rrt.html) on April 1st. In the meantime, here are the new entries. (If you have any corrections or additions, please e-mail them to me before April 1st.) %A D. Arques %A S. Michelin %T Improving the Zonal Method Through the Use of Series Developments to Approximate Volume/Volume Form Factors %J Proceedings of the Fourth International Conference in Central Europe on Computer Graphics and Visualization '96 %E V. Skala %I University of West Bohemia %C Plzen, Czech Republic %D February 1996 %A G. Baciu %A R. K. W. Tsang %T Advancing Front Meshing for Radiosity Solutions %B Lecture Notes in Computer Science %E R. T. Chin %I Springer-Verlag %C Berlin, Germany %V 1024 %P 283-291 %D 1995 %A Martin Feda %T Parallel Radiosity on Transputer with Low Communication Overhead %J Hungarian Academy of Sciences Central Research Institute for Physics %I Hungarian Academy of Sciences %V 2 %N M,N %P 62-70 %D 1995 %O Second Austrian-Hungarian Workshop on Transputer Applications (Budapest, September 1994) %A T. A. Funkhouser %T Database Management for Interactive Display of Large Radiosity Models %J Graphics Interface '96 %C Toronto, Ontario %D May 1996 %P (to appear) %A S. Ghali %A A. J. Stewart %T A Complete Treatment of D1 Discontinuities in a Discontinuity Mesh %J Graphics Interface '96 %C Toronto, Ontario %D May 1996 %P (to appear) %A Jonathan Goldman %T Parallel Progressive Refinement and Projection-based Discontinuity Meshing for Radiosity %R Master's thesis %I University of Illinois at Chicago %C Chicago, IL %D 1995 %A Henrik Wann Jensen %A Niels J. Christensen %T Efficiently Rendering Shadows Using the Photon Map %J Edugraphics + Compugraphics Proceedings %E Harold P. Santo %I GRASP- Graphic Science Promotions & Publications, P.O. Box 4076, Massama, 2745 Queluz, Portugal %C Alvor, Portugal '95 %D December 12, 1995 %P 285-291 %O ISBN 972-8342-00-4 %A Henrik Wann Jensen %T Rendering Caustics on Non-Lambertian Surfaces %J Graphics Interface '96 %C Toronto, Ontario %D May 1996 %P (to appear) %A A. Keller %T A Quasi-Monte Carlo Algorithm for the Global Illumination Problem in the Radiosity Setting %B Lecture Notes in Statistics %I Springer-Verlag %C New York, NY %V 106 %P 239-251 %D 1995 %A S. Z. Li %T Adaptive Sampling and Mesh Generation %J Computer-Aided Design %V 27 %N 3 %D March 1995 %P 235-240 %A A. A. Maierhofer %A M. Gervautz %A K. F. Karner %T Meshing for Discontinuity Driven Hierarchical Radiosity %J Proceedings of the Fourth International Conference in Central Europe on Computer Graphics and Visualization '96 %E V. Skala %I University of West Bohemia %C Plzen, Czech Republic %D February 1996 %A T. Moeller %T Radiosity Techniques for Virtual Reality - Faster Reconstruction and Support for Levels of Details %J Proceedings of the Fourth International Conference in Central Europe on Computer Graphics and Visualization '96 %E V. Skala %I University of West Bohemia %C Plzen, Czech Republic %D February 1996 %A K. Myszkowski %A T. L. Kunii %T An Efficient Cluster-Based Hierarchical Progressive Radiosity Algorithm %B Lecture Notes in Computer Science %E R. T. Chin %I Springer-Verlag %C Berlin, Germany %V 1024 %P 292-303 %D 1995 %A K. Nechvile %A J. Sochor %T Form-factor Evaluation with Regional BSP Trees %J Proceedings of the Fourth International Conference in Central Europe on Computer Graphics and Visualization '96 %E V. Skala %I University of West Bohemia %C Plzen, Czech Republic %D February 1996 %A Adelene Whye-Leng Ng %T Assessment of Five Radiosity Acceleration Techniques %J Computers & Graphics %V 19 %N 5 %P 727-??? %D 1995 %A Thomas Kenji Otake %T Saccade-based Progressive Refinement Radiosity for Virtual Reality Displays %R Master's thesis %I Department of Computer Science, University of Alabama %D 1995 %A M. Sbert %A X. Pueyo %A L. Neumann %A W. Purgathofer %T Global Multipath Monte Carlo Algorithms for Radiosity %J The Visual Computer %V 12 %N 2 %P 47-?? %D 1996 %A Gernot Schaufler %A Wolfgang Stuerzlinger-Protoy %T Exact and Error Bounded Approximation of Local Illumination %J Edugraphics + Compugraphics Proceedings %E Harold P. Santo %I GRASP- Graphic Science Promotions & Publications, P.O. Box 4076, Massama, 2745 Queluz, Portugal %C Alvor, Portugal '95 %D December 12, 1995 %P 327-366 %O ISBN 972-8342-00-4 %A L. Sindlar %A J. Pelikan %T Parallel Radiosity on a Cluster of Workstations %J Proceedings of the Fourth International Conference in Central Europe on Computer Graphics and Visualization '96 %E V. Skala %I University of West Bohemia %C Plzen, Czech Republic %D February 1996 %A Chegu Vinod %T Parallel Hierarchical Radiosity Algorithms %R Master's thesis %I Wayne State University %D 1995 %A Adam Worrall %A Claire Willis %A Derek Paddon %T Dynamic Discontinuities for Radiosity %J Edugraphics + Compugraphics Proceedings %E Harold P. Santo %I GRASP- Graphic Science Promotions & Publications, P.O. Box 4076, Massama, 2745 Queluz, Portugal %C Alvor, Portugal '95 %D December 12, 1995 %P 367 - 375 %K discontinuity meshing, dynamic environments %O ISBN 972-8342-00-4 %Z available as http://aloha.cs.bris.ac.uk/~worrall/scope/port95.html Ian Ashdown, P. Eng. | READ THE BOOK! Research & Development Manager | Radiosity: A Programmer's Perspective Ledalite Architectural Products Inc. | by Ian Ashdown | John Wiley & Sons, 1994 Visit http://www.ledalite.com | (Sneaky Internet Advertising) From owner-globillum@imag.fr Mon Mar 25 10:05:04 1996 Return-Path: Date: Mon, 25 Mar 1996 16:45:54 +0100 (MET) From: Eric Lafortune To: globillum@imag.fr Subject: PhD dissertation Status: RO Dear Globillumers, It is my pleasure to announce that my PhD dissertation is now available on the net. The dissertation is entitled: Mathematical Models and Monte Carlo Algorithms for Physically Based Rendering It's all about global illumination models, Monte Carlo methods, variance reduction techniques, path tracing, light tracing and bidirectional path tracing. You can find the abstract, an overview of the chapters, the table of contents, the colour images and the dissertation itself at: http://www.cs.kuleuven.ac.be/~ericl/thesis/ Even if you're not interested in the text you can just have a look at the pretty pictures. Enjoy! Kind regards, Eric Lafortune Computer Graphics Research Group Department of Computer Science Katholieke Universiteit Leuven Belgium From owner-globillum@imag.fr Thu Mar 28 18:54:21 1996 Return-Path: From: Peter Shirley Subject: Ugly terminology question To: globillum@imag.fr Date: Thu, 28 Mar 96 21:26:12 EST Mailer: Elm [revision: 70.85] Status: RO Ok, we often pretend that we are solving for radiance, or spectral radiance at each pixel. But chances are we are calculatining luminance Y = 683 lm/cd INT y(lambda) L(lambda) dlamba as well as X and Z. In a "radiosity" program (no flames please) we calculate luminous exitance plus some X and Z that are like luminous exitance but with x and z for weighting functions. Here is the question, if Y is called luminance, what are X and Z called? And what is (X,Y,Z) called? And if V is scotopic luminance, what is (V,X,Y,Z) called? The IES handbook and W&S do not seem to have an answer (but one can miss a 20 page article in either of those volumes!). Does anyone? Thanks, Pete PS-- Bruce Walter suggested "tristimulance" for (X,Y,Z), and this also implies "tristimulous exitance". I am not sure what (V,X,Y,Z) is in this system. From owner-globillum@imag.fr Mon Apr 1 12:47:07 1996 Return-Path: From: Brother Louis Subject: Radiosity vs ray tracing To: globillum@imag.fr Date: Mon, 1 Apr 1996 20:53:45 +0000 (BST) Status: RO I wonder could anyone tell me where I could get information on Ray Tracing versus Radiosity in the context of solving a scene......ie which models shadows better etc,etc. Or any recomended books on the subject. Any information would be gratefully appreciated From owner-globillum@imag.fr Sat Apr 6 03:57:33 1996 Return-Path: Date: Sat, 6 Apr 1996 13:14:44 +0200 (MET DST) From: Eric Lafortune To: globillum@imag.fr Subject: Re: PhD dissertation Status: R Dear Globillumers, Those of you who have tried downloading my PhD dissertation on Monte Carlo rendering may have experienced problems getting the entire files, due to the connections stalling and timing out. I'm sorry for the inconvenience. Both the b/w and grey-scale versions are now mirrored at ftp.funet.fi and at www.graphics.cornell.edu. You can reach them through my web page at: http://www.cs.kuleuven.ac.be/~ericl/thesis/ or directly at: ftp://ftp.funet.fi/pub/sci/papers/graphics/Lafortune/ or: http://www.graphics.cornell.edu/~eric/ Thanks to Juhana and to Sumant. So, does this dissertation present the ultimate solution to the global illumination problem? Does its bibliography do justice to your work? Will Clive realise that Bill is actually his long-lost half-brother? Tune in and find out... Kind regards, Eric Lafortune. From owner-globillum@imag.fr Mon Apr 15 09:49:37 1996 Return-Path: From: holzschu@cs.uct.ac.za (Nicholas Holzschuch) Date: Mon, 15 Apr 1996 16:18:38 +0200 To: globillum@imag.fr Subject: PhD Thesis available Status: R Hi Globillumers ! My PhD thesis is now available. It deals with hierarchical radiosity, radiosity derivatives, namely first derivatives (Jacobian or gradient) and second derivatives (Hessian), and how to compute them (especially the Hessian). It also explores ways to use these derivatives to compute reliable error-bounds on any interaction, using concavity properties of the radiosity. Finally, it presents a refinement strategy based on these error bounds. The thesis is on A4 paper, takes 176 pages: ftp://ftp.imag.fr/pub/Mediatheque.IMAG/theses/96-Holzschuch.Nicolas/these.ps.gz (3.4 Mo) If you wish, there is a version with 2 pages on one, takes only 88 pages: ftp://ftp.imag.fr/pub/Mediatheque.IMAG/theses/96-Holzschuch.Nicolas/these.a5.ps.gz (3.4 Mo anyway) I'm afraid it is written in french. There should be a paper in english dealing with the same problems, coming real soon :-) Abstract ======= We introduce several improvements to the hierarchical radiosity method. First, a complete analysis of a specific implementation of the hierarchical radiosity method allows to point out its bottlenecks. Based on this analysis, we suggest two simple improvements: a lazy evaluation of top-level interactions, and a new refinement criterion, that greatly reduces the number of interactions, without loss of precision. A brief introduction to the properties of functions of several variables and their derivatives follows, which allows a rewriting of the expression of radiosity, and hence a better numerical approximation. Methods for the estimation of the error produced during the radiosity computations are analysed. We then introduce the concavity properties of the radiosity function that, combined with an exact computation of the radiosity derivatives, allow a complete control of the error on the interactions between patches, and hence a precise minoration and majoration of the radiosity on all the patches. We introduce a new refinement criterion based on this modelling of interactions, and a complete hierarchical radiosity algorithm using this refinement criterion. The last part of the thesis is devoted to practical computations of the radiosity derivatives (gradient and Hessian), first for a constant emitter with total visibility, then for a constant emitter with partial visibility and for an emitter with linear radiosity. -- +-----------------------------+---------------------+ | Nicolas Holzschuch -- Iquipe iMAGIS/IMAG | | 385, avenue de la Bibliothhque | | B.P. 53 -- 38041 Grenoble cedex 9 -- France | +---------------------------------------------------+ | Currently at the University of Cape Town, | | Dept. of Computer Science -- 7700 Rondebosch | | South Africa | +---------------------------------------------------+ From owner-globillum@imag.fr Tue Apr 23 12:39:04 1996 Return-Path: From: seth@graphics.lcs.mit.edu (Seth Teller) Date: Tue, 23 Apr 1996 10:25:04 -0400 Reply-To: seth@graphics.lcs.mit.edu To: globillum@imag.fr Subject: Comp. Geom. Impact Task Force Report (Application Challenges to CG) Cc: sequin@cs.berkeley.edu, arir@cs.huji.ac.il, chazelle@cs.princeton.edu, edelman@lcs.mit.edu, gjs@ai.mit.edu, graphics@graphics.lcs.mit.edu, nmp@deslab.mit.edu, olivier.faugeras@sophia.inria.fr, tlp@ai.mit.edu, wisdom@mit.edu Status: R dear global illumination researchers and others, charged by, and under the leadership of, bernard chazelle, the CG Impact Task Force has completed its report entitled "Application Challenges to Computational Geometry." it's an exhortation to comp. geometers to get more involved in identi- fying and attacking problems faced by practitioners in many areas of geometric computing, including computer graphics, imaging, shape reconstruction, machine vision, GIS, mesh generation, robotics, manufacturing, robustness, computa- tional and molecular biology, and astrophysics. i hope that many in our community will find it an interesting, provocative read as well. three versions (dvi, postscript, and compressed postscript) of the full report are available at http://graphics.lcs.mit.edu/~seth/pubs/acmtaskforce.dvi 1/4Mb http://graphics.lcs.mit.edu/~seth/pubs/acmtaskforce.ps 1/2Mb http://graphics.lcs.mit.edu/~seth/pubs/acmtaskforce.ps.Z 1/4Mb (postscript is also available off bernard's page at princeton, but for some reason it's a 2Mb file there.) i've attached to this message postscript for the title page. finally, a paper version of the report is available as TR-521-96 from the princeton cs dept, 35 olden st., princeton nj 08544 usa. comments, criticism, discussion are of course encouraged. best regards, seth teller. -- Asst. Prof of CS and Eng. Synthetic O ~ ~ seth@lcs.mit.edu MIT Lab for CS NE43-208 Imagery <=> ~ tel: 617 258 7885 545 Technology Square Group / \ fax: 617 253 6652 Cambridge MA 02139 / ____________ / http://graphics.lcs.mit.edu/~seth/ From owner-globillum@imag.fr Wed Apr 24 10:44:42 1996 Return-Path: Date: Wed, 24 Apr 1996 10:07:28 -0600 From: DILAURA DAVID L To: globillum@imag.fr Subject: Form Factor Calculations Status: RO Colleagues: We have found (more) new equations for the calculation of radiative transfer form factors. A result of this work is a new method for determining the effect of blocking objects. I will be presenting a paper on this at the Annual Conference of the Illuminating Engineering Society in August. I have placed a postscript pre-print of it in anonymous ftp at: civil.colorado.edu The file name is: non_diff_contour_4.ps and it is in the directory: pub/Illumination Notice the uppercase I. ___ David L. DiLaura Department of Civil and Architectural Engineering University of Colorado at Boulder From owner-globillum@imag.fr Wed Apr 24 20:25:33 1996 Return-Path: From: seth@graphics.lcs.mit.edu (Seth Teller) Date: Wed, 24 Apr 1996 22:56:32 -0400 Reply-To: seth@graphics.lcs.mit.edu To: globillum@imag.fr Subject: CG Impact Task Force Report now in html, ps, dvi... Cc: arir@cs.huji.ac.il, chazelle@cs.princeton.edu, edelman@lcs.mit.edu, gjs@ai.mit.edu, graphics@graphics.lcs.mit.edu, karlin@cs.washington.edu, nmp@deslab.mit.edu, olivier.faugeras@sophia.inria.fr, sequin@cs.berkeley.edu, tlp@ai.mit.edu, wisdom@mit.edu Status: RO hi everyone, the taskforce report is now available in html as http://graphics.lcs.mit.edu/~seth/pubs/taskforce/techrep.html as well as in postscript http://graphics.lcs.mit.edu/~seth/pubs/taskforce.ps compressed postscript http://graphics.lcs.mit.edu/~seth/pubs/taskforce.ps.Z and dvi http://graphics.lcs.mit.edu/~seth/pubs/taskforce.dvi please forgive my cluttering your mailbox with this second message. best regards, seth teller. From owner-globillum@imag.fr Wed May 1 11:56:20 1996 Return-Path: Date: Wed, 1 May 1996 14:09:54 -0400 From: Holly Rushmeier To: globillum@imag.fr Subject: appearance workshop Status: RO For those of you interested in reflectance modelling/measurement, my ex-coworkers at NIST are organizing a workshop to generate industry interest in research in the appearance of coatings. The workshop and the project they are trying to get started are described at: http://titan.cbt.nist.gov/~mikeg/workshop.html -- Holly Rushmeier holly@watson.ibm.com From owner-globillum@imag.fr Wed May 15 11:01:08 1996 Return-Path: From: Neil Gatenby Date: Wed, 15 May 96 15:03:35 BST To: globillum@imag.fr Subject: Job Advert Status: R Hi, The following is a job advert which may interest some folk on this list. Please feel free to distribute this to friends and colleagues who may be interested. Best wishes, Neil ------------------------------------------------------------- Neil Gatenby, | LightWork Design, Senior Graphics Programmer, | 60 Clarkehouse Road, email: neil@lightwork.co.uk | Sheffield, S10 2LH, England. ------------------------------------------------------------- voice: (+44) (0)114 266 8404 ..... fax: (+44) (0)114 266 1383 ==================================================================== Opportunities at LightWork Design LightWork Design is Europe's leading 3D computer graphics software developer. We specialise in the fields of 3D graphical technologies for modelling, rendering, simulation and animation. Since our formation in 1989, we have experienced substantial year on year growth and expect this to continue. We recruit software engineers on an on-going basis and our looking for high calibre graduates with commercial experience. Details of current specific vacancies are given below. About LightWork Design Lightwork was founded by four people in 1989 and has grown to a staff of 25 today (May 1996) with a target of 40 by 1997. The majority of our staff are young software engineers engaged in the design, implementation, testing and support of products and bespoke software development in the areas of 3D graphical technologies. Products that we develop, market and support directly are LightWorks and LightWorks-NC. These are component technologies: toolkit products that are licensed to other software development companies who embed them within their own products and sell on the technologies to end users. LightWorks provides a wide range of photo-realistic rendering capabilities and LightWorks-NC is a simulation and verification tool for Numerical Control processes. Both products are supported on a very broad range of computing platforms, including PCs running Windows 3.1, Windows 95 and Windows NT, Unix workstations from Sun, Silicon Graphics, Hewlett Packard, IBM and DEC, and Macintosh computers. We also develop a number of plug-in modules for other products that are marketed through other channels, including those for SolidWorks, Autodesk's 3D Studio MAX, Apple's QuickDraw-3D and Ricoh's DESIGNBASE. Our customers Having already established ourselves as one of the world's leading suppliers of graphics technology for CAD/CAM, our business is now expanding into the mainstream 3D graphics and animation markets. We currently have over 50 customers and partners in the industry including Sun Microsystems, Apple Computer, Autodesk, EDS/Unigraphics, Auto-des-sys, Engineering Animation, Matra Datavision, Ricoh Corporation and Integrated Computing Engines. We are working with a number of significant players in the graphics and animation and internet industries and expect new products towards the end of 1996. What we expect from you We expect candidates of the highest calibre. All our software engineers have a BSc in a science or engineering discipline, with many having MSc or PhD degrees. The work we do is intellectually demanding, and requires excellent analytical skills. We require individuals who are perceptive, dedicated, creative and eager to succeed, and who want to be among the very best in their field. We are looking for team players; those who thrive in a vibrant environment of young and energetic individuals with drive and a passion for computer graphics technology. We pride ourselves on the quality and robustness of our software. We expect high standards of software engineering, with close attention to detail, and a focus on developing bug-free software. You will need to be a competent programmer in C or C++, and familiar with developing software on a Unix, Windows or Macintosh platform. We expect you to be creative and to contribute ideas from day one. You will need to communicate your ideas effectively to colleagues and customers. You may be required to travel internationally to visit our customers and partners; the majority of our revenues are earned in the USA, Europe and Japan. What you can expect from LightWork You can expect that your hard work will be recognised and that you will be rewarded according to your contribution. We offer competitive salaries and a package that includes non-contributory pension, a minimum of four weeks paid holiday per year, and a profit-sharing scheme. We want to continue to expand, and need candidates who are eager to take on new challenges, including technical project leadership. Expect to be pushed to the limits of your capabilities, and to move quickly into a position of responsibility. Where you will be located Our headquarters are in Sheffield, England. We are located on the West side of the city, close to the Peak District National Park. We are in the process of opening satellite offices at other locations in the UK. Please check for latest information. Vacancies The following is a list of our current specific vacancies. However, we recruit on an on-going basis. If you are an outstanding candidate and are excited by what you can contribute at LightWork Design, then please contact us and provide a copy of your CV. ---------------------------------------------------------------------- Job Title: Graphics Software Specialists Job Ref: SG/GR There are two vacancies for specialists to work in our Graphics Technology team with responsibility for designing and developing 3D software. You will have expert level C or C++ programming skills with a proven track record and at least three years experience as a software engineer in a team-oriented environment. You will have experience of implementing algorithms for rendering, modelling, visualisation or animation, and be familiar with published work in the field and current trends. Areas of interest are: ray tracing, global illumination, radiosity, kinematics, shading and texturing. ---------------------------------------------------------------------- Job Title: Displays Software Specialists Job Ref: SA/DS You will be working in our Display Technology team with responsibility for developing interfaces to X windows and/or Microsoft Windows platforms. You will have two or more years experience as a software engineer in the areas of GUI implementation, and have excellent programming skills in C. You will have a good understanding of computer architectures and instruction sets of current processors and be prepared to optimise software to take advantage of these instruction sets. You will be required to work with industry standard 3D APIs, including OpenGL and Direct3D. A knowledge of graphical image file formats will be an advantage. ---------------------------------------------------------------------- Job Title: Product Integration Specialists Job Ref: MD/SD You will be working in a team of software engineers involved in integration of LightWorks technologies with a leading-edge 3D CAD system. We have one vacancy for two projects based under Microsoft Windows NT with Visual C++, and one for a project based under Unix/X-Windows. You will have experience of developing or interfacing to software for solid modelling, and have an understanding of the mathematics and software engineering issues pertinent to solid modellers. You will have expert level programming skills in C++ under a Unix/Windows development environment, and at least three years of team oriented software engineering experience. For Windows developers, you should be familiar with Windows NT and Visual C++; knowledge of OLE will be an advantage. ---------------------------------------------------------------------- Job Title: Multiprocessor Technology Team Lead Job Ref: SG/MP You will lead a small team of software engineers focusued on developing multiprocessor technologies for desktop computing platforms and supercomputers. You will have hands-on experience of developing algorithms for symmetric multiprocessor systems, and an understanding of the issues relevant to SIMD algorithm design. You will have worked previously in a project lead or senior software engineer role, and have first hand experience of the software development life cycle. ---------------------------------------------------------------------- Job Title: NC Project Team Lead Job Ref: GO/NC A vacancy exists for an experienced software project lead to take technical responsibility for an NC simulation project. Successful applicants will have two or more years of experience in a team lead position in the CAD/CAM industry. You will have knowledge of Solid-Modelling and CNC cutter-path generation/verification, and 3-, 4- and 5-axis milling and turning. You will be involved in hands-on design and development of the product in addition to leading a team of software engineers. ---------------------------------------------------------------------- Job Title: 3D Geometry Specialist Job Ref: MD/GE The successful applicant will have ideally an MSc or PhD in a mathematics subject, and have experience of design and development of 3D surface tessellation software. You will have expert level of programming experience in C or C++. Experience of surface and solid modelling will be an advantage. ---------------------------------------------------------------------- Job Title: Applications Consultants Job Ref: PK/IN We have two vacancies for application engineers to work on short term projects involving integrating LightWorks with customer products. The work will involve travel to customer sites in USA, Japan and Europe. Successful applicants will be highly motivated and able to work alone without supervision. You should be a competent programmer in C and C++, with experience of integrating with third party 3D graphics or CAD/CAM products. ---------------------------------------------------------------------- Job Title: Product Support Specialist Job Ref: WN/PS An engineer is required to join our support team with responsibility for providing post-sales support for the LightWorks and LightWorks-NC products. You will be a self-starter with drive to resolve highly complex and challenging problems presented by customers. You will be liaising with customers who are themselves highly compentent software engineers, and will require excellent communication and problem solving skills. You should have at least one year of experience in a technical role in a team-oriented environment. ---------------------------------------------------------------------- Job Title: PC Systems Administrator Job Ref: MD/SA We require a system administrator to take responsibility for support and maintenance of our expanding network of PC workstations. You should have at least two years of experience in a similar role, and be able to work effectively without close supervision. You should be familiar with the following technologies and activities: Microsoft Windows (WFW 3.11, Windows 95, Windows NT and Advanced Server), machine setup and configuration, installation of hardware, printer setup, system security, installation and maintenance of commercial and public domain packages, networking and network optimisation in a multi-platform environment. Knowledge of Unix systems (System V and BSD) and NFS is an advantage. ---------------------------------------------------------------------- Job Title: QA Software Engineer Job Ref: WN/PR We require a software engineer to complement our existing Quality Assurance programme. You will be part of our productisation team, and working in a Unix and/or Windows environment, with responsibility for defining, designing and implementing testing strategies for a variety of products. C and/or C++ programming experience will be an advantage. You should have worked previously in an ISO 9001 development environment and be familiar with Quality Management Systems. Further info: Nina Travaglioni Lightwork Design Limited 60 Clarkehouse Road Sheffield S10 2LH Email: nina@lightwork.co.uk Voice: (+44) 114 266 8404 Fax: (+44) 114 266 1383 From owner-globillum@imag.fr Mon May 20 07:52:48 1996 Return-Path: Date: Mon, 20 May 96 14:46:16 BST From: Simon Gibson To: globillum@imag.fr Subject: SIGGRAPH '94 course notes Status: R I am looking for a copy of Holly Rushmeier's 1994 SIGGRAPH course notes on tone-reproduction for rendering. Does anybody have these in electronic form, or will I have to contact SIGGRAPH and order a paper copy? Simon From owner-globillum@imag.fr Wed May 22 08:53:28 1996 Return-Path: From: owner-globillum@imag.fr Date: Wed, 22 May 1996 09:27:33 -0500 To: Philippe.Bekaert@cs.kuleuven.ac.be, olga%BGCICT.BITNET@gatech.edu, OMB@vmei.acad.bg, beltcheva@stellaris.cg.tuwien.ac.at, alan@cs.bris.ac.uk, chesnais@siggraph.org, elias@fmph.uniba.sk, falcidieno@ima.ge.cnr.it, dieter@cs.uni-bonn.de, gervautz@stellaris.cg.tuwien.ac.at, glassner@microsoft.com, groeller@stellaris.cg.tuwien.ac.at, grossm@inf.ethz.ch, igkhwj@unidhp.uni-c.dk, ari@cs.sunysb.edu, leberl@icg.tu-graz.ac.at, neumann@odin.net, Niepel@fmph.uniba.sk, peroche@emse.fr, Frits.Post@twi.tudelft.nl, xavier@ima.udg.es, schumann@informatik.uni-rostock.de, shirley@graphics.cornell.edu, skala@kiv.zcu.cz, slavik@cs.felk.cvut.cz, strasser@gris.informatik.uni-tuebingen.de, thalmann@di.epfl.ch, P.J.Willis@bath.ac.uk, zara@cs.felk.cvut.cz, fuchs@dpt-info.u-strasbg.fr, kin@eml.hiroshima-u.ac.jp, cazier@dpt-info.u-strasbg.fr, keller@informatik.uni-kl.de, kolinger@kiv.zcu.cz, mikita@virgo.dam.fmph.uniba.sk, czanner@fmph.uniba.sk, luscan@center.fmph.uniba.sk, skala@kiv.zcu.cz, kotrec@fmph.uniba.sk, chalmo@virgo.dam.fmph.uniba.sk, karner@icg.tu-graz.ac.at, mu@piis10.joanneum.ac.at, stuerzlinger@gup.uni-linz.ac.at, kotto@informatik.uni-rostock.de, chover@inf.uji.es, raidl@eiunix.tuwien.ac.at, berka@sgi.felk.cvut.cz, hagman@ling.gu.se, elias@fmph.uniba.sk, jacekl@sunrise.pg.gda.pl, gervautz@stellaris.cg.tuwien.ac.at, matkovic@stellaris.cg.tuwien.ac.at, groeller@stellaris.cg.tuwien.ac.at, elka@sequoia.usoms.poznan.pl, kpgso@fmph.uniba.sk, dba@sys.uea.ac.uk, barth@eiunix.tuwien.ac.at, rdb@cs.unh.edu, Kadi.Bouatouch@irisa.fr, pere@turing.upc.es, mcohen@microsoft.com, Steven.Collins@cs.tcd.ie, Sabine.Coquillart@inria.fr, cunningham@siggraph.org, rsc@csustan.csustan.edu, Philip.Dutre@cs.kuleuven.ac.be, elias@fmph.uniba.sk, jle@igd.fhg.de, falcidieno@ima.ge.cnr.it, dieter@cs.uni-bonn.de, fournier@cs.ubc.ca, gnatz@lan.informatik.tu-muenchen.de, goebel@igd.fhg.de, mueller@euklid.informatik.uni-dortmund.de, ferko@fmph.uniba.sk, Martin.Goebel@gmd.de, Guenther.Greiner@informatik.uni-erlangen.de, grossm@inf.ethz.ch, hagen@informatik.uni-kl.de, hansmann@informatik.uni-hamburg.de, herzner@zdfzs.una.ac.at, igkhwj@unidhp.uni-c.dk, sjk@pwm.ict.pwr.wroc.pl, lassek@nada.kth.se, H131Kra@huella.bit Status: R NET@gatech.edu, leberl@icg.tu-graz.ac.at, elias@fmph.uniba.sk, jle@igd.fhg.de, sjk@pwm.ict.pwr.wroc.pl, lassek@nada.kth.se, nelson@max.ocf.llnl.gov, mam@cs.hut.fi, T.M.Morrow@bath.ac.uk, a.m.mumford@lut.ac.uk, neumann@odin.net, ps@math.scarolina.edu, Sumant.Pattanaik@irisa.fr, pottmann@geometrie.tuwien.ac.at, Claude.Puech@imag.fr, holly@cam.nist.gov, gsakas@igd.fhg.de, schlick@labri.u-bordeaux.fr, schumann@informatik.uni-rostock.de, Ernst.Schuster@akh-wien.ac.at, seidel@informatik.uni-erlangen.de, Francois.Sillion@imag.fr, skala@kiv.zcu.cz, slavik@cs.felk.cvut.cz, slusallek@informatik.uni-erlangen.de, strasser@gris.informatik.uni-tuebingen.de, wrzl@gup.uni-linz.ac.at, szirmay@fsz.bme.hu, paulh@cwi.nl, Nadia.Thalmann@cui.unige.ch, christof@uranus.tuwien.ac.at, remco@cwi.nl, remcov@cs.ruu.nl, volkert@gup.uni-linz.ac.at, igkhwj@unidhp.uni-c.dk, weng@iidec.iinform.oeaw.ac.at, globillum@imag.fr From: Elaine Swobe (Elaine Swobe) Subject: Jarek Rossignac to Head GVU Center at Georgia Tech FOR IMMEDIATE RELEASE May 22, 1996 Jarek Rossignac to become the new Director of Georgia Tech's top-ranked Graphics, Visualization & Usability (GVU) Center The Georgia Institute of Technology's College of Computing has invited Jarek Rossignac to head its Graphics, Visualization & Usability (GVU) Center. It is anticipated that Dr. Rossignac, who succeeds Dr. James D. Foley, will assume his duties on August 1, 1996. He will report to Dean Peter Freeman and will be a professor in the College of Computing. An internationally known researcher, Dr. Rossignac comes to GVU from IBM's T.J. Watson Research Center in Yorktown Heights, NY, where he is the Senior Manager of Visualization, Interaction and Graphics, leading research activities in interactive 3D graphics, scientific and medical visualization, and industrial applications of virtual reality. He was the Research Strategist for Visualization and was also responsible for the development of two IBM visualization and walkthrough products. He holds a PhD in Electrical Engineering from the University of Rochester, NY, and a Diplome d'Ingenieur in Electrical Engineering and Mechanical Engineering from the ENSEM, Nancy, France. His most notable scientific contributions are in solid modeling and animation, compression and interactive rendering of highly complex 3D databases, and user interfaces for 3D design and navigation. He has chaired several international conference committees, regularly serves as associate or guest editor for professional journals, has authored 13 patents and more than 40 papers, and has won numerous awards for his publications and technical contributions "Dr. Rossignac has not only shown his creativity in his personal research, but he has been an effective leader in building a strong research group at IBM," said Peter Freeman, Dean of the College of Computing. "We selected him from among the very few candidates who have the creativity, experience and energy required to lead GVU into the next century. We are extremely pleased to have him." Established at Georgia Tech in 1991 and housed in the College of Computing, the GVU Center is an interdisciplinary research center comprised of faculty and graduate students from nine diverse campus units including Computing; Architecture; Psychology; Industrial & Systems Engineering; and Literature, Communication & Culture. The Center encourages collaborative research and innovative approaches in applying new technologies to everyday problems. In March of this year, the GVU Center was ranked #1 in the country in 'Graphics: User Interaction' in a survey of doctoral programs conducted by U.S. News & World Report. Dr. Rossignac believes that GVU's size, diversity and unique combination of talents make it the perfect breeding ground for fundamental innovations in the way we communicate with computers and, more importantly, the way we use computers to do our work faster and better communicate with each other. Dr. Foley, GVU's founding director, will leave Georgia Tech this summer to become Director of the Mitsubishi Electric Research Lab in Cambridge, MA, and Executive Vice President of Mitsubishi Electric Information Technology Center America. He will maintain his ties to Georgia Tech as a member of the College of Computing's Advisory Board. Dr. Foley said of Dr. Rossignac's appointment, "We have attracted a dynamic leader and respected researcher who will not only maintain but further strengthen our research and educational programs. I expect to see the GVU Center continue in a leadership position for many years." After August 1, 1996, Dr. Rossignac can be reached as follows: Prof. Jarek Rossignac, Director Graphics, Visualization & Usability Center Georgia Institute of Technology Atlanta, GA 30332-0280 404/0671 FAX: 404/894-0673 Email: rossignac@cc.gatech.edu GVU Home Page: http://www.cc.gatech.edu/gvu/gvutop.html ### For more information contact: Elaine Swobe, Information Specialist II GVU Center Georgia Institute of Technology Atlanta, GA 30332-0280 404/894-4488 FAX: 404/894-0673 email: elaine@gvu.gatech.edu ---------------------- Elaine Swobe Information Specialist elaine@gvu.gatech.edu GVU Center, College of Computing Phone (404) 894-9392 Georgia Institute of Technology FAX (404) 894-0673 Atlanta, GA 30332-0280 From owner-globillum@imag.fr Fri May 24 16:51:45 1996 Return-Path: From: wexler@pdi.com (Dan Wexler) Subject: Illuminated by black light To: globillum@imag.fr, thad@hammerhead.com Date: Fri, 24 May 1996 16:03:41 -0700 (PDT) Status: R Here's a great little anecdote that illustrates just how far rendering is from reality: One of our animators was trying to simulate a shadow using a projection light. He created a texture that was white where he wanted light, and black where he wanted shadow. Then he used a special material shader we have called a 'shadow-only' shader that renders the inverse shadow (ie. white/gray wherever there are shadows and black everywhere else). As you might guess, the "shadows" from the projection light did not show up in the image generated by the shadow-only shader. When I explained the situation to him I caught myself saying: "Well, those points are not in shadow. They are illuminated with black light." He looked at me with a completely blank expression, so I went on: "If you were in a completely closed room without a light, would the room be completely shadowed, or not illuminated?" The boundary between science and philosophy is a blurry one. Daniel Wexler R&D Staff, Pacific Data Images From owner-globillum@imag.fr Fri May 24 17:47:11 1996 Return-Path: Date: Fri, 24 May 1996 17:10:36 -0700 From: "Samuel P. Uselton" To: globillum@imag.fr Subject: [wexler@pdi.com: Illuminated by black light] Reply-To: uselton@nas.nasa.gov Status: R From: wexler@pdi.com (Dan Wexler) > >Here's a great little anecdote that illustrates just how far >rendering is from reality: > >One of our animators was trying to simulate a shadow using {trimmed for brevity} > >When I explained the situation to him I caught myself saying: > >"Well, those points are not in shadow. They are illuminated >with black light." > >He looked at me with a completely blank expression, so I went on: > >"If you were in a completely closed room without a light, >would the room be completely shadowed, or not illuminated?" > >The boundary between science and philosophy is a blurry one. Of course we aren't always trying to duplicate reality. Sometimes, especially in scientific visualization, we want to make realistic *seeming* images of things that one can not see. My anecdote on the communication break down between disciplines goes like this... A petroleum engineer (old, gruff and crotchety) was attending the annual project review for the Visualization group at an oil company research lab. The company and the engineer shall remain nameless, but one of the people making the presentation was my friend, collaborator and one time student, Mark Lee. The main uses of visualization in the oil company were in the analysis of seismic data and the display of petroleum reservoir simulation results. Mark was explaining about adding capabilities to use a variety of shading models, and what the input to the vis package needed to be for some of the nicer shaders. In particular, he described the benefits of being able to specify the position of the light source, and change it interactively, in enhancing visibility of certain things in the visualization. The petroleum engineer interrupts and rather rudely proclaims to all that the software can't POSSIBLY work like that 'cause everybody knows there's no light underground. Mark tried to explain, but his critic couldn't pry his mind open enough to understand the explanation. Sam Uselton uselton@nas.nasa.gov From owner-globillum@imag.fr Tue May 28 13:18:34 1996 Return-Path: From: cn1@irz301.inf.tu-dresden.de (Nguyen, D.C.) Subject: Procedural bloby objects avialable. To: globillum@imag.fr (Global Illumination List) Date: Tue, 28 May 1996 21:24:19 +0200 (MESZ) Status: R For infos about RTEvol(RayTraced Evolution:), a free package for procedural- modelling, using Lindenmeyer-grammars and interpreted C-like macros/function, look at this URL: http://www.rz.tu-ilmenau.de/~juhu/GX/RTEvol/ Primarly i use this package to test some raytracing-acceleration techniques, but now it expands to a fully programmable system. It is an ideal tool for quickly generation of test-scenes . Have fun, --JuHu From owner-globillum@imag.fr Wed Jun 19 22:34:00 1996 Return-Path: To: globillum@imag.fr From: iashdown@ledalite.com (Ian Ashdown) Subject: Interesting literature Date: Wed, 19 Jun 1996 21:55:25 -0800 Status: R Here are three papers scheduled to be presented at the 1996 Illuminating Engineering Society Annual Conference in Cleveland, Ohio (August 5-7) that may be of interest: 1. DiLaura, David L. 1996. "Non-Diffuse Radiative Transfer III: Inhomogeneous Planar Area Sources and Point Receivers." 2. DiLaura, David L., and Scott Santoro. 1996. "Non-Diffuse Radiative Transfer IV: General Procedure for Planar Area Sources and Area Receivers." 3. Nievergelt, Y. 1996. "Making Any Radiosity Matrix Symmetrix Positive Definite." You can obtain preprints of David's papers as pub/Illumination/ non_diff_contour_3.ps and pub/Illumination/non_diff_contour_4.ps from civil.colorado.edu. As for Nievergelt's paper, I am not aware of it being available online. If it isn't, you might want to obtain a copy of the 1996 IESNA Annual Conference Technical Papers that are supposed to be available in mid-June. Check http://www.iesna.org for details -- they are generally not available after the conference is over. (If it's anything like the past few years, the publication will be over 1,000 pages and cost about $125 US.) Ian Ashdown, P. Eng. | READ THE BOOK! Research & Development Manager | Radiosity: A Programmer's Perspective Ledalite Architectural Products Inc. | by Ian Ashdown | John Wiley & Sons, 1994 Visit http://www.ledalite.com | (Sneaky Internet Advertising) From owner-globillum@imag.fr Thu Jun 27 08:46:17 1996 Return-Path: From: Alexander Keller AG Heinrich Subject: Quasi-Monte Carlo Radiosity To: globillum@imag.fr Date: Thu, 27 Jun 1996 15:45:22 +0200 (MET DST) Status: R Hi ! The extended version of my Eurographics Workshop on Rendering contribution is now available on the net via: http://www.uni-kl.de/AG-Heinrich/Alex.html and then clicking the "publications and reports" link. Besides the 18-pages version (instead of 10), you will find related work from the field of quasi-Monte Carlo methods. Any comments or discussions about the work are welcome. Best regards, Alex -- Alexander Keller, Tel.: +49-631-205-3345, Fax.: +49-631-205-3270 Dept. of Computer Science, University of Kaiserslautern Postfach 3049, D-67653 Kaiserslautern, Germany e-mail: keller@informatik.uni-kl.de, URL: http://www.uni-kl.de/AG-Heinrich/ From owner-globillum@imag.fr Wed Jul 3 22:36:31 1996 Return-Path: From: Andrew Glassner To: "'globillum@imag.fr'" , "'Reetinder Pal Sidhu'" Subject: RE: Graphics Gems Date: Wed, 3 Jul 1996 21:30:25 -0700 Encoding: 22 TEXT Status: RO I believe that there will not be any more volumes in the Gems series. You may wish to instead consider the Journal of Graphics Tools, which is a new quarterly journal for small and practical graphics methods. The first issue or two will be available at Siggraph. Check out http://www.acm.org/jgt/ -Andrew Glassner http://www.research.microsoft.com/research/graphics/glassner/ >---------- >From: Reetinder Pal Sidhu[SMTP:sidhu@halcyon.usc.edu] >Sent: Wednesday, July 03, 1996 4:14 PM >To: globillum@imag.fr >Subject: Graphics Gems > >Does anyone know if another book in the Graphics Gems series is in the >works? Please let me know if you have any idea who should be contacted >for submitting contributions to it. Thank you. > > Reetinder Sidhu > From owner-globillum@imag.fr Thu Jul 4 05:26:32 1996 Return-Path: Sender: ajc@imag.fr Date: Thu, 04 Jul 1996 10:52:16 +0100 From: "Adrian J. Chung" Organization: Dept. of Computing, Imperial College To: globillum@imag.fr Subject: Book Reviews Status: RO (Warning: I'm new to this list...) I'm surveying a cross section of research publications in global illumination and have come across a few candidates for what I'd consider to be "the bible" for this field (in the same sense that the Foley & Van Dam book is for CG in general). I'd like to hear your opinions on the matter. I've skimmed through the past archived communications for globillum in case this was already discussed, but it doesn't seem to have been recently. So... Andrew S. Glassner: Priciples of Digital Image Synthesis Is it well worth the US$90? How much does it cost in the UK? I'm considering diverting a portion of my student grant toward acquiring the two volume set. (Fewer beers on weekends, looks like...) How does it compare to the less expensive alternatives: Franois X. Sillion & Claude Puech: Radiosity and Global Illumination Michael F. Cohen & John R. Wallace: Radiosity and Realistic Image Synthesis ...any others I should know about? Adrian -- If you think in seasons, plant crops. If you think in decades, plant trees. If you think in centuries, educate your children. Confucious From owner-globillum@imag.fr Wed Jul 10 22:22:50 1996 Return-Path: To: globillum@imag.fr From: iashdown@ledalite.com (Ian Ashdown) Subject: Re: Book Reviews Date: Wed, 10 Jul 1996 21:53:04 -0800 Status: R On Thu, 04 Jul 1996 10:52:16, Adrian J. Chung wrote: >I'm surveying a cross section of research publications in global illumination >and have come across a few candidates for what I'd consider to be "the bible" >for this field (in the same sense that the Foley & Van Dam book is for CG in >general). I'd like to hear your opinions on the matter. I've skimmed through the >past archived communications for globillum in case this was already discussed, >but it doesn't seem to have been recently. So... > In my very humble opinion, the definitive bible on global illumination has yet to be written. One good reason for this is that global illumination research is still a very active topic. There have been close to 100 global illumination papers and theses released in the past six months alone. Given that it takes 12 to 18 months to get a book written and published, any "bible" will be at least a year out of date as soon as it is released. >Andrew S. Glassner: Principles of Digital Image Synthesis > >Is it well worth the US$90? How much does it cost in the UK? >I'm considering diverting a portion of my student grant toward acquiring the two >volume set. (Fewer beers on weekends, looks like...) > Knowing how much one publisher in particular marks up its books for the UK market, I shudder to think how much the two-volume set will cost you. You may have to give up beer for the remainder of your academic career :+) For what it's worth, I much prefer Glassner to Foley et alia as my primary CG reference. However, I can appreciate that many undergraduate students may be intimidated by the mathematical depth of the former. Different strokes ... >How does it compare to the less expensive alternatives: > >Francois X. Sillion & Claude Puech: Radiosity and Global Illumination > >Michael F. Cohen & John R. Wallace: Radiosity and Realistic Image Synthesis > It all depends on your needs and interests, and also on whether you are interested in (and enjoy) the mathematical details. I have all three, and I can recommend any of them. >...any others I should know about? > I haven't had the opportunity to read this book, but you might try: Kok, Arjan J. F. 1994. "Ray Tracing and Radiosity Algorithms for Photorealistic Image Synthesis," Delft University Press, Stevinweg 1, 2628 CN Delft, The Netherlands, ISBN 90-6275-981-5. (Also available from Coronet Books, Philadelphia.) This was Arjan's PhD thesis at the Delft University of Technology. There have been at least two other books written on radiosity, but neither qualify as global illumination "bibles." Actually, the best sources of up-to-date and comprehensive information on global illumination techniques are the most recent MSc and PhD theses, many of which are available online. PhD theses in particular are great -- the poor students are required to demonstrate their in-depth knowledge of the field, which generally means a 50-page prologue to their actual research topic, and a bibliography with at least 50 references. For a complete listing ... ah heck, you know where to find my bibliography ;+> Ian Ashdown, P. Eng. | READ THE BOOK! Research & Development Manager | Radiosity: A Programmer's Perspective Ledalite Architectural Products Inc. | by Ian Ashdown | John Wiley & Sons, 1994 Visit http://www.ledalite.com | (Sneaky Internet Advertising) From owner-globillum@imag.fr Thu Jul 11 14:01:55 1996 Return-Path: From: "Nelson L. Max" Date: Thu, 11 Jul 1996 11:36:17 -0700 To: globillum@imag.fr Subject: Report on Dagstuhl and Porto rendering conferences. Status: R The following is a report on three conferences I attended. I am broadcasting it because it contains summaries of several papers that may not appear for a while in more widely read venues. I appologize if your paper was not mentioned. Only the first two conferences were on rendering, so you might want to skip the stuff about the last one, though my summaries for it are mostly restricted to rendering-related talks. My first stop was the University of Kaiserslautern, where I visited the research laboratory of Hans Hagen. Hans arranged for a schedule of demonstrations and discussions with his graduate students, and arranged for them to take me out to lunch and dinner in town (I paid for my food, but they provided the transportation and the company, which was a nice form of hospitality.) I was impressed with Hans' personal research in the design of plastic reflector and lens shapes for car headlights, to give a desired distribution of illumination intensity on the road. I also had a long discussion with Alexander Keller, who explained to me in detail the Quasi-Monte-Carlo method he was using for global illumination, which he presented at both of the next two meetings. He gave me the longer"uncut" version of his paper, so I was able to appreciate well the fact that certain non-random sequences of test points give estimates that converge much faster than for random test points. A final memorable project was a method where potential purchasers could design and view semi-custom prefabricated homes over the Internet. The meeting in Schloss Dagstuhl was one of a series of week-long seminars in aspects of Computer Science partially supported by the governments of Germany and the state of Saarbrucken. The topic of this seminar was rendering, and it was scheduled to just precede the Eurographics workshop the following week. The hope was that attendees from outside Europe would gain efficiency in their long distance travel plans, which was the case for me, but many Europeans could not afford more than a week away from their institutions, especially if they were teaching, so the attendance at the Eurographics Workshop was actually down from last year. A summary of the some of talks follows. Xavier Pueyo proposed methods for generating random densities of infinite lines in space, and intersecting each line with all objects in the scene to get form factor contributions from each segment in the space between two object surfaces. He chose his lines by connecting two random points on the surface of a sphere enclosing all the objects, and I later pointed out that this will not give the correct density because it is missing a cosine term. Dani Tost discussed her work on visualizing blood vessels, involving both maximum intensity projection and shading, with voxel splats. Henrick Wann Jensen's talk on "Global Illumination using Photon Maps" generated the most excitement and discussion of the seminar, because of the impressive performance of his method, which is based on saving in a spatial data structure (a KD tree) both position and direction of all hits by photon paths traced from light sources through multiple random bounces. During viewpoint dependent rendering, these are used for the intensity at the second bounce in a local pass from the eye, by expanding a sphere about the hit point until the n closest photon hits are found in the KD tree. At the first bounce from the eye, the same distribution is used for importance sampling of the bounced rays. Finally, the initial rays from the light source are continued past their first surface intersection to create shadow maps at subsequent intersections, which are used to decide when shadow feelers are necessary to determine direct illumination. Since the incoming directions are available, non diffuse reflections can be rendered. A separate caustic map, with many more photons directed at only the shiny surfaces, is used similarly at the first bounce in rendering. Dani Lischinski gave a preview of a Siggraph paper on "Hierarchical Image Caching for Accelerated Walkthroughs of Complex Environments." Robert Garmann talked on the computational complexity of hierarchical radiosity, and gave a careful analysis of the number of links required in a simple scene with two parallel plane patches, in which the subdivision oracle is based on the total form factor of a link. He showed that the total number of links, as the allowed error approaches zero, is of order O(N^2), where N is the number of leaf nodes in the hierarchical subdivision. This seems to contradict previous beliefs that it would be O(N log N), or even O(N). Dieter Fellner, working with Stefan M|ller's group at Darmstadt, showed how real time rendering of radiosity scenes could be accomplished on environments with the order of a million polygons, and presented an impressive video of additions to the Frankfort airport. Wolfgang St|rzlinger talked about using hierarchical radiosity links in the local pass (final one bounce gather to the viewpoint) by doing a Weiler-Atherton type subdivision of the unit hemisphere, using 3D coordinates of the unit vectors, in order to determine the links involved at a pixel. Mark Summinger from Erlangen University talked about decoupling the reflection and transport operators in a progressive radiosity framework for non diffuse surfaces. The shot and transported energy is saved in a data structure which is indexed by both receiving position and angle bins. The advantage is that when it is time to shoot for a patch, all the energy in an incoming angle bin can be reflected at once, which requires fewer evaluations or accesses to the BDRF. The abstracts to these talks were handwritten into a Dagstuhl record book, and are being transcribed to be sent to the participants and saved at Dagstuhl. The proceedings of the next conference I attended, the 7th Eurographics Workshop on Rendering, at Porto, Portugal, will be published rapidly by Springer. At Porto, (and also at Dagstuhl) I spoke on "Hierarchical Rendering of Trees from Precomputed Multi-Layer Z-Buffers". This is based on reprojecting images of trees and their subparts, prerendered from different viewpoints (image based rendering). Fabrice Neyret gave a related paper which had an impressive video of a flight over a forest, produced by ray tracing hierarchical (mip mapped) volume textures with an ellipsoidally approximated surface normal distribution at each voxel. Fredo Durand, George Drettakis, and Claude Puesch gave a speculative talk on an unimplemented method of dividing the 4D space of all lines in 3D up into regions where the visibility along the ray is constant. To deal with rays which have multiple segments in the free volume between objects, they use and extra discrete dimension to index the segments, but the space of such segments still has only 4 real parameters for a fixed scene. They discuss the various lower dimensional manifolds of visibility change events that divide this space into regions of homogeneous visibility, and show why the resulting data structure is of size O(n^4), where n is the number of polygon edges, and can be constructed by a sort and sweep algorithm in time O(n^4 log n). This is considerably better than the aspect graph, of size O(n^6), because the aspect graph computes for each viewing direction (or viewpoint) the intersection of the 2D pencil of lines making up the image, with this subdivision of the 4D space of all lines.Eric Veach pointed out that in the case of caustic maps under water, and the case of bump mapped shading normals differing from the normals of the surfaces which intercept the light transport rays, non symmetric scattering functions (BDRFs or BDTFs) must be used, which do not satisfy reciprocity, and therefore act differently when light energy or importance are being transported, or equivalently, act differently for the two directions in bidirectional path tracing (photon paths and viewing paths). Stephen Hardt and Seth Teller from MIT showed how the rendering pipeline and texture mapping hardware with perspective correction of a high end workstation could be cleverly used to produce accurate radiosity rendering at interactive rates by fitting the radiosity off-line (ahead of time) by quadratic triangular patches, and then using the hardware polygon renderer to deposit at each pixel the polygon ID and two barycentric coordinates in the triangle. They use the perspective correction in the texture mapper to get the barycentric coordinates accurately. With Michael Allison, I showed in Graphic Gems III how the barycentric coordinates could be stored in color fields, using only the Gouraud shading interpolation hardware, if perspective corrections are not needed. The radiosity is then computed in software as a quadratic polynomial in the two barycentric coordinates, with coefficients indexed by the polygon ID. Jos Stam and Eric Languinou spoke about ray tracing in non-constant media (mirages). Eric Lafortune and Yves Willems extended bidirectional path tracing to the case of 3D volumes with participating media (smoke, steam, or clouds). George Dretakis and Francois Sillion spoke on incorporating discontinuity meshing into hierarchical quadtree meshes, which allows large quadtree cells on homogeneous unoccluded regions; previous discontinuity meshes based on BSP trees had unnecessarily long edges crossing into regions beyond the discontinuities that defined them. I spent the 6 days between the Porto and Chamonix conferences on vacation in Portugal, cycling with my wife Mika from Coimbra to Alcobaca, on bicycles kindly loaned by the local conference organizer, Augusto de Sousa, because there were no bicycle rental shops in northern Portugal. The final day before the Curves and Surfaces conference began was spent travelling from Porto to Chamonix. The topics of the Chamonix conference were less familiar to me, being weighted towards approximation theory based on functional analysis on Sobelov spaces (I still haven't figured out what theses are) and wavelets. I attended because Greg Nielson invited me to give a talk at a Mini-symposium he organized an Scientific Visualization. I spoke on "Applications of Texture Mapping to Volume and Flow Visualization," giving in 25 minutes almost all the content of the version I also earlier presented at the University of Kaiserslautern in 65 minutes. In the same session, Marcus Gross gave a talk on "Finite Element Modelling and Visualization for Facial Surgery," in which the soft tissues between the bone and skin are modelled by finite elements, whose deformation is simulated as bones are cut and displaced, so that the final appearance of the face can be displayed before the operation is carried out. There were 6 days of mostly 3 parallel sessions of 25 minute talks form 8:30 AM until 6:30 PM (with a 2 hour break for lunch, and two half hour coffee breaks) for 6 conference days, which made for a pretty grueling schedule. I attended most of the time, but admit to "playing hooky" for two mornings in order to enjoy the mountain scenery. I probably absorbed some approximation theory by osmosis, especially from an excellent Mini-symposium on non-linear and adaptive wavelet approximation, including talks by Yves Meyer on the bump algebra, by S. Mallet on Image Compression, emphasizing the quantization and coding of the wavelet or basis coefficients, and the coding of the position indices of the non-zero coefficients, as well as just which coefficients can be set to zero, and by Ron DeVore on adaptive numerical methods for partial differential equations. There was also an interesting talk by A. Pinkus on approximating by ridge functions, the set of finite linear combinations of ridges, which are "long crested waves" of one linear parameter in 2 or 3 dimensions. There were many talks on extending the ideas of wavelets from the plane to arbitrary 2-manifolds, and in particular, to the 2-sphere. Beyond these approximation theory talks, the talks I understood best were on surface shape. There were a couple of talks on developable surfaces, which are important in manufacturing because they can be formed from sheet metal without stretching. An invited talk by Joseph Hoschek on interpolation and approximation with developable surfaces gave an example of designing the blank holder in a sheet metal forming process. This is the part of the mold which should first clamp the sheet, without stretching it, and hold it while the part of the deformation involving more severe stretching deformations takes place. Another talk by Y. L. Kergosian analyzed the folds and cusps where a developable surface can have singularities, and simulated them for the case of a bent tin can, generating impressively realistic images. There was also a Mini-symposium on Multiresolution Methods in Computer Graphics, including the following talks. Richard Bartels talked on hierarchical splines. Peter Scrhvder spoke on spherical wavelets, and showed his Siggraph '95 images. After hearing it for the nth time, I finally understood the idea behind lifting. R. Westerman described his wavelet-based volume rendering, in which the wavelets are used only for determining the appropriate adaptive sampling frequency along a ray and for reconstructing the samples, for a traditional opacity accumulation algorithm. Thus full opacity effects are possible, in contrast to faster algorithms which try to precompute the splats of each wavelet, and therefore cannot account for interwavelet opacity effects. David Salesin presented three multiresolution techniques from his past and future Siggraph papers: image editing, image querying, and multiresolution video "clip art". -- Nelson Max http://www.llnl.gov/graphics max2@llnl.gov Lawrence Livermore National Laboratory (510) 422-4074 7000 East Avenue fax (510) 423-8704 Livermore, CA 94550, USA From owner-globillum@imag.fr Fri Jul 12 06:10:12 1996 Return-Path: Date: Fri, 12 Jul 1996 12:44:16 +0100 (WET DST) From: Carlos Urena Almagro To: "Nelson L. Max" Cc: globillum@imag.fr Subject: Re: Report on Dagstuhl and Porto rendering conferences. Status: RO On Thu, 11 Jul 1996, Nelson L. Max wrote: > Xavier Pueyo proposed methods for generating random densities of infinite > lines in space, and intersecting each line with all objects in the scene to get > form factor contributions from each segment in the space between two object > surfaces. He chose his lines by connecting two random points on the surface of > a sphere enclosing all the objects, and I later pointed out that this will not > give the correct density because it is missing a cosine term. Some years ago, when Sbert & Pueyo showed me their method, I though about this objection, because it seems counter-intuitive that this selection of points on the sphere induces the correct density. But later I was convinced of it's correctnes, both by estimating that way form-factors whose value was analiticaly known a priori, and by formal derivations from results in Integral Geometry theory. There is a formula on Santalo's book about Integral Geomtery which gives the density of the points of intersection of a convex object with lines of constant density in 3D. When instancing the convex object to a sphere, the density for intersections points becomes uniform. This is so because the formula involves the diferential poin-to-point form factor between the two intersection points of each line, an this value, in the case of a sphere, is a constant which only depends on sphere's radius. You can check this by seeing the internal angles of a triangle whose vertexs are these two points and the center of the sphere. The refered formula is at the bottom of page 230 of: Integral Geometry and Geometric Probability. Luis A. Santalo. Addison-Wesley, 1976. Sincerely yours, Carlos Urena. _____________________________________________________________________________ Carlos Urena Almagro e-mail : almagro@goliat.ugr.es Dpto. de Lenguajes y Sistemas Informaticos voice : +34 58 243178 ETS Ingenieria Informatica Universidad de Granada From owner-globillum@imag.fr Mon Jul 15 11:24:44 1996 Return-Path: From: "Nelson L. Max" Date: Mon, 15 Jul 1996 09:20:30 -0700 To: globillum@imag.fr Subject: Correction to Report on Dagstuhl and Porto rendering conferences Cc: almagro@goliat.ugr.es, xavier@ima.udg.es Status: RO I had claimed that the method used by Xavier Pueyo to generate uniformly distributed lines inside a sphere, by joining pairs of points randomly distributed on the sphere's surface, was incorrect, but Carlos Urena Almagro has pointed out that it is I who was mistaken. My reasoning was as follows. If uniformly distributed lines in a certain fixed direction w intersect the unit sphere, they will not be uniformly distributed on the surface area. Instead, lines making an angle of t with the surface normal at their point of intersection will be less dense by a factor of cos t, as in the geometrical reasoning behind Lambert's law. However, I neglected to consider the solid angle effect. It turns out that the chord length of the ray segment between sphere surface intersection points A and B, is twice cos t. Therefore, the solid angle intercepted by a surface area ds at A, as measured at B, is (ds cos t)/(2 cos t)^2 = ds/(4 cos t). The cos t in the denominator here cancels the cos t for the Lambert area distribution factor at B, so that the number of rays within an element ds dw, of differential area ds normal to the beam and differential solid angle dw, is constant. (The cos t for the Lambert factor at A is already present in the numerator at the left side of the above equation.) -- Nelson Max http://www.llnl.gov/graphics max2@llnl.gov Lawrence Livermore National Laboratory (510) 422-4074 7000 East Avenue fax (510) 423-8704 Livermore, CA 94550, USA From owner-globillum@imag.fr Fri Jul 26 12:06:59 1996 Return-Path: From: cn1@irz301.inf.tu-dresden.de (Nguyen, D.C.) Subject: Comments for Diplom-Thesis To: globillum@imag.fr (Global Illumination List) Date: Fri, 26 Jul 1996 20:03:39 +0200 (MESZ) Status: RO Hi, The prereleased version of my diplom (in german!) could be found at: http://www.rz.tu-ilmenau.de/~juhu/Diplom/juhudip.ps.gz Be warned!(I've spend 1 year for hacking, but only 1 week for writing..:) Below are some highlights of this work: -Improvements for classical speedup-methodes, i.a: - the use of coherence for speedup-methodes (1D,2D,3D,5D) - projected area weighted, object intersection cost weighted ABVH - balanced BSP (to avoid the "Teapot in a football stadium" problem) - adaptive, "on the fly" subdivided Vista/Light-Buffer, applicable for volume-lightsources and extended cameras (There is a methode to avoid the "exhaustive classification/reclassification" effects, caused by Monte-Carlo-rays bundles near a big lightsource) - 5D Ray Classification for groups of pointlightsources or for a volume-lightsource w/ complicated shape -Comparisons: - Heuristics for efficiencies/defficienies of classical methodes - How to determine the complexity of a scene ? - What methode is best (hehe) ? -Hybrid-speeedup: - When to use, and how ? - Implemention of some hybrid shemes, such as hybrid-subdivision, local optimizaion for shadow/eye-rays (adaptive Vista/Light-Buffer for eye/shadow rays balaced BSP for secondary rays), generalized Polymorph-Caching etc.. - Some speculations on hybrid-methodes, not much infomative... I would like to hear your comments on this work....Thanks in advance, --JuHu /\__ Nguyen Duc Cuong (aka JuHu) - CG-student +- / -> Home /__\ \ EMail : juhu@rz.tu-ilmenau.de +- /GX -> GX/GENERIC \__/ WWW : http://www.rz.tu-ilmenau.de/~juhu -+- /GX/RTEvol -> RTEvol From owner-globillum@imag.fr Fri Aug 30 16:01:30 1996 Return-Path: From: danix@cs.washington.edu (Dani Lischinski) Subject: terminology question To: globillum@imag.fr Date: Fri, 30 Aug 1996 15:13:31 -0700 (PDT) Status: R Hi globillumers, Is there a name for incoming flux per unit PROJECTED area? Note that this is different from irradiance (incoming flux per unit area). If there's a name, is there also a symbol or letter commonly used to represent this quantity? Thanks a bunch, Dani From owner-globillum@imag.fr Fri Aug 30 17:10:30 1996 Return-Path: Date: Fri, 30 Aug 1996 16:20:35 -0700 (PDT) To: globillum@imag.fr From: iashdown@ledalite.com (Ian Ashdown) Subject: Re: terminology question Status: R >Hi globillumers, > >Is there a name for incoming flux per unit PROJECTED area? >Note that this is different from irradiance (incoming flux >per unit area). If there's a name, is there also a symbol >or letter commonly used to represent this quantity? > >Thanks a bunch, > The lighting community's bible, ANSI/IES RP-16, "Nomenclature and Definitions for Illuminating Engineering," neatly sidesteps this issue by saying in Clause 3.3 (which admittedly refers to illuminance rather than irradiance) that the surface "need not be a physical surface; it may also be a mathematical plane." In other words, their definition of irradiance/illuminance applies both to physical surfaces and imaginary surfaces (which can include those normal to the direction of the incident flux). You might find what you are looking for in Moon and Spencer's "The Photic Field" (MIT Press, 1981), where I think they called it "pharosage." However, adopting any of Parry Moon's terminology (apart from his "radiosity") is an open invitation to be ignored by the old guard in the IESNA :+) Ian Ashdown, P. Eng. | READ THE BOOK! Research & Development Manager | Radiosity: A Programmer's Perspective Ledalite Architectural Products Inc. | by Ian Ashdown | John Wiley & Sons, 1994 Visit http://www.ledalite.com | (Sneaky Internet Advertising) From danix@cs.washington.edu Sat Aug 31 11:55:10 1996 Return-Path: From: danix@cs.washington.edu (Dani Lischinski) Subject: Re: terminology question To: greg@hobbes.lbl.gov (Gregory J. Ward) Date: Sat, 31 Aug 1996 11:54:50 -0700 (PDT) Status: RO Thanks Greg, that would be great. My fax number is (206) 543-2969 Please make sure that my name is on the first page, so they would know whose mailbox to stick the fax into. Thanks again, Dani > > I can fax you a handy reference that makes this a whole lot clearer than > my babblings. What's your fax number? > > -Greg > From owner-globillum@imag.fr Mon Sep 2 11:05:48 1996 Return-Path: From: Neil Gatenby Date: Mon, 2 Sep 96 16:57:55 BST To: globillum@imag.fr Subject: goniometric file formats Status: RO Hi globillum folk; I have a question regarding file formats used to store luminaire goniometric data; any help would be much appreciated. Which file formats are in common useage in Japan and Germany? I know the UK is keen on CIBSE. I know the US is keen on IESNA. I know a little about the CIE format (what I've read in Glassner's "Principles ...") But, I don't know what's popular in these two large market areas. Thanks in advance Neil Neil Gatenby, | LightWork Design, Senior Graphics Programmer, | 60 Clarkehouse Road, email: neil@lightwork.co.uk | Sheffield, S10 2LH, England. voice: (+44) (0)114 266 8404 ..... fax: (+44) (0)114 266 1383 From owner-globillum@imag.fr Tue Sep 3 14:40:16 1996 Return-Path: Date: Tue, 3 Sep 1996 13:29:10 -0700 (PDT) To: globillum@imag.fr From: iashdown@ledalite.com (Ian Ashdown) Subject: Global illumination bibliography update Status: R ANNOUNCE: 96/09/01 Release of RADBIB96 -------------------------------------- RADBIB96 is a comprehensive bibliography of radiosity and related global illumination papers, theses, articles, and books. A total of 41 new references have been added since its last release on July 1, 1996, bringing the total to 975 references. This bibliography is available in refer format (ASCII text) as RADBIB96.TXT (with a release date of September 1, 1996) from: http://www.ledalite.com/library-/rrt.htm and as compressed RadBib96.Z from: ftp://hobbes.lbl.gov/pub/doc A gzip-compressed BibTex-format version is available from: ftp.cs.columbia.edu/archives/bibliographies/Graphics/rad.html but it may be a previous release. As always, it is time-consuming and sometimes difficult to track down conference papers and theses on radiosity and global illumination. If you know of a relevant reference that is not included in the bibliography, please let me know so that I can include it in the next release. From owner-globillum@imag.fr Fri Sep 6 07:36:20 1996 Return-Path: From: jpt@btc.uwe.ac.uk Date: Fri, 6 Sep 96 14:23:06 BST To: globillum@imag.fr Subject: Voxel neighbours in octrees Status: R Hello colleagues I have a problem relating to finding neighbouring voxels in octrees and feel sure this must have been addressed previously. I want to be able to find all the neighbouring (adjacent in space) voxels from a given voxel stored in an octree. It seems feasible that an operation based on traversal of the octree will allow neighbouring voxels to be discovered. Thanks in advance for any assistance john -------------------------------------------------------------------------- Jonathan Tidmus jpt@ics.uwe.ac.uk Researcher Intelligent Computer Systems Centre phone: +44 (0)117 9656261 ext 3357 University of the West of England fax: +44 (0)117 9750416 Bristol BS16 1QY From owner-globillum@imag.fr Fri Sep 6 09:06:53 1996 Return-Path: From: Francois Sillion Subject: Re: Voxel neighbours in octrees To: jpt@btc.uwe.ac.uk Date: Fri, 6 Sep 1996 16:45:18 +0200 (MDT) Cc: globillum@imag.fr Reply-To: Francois.Sillion@imag.fr Status: R > Hello colleagues > > I have a problem relating to finding neighbouring voxels in octrees and > feel sure this must have been addressed previously. > > I want to be able to find all the neighbouring (adjacent in space) voxels > from a given voxel stored in an octree. It seems feasible that an > operation based on traversal of the octree will allow neighbouring > voxels to be discovered. > I have only done it with quadtrees, but I believe that you will find simple code that does precisely that in one of H. Samet's book on hierarchical data structures. @book{Samet90, author = {Hanan Samet}, title = {The Design and Analysis of Spatial Data Structures}, publisher = {Addison-Wesley}, address = {Reading, Massachusetts}, year = {1990} } @book{Samet, author = {Hanan Samet}, title = {Applications of Spatial Data Structures}, publisher = {Addison-Wesley}, address = {Reading, Massachusetts}, year = {1990} } +------------------+------------------------------------------------------+ | Francois SILLION | iMAGIS - GRAVIR/IMAG, B.P. 53, 38041 Grenoble Cedex 9| | ' | France. Tel:(+33) 76 51 43 54 - Fax:(+33) 76 44 66 75| +------------------+----------+-------------------------------------------+ | Francois.Sillion@imag.fr | http://w3imagis.imag.fr/~Francois.Sillion | +-----------------------------+-------------------------------------------+ From owner-globillum@imag.fr Fri Sep 6 14:50:51 1996 Return-Path: From: Paul.Heckbert@hostess.graphics.cs.cmu.edu Date: Fri, 6 Sep 96 17:03:59 EDT To: Francois.Sillion@imag.fr, glassner@microsoft.com, jpt@btc.uwe.ac.uk Subject: RE: Voxel neighbours in octrees Cc: globillum@imag.fr Status: R One of the methods that Samet describes does not require neighbor pointers (although that is certainly one way to do it), but instead you ascend the tree until you can step in the direction you want, then you descend the tree, staying as close spatially to the previous point as possible, until you hit a leaf, or get to the level of the tree that you desire. With this method, you don't need neighbor pointers, just 8 child pointers and 1 parent pointer. Samet shows, as I recall, that you go up and down 2 times, on average, i.e. that the average cost to find a neighbor is O(1). If you found neighbors by starting at the root every time, it would cost O(depth). >> jpt@btc.uwe.ac.uk >> >> I have a problem relating to finding neighbouring voxels in octrees and >> feel sure this must have been addressed previously. Paul Heckbert Computer Science Dept., Carnegie Mellon University 5000 Forbes Ave, Pittsburgh PA 15213-3891, USA ph@cs.cmu.edu http://www.cs.cmu.edu/~ph From owner-globillum@imag.fr Sat Sep 7 06:16:06 1996 Return-Path: From: Slawomir Kilanowski To: "'globillum list'" Date: Sat, 7 Sep 1996 14:07:21 +-200 Status: RO Dear Collegues, I am working on speed-up of global illumination calculations and ray tracing for scenes containing huge number of lights. Except some visibility pre-processing I would like to limit number of considered lights for given space points doing some "light importance" pre-processing. The tempting idea is to partition scene space into regions tied with ordered lists of lights that can influence them, then, during calculation, process only those "significant" lights in order of their importance. I have browsed RadBIB and ACM Siggraph bibliographies but I have not found any related papers. Have I missed something important ? Does anybody know about some previous work on such or similar concepts ? Thanks in advance, Slawek ================================================================ Slawomir Kilanowski metagram@wro.ternet.pl METAGRAM, Swieradowska 73/23, 50-559 Wroclaw, Poland Phone/Fax : +48-(71)-731519 ================================================================ From owner-globillum@imag.fr Sat Sep 7 14:16:38 1996 Return-Path: From: Marcos Fajardo Orellana To: "'globillum@imag.fr'" Subject: RE: Date: Sat, 7 Sep 1996 21:02:51 +-200 Status: RO Slawomir Kilanowski wrote: >Dear Collegues, > > I am working on speed-up of global illumination calculations and ray tracing for scenes >containing huge number of lights. Except some visibility pre-processing I would like to >limit number of considered lights for given space points doing some "light importance" >pre-processing. The tempting idea is to partition scene space into regions tied with >ordered lists of lights that can influence them, then, during calculation, process only >those "significant" lights in order of their importance. > > I have browsed RadBIB and ACM Siggraph bibliographies but I have not found any >related papers. Have I missed something important ? Does anybody know about some >previous work on such or similar concepts ? > >Thanks in advance, > >Slawek I think these two papers could be of interest to you, Ward, Gregory, "The RADIANCE Lighting Simulation and Rendering System," Computer Graphics, pp. 459-472, July 1994 Ward, Gregory, "Adaptive Shadow Testing for Ray Tracing," Second EUROGRAPHICS Workshop on Rendering, Barcelona, Spain, April 1991 Peter Shirley has some excellent work on sampling light sources as well. This one is on-line (check out his homepage at http://www.cs.utah.edu/~shirley ), Shirley, Peter, "Direct Lighting Calculation by Monte Carlo Integration," Second EUROGRAPHICS Workshop on Rendering, June 1991 (?) Hope this helps Marcos http://www.geocities.com/TimesSquare/2143 From owner-globillum@imag.fr Mon Sep 9 05:04:52 1996 Return-Path: Date: Mon, 9 Sep 96 11:34:09 BST From: Simon Gibson To: globillum@imag.fr Subject: Re: Status: RO Slawomir Kilanowski wrote: >Dear Collegues, > > I am working on speed-up of global illumination calculations and ray tracing for scenes >containing huge number of lights. Except some visibility pre-processing I would like to >limit number of considered lights for given space points doing some "light importance" >pre-processing. The tempting idea is to partition scene space into regions tied with >ordered lists of lights that can influence them, then, during calculation, process only >those "significant" lights in order of their importance. > > I have browsed RadBIB and ACM Siggraph bibliographies but I have not found any >related papers. Have I missed something important ? Does anybody know about some >previous work on such or similar concepts ? > >Thanks in advance, > >Slawek You might want to check out: %A Kurt Zimmerman %A Peter Shirley %T A Two-Pass Realistic Image Synthesis Method for Complex Scenes %E P. M. Hanrahan %E W. Purgathofer %B Rendering Techniques '95 (Proceedings of the Sixth Eurographics Workshop on Rendering) %I Springer-Verlag %C New York, NY %D 1995 %P 284-295 %O ISBN 3-211-82733-1 available as an Indiana University Technical Report - ftp://ftp.cs.indiana.edu/pub/techreports/TR434.ps.Z Simon - From owner-globillum@imag.fr Mon Sep 9 12:08:34 1996 Return-Path: From: ml@bug.cophos.co.at (Martin Lob) Subject: Re: goniometric file formats To: globillum@imag.fr Date: Mon, 9 Sep 1996 19:51:29 +0200 (CETDST) Reply-To: ml@cophos.co.at Organization: Cophos Development Team, Zumtobel Licht, Dornbirn, Austria Phone: +43-5572-390-1383 Fax: +43-5572-390-246 Status: R Neil Gatenby wrote ... | From: Neil Gatenby | Date: Mon, 2 Sep 96 16:57:55 BST | Message-Id: <28453.9609021557@lightwork.co.uk> | To: globillum@imag.fr | Subject: goniometric file formats | | | Hi globillum folk; | | I have a question regarding file formats used to store luminaire | goniometric data; any help would be much appreciated. | | Which file formats are in common useage in Japan and Germany? In Germany the EULUMDAT format is used. It was introduced by Axel Stockmar. A copy of the format description aswell as files in EULUMDAT are available from ZUMTOBEL. | | I know the UK is keen on CIBSE. | I know the US is keen on IESNA. | I know a little about the CIE format (what I've read in Glassner's | "Principles ...") | | But, I don't know what's popular in these two large market areas. | | Thanks in advance | Neil | | Neil Gatenby, | LightWork Design, | Senior Graphics Programmer, | 60 Clarkehouse Road, | email: neil@lightwork.co.uk | Sheffield, S10 2LH, England. | voice: (+44) (0)114 266 8404 ..... fax: (+44) (0)114 266 1383 | -- \|/ ml@cophos.co.at http://www.cophos.co.at/~ml --O-- /|\ l Tel.: +43/5572/390-1383 ___ ___ m mmm mmm l Fax : +43/5572/390-650 / __\ /__ \ mm m m l ZUMTOBEL Licht GmbH / / \ / \ mm m m l Schweizerstr. 30 / / \ / \ m m m l A-6850 DORNBIRN | | \ m m martin . lob . Austria | | :-Q | | Prediction is very difficult, especially of the future! | | n_u__n___ From owner-globillum@imag.fr Mon Sep 9 15:46:23 1996 Return-Path: Date: Mon, 9 Sep 1996 14:46:14 -0700 From: Alain Fournier To: alz@lsil.com, globillum@imag.fr Subject: Re: spatial subdivision Status: R You might find useful a look at Fournier, A., and Poulin, P., ``A Ray Tracing Accelerator Based on a Hierarchy of 1D Sorted Lists'', Proceedings of GI '93, Toronto, May 1993, pp. 53-61. We used a hierarchy of bounding boxes aligned with the axes. This of course determines an irregular grid on the scene, which is traversed by listing events (entering and exiting a box) in 1D lists (one per coordinates). Many interesting conclusions, but the first one: "it's hard to beat regular grid subdivision". From owner-globillum@imag.fr Mon Sep 9 16:06:37 1996 Return-Path: Date: Mon, 9 Sep 1996 15:07:07 -0700 From: "Samuel P. Uselton" To: alz@lsil.com Cc: globillum@imag.fr Subject: Re: spatial subdivision Reply-To: uselton@nas.nasa.gov Status: R I had an MS student who did a thesis on the topic many (7? 8?) years ago. The main paper got turned down for SIGGRAPH. The student took a job and I left academia, so we never got the "improved" version completed and accepted anywhere. However, a description of a hardware accelerator for it was accepted in a small conference. The student who did this work was Scott Senften (this year's SIGGRAPH Tutorial's chair); you should be able to reach him at scott@lgc.com or senften@siggraph.org. I know k-d trees and space partitioning trees (BSP-trees) have also been considered for this purpose, but I don't know if the work has been published. I hope that helps. Sam Uselton uselton@nas.nasa.gov From owner-globillum@imag.fr Mon Sep 9 18:20:41 1996 Return-Path: From: ecamahor@cs.utexas.edu (Emilio Camahort) Date: Mon, 9 Sep 1996 19:11:58 -0500 To: globillum@imag.fr Subject: Re: spatial subdivision Cc: alz@lsil.com Status: R >I know k-d trees and space partitioning trees (BSP-trees) have also >been considered for this purpose, but I don't know if the work has >been published. K-d trees for ray-tracing are described in K.R.Subramanian's PhD thesis: K.R.Subramanian "Adapting Search Structures to Scene Characteristics for Ray Tracing" Department of Computer Sciences, The University of Texas at Austin, Austin, TX 78712, December 1990 You may be able to obtain a copy from: trcenter@cs.utexas.edu As for BSP-trees, I don't know of any paper describing their appli- cation to ray-tracing, but the following paper discusses ways of constructing good BSP-trees for ray-tracing: B.Naylor "Constructing Good Partitioning Trees" Proceedings of Graphics Interface'93, 1993 Good luck!! Emilio ecamahor@cs.utexas.edu From owner-globillum@imag.fr Mon Sep 9 19:07:51 1996 Return-Path: From: "Eric A. Haines" Subject: Re: spatial subdivision To: ecamahor@cs.utexas.edu Date: Mon, 9 Sep 96 21:08:13 EDT Cc: globillum@imag.fr Mailer: Elm [revision: 70.85] Status: R As far as non-uniform grids go, I come up empty beyond Gigante's work. >K-d trees for ray-tracing are described in K.R.Subramanian's PhD >thesis: An easier to obtain paper is: %A K.R. Subramanian %A Donald S. Fussell %T Automatic Termination Criteria for Ray Tracing Hierarchies %J Proceedings of Graphics Interface '91 %I Canadian Information Processing Society %C Calgary, Alberta %D June 1991 %P 93-100 %K octree Morgan-Kaufmann sells GI Proceedings (which I recommend; I've never been, but the proceedings have some interesting and useful papers in these). K.R. Subramanian is currently at krs@mail.cs.uncc.edu, UNC Charlotte. >As for BSP-trees, I don't know of any paper describing their appli- >cation to ray-tracing, but the following paper discusses ways of >constructing good BSP-trees for ray-tracing: There are six ray tracing papers with BSP in the title (and many other related papers using octrees, a relative of BSP), and there are some other papers by K.R. Subramanian on k-d trees (tech. reports, etc), check: http://wuarchive.wustl.edu/graphics/graphics/bib/ or ftp://wuarchive.wustl.edu/graphics/graphics/bib/ and get rtabs.shar.Z (which is Tom Wilson's collection of abstracts of hundreds of ray tracing articles) and rtbib95.zip/tar.Z, which is Paul Heckbert's and my collection of ray tracing references (somewhat dated, I've been too busy - please do send me new references, I hope to get an update out before year's end). Eric Haines erich@eye.com From owner-globillum@imag.fr Mon Sep 9 21:24:53 1996 Return-Path: From: krs@strauss.cs.uncc.edu (K. R.) Date: Mon, 9 Sep 1996 22:53:25 GMT+447 To: globillum@imag.fr Subject: k-d trees in ray tracing.. Status: R On Sep 9, 9:08pm, "Eric A. Haines" wrote: > Subject: Re: spatial subdivision > As far as non-uniform grids go, I come up empty beyond Gigante's work. > > > >K-d trees for ray-tracing are described in K.R.Subramanian's PhD > >thesis: > > An easier to obtain paper is: > > %A K.R. Subramanian > %A Donald S. Fussell > %T Automatic Termination Criteria for Ray Tracing Hierarchies > %J Proceedings of Graphics Interface '91 > %I Canadian Information Processing Society > %C Calgary, Alberta > %D June 1991 > %P 93-100 > %K octree Or, a postscript version of the above is available from my web page: http://www.cs.uncc.edu/~krs/publ.html I also have a postscript file of my thesis. Always willing to spread the word! > > Morgan-Kaufmann sells GI Proceedings (which I recommend; I've never been, but > the proceedings have some interesting and useful papers in these). > K.R. Subramanian is currently at krs@mail.cs.uncc.edu, UNC Charlotte. > > > >As for BSP-trees, I don't know of any paper describing their appli- > >cation to ray-tracing, but the following paper discusses ways of > >constructing good BSP-trees for ray-tracing: There is a tech report on it: B. Naylor, W. Thibault, "Application of BSP Trees to Ray Tracing and CSG Evaluation", TR GIT-CS 86/03, School of Inf. and Comp.Sc. Georgia Tech., 1986. Naylor can be reached at naylor@spatial-labs.com > There are six ray tracing papers with BSP in the title (and many other related > papers using octrees, a relative of BSP), and there are some other > papers by K.R. Subramanian on k-d trees (tech. reports, etc), check: > > http://wuarchive.wustl.edu/graphics/graphics/bib/ > or > ftp://wuarchive.wustl.edu/graphics/graphics/bib/ > > and get rtabs.shar.Z (which is Tom Wilson's collection of abstracts of hundreds > of ray tracing articles) and rtbib95.zip/tar.Z, which is Paul Heckbert's and > my collection of ray tracing references (somewhat dated, I've been too busy - > please do send me new references, I hope to get an update out before year's > end). > > Eric Haines > erich@eye.com >-- End of excerpt from "Eric A. Haines" -- krs -- K.R.Subramanian Phone: (704) 547-4872 Department of Computer Science FAX: (704) 547-3516 UNC Charlotte email: krs@zappa.cs.uncc.edu Charlotte, NC 28223-0001 WWW: http://www.cs.uncc.edu/~krs From owner-globillum@imag.fr Tue Sep 10 08:15:48 1996 Return-Path: From: cn1@irz301.inf.tu-dresden.de (Nguyen, D.C.) Subject: Re: spatial subdivision To: alz@lsil.com (Al Zimmerman) Date: Tue, 10 Sep 1996 14:41:39 +0200 (MESZ) Cc: globillum@imag.fr Status: R > > So, does anybody out there have any familiarity with non-uniform grids > for spatial subdivision. I never used grids for RT-speedup (memories!), but it should be possible to construct a near-optimal BSP-tree and then convert it back to your grids. I dont think that grids are much faster than BSP, except you implement this alg. in hardware. Another fact is that pure-spatial subdivision algorithms are almost always static and they all are based on some more or less efficient "heuristics", so it is very hard to obtain a really optimal subdivision. A good idea is to bring some "intelligence" into your subdivision sheme, alias hybrid-shemes. Especially for raytracing, i've some good results while implementing some hybrid-shemes in GX: The speedup is about 300-500% comparing to balanced BSP(!) --JuHu /\__ Nguyen Duc Cuong (aka JuHu) - CG-student +- / -> Home /__\ \ EMail : juhu@rz.tu-ilmenau.de +- /GX -> GX/GENERIC \__/ WWW : http://www.rz.tu-ilmenau.de/~juhu -+- /GX/RTEvol -> RTEvol From owner-globillum@imag.fr Wed Sep 11 09:14:29 1996 Return-Path: From: "Eric A. Haines" Subject: Re: spatial subdivision To: Frederic.Cazals@imag.fr Date: Wed, 11 Sep 96 10:15:33 EDT Cc: erich@eye.eye.com, globillum@imag.fr Mailer: Elm [revision: 70.85] Status: R Frederic Cazals writes: >-so far, it seems that the fastest data structures are the recursive >grids roughly built as follows: subdivide the bounding box of n >objects into \sqrt[3]{n} subdivisions along the x,y and z axis, and >iterate in each voxel containing more than MAX items --where MAX is >some constant, say 50. of course, getting the right value for MAX in I agree entirely, nested grids looks like a big win: you get the walking efficiency of grids and so get to walk large empty spaces quickly with the adaptive advantages of speed and robustness (rendering a teapot in a stadium brings a single grid structure to its knees). For similar work, see: %A David Jevans %A Brian Wyvill %T Adaptive Voxel Subdivision for Ray Tracing %J Proceedings of Graphics Interface '89 %I Canadian Information Processing Society %C Toronto, Ontario %D June 1989 %P 164-72 %Z nested grid subdivision structures %K grid subdivision, hierarchical subdivision %A David Jevans %T Adaptive Voxel Subdivision for Ray Tracing %R Master's Thesis %I Dept. of Computer Science, Univ. of Calgary %D 1990 %Z long version of paper %K grid subdivision, hierarchical subdivision Frederic, if you've seen these, how does your work compare with their technique? Personally, I use a variant of having the global grid store just object IDs, then each object itself has a bounding volume and grid if needed. The advantage to me is ease of coding and tight bounds - the same generic grid code is used for both, and the object's bounding box defines its grid size. Also, this method has the advantage of an intermediate bounding volume test before going into the nested grid, as a global grid cell may have a tiny object or a small part of some object in it, in which case you would normally spend (with just nested grids) a fair bit of time traversing the nested grid for no intersection. I need the bounding box test anyway to get a ray starting point for the object's grid. Eric Haines erich@eye.com From owner-globillum@imag.fr Wed Sep 11 09:16:39 1996 Return-Path: From: Frederic Cazals Subject: Re: spatial subdivision To: erich@eye.com Date: Wed, 11 Sep 1996 15:54:38 +0200 (MDT) Cc: globillum@imag.fr Status: R Hello, here are my $0.02 about speeding up ray-tracing with spatial subdivisions. the following elements are based upon a paper presented at Eurographics 95 (so see the proceedings or plug into http://flamingo.stanford.edu/~cazals/xfc_research.html and get the first paper) called 'Filtering, clustering and hierarchy construction: a new solution for ray tracing complex scenes' -so far, it seems that the fastest data structures are the recursive grids roughly built as follows: subdivide the bounding box of n objects into \sqrt[3]{n} subdivisions along the x,y and z axis, and iterate in each voxel containing more than MAX items --where MAX is some constant, say 50. of course, getting the right value for MAX in order to have a good tradeoff speed/memory requirements is the tricky point and that's one of the reasons why we came up with the Hierarchy of Uniform Grids (hug :)) -it is not obvious that non uniform subdivision implies 'heuristic that will fail in some particular case'. see the intuition provided by what is known about the asymptotic complexity of bucket sort vs. quick sort in our paper and how this should help in capturing the statistical properties of complex scenes frederic Cazals. -- ------------------------------------ ---------------- -------- ---- -- - -- iMAGIS Projet - Bat. B, 3 eme etage -- 385 rue de la Bibliotheque - Domaine Universitaire - StMartin d'Heres -- BP 53 - 38041 Grenoble cedex 09 - FRANCE -- Tel: 76-63-57-95 - Fax: 76-44-66-75 -- Frederic.Cazals@imag.fr From owner-globillum@imag.fr Thu Sep 12 06:17:43 1996 Return-Path: From: Frederic Cazals Subject: Re: spatial subdivision To: erich@eye.com (Eric A. Haines) Date: Thu, 12 Sep 1996 13:43:09 +0200 (MDT) Cc: globillum@imag.fr Status: R > %A David Jevans > %T Adaptive Voxel Subdivision for Ray Tracing > %R Master's Thesis > %I Dept. of Computer Science, Univ. of Calgary > %D 1990 > %Z long version of paper > %K grid subdivision, hierarchical subdivision > > Frederic, if you've seen these, how does your work compare with their technique? there are three major differences: -while D. Jevans's data structure is built top-down, ours is built bottom-up -we do not have any hand tuned parameter while he has two of them: the max number of items per voxel and the max hierarchy depth -he assumes that he has an efficient dynamic hashing algorithm to store the non-empty voxels since he does not know beforehand how many such voxels he is going to end up with, while the only data structures we are using are arrays and lists (allocated once for all and thus not causing any memory fragmentation problem). frederic Cazals. -- ------------------------------------ ---------------- -------- ---- -- - -- iMAGIS Projet - Bat. B, 3 eme etage -- 385 rue de la Bibliotheque - Domaine Universitaire - StMartin d'Heres -- BP 53 - 38041 Grenoble cedex 09 - FRANCE -- Tel: 76-63-57-95 - Fax: 76-44-66-75 -- Frederic.Cazals@imag.fr From owner-globillum@imag.fr Tue Sep 24 08:56:22 1996 Return-Path: Date: Tue, 24 Sep 1996 14:26:07 +0200 (MET DST) From: Phil Dutre To: globillum@imag.fr Subject: Ph.D. Thesis available Status: R Dear collegues, My Ph.D Thesis (which I defended succesfully last week) is available on the WWW: http://www.cs.kuleuven.ac.be/cwis/research/graphics/CGRG.PUBLICATIONS/PHDPHD/ (nice alliteration there ... ) The files are available as gzipped postscript. If you have any problems in downloading the text, please do not hesitate to contact me. Philip Dutre +-----------------------------------------------------------------------+ |Philip.Dutre@cs.kuleuven.ac.be Department of Computer Science | |http://www.cs.kuleuven.ac.be/~philipd/ Computer Graphics Research Group| |Phone: ++32 16 327667 (NEW!) Katholieke Universiteit Leuven | |Fax: ++32 16 327996 Celestijnenlaan 200A | |Office: C200, A.01.44 B-3001 Heverlee, BELGIUM | +-----------------------------------------------------------------------+ Title: Mathematical Frameworks and Monte Carlo Algorithms for Global Illumination in Computer Graphics Abstract: The title of this thesis `Mathematical Frameworks and Monte Carlo Algorithms for Global Illumination in Computer Graphics' refers to a domain in the field of computer graphics known as photo-realistic image rendering or global illumination. The goal of this domain is to compute realistic pictures of a three-dimensional scene, as could have been observed by a human observer or more precisely, a camera. The first part of this work describes the physical and mathematical foundations which are needed in order to describe the global illumination problem. The fundamental physical measure needed to describe the distribution of light in an environment is radiance. The equation describing the transport of radiance is a recursive integral equation. The dual problem introduces potential as a basic measure, and the potential equation as the corresponding transport equation. Both dual formulations can be used in order to solve the global illumination problem. Once the mathematical framework has been developed, the equations describing the transport of light or potential can be solved. Due to the high number of integrals and the complexity and unknown behaviour of the functions to be integrated, Monte Carlo integration provides a viable method of computing the global illumination in a three-dimensional scene. Depending on the choice of what transport equation to use, the radiance transport equation leads to distributed ray tracing or path tracing, and the potential transport equation leads to light tracing or particle tracing. The latter method generates particles at the light sources, which each carry a small amount of power. They carry out a random walk in the three-dimensional scene, and possibly contribute their power to the flux of a pixel on the screen. Mathematically, this algorithm can be considered as the dual algorithm of ray tracing. The sampling functions used for the generation of the random walks can be based on reflective properties of the surfaces encountered. However, in diffuse environments, better results can be expected when they are based on the (unknown) potential distribution. Since the optimal sampling function is not known in advance, one solution is to use adaptive probability density functions. As more particles are being generated, the potential distribution can be approximated more accurately, and thus a better sampling function can be constructed. This technique requires a substantial amount of memory, but produces better results. The used sampling algorithms can also be extended to other Monte Carlo rendering algorithms, such as bidirectional path tracing. From owner-globillum@imag.fr Tue Sep 24 13:53:04 1996 Return-Path: From: oleg@buffer.lsu.edu To: globillum@imag.fr Subject: analytic solutions Date: Tue, 24 Sep 96 14:58:31 -0500 X-Mts: smtp Status: R Salut ! I was doing my radiosity project when I realized that the approximate "differential area - to - disk" form factor formula FF = cos(a)*cos(b)*R^2 / (R^2 + h^2) given in so many books for numerical form factor integration gives in most cases 100%-200% numerical errors (!) . I had to derive the exact general analytic solution for this case, which was possibly known before ( do you have any references ?), but apparently was never recommended for practical use (to my knowledge). This exact formula is not very complicated compared to its widely used approximation, but it produces much more accurate results. It is also computationally simpler than the exact formulas known for other geometries (such as point-to-polygon); I think it makes this solution very useful. If it sounds interesting or if you faced any form factor computing problems before, please give me some feedback. I am also interested in any related open research problems. Oleg Pianykh Ph.D. student Louisiana State University oleg@bit.csc.lsu.edu P.S. Vous pouvez repondre en francais... From owner-globillum@imag.fr Thu Oct 3 10:18:14 1996 Return-Path: From: shirley@facility.cs.utah.edu Subject: Help with conference/journal links To: globillum@imag.fr Date: Thu, 3 Oct 1996 09:54:48 -0600 (MDT) Status: R Hi-- on my new home page: http://www.cs.utah.edu/~shirley/ I have added links to graphics journals and conferences with home pages. Please send me additions/corrections (I know I am missing GI and C&G-- where are they?) Thanks Pete Shirley shirley@cs.utah.edu From owner-globillum@imag.fr Tue Oct 8 08:42:25 1996 Return-Path: Date: Tue, 08 Oct 1996 14:34:20 +0100 From: Slawomir Kilanowski Organization: Metagram To: Global Illumination Mailing List Subject: Shadow analysis acceleration Status: R Dear Collegues, A month ago (September 7th) I asked for help in finding papers related to the project I was involved in - speed up of shadows analysis. I would like to thank once again all those who answered my query. Below you'll find the small bibliography I have completed. I hope it may be of some use for someone who will encounter the same problem. For those who are interested in "quick fix" of performance of a ray tracer with shadows calculated by ray casting I may honestly devise the Greg Ward's method described in "Adaptive Shadow Testing for Ray Tracing". It gave average speed-up factor varying from 1.5 - 5.0 calculated on models build of 10,000 - 40,000 polygons, with 50 - 400 lights. The differences in resultant images were not noticeable. In absolute terms (number of differing pixels and magnitude of differences) the differences were smaller than introduced by standard JPEG compression. Andrew Woo and Pierre Poulin and Alain Fournier, "A Survey of Shadow Algorithms", IEEE Computer Graphics and Applications, Vol 10, No 6, November 1990 Andrew Woo and John Amanatides, "Voxel Occlusion Testing: {A} Shadow Determination Accelerator for Ray Tracing", Proceedings of Graphics Interface '90, held in Halifax, Nova Scotia; 14-18 May 1990", Andrew Pearce and David Jevans "Exploiting Shadow Coherence in Ray Tracing", Proceedings of Graphics Interface '91", held in Calgary, Alberta; 3-7 June 1991, Frederic Asensio, "A Hierarchical Ray-Casting Algorithm for Radiosity Shadows" Third Eurographics Workshop on Rendering, 1991, Bristol, UK H. K. Choi and C. M. Kyung Pysha: a Shadow-Testing Acceleration Scheme for Ray Tracing, Computer-aided design, Vol 24, No 2, February 1992 A. James Stewart and Sherif Ghali, "An Output Sensitive Algorithm for the Computation of Shadow Boundaries", Canadian Conference on Computational Geometry, August 1993 Arjan J. F. Kok and Frederik W. Jansen and C.Woodward, "Efficient, Complete Radiosity Ray Tracing Using a Shadow-Coherence Method", The Visual Computer, Vol 10, 1994 A. James Stewart and Sherif Ghali, "Fast Computation of Shadow Boundaries Using Spatial Coherence and Backprojections", Proceedings of SIGGRAPH '94 (Orlando, Florida, July 24--29, 1994) Yiorgos Chrysanthou and Mel Slater, Shadow Volume {BSP} Trees for Computation of Shadows in Dynamic Scenes, 1995 Symposium on Interactive {3D} Graphics, Seth Teller and Pat Hanrahan, "Global Visibility Algorithms for Illumination Computations", Computer Graphics Proceedings, Annual Conference Series, 1993, A.J.F. Kok and F.W. Jansen Source Selection of the Direct Lighting Computation in Global Illumination Proceedings Second Rendering Workshop, 1991, Barcelona. In: Photorealistic Rendering in Computer Graphics, Springer Verlag, 75-82. Kurt Zimmerman, Peter Shirley "A Two-Pass Realistic Image Synthesis Method for Complex Scenes" Rendering Techniques '95 (Proceedings of the Sixth Eurographics Workshop on Rendering), Springer-Verlag, New York, NY 1995, pp 284-295 George Dretakkis and Eugene Fiume, "A Fast Shadow Algorithm for Area Light Sources Using Backprojection" Proceedings of SIGGRAPH '94 (Orlando, Florida, July 24--29, 1994), Seth J. Teller and Carlo H. Sequin, "Visibility preprocessing for interactive walkthroughs", Computer Graphics (SIGGRAPH '91 Proceedings), held in Las Vegas, Nevada; 28 July - 2 August 1991, Ward, Gregory, "Adaptive Shadow Testing for Ray Tracing," Second EUROGRAPHICS Workshop on Rendering, Barcelona, Spain, April 1991 Shirley, Peter, "Direct Lighting Calculation by Monte Carlo Integration," Second EUROGRAPHICS Workshop on Rendering, June 1991 (?) George Drettakis, Francois Sillion "Accurate Visibility and Meshing Calculations for Hierarchical Radiosity" Seth Teller, Pat Hanrahan "Global Visibility Algorithms for Illumination Computations", Computer Graphics, SIGGRAPH '94 proceedings. Kurt Zimmerman, Peter Shirley "A Two-Pass Realistic Image Synthesis Method for Complex Scenes", Indiana Univeristy, Technical Report No 434 -- ================================================================ Slawomir Kilanowski metagram@wro.ternet.pl METAGRAM, Swieradowska 73/23, 50-559 Wroclaw, Poland Phone/Fax : +48-(71)-731519 ================================================================ From owner-globillum@imag.fr Tue Oct 8 11:51:14 1996 Return-Path: From: Paul.Heckbert@hostess.graphics.cs.cmu.edu Date: Tue, 8 Oct 96 13:23:43 EDT To: globillum@imag.fr Subject: mesh generation info on web Status: R I've created an index to mesh generation info on the world wide web. This might be of interest to radiosity researchers. http://www.cs.cmu.edu/~ph/mesh.html Here's a preview of what you'll find there: ----------------------------------------------------------- Paul Heckbert's Collection of Mesh Generation Links This is a collection of World Wide Web links to information on mesh generation. There are also some links not specifically focused on mesh generation, relating to computational fluid dynamics (CFD), finite element methods (FEM), multigrid, triangulation, and computational geometry. The bias of these links is toward anisotropic unstructured triangular mesh generation (and consequently toward viscous flow applications). Too much jargon? Try the [mini-glossary of mesh generation]. table of contents: Collections of Links (this section includes links to several more comprehensive collections by Robert Schneiders and Steve Owen) Bibliographies Online Conferences/Journals/Newsletters & Big Paper Collections Offline Conferences & Journals People and Their Papers Software ----------------------------------------------------------- Paul Heckbert Computer Science Dept., Carnegie Mellon University 5000 Forbes Ave, Pittsburgh PA 15213-3891, USA ph@cs.cmu.edu http://www.cs.cmu.edu/~ph From owner-globillum@imag.fr Wed Oct 9 03:08:59 1996 Return-Path: Date: Wed, 9 Oct 96 9:48:15 METDST From: Erik Jansen Subject: Re: Shadow analysis acceleration To: metagram@wro.ternet.pl (Slawomir Kilanowski) Cc: globillum@imag.fr Mailer: Elm [revision: 70.85.1.76] Status: R Slawomir Kilanowski wrote: > > A month ago (September 7th) I asked for help in finding papers > related to the project I was involved in - speed up of shadows > analysis. I would like to thank once again all those who answered > my query. Below you'll find the small bibliography I have completed. > I hope it may be of some use for someone who will encounter the > same problem. Excellent to give this overview of your experiences and results. To complement your list of references I can provide the following information: > > Ward, Gregory, "Adaptive Shadow Testing for Ray Tracing," Second > EUROGRAPHICS Workshop on Rendering, Barcelona, Spain, April 1991 > > Shirley, Peter, "Direct Lighting Calculation by Monte Carlo > Integration," Second EUROGRAPHICS Workshop on Rendering, June 1991 (?) > The second EG Workshop on Rendering was held in May(!) 1991. And the proceedings are published as P. Brunet, F.W. Jansen (eds) Photorealistic Rendering in Computer Graphics, Springer Verlag, 1994 (!) ISBN 3-540-56449-7 or 0-387-56449-7 The papers mentioned appear at the following pages: Ward, "Adaptive Shadow Testing for Ray Tracing," p. 11 - 20. Shirley, "Direct Lighting Calculation ...", p. 54 - 59. Kok and Jansen, "Source Selection for ....", p. 75 - 82. I would like to suggest that the papers are referenced as dating from 1991 instead of 1994 the year the Springer proceedings were published. The latest RW proceedings (Rendering Techniques'9x) are now fortunately published within the same year as the workshop has been held. Erik Jansen From owner-globillum@imag.fr Tue Oct 22 15:47:10 1996 Return-Path: Date: Tue, 22 Oct 1996 15:03:59 -0700 (PDT) To: globillum@imag.fr From: iashdown@ledalite.com (Ian Ashdown) Subject: Radiosity bibliography in BibTex Status: R In response to intense public pressure (well, two people did complain), I have finally converted the RADBIB96 radiosity and global illumination bibliography from refer to BibTex format. I also converted the color quantization (CQUANT96) and winged edge / boundary representation (B-REP96) bibliographies. They are now available as: ftp://ftp.ledalite.com/pub/radbib96.bib ftp://ftp.ledalite.com/pub/cquant96.bib ftp://ftp.ledalite.com/pub/b-rep96.bib and also from our Web site: http://www.ledalite.com/library-/rrt.htm http://www.ledalite.com/library-/cgis.htm These files are mirrored by Greg Ward's ftp server: ftp://hobbes.lbl.gov/pub/doc while the old refer-format files are still available at: ftp://hobbes.lbl.gov/pub/doc/refer However, these files will not be updated with new releases. Thanks to Christine Piatko at NIST for providing the conversion software. Ian Ashdown, P. Eng. | READ THE BOOK! Research & Development Manager | Radiosity: A Programmer's Perspective Ledalite Architectural Products Inc. | by Ian Ashdown | John Wiley & Sons, 1994 Visit http://www.ledalite.com | (Sneaky Internet Advertising) From owner-globillum@imag.fr Fri Oct 25 12:23:41 1996 Return-Path: Date: Fri, 25 Oct 1996 10:30:48 -0700 (PDT) To: globillum@imag.fr From: iashdown@ledalite.com (Ian Ashdown) Subject: RADBIB96.BIB -- oops! Status: R Anyone who downloaded RADBIB96.BIB since it was made available earlier this week is advised to do so again. The file was inadvertently truncated at the reference {Eric P. Lafortune and Yves D. Willems}. (We exceeded our 50 MB space allocation). Our apologies for the inconvenience. For those who missed the earlier announcement, RADBIB96.BIB is available from: ftp://ftp.ledalite.com/pub/radbib96.bib and: http://www.ledalite.com/library-/rrt.htm It's also available as ftp://hobbes.lbl.gov/pub/doc/RADBIB96.Z, but please allow Greg Ward a day or so to update his copy of the file. From owner-globillum@imag.fr Mon Oct 28 07:57:36 1996 Return-Path: From: cn1@irz301.inf.tu-dresden.de (Nguyen, D.C.) Subject: What's wrong w/ Monte-Carlo methods? To: globillum@imag.fr (Global Illumination List) Date: Mon, 28 Oct 1996 15:50:34 +0200 (MESZ) Status: R I often ask myself : Monte-Carlo ray-tracing, is this the way to do globillum in the future? After reading a lot of papers aboud MC-methods, i still get confused w/ their terminologies. I can't see any advantage of these methods over traditional methods (radiosity), except the fact that meshing is not needed, and that you can do reference-images for RMS-benchmark(!) For me, the most important feature of a rendering method is not its physical-correctness, but its efficiency and visual-asthetic-possibilty. With MC-rendering, i must spend lot of works to develope specific sampling shemes and reasonable 'good' estimators. Even w/ that, i still get useless images (too noisy!), or i must increase the sampling rate and wait forever... It is not always true that most people find noises less obsevable than aliasing.( i.e white pixels in a dark-corner vesus aliased dark-lines) . Especially for the direct lighting computation, MC-methods are definitely *NOT* the way to go. : The most regions of an image are not in shadow, so why should we cast so many shadow-rays to the light-source ? In fact, we dont need to cast any shadow-rays, if the visibilities are known a priory ( w/ shaftculling) and the radiance comming from the light can be easly computed (analytically). Only for the case, that complex-shadow occurs, MC-sampling would be helpfull. Also for this case, the soft-shadow generated w/ them can be much better without increasing the sampling rate ( We simple smooth the shadow-regions, visual-aesthetic, not physical-correct!). Of course, i could be wrong:) --JuHu From owner-globillum@imag.fr Mon Oct 28 11:11:32 1996 Return-Path: Date: Mon, 28 Oct 96 11:09:48 -0500 From: swestin@ford.com (Stephen Westin ) To: globillum@imag.fr Subject: Re: What's wrong w/ Monte-Carlo methods? Status: R Why do folks bother at all with Monte Carlo methods for global illumination? Complexity. Think of the problem of computing the irradiance at a given point. Do you want to go around the whole environment, calculating the irradiance from every object, regardless of occlusion or distance from the point? Or do you want to probe the environment, spending similar effort for every incident direction? This is the basic choice between mesh-based methods and Monte Carlo calculations. For simple environments, the mesh-based methods are excellent; they give no noise artifacts, and computation is tractable. For extremely complex environments, mesh-based algorithms tend to get inefficient. Actually, the mesh-based world and Monte Carlo are working toward each other. Hierarchical meshing is basically a way to make a mesh-based algorithm behave more like Monte Carlo, spending effort for irradiance contributions rather than for geometric complexity. And any well-designed Monte Carlo calculation uses deterministic methods wherever practical, and attempts to take advantage of spatial coherence. The ultimate global illumination method will probably be a hybrid of Monte Carlo and mesh-based methods. -Stephen H. Westin swestin@ford.com The information and opinions in this message are mine, not Ford's. From owner-globillum@imag.fr Mon Oct 28 11:12:32 1996 Return-Path: Sender: greg@lightscape.com Date: Mon, 28 Oct 1996 09:24:23 -0800 From: Greg Spencer Organization: Lightscape Technologies, Inc. http://www.lightscape.com To: globillum@imag.fr Subject: Lens measurement? Status: R This isn't directly related to global illumination, but does relate to physically-based rendering. Does anyone know where one might get a real camera lens measured in order to calibrate it -- i.e., the distortion, chromatic abberations, intensity falloff, etc? I'd like to plug the results into a rendering system to get good approximations of a physical lens, but I have no data... It doesn't have to be a free service, but those are (of course) preferred. I've heard several rumors about a "European" company that does this sort of thing (for a large fee), but that's the entire rumor. Please respond to me directly, since I don't want to fill your mailboxes with non-related junk. I'll post a summary of responses in a week. I've researched using the Tsai method for calibration, but that uses video cameras and iteration... I would like to be able to measure lenses used for film cameras. Thanks! -Greg. -- Greg Spencer, Software Engineer greg@lightscape.com Lightscape Technologies., Inc. (408) 342-1900 http://www.lightscape.com (PGP key available upon request) From owner-globillum@imag.fr Mon Oct 28 11:28:11 1996 Return-Path: From: cn1@irz301.inf.tu-dresden.de (Nguyen, D.C.) Subject: Re: What's wrong w/ Monte-Carlo methods? To: shirley@facility.cs.utah.edu Date: Mon, 28 Oct 1996 18:23:19 +0200 (MESZ) Cc: cn1@irz301.inf.tu-dresden.de, globillum@imag.fr Status: R > > > Especially for the direct lighting computation, MC-methods are definitely > > *NOT* the way to go. : The most regions of an image are not in shadow, so why > > should we cast so many shadow-rays to the light-source ? In fact, we dont > > need to cast any > > shadow-rays, if the visibilities are known a priory ( w/ shaftculling) and > > the radiance comming from the light can be easly computed (analytically). > > Only for the case, that complex-shadow occurs, MC-sampling would be > > helpfull. Also for this case, the soft-shadow generated w/ them can be much > > better without increasing the sampling rate ( We simple smooth the > > shadow-regions, visual-aesthetic, not physical-correct!). > > I welcome you to implement shaft-culling on scene 5 above. Slower > than MC, and will usually core-dump even with a year > of implementation I'll bet. I've actually implemented shaft-culling for complex-scenes in GX/GENERIC. Not really shaft-culling, but a combined version of Arvo's hyperoctree and Haines's light-buffer. It's definitely faster than pur MC, because the cost for collision-test between a beam and a bbox is quite the same between a ray and a bbox. --JuHu From owner-globillum@imag.fr Mon Oct 28 11:30:48 1996 Return-Path: From: shirley@facility.cs.utah.edu Subject: Re: What's wrong w/ Monte-Carlo methods? To: cn1@irz301.inf.tu-dresden.de (Nguyen D.C.) Date: Mon, 28 Oct 1996 08:31:22 -0700 (MST) Cc: globillum@imag.fr, shirley@facility.cs.utah.edu (Peter Shirley) Status: R Wow-- we may actually get a discussion going! Is this allowed? :^) > I often ask myself : Monte-Carlo ray-tracing, is this the way to do > globillum in the future? After reading a lot of papers aboud MC-methods, i still get > confused w/ their terminologies. I can't see any advantage of these methods > over traditional methods (radiosity), except the fact that meshing is not > needed, and that you can do reference-images for RMS-benchmark(!) There is a lot of confusion on this because we all over-hype our methods in papers (me included) and as reviewers and authors we are sloppy about making people carefully characterize their methods. Here-- I will make up four scenes: 1. Lambertian Cornell box 2. Lambertian Cornell box w/smooth metal box 3. Lambertian Cornell box w/glass sphere instead of short block 4. Semi-matte (direction diffuse) Cornell box 5. Semi-matte (direction diffuse) Cornell box with "real object (10^6 patches) 1. Traditional world-space FE will work easily and we can do a walkthrough. RADIANCE will also work easily, but will not in practice allow a walkthrough-- the view-independent info is there, but it is not easily accessible. MCPT (Monte Carlo path tracing) will take all day, but will give an unbiased image (so what?). 2. Now radiosity has problems. We can add a virtual world, or use particle-tracing based radiosity with a density estimation post-process, but then doing the walktrhough is a problem. RADIANCE does fine for a given viewpoint, and we can re-use the irradiance map. MCPT will have LOTS of noise on the ceiling unless very good importance sampling is used. 3. Uh-oh-- particle tracing based radiosity works. RADIANCE and MCPT will have a very noisy caustic under the ball (although RADIANCE will not have this problem for the important glass case-- windows!). 4. Ouch. Sillion-style FE works, as does Jensen's photon map. MCPT is so dumb, it doesn't realize that this case is harder than Lambertian. RADIANCE will not work because it caches irradiance, so it will degenerate to MCPT (really, you can treat secondary bounces as Lambertian-- I believe this is a good move in almost all scenes, but it is hard to quantitatively justify). 5. Ouch^2. FE runs out of memory FAST. MCPT works no worse than 4. Jensen's photon map also works, but will be storage-intensive if the object is not very smooth. Radiance will perform as in 4. In summary, pure MCPT has only two advantages-- it is so dumb that it doesn't get hit by big scenes, and it is easy to implement. If you want an interactive walkthrough, then you are currently limited to radiosity (I use that term for all world space irradiance calculating alg's), and that limits you to a relatively small scene (100k initial polygons will kill almost all radiosity implementations). > For me, the most important feature of a rendering method is not its > physical-correctness, but its efficiency and visual-asthetic-possibilty. > With MC-rendering, i must spend lot of works to develope specific sampling > shemes and reasonable 'good' estimators. Even w/ that, i still get useless > images (too noisy!), or i must increase the sampling rate and wait forever... > It is not always true that most people find noises less obsevable than aliasing.( > i.e white pixels in a dark-corner vesus aliased dark-lines) . I agree with the above, and I think the solution is hybrid methods-- add bias! (This is blasphemy in MC circles :^) ). I do want to keep the good parts of MC methods-- they are damned robust and are possible to implement correctly-- my MC code does not bomb on wierd untweaked inputs-- tell me with a straight face that is true of most non-MC implementations. However, you are right that the results are too noisy!!! We can keep these benefits and reduce noise if we add bias the right way (not that I know what that right way is). > Especially for the direct lighting computation, MC-methods are definitely > *NOT* the way to go. : The most regions of an image are not in shadow, so why > should we cast so many shadow-rays to the light-source ? In fact, we dont > need to cast any > shadow-rays, if the visibilities are known a priory ( w/ shaftculling) and > the radiance comming from the light can be easly computed (analytically). > Only for the case, that complex-shadow occurs, MC-sampling would be > helpfull. Also for this case, the soft-shadow generated w/ them can be much > better without increasing the sampling rate ( We simple smooth the > shadow-regions, visual-aesthetic, not physical-correct!). I welcome you to implement shaft-culling on scene 5 above. Slower than MC, and will usually core-dump even with a year of implementation I'll bet. Now shaft culling on simplified geometries (which it sounds like you might be suggesting) sounds like a very good idea. Only use MC when needed-- yes, definitely smart. Overall, this has got me to again reflect on the state of our field. It is VERY hard to get a rendering paper into SIGGRAPH, even with good reviews. It is easy to get toys based on low-handing fruit into SIGGRAPH. Clearly we are doing something very wrong (you could rightly argue SIGGRAPH is doing something wrong, but that wont change anything-- we have to figure out where our share of the blame is). I think this is partially because most graphics people think TOY STORY graphics is good enough. I, however, want virtual reality that looks REAL and is predictive-- I don't want a virtual cartoon world. We are very far from getting things to look real, and from understanding our algorithms' behaviors. No working program gives useful error estimates. We have totally inadequate local reflection models. Most algorithms are memory hogs and don't parallelize. Most algorithms do a very poor job with dielectrics (water, glass). I think we need to make our own "grand challenge" models, and publicize that they can't currently be done (e.g, a human at a desk illuminated through a skylight), so that our field wont dry up and blow away. Pete From owner-globillum@imag.fr Mon Oct 28 13:57:13 1996 Return-Path: From: Eric Veach Subject: Re: What's wrong w/ Monte-Carlo methods? To: globillum@imag.fr Date: Mon, 28 Oct 1996 12:36:11 -0800 (PST) Status: R One of the big advantages of MC algorithms is that they let you model the scene you actually want to use. Sure, radiosity algorithms can be efficient --- if we limit ourselves to diffuse surfaces, with maybe a few mirrors or whatever that are handled in a ray-tracing pass. But flat polygons and diffuse reflectors do not go very far in modeling the real world, and finite-element algorithms don't seem to be practical for much more than this. (Memory usage blows up for complex scenes, or when there are lots of glossy surfaces.) This is an important issue in graphics, since often the biggest source of error is the scene model itself. What good is an accurate solution to the wrong scene model? At least MC algorithms start with the desired input. Even if you aren't interested in physically correct results, diffuse surfaces lead to that wonderful "computer graphics look" we all know and love. It's no wonder that radiosity algorithms tend to be faster, since they are solving a much simpler problem: the solution is only a two-dimensional function rather than a four-dimensional one. To me, the amazing thing is that radiosity algorithms need to be so *complicated* to be efficient. By the time you implement discontinuity meshing, hierarchical basis functions, clustering, shaft culling, etc., how many lines of code are we talking about? And can you actually trust it not to core-dump, and to compute a reasonable result in a reasonable amount of time? And let's not kid ourselves that an algorithm is "general" just because it can handle a few mirrors or glossy surfaces. The real test of generality is how an algorithm performs when there are *no* diffuse surfaces, since that's how it is in the real world. Another reason to use MC algorithms is scene complexity. Finite element algorithms work with explicit representations of the scene and its properties. They are strongly affected by the size and complexity of the scene representation. On the other hand, Monte Carlo algorithms are based on sampling, which means that the scene model is accessed through a small set of queries (e.g. what is the first surface point intersected by this ray?) This hides the scene complexity behind a layer of abstraction, and can mean that rendering times are only loosely coupled to the scene representation (e.g. it may affect the time required to cast a ray). In effect, Monte Carlo algorithms can sample the scene to determine the information they actually need, while deterministic algorithms examine every detail, whether it is relevant or not. That's not to say that MC algorithms need to sample *everything*. It's perfectly reasonable to embed deterministic calculations within a Monte Carlo framework, especially for low-dimensional integration problems (e.g.\ direct lighting from a small number of uniform, diffuse, polygonal luminaires). Sometimes this introduces bias, but often this is okay, especially when we can bound the errors or at least characterize them. Ideally, rendering algorithms should not depend on the details of the scene representation, but only on the underlying mathematical model. For example, a square area light source can be simulated fairly well with a ten by ten array of point sources, but many rendering algorithms would have a much worse performance in the second case. Similarly, if we replace the square light source by two flourescent bulbs covered by a diffusely transmitting panel, why should it make a huge difference to our algorithms? The same comments apply to geometric complexity: if we represent an indoor plant as a thousand polygons or a million Bezier patches, how much should the rendering time go up? I can't say that MC algorithms have achieved this level of isolation from the scene representation, but at least it seems that the opportunity is there. There has been a lot of emphasis on rendering algorithms that exploit special properties of the input scene, e.g. that lighting is direct rather than through a diffusing panel or bouncing off the ceiling. It would be nice to see more work on algorithms whose performance does not go down the tubes when these conditions are not met, i.e. algorithms that are more *robust*. It seems that this should be possible without resorting to the level of "dumbness" found in MCPT (as Pete Shirley put it). I guess the last major issue for MC algorithms is the correctness of the results. Here it is important to distinguish between unbiased, biased, and consistent estimators. Intuitively, an unbiased estimator computes the right answer, on average. A biased estimator computes the wrong answer, on average. A consistent estimator also computes the wrong answer, on average, but the error can be made arbitrarily small by increasing the number of samples. Most of the "biased" algorithms in graphics are in fact consistent, otherwise we wouldn't have any confidence at all in their results. The main advantage of unbiased algorithms is that they make it far easier to estimate the error in a solution. For unbiased algorithms, this error can be estimated by the sample variance, since any error is guaranteed to show up as random variation among the samples. Thus, if an unbiased image is not noisy, we can be reasonably sure that it is correct. For scene of realistic complexity, this seems to be the only practical way to generate correct images. For algorithms which are merely consistent, however, we must also bound the bias. In general this is difficult to do; we cannot estimate bias by simply drawing a few more samples. Bias shows up as results that are not noisy, but in fact are incorrect. In graphics algorithms, this error is often noticeable visually, in the form of discontinuities, excessive blurring, or surface shading that just looks wrong. Other things being equal, it is clear that we should prefer an unbiased algorithm. If these algorithms were also robust and efficient, then why would we want to use anything else? However, conventional wisdom says that unbiased methods are "too expensive", and that we can achieve an acceptable image in less time by making approximations. But where is the research to support this claim? There has been a huge amount of effort on approximate methods in graphics, while there has been hardly any work on unbiased algorithms. Some people seem to think that "unbiased" is a synonym for "pure Monte Carlo path tracing". Until we have thoroughly explored this type of algorithm, we can hardly make judgements on their capabilities. I would like to see more results on what can and cannot be achieved by unbiased methods, so that we can make better decisions on these issues. (Can you tell that I'm writing a thesis? :-) Eric From owner-globillum@imag.fr Mon Oct 28 13:47:49 1996 Return-Path: Date: Mon, 28 Oct 96 12:25:02 PST From: alz@lsil.com (Al Zimmerman) To: globillum@imag.fr Subject: quadratic intersection Cc: alz@lsil.com Status: R I was reading up on ray intersection with a quadratic and I always see mention of the Q matrix, but I can't find any material describing how to construct the Q matrix. The Q matrix is mentioned in just about every piece of documentation that deals with intersecting a ray with a quadratic, but none of the documentation states how to construct the matrix. The only documentation I can find deals with the Q matrix when the quadratic is in homogeneous coordinates where most of the variables in the Q matrix go to zero. To work around this problem, I've seen solutions to translate the quadratic back to the origin, scale , and then rotate to lie on the axis. Now use the homogeneous Q matrix for intersection. Does anyone know how to construct the Q matrix when the quadratic is not in homogeneous unit coordinates ? Thanks in advance, Al Z From owner-globillum@imag.fr Tue Oct 29 07:39:14 1996 Return-Path: X-Lotus-Fromdomain: IBM RESEARCH From: "Holly Rushmeier" To: shirley@facility.cs.utah.edu Cc: cn1@irz301.inf.tu-dresden.de, globillum@imag.fr Date: Tue, 29 Oct 1996 08:11:58 -0400 Subject: Re: What's wrong w/ Monte-Carlo methods? Status: R I would take issue with one of Pete's statements: >In summary, pure MCPT has only two advantages-- it is so dumb >that it doesn't get hit by big scenes, and it is easy to implement. >If you want an interactive walkthrough, then you are currently >limited to radiosity (I use that term for all world space >irradiance calculating alg's), and that limits you to >a relatively small scene (100k initial polygons will kill >almost all radiosity implementations). The big deal about image-based rendering, i.e. QuickTimeVR (or PanoramIX :) ), or the more advanced Light Field Rendering or Lumigraph is that we can interactively walkthrough scenes precomputed with Monte Carlo -- the same way you can walk through a scene precomputed with radiosity. -- Holly From owner-globillum@imag.fr Tue Oct 29 08:35:22 1996 Return-Path: From: shirley@facility.cs.utah.edu Subject: Re: What's wrong w/ Monte-Carlo methods? To: HOLLY@watson.ibm.com (Holly Rushmeier) Date: Tue, 29 Oct 1996 06:23:45 -0700 (MST) Cc: shirley@facility.cs.utah.edu, cn1@irz301.inf.tu-dresden.de, globillum@imag.fr Status: R Holly is of course right! As a MCPT fan (maybe you couldn't tell that from my note-- it is my favorite rendering alg, because although it is flawed, I think its flaws are easier to fix than other alg's flaws-- see Eric Veach's note), I was very happy to see that image-based stuff get big-- where will those images come from? :^) Also, my comments really apply to "naive" MCPT-- if you add bias or good importance sampling, it may end up being practical even without Image-based stuff. Pete From owner-globillum@imag.fr Tue Oct 29 09:49:56 1996 Return-Path: Posted-Date: Tue, 29 Oct 1996 16:23:38 GMT To: "Holly Rushmeier" Cc: shirley@facility.cs.utah.edu, cn1@irz301.inf.tu-dresden.de, globillum@imag.fr, jnimerof@graphics.cis.upenn.edu Subject: Re: What's wrong w/ Monte-Carlo methods? Date: Tue, 29 Oct 1996 11:23:38 -0500 From: "Jeffry S. Nimeroff" Status: R > > The big deal about image-based rendering, i.e. QuickTimeVR > (or PanoramIX :) ), or the more advanced Light Field Rendering or > Lumigraph is that we can interactively walkthrough scenes > precomputed with Monte Carlo -- the same way you can walk > through a scene precomputed with radiosity. > > -- Holly > Well, I have to take exception with this statement, at least for now (sorry Holly :-)). The lumigraph and light fields are for the space around convex regions of the environment (inside the "slabs") or for a free space region inside an interior scene. Freedom of movement (quick indexing of the data structure) can be done using hardware texturing which is nice, but the method is not applicable for any environments I would consider outstanding. Being able to orbit around or pan near a small cluster of objects is not much more novel than the capabilities supplied in Quicktime VR and I don't know of many interior scenes that have lots of free space (pathways without occlusions like columns, or furniture). There is a simple modification of light-fields that allows full range of motion within computer-rendered scenes that is equally as efficient as the original implementation, but you'll have to wait for my newest work to be done :-). And if you want moving objects in your scene (a sense of time)... -Jeff From owner-globillum@imag.fr Tue Oct 29 11:02:37 1996 Return-Path: Date: Tue, 29 Oct 1996 09:35:57 -0800 From: Alain Fournier To: HOLLY@watson.ibm.com, jnimerof@graphics.cis.upenn.edu Subject: Re: What's wrong w/ Monte-Carlo methods? Cc: cn1@irz301.inf.tu-dresden.de, globillum@imag.fr, shirley@facility.cs.utah.edu Status: R Quick remark (and boy, have I been wrong before): I think the light field techniques are very interesting and valuable, but not as primary rendering techniques (if they were ever intended that way). They will be especially useful when merged with CG scenes rendered from models (with global illum, natch, also merging with real scenes won't hurt). Paper at 11:00. From owner-globillum@imag.fr Tue Oct 29 13:49:42 1996 Return-Path: From: Henrik Wann Jensen Subject: Re: What's wrong w/ Monte-Carlo methods? To: ericv@cs.stanford.edu (Eric Veach) Date: Tue, 29 Oct 1996 21:38:43 +0100 (MET) Cc: globillum@imag.fr Status: R Eric Veach wrote: > MC is better than FE... I agree :-) > Other things being equal, it is clear that we should prefer an > unbiased algorithm. I vote for consistent MC-methods since they really are significantly faster than the unbiased methods we have seen so far. Just take the irradiance gradient caching scheme by Greg Ward and the photon map :) > The main advantage of unbiased algorithms is that they make it > far easier to estimate the error in a solution. It's true that the error can be estimated for unbiased methods but this estimate is probabilistic which in my opinion makes it less useful since you cannot really trust your result but only be "reasonably sure" that it is correct. > I would like to see more results on what can and > cannot be achieved by unbiased methods, so that we can make > better decisions on these issues. You can solve all rendering problems using unbiased techniques such as path tracing and bidirectional path tracing. But for certain problems these methods are *very* inefficient. Path tracing is not practical for rendering caustics. Bidirectional path tracing is much better at visualizing caustics but it fails when it comes to rendering the mirror reflection of caustics (created by a small light source). Consider for example a glass of cognac on a procedural surface :) Even bidirectional path tracing would have a hard time computing the illumination of the surface just below the glass and it would be very costly (and time-consuming) computing billions of intersection points with a complex procedural surface. This problem is much easier to solve if you allow storing illumination information in the model (=bias). - Henrik From owner-globillum@imag.fr Tue Oct 29 18:33:09 1996 Return-Path: From: Eric Veach Subject: Re: What's wrong w/ Monte-Carlo methods? To: henrik@mental.com (Henrik Wann Jensen) Date: Tue, 29 Oct 1996 17:58:01 -0800 (PST) Cc: ericv@cs.stanford.edu, globillum@imag.fr Status: R Henrik Wann Jensen writes: | > MC is better than FE... Hey, I didn't say that. Finite element methods also have advantages, I just didn't mention them. | > Other things being equal, it is clear that we should prefer an ^^^^^^^^^^^^^^^^^^^^^^^^ | > unbiased algorithm. | | I vote for consistent MC-methods since they really are significantly faster | than the unbiased methods we have seen so far. Just take the irradiance | gradient caching scheme by Greg Ward and the photon map :) The point is that you can't judge the whole class of unbiased algorithms based on a couple of examples. If you had an unbiased algorithm that was just as fast, wouldn't you use it? Such an algorithm doesn't exist yet, but we haven't seen any solid evidence that this goal is impossible. It's going to take more research before we know what can be achieved. | It's true that the error can be estimated for unbiased methods but | this estimate is probabilistic which in my opinion makes it less useful | since you cannot really trust your result but only be "reasonably sure" | that it is correct. Well, that's still better than no error estimates at all, which is what you get with biased or consistent algorithms. For example, let's consider your photon map. I like this algorithm, and I think it's a great practical tool. But like many consistent algorithms, it can make large errors that are difficult to characterize (as I'm sure you are aware). Let's look at some of the situations where this happens. For some scenes, the results can be wrong by an arbitrary amount. The cognac glass sitting on a fractal surface is a perfect example. Given some point "x" to be shaded, you find the smallest sphere centered at "x" that encloses N photon hits. Then you estimate irradiance by assuming that the scene is locally planar, i.e. its intersection with the interior of the sphere is approximately a flat *disc*. Thus to get irradiance, the power carried by each photon is divided by (Pi * r^2). This obviously doesn't make any sense for a fractal surface. The area of the surface within a sphere of radius "r" is much larger than Pi * r^2 (for a true fractal, the area would be infinite, but even for the reasonably fine subdivisions you are using, it would be significantly higher). So, the caustics in your images are probably much brighter than they should be. Similarly, the disc estimate will be substantially wrong near corners, or for narrow objects (dangling power cords, wire cages, blades of grass), or for parallel surfaces that are close together (e.g. a slide tray, or vertical blinds). The errors are not small -- we're talking about factors of two, or ten, or even a hundred. The error depends on the ratio of the true surface area over which the photons are distributed, vs. the area of the approximating disc. Now, the photon map is a consistent estimator, so these errors will get smaller as the number of photons is increased. But for these examples, it would take incredible numbers of photons to get a reasonable error. Let's consider the handle on my coffee mug. It has a diameter of about 1cm. For the disc estimate to be reasonable (say within 20%), the diameter of the corresponding sphere must be a couple of millimeters at most. This sphere is supposed to enclose N=50 or so photons, according to your rules of thumb, so this implies a density of about ten million photon hits per square meter. Since all of these photons are stored in a search tree, the memory requirements would be ridiculous for typical scenes. These kinds of errors are typical of many rendering algorithms that are only claim consistency. I have just been using the photon map as an example. In fact, it would be my first choice for some applications. Let's face it, we are stuck with consistent algorithms for many problems (until something better comes along). However, I don't think it's fair to compare the photon map with an unbiased algorithm like bidirectional path tracing. Sure, there are situations where bidirectional path tracing does not work well either, but at least the errors can be detected and estimated by means of the sample variance. Eric From owner-globillum@imag.fr Wed Oct 30 04:10:27 1996 Return-Path: From: Henrik Wann Jensen Subject: Re: What's wrong w/ Monte-Carlo methods? To: ericv@CS.Stanford.EDU (Eric Veach) Date: Wed, 30 Oct 1996 10:12:19 +0100 (MET) Cc: globillum@imag.fr Status: R Thus spoke Eric Veach: > > Henrik Wann Jensen writes: > | > MC is better than FE... > > Hey, I didn't say that. Finite element methods also have > advantages, I just didn't mention them. I were just abbreviating your intro ;-) > If you had an unbiased algorithm that was just as fast, wouldn't you use it? I sure would. In my examples I was simply refering to the two wellknown examples of unbiased path tracing based algorithms and they are very slow. > For the disc estimate to > be reasonable (say within 20%), the diameter of the corresponding > sphere must be a couple of millimeters at most. This sphere is > supposed to enclose N=50 or so photons, according to your rules > of thumb, so this implies a density of about ten million photon > hits per square meter. Since all of these photons are stored in > a search tree, the memory requirements would be ridiculous for > typical scenes. I agree that the basic photon map implementation can give large errors. These errors can be reduced by using different filtering techniques but still, I agree, if you want absolute confidence in your result you may need a large number of photons. The same does, however, apply to path tracing. A student of mine recently investigated the error estimates for unbiased path tracing. His results indicate that just having a confidence of 15% (five percent) that you are within 1% of the correct result required for most pixels thousands of sample rays and for some pixels (such as the edges of light sources) the number of rays exploded. But I must admit that I really like the unbiased path tracing algorithms and they would be my choice if I wanted to have absolute confidence in the result. They are, however, not very practical for everyday rendering. - Henrik From owner-globillum@imag.fr Wed Oct 30 08:56:24 1996 Return-Path: From: Henrik Wann Jensen Subject: Re: What's wrong w/ Monte-Carlo methods? To: globillum@imag.fr Date: Wed, 30 Oct 1996 15:45:49 +0100 (MET) Status: R Henrik Wann Jensen wrote: > His results indicate that just having a confidence of 15% (five percent).. This should be 15% and not 5% and btw. the scene was a simple Cornell box model. - Henrik From owner-globillum@imag.fr Wed Oct 30 09:32:18 1996 Return-Path: From: shirley@facility.cs.utah.edu Subject: advanced pages To: globillum@imag.fr Date: Wed, 30 Oct 1996 08:03:45 -0700 (MST) Status: R I have just started a list of advanced course pages (with one entry so far). If you teach some sort of advanced graphics course (e.g. a seminar on rendering) and want to be listed send me mail. http://www.cs.utah.edu/~shirley/courses.html Pete shirley@cs.utah.edu From owner-globillum@imag.fr Wed Oct 30 09:50:10 1996 Return-Path: X-Lotus-Fromdomain: IBM RESEARCH From: "Holly Rushmeier" To: henrik@mental.com Cc: ericv@cs.stanford.edu, globillum@imag.fr Date: Wed, 30 Oct 1996 11:11:38 -0400 Subject: Re: What's wrong w/ Monte-Carlo methods? Status: R --0__=PEkFpXAZZg4i1H2E6JR37TKILDOnzqccjM5ggLSobZuGuvCe2iEcLTGR Content-type: text/plain; charset=us-ascii To: ericv @ CS.Stanford.EDU cc: globillum @ imag.fr (bcc: Holly Rushmeier/Watson/IBM Research) From: henrik @ mental.com Date: 10/30/96 10:12:19 AM Z-1 Subject: Re: What's wrong w/ Monte-Carlo methods? --0__=PEkFpXAZZg4i1H2E6JR37TKILDOnzqccjM5ggLSobZuGuvCe2iEcLTGR Henrik wrote: >The same does, however, apply to path tracing. A student of mine recently investigated the >error estimates for unbiased path tracing. His results >indicate that just having a confidence of 15% (five percent) that you >are within 1% of the correct result required for most pixels thousands >of sample rays and for some pixels (such as the edges of light sources) >the number of rays exploded. Werner Purgathofer did a nice analysis of the number of samples needed for anti-aliasing in "A Statistical Method for Adaptive Sampling" in Computers and Graphics, 1987, pp. 157-162. Using his methodology, and taking into account the dynamic range of the global illumination problem, assuming simple minded tone mapping, allowing an error of +/- 10 in final pixel value (out of 0-255) and a requiring an 80% confidence level gives a minimum sampling rate of 16094 (see Rushmeier & Ward, "Energy Preserving Non-Linear Filters", Siggraph 94, pp 131 - 138) The above paper also brings up the notion, that rather than use a biased algorithm, you can compute a result with an unbiased algorithm, and then filter the results for consistency based on the values and error estimates that you get. -- Holly --0__=PEkFpXAZZg4i1H2E6JR37TKILDOnzqccjM5ggLSobZuGuvCe2iEcLTGR-- From owner-globillum@imag.fr Wed Oct 30 11:20:21 1996 Return-Path: Posted-Date: Wed, 30 Oct 1996 17:38:40 GMT To: "Holly Rushmeier" Cc: henrik@mental.com, ericv@cs.stanford.edu, globillum@imag.fr, jnimerof@graphics.cis.upenn.edu Subject: Re: What's wrong w/ Monte-Carlo methods? Date: Wed, 30 Oct 1996 12:38:40 -0500 From: "Jeffry S. Nimeroff" Status: R > > Werner Purgathofer did a nice analysis of the number of samples > needed for anti-aliasing in "A Statistical Method for Adaptive > Sampling" in Computers and Graphics, 1987, pp. 157-162. > > Using his methodology, and taking into account the dynamic range > of the global illumination problem, assuming simple minded > tone mapping, allowing an error of +/- 10 in > final pixel value (out of 0-255) and a requiring an 80% confidence > level gives a minimum sampling rate of 16094 (see Rushmeier & Ward, > "Energy Preserving Non-Linear Filters", Siggraph 94, pp 131 - 138) > > The above paper also brings up the notion, that rather than use a > biased algorithm, you can compute a result with an unbiased algorithm, and > then filter the results for consistency based on the values and error > estimates that you get. > > -- Holly > I think this brings up the best motivation of all. Unbiased algorithm, then filtering for results. Not being a MC person myself, has work been done in this manner. It always seems that the algorithms themselves are either unbiased (with proponents talking about error bounds and validation), or biased (with proponents talking about consistency and/or promoting the "look" of the results). It seems like efficiency increases with error bounds (even if they are conservative) can best be accomplished by meeting in the middle. -Jeff From owner-globillum@imag.fr Wed Oct 30 14:54:24 1996 Return-Path: Date: Wed, 30 Oct 1996 17:12:57 -0500 (EST) From: Ken Musgrave To: globillum@imag.fr Subject: Re: What's wrong w/ Monte-Carlo methods? Status: R My two cent's worth on Monte Carlo vs. radiosity: The former stands up to a shave with Occam's razor substantially better. It took years for Mandelbrot to pound a full appreciation of elegance into my thick head. -Ken From owner-globillum@imag.fr Thu Oct 31 06:49:01 1996 Return-Path: From: Henrik Wann Jensen Subject: Re: What's wrong w/ Monte-Carlo methods? To: HOLLY@watson.ibm.com (Holly Rushmeier) Date: Thu, 31 Oct 1996 13:07:24 +0100 (MET) Cc: globillum@imag.fr Status: R Thus spoke Holly Rushmeier: > Using his methodology, and taking into account the dynamic range > of the global illumination problem, assuming simple minded > tone mapping, allowing an error of +/- 10 in > final pixel value (out of 0-255) and a requiring an 80% confidence > level gives a minimum sampling rate of 16094 (see Rushmeier & Ward, > "Energy Preserving Non-Linear Filters", Siggraph 94, pp 131 - 138) > > The above paper also brings up the notion, that rather than use a > biased algorithm, you can compute a result with an unbiased algorithm, and > then filter the results for consistency based on the values and error > estimates that you get. You can also filter an image generated by a consistent Monte Carlo renderer and obtain "good quality" much faster. I seem to remember that the "Energy Preserving Non-Linear Filters" paper also presented a technique for filtering images generated by Radiance (= a consistent but biased MC renderer). - Henrik From owner-globillum@imag.fr Thu Oct 31 14:55:33 1996 Return-Path: Date: Thu, 31 Oct 1996 16:58:21 -0500 (EST) From: Ken Musgrave To: globillum@imag.fr Subject: Re: What's wrong w/ Monte-Carlo methods? Status: R |From: Eric Veach |Date: Tue, 29 Oct 1996 17:58:01 -0800 (PST) | |This obviously doesn't make any sense for a fractal surface. The |area of the surface within a sphere of radius "r" is much larger |than Pi * r^2 (for a true fractal, the area would be infinite, Not to mention the fact that there would exist no surface normal anywhere for such a fractal, and that therefore light can only be propagated via diffraction. ;-) Mo Fractal From owner-globillum@imag.fr Fri Nov 1 03:14:35 1996 Return-Path: From: Henrik Wann Jensen Subject: Re: What's wrong w/ Monte-Carlo methods? To: ericv@cs.stanford.edu Date: Fri, 1 Nov 1996 11:46:08 +0100 (MET) Cc: globillum@imag.fr Status: R Thus spoke Eric Veach > This obviously doesn't make any sense for a fractal surface. The > area of the surface within a sphere of radius "r" is much larger > than Pi * r^2 (for a true fractal, the area would be infinite, The formula actually uses the *projected area* which is well-defined even for a fractal surface. And we do not need the normal if the reflection model for the fractal is Lambertian :) - Henrik From owner-globillum@imag.fr Mon Nov 11 16:07:47 1996 Return-Path: From: krs@strauss.cs.uncc.edu (K. R.) Date: Mon, 11 Nov 1996 18:13:57 GMT+447 To: globillum@imag.fr Subject: Foley,Van Dam - diffuse reflection.. Status: R I wonder if any of you have read carefully through Foley Van Dam's explanation of diffuse reflection. The explanation is either misleading or incorrect. Lambert's law is claimed to be related to the viewer location/angle.. I quote, "...Second, we must consider the amount of light seen by the viewer. Lambertian surfaces have the property, often known as Lambert's law, that the amount of light reflected from a unit differential area dA towards the viewer is directly proportional to the cosine of the angle between the direction of viewer and N..." They go on to use this to explain how the intensity is constant in all directions. However, on the one hand the angle theta is between the normal and the light vector, while the second angle is between the viewer and N. These are certainly not the same. -- krs -- K.R.Subramanian Phone: (704) 547-4872 Department of Computer Science FAX: (704) 547-3516 UNC Charlotte email: krs@zappa.cs.uncc.edu Charlotte, NC 28223-0001 WWW: http://www.cs.uncc.edu/~krs From owner-globillum@imag.fr Tue Nov 12 10:29:12 1996 Return-Path: Date: Tue, 12 Nov 96 13:51 GMT From: Adrian James Chung To: globillum@imag.fr Subject: The case for FEM Status: R I guess the "What's wrong w/ Monte-Carlo methods?" thread has died. Pity. I was quite enjoying it as it reflected the "state of the art" in Global Illum more than any paper would have IMHO. I'd like to give my 2p if it's not too late: ** On scene complexity: Pete Shirley: > In summary, pure MCPT has only two advantages-- it is so dumb > that it doesn't get hit by big scenes, and it is easy to implement. [...] > radiosity (I use that term for all world space > irradiance calculating alg's), and that limits you to > a relatively small scene (100k initial polygons will kill > almost all radiosity implementations) This just illustrates the time/space trade-off in global illumination. Naive MCPT is so "dumb" it keeps throwing away intermediate results that could come in handy when the next path gets traced. I know there are some intersection acceleration techniques to exploit path coherency but very few exploit coherency in the radiance function (for instance, irradiance caching in RADIANCE). Stephen Westin: > Why do folks bother at all with Monte Carlo methods for global > illumination? Complexity. [...] > Do you want to go around the whole environment, calculating the > irradiance from every object, regardless of occlusion or distance from > the point? Which is the motivation for importance (or Pattanaik's potential) based FE techniques. > Hierarchical meshing is basically a way to make a mesh-based algorithm > behave more like Monte Carlo, spending effort for irradiance > contributions rather than for geometric complexity. (...) > The ultimate global illumination method will probably be a > hybrid of Monte Carlo and mesh-based methods It's a pity that intrisically MCPT is not really hierarchical. It may use a hierarchical data structure for every intersection but it is essentially a point sampling method. In Fast Multipole Methods the physical characteristics stored at each interior node serves as a course representation of that stored by the descendant nodes in the heirarchy thus interactions can be computed without descending all the way to the leaves. As all point samples in MCPT are independent they must all descend to the leaves of the data structure to determine on an individual basis how each gets reflected. Unanswered questions: Should we, and how do we, make MCPT more like FMM? Or should Hierarchical FE be made more like MCPT? In short, what form should this hybrid take? Eric Veach: > But flat polygons and diffuse reflectors do not go very far in > modeling the real world, and finite-element algorithms don't seem to > be practical for much more than this. And in a later email: > The point is that you can't judge the whole class of unbiased > algorithms based on a couple of examples. Same applies to finite element methods. This thread has been judging the relative merits of MCPT and FE on the basis of what can currently be done practically. I say we also need to look at their potential for future improvements. We criticise FE's inability to deal with gloss based upon methods that apply meshing to 2D surfaces. But the global plenoptic function is 5-dimensional and have there been any attempts at discretizing this space? (Drettakis et al.'s visibility complex is a start...) > I would like to see more results on what can and > cannot be achieved by unbiased methods, so that we can make > better decisions on these issues. ...as well as for FE and true hierarchical methods. IMO visibilty has been handled poorly in FE radiosity, often reducing to a MonteCarlo approach of casting rays between patches and/or clusters. Is there a robust algorithm that reliably implements the triage concept (i.e. doesn't say two patches are fully occluded simply because the 16 rays cast between them so happened to hit the cloud of intervening occluders). > To me, the amazing thing is that radiosity algorithms need to be so > *complicated* to be efficient. I get this same feeling for MCPT. We now have irradiance caching, a variety of intersection acceleration methods, special cases for direct illumination, luminaire classification schemes based on significance, caustic and photon-mapping pre-passes, special closed form analytical BRDFs, "imposter" substitution for indirect luminaires (or whatever the correct term for it is...), etc. Of course, once you've implemented all these you'd be able to handle a much wider domain of problems than current FE methods, but I bet you'll still miss your deadline. ** On memory management and parallelism Pete: > Most algorithms are memory hogs and don't parallelize. This enters into the field of operating systems. My opinion is that most OS designs have been based on applications of the 70's and before. Back then there was little use of dynamic data structures. It would be a mistake to design a globillum application to fit into this framework. Things are improving with new research into microkernels which can allow one to specify user defined virtual memory systems specially taylored for the demands of particular algorithms. On the parallelism front computational scientists are increasingly moving toward adaptive irregular computations (a behaviour so common in MCPT and HR) necessitating runtime support for multi-threading and asynchronous control. My belief is that most MCPT and FE radiosity methods can be expressed in a multithreaded asynchronous style to make use of these innovations. ** Grand Challenge models Pete: > I think we need to make our own "grand challenge" models, and publicize > that they can't currently be done (e.g, a human at a desk illuminated > through a skylight), so that our field wont dry up and blow away. A Great Idea! Eric Veach: > The real test of generality is how an algorithm performs when there are > *no* diffuse surfaces, since that's how it is in the real world. Additionally: (i) when 90% of the scene is outside the viewing frustum but may still influence the illumination of the visible geometry. How would the photon map perform on a 5 story architecture where the janitor has left the light on inside a closed closet? How does MCPT perform on the nested labyrinth models used by Smits (SigGraph 1992)? This and Eric Veach's comment below makes the case for importance estimation which can be done by FE also: > In effect, Monte Carlo algorithms can sample the scene to > determine the information they actually need, while deterministic > algorithms examine every detail, whether it is relevant or not. (ii) when feature sizes vary over several orders of magnitude (such as fractals). A pathological case would be to render a scene of a pile of sand where part of the view is through a powerful magnifying glass. Contrived though it is, it illustrates where a sort of multi-resolution BRDF would come in handy so that samples passing through the magnifying glass make use of the detailed BRDF of the sand particles, whereas indirect illumination reflecting off the entire pile uses the courser BRDF representation. Has there been any research into generating a multi-resolution BRDF like this automatically? The current technique is to use imposters but this requires user intervention. This would help handle this model: Eric: > Ideally, rendering algorithms should not depend on the details of > the scene representation, but only on the underlying mathematical > model. For example, a square area light source can be simulated > fairly well with a ten by ten array of point sources (...) > Similarly, if we replace the square light source by two flourescent > bulbs covered by a diffusely transmitting panel, (...) The same > comments apply to geometric complexity: if we represent an indoor > plant as a thousand polygons or a million Bezier patches, how much > should the rendering time go up? These will make great Grand Challenge problems! Someone should catalogue pathological cases with explanations why each of the currently available techniques perform poorly. Henrik Wann Jensen: > Consider for example a glass of cognac on a procedural surface :) Eric Veach: > Let's consider the handle on my coffee > mug. (...) this implies a density of about ten million photon > hits per square meter. We can make this another Grand Challenge problem. Picture a messy kitchen with daylight incident on a sink full of turbid water reflecting caustics onto Eric's mug. (Do you have a NURBS description of that?) Henrik on the photon map & fractal surfaces: > The formula actually uses the *projected area* which is well-defined > even for a fractal surface. And we do not need the normal if the > reflection model for the fractal is Lambertian :) I'm confused. Does the formula apply if the fractal surface self occludes? What about fractally defined aggregate surfaces (e.g. a ball of cotton) ** On bias vs. variance (noise) > For algorithms which are merely consistent, however, we must also > bound the bias. (...) Bias shows up as results that are not noisy, > but in fact are incorrect. In graphics algorithms, this error is > often noticeable visually, in the form of discontinuities, excessive > blurring, or surface shading that just looks wrong. Not necessarily bound it but *blend* it between visually coherent regions such that the bias is not noticeable. I know the scientifically correct way would be to bound bias, but if the end product is an aesthetic image rather than actual luminance statistics, you can probably produce something acceptable by removing unnecessary variation via judicious use of interpolation. This amounts to filtering over the finite elements of course. > Finite element methods also have advantages, I just didn't mention > them. I didn't mean to write this much... Just that no one else was speaking up for FE. Please feel free to rebut since I'm about to invest a massive amount of time implementing a hairy hierarchical global illumination multigridded FE method with importance sampling etc. :-) Adrian -- Oh and since no one has answered this at time of writing... K. R. wrote: > I wonder if any of you have read carefully through Foley > Van Dam's explanation of diffuse reflection. The explanation is > either misleading or incorrect. Lambert's law is claimed to be > related to the viewer location/angle.. I quote, > > "... that the amount of light reflected from a unit differential > area dA towards the viewer is directly proportional to the cosine of > the angle between the direction of viewer and N..." Depends on what is meant by "amount of light". If referring to energy or power directed towards the viewer then this is correct. Since radiance is constant over the hemisphere the "amount of light" will depend on area projected by the unit differential area towards the viewer which will indeed be proportional to the cosine of the angle between N and view direction.(A simple check: if N is at right angles to your view, the differential area is a silhouette, projects zero area on the image, hence cannot be seen) In practice this calculation is taken care of by the perspective/orthographic projection or by sampling in the image domain. Most implementations take the cosine of the angle between N and a light source direction in order to estimate how much light energy was being intercepted by the surface in the first place to determine what constant value the radiance will take. It is misleading in that the terminology isn't quite clear. (Did that make any sense or did I just make a fool of myself?) From owner-globillum@imag.fr Tue Nov 12 12:08:44 1996 Return-Path: Sender: greg@lightscape.com Date: Tue, 12 Nov 1996 10:53:38 -0800 From: Greg Spencer Organization: Lightscape Technologies, Inc. http://www.lightscape.com To: globillum@imag.fr Subject: Lens Calibration summary Status: R I got so caught up in the FE vs. MCPT thread, I forgot to post the summary of lens calibration responses that I got. I got several possibilities, and even found that elusive "company" in europe that I had heard abnout. It turns out that the "company" is actually a photogrammetry department at University College London, and they will measure lenses for a fee of 522.50 pounds (see attached message for address, etc.). Michael Cohen reports that Tsai's method is satisfactory for most uses as long as you can get the images scanned in reliably. The drawbacks I see are that Tsai's method only models radial distortion, and doesn't handle any chromatic or intensity issues. I also found a piece of Macintosh photogrammetry software that will take an image which contains their calibration target and provide you with radial distortion and other information about the camera system. It is designed for CCDs, but reportedly could be used for any camera system where the scanning of the image was consistent. The name of the software is "Opti-CAL", and the contact for information is gchow@kinetic.bc.ca. If anyone is interested, I have a technical summary that they sent me on the product. Ken Musgrave's friend (who is a lens designer) suggested that if one wishes to model the optics directly to determine a mapping (as in Craig Kolb's SIGGRAPH paper), lens patent descriptions may be used to find out information on the configurations of the lenses. -Greg. -- Greg Spencer, Software Engineer greg@lightscape.com Lightscape Technologies., Inc. (408) 342-1900 http://www.lightscape.com (PGP key available upon request) ---------------------------------snip-------------------------------- Subject: Re: Lens measurement? From: Leoni Blank We do have a service for calibrating cameras in our dept. (Department of Photogrammetry and Surveying, UCL). We normally deal with photogrammetric metric cameras, but can also measure semi and non metric cameras. We calibrate for lens distortion, principle distance, and principle point position. However we do not consider chromatic abberation or intensity falloff. We do charge for this service, if you send the camera to us then we will carry out the calibration and issue a certificate for 522.50 pounds. If you want any details then please email me, and let me know what kind of camera you have. Leoni Blank Department of Photogrammetry and Surveying UCL Gower Street London WC1E 6BT From owner-globillum@imag.fr Tue Nov 12 14:46:20 1996 Return-Path: From: Paul.Heckbert@HOSTESS.GRAPHICS.CS.CMU.EDU Date: Tue, 12 Nov 96 16:46:37 EST To: globillum@imag.fr Subject: Re: Foley,Van Dam - diffuse reflection.. Status: R I hadn't noticed that one, but if we're collecting weaknesses of that book, I've been quite disappointed by their discussion of gamma correction. In my undergrad graphics class (see my web page), I always tell my students to skip the gamma correction section of Foley et al's book and to read Blinn's column on that topic instead: James F. Blinn Dirty Pixels IEEE Computer Graphics & Applications July 1989 pp. 100-105 By the way, somebody should collect up these comments on Foley's book and forward them to Foley et al. Paul Heckbert Computer Science Dept., Carnegie Mellon University 5000 Forbes Ave, Pittsburgh PA 15213-3891, USA ph@cs.cmu.edu http://www.cs.cmu.edu/~ph From owner-globillum@imag.fr Wed Nov 13 16:32:54 1996 Return-Path: From: jfh@cs.washington.edu (John Hughes) Subject: [krs@strauss.cs.uncc.edu: Foley,Van Dam - diffuse reflection..] (fwd) To: globillum@imag.fr Date: Wed, 13 Nov 1996 15:27:45 -0800 (PST) Cc: avd@cs.brown.edu, foley@merl.com, feiner@cs.columbia.edu Status: R David Salesin was kind enough to forward the following message to me, and I figured that I'd try to address it. First of all, let me admit that our book has many errors, all of which we try to track in our "Bug List," which is available by sending mail to graphtext@cs.brown.edu. But I believe that the "error" below is one of the (many?) places where we actually got it right. > "...Second, we must consider the amount of light seen by the viewer. Lambertian > surfaces have the property, often known as Lambert's law, that the amount > of light reflected from a unit differential area dA towards the viewer is > directly proportional to the cosine of the angle between the direction of > viewer and N..." I believe that the statement above is correct; but you need to note that it says that the amount reflected *from a unit differential area* is proportional to the cosine of the *view-to-normal* angle. But a single bit of your eye (one receptor, for example) will actually see more or less surface depending on the viewing angle. That's what the next sentence says: "...Since the amount of surface area seen is inversely proportional to the cosine of this angle, these two factors cancel out." The phrase "this angle" has antecedent "the angle between the direction to the viewer and N", and "two factors" has antecedents "directly proportional to the cosine of ..." and "inversely proportional to the cosine of...". > They go on to use this to explain how the intensity is constant in all > directions. However, on the one hand the angle theta is between the > normal and the light vector, while the second angle is between the viewer > and N. These are certainly not the same. The symbol theta is only used to denote the angle between the direction to the light source and the normal. The direction-to-viewer/normal angle is not given a symbol anywhere in the discussion, but is simply described as it is used, two times (which happen to cancel out). * * * Paul Heckbert also commented on Gamma Correction. There, too, I think that the explanation is correct, although I personally am not in love with the presentation of the material -- if we were to do it over again, and I had a chance to rewrite *that* bit, I'd be inclined to do it differently. Anyhow, I feel sure that I speak for my coauthors as well when I say that we really *are* sorry about the errors in the text, and hope that the stuff that's right makes up for it. Some of the errors come directly from the source material (I won't say here whose papers had incorrect descriptions of the work which was only fixed in subsequent papers, but such errors do abound), others are our fault alone. It's also interesting to see one's own errors propagated to other texts, whose authors apparently didn't bother to read the original papers themselves. It's annoying, however, to see whole chunks of one's (correct) prose copied verbatim to other texts without attribution :-(. -John Hughes From owner-globillum@imag.fr Thu Nov 14 15:24:34 1996 Return-Path: X-Lotus-Fromdomain: IBM RESEARCH From: "Holly Rushmeier" To: globillum@imag.fr Date: Thu, 14 Nov 1996 16:56:33 -0400 Subject: ACM TOG Status: R Hi -- I don't know if you have noticed, but over the past year TOG (Transactions on Graphics) has had a number of papers of interest to globillumers, e.g. in the Jan. 1996 issue there were: " Monte Carlo Techniques for Direct Lighting Calculations" , by Peter Shirley, Chang Yaw Wang, and Kurt Zimmerman and "Global Illumination of Glossy Environments Using Wavelets and Importance" by Per H. Christensen, Eric J. Stollnitz, David H. Salesin, and Tony D. DeRose The Oct. 1996 issue also has some papers you may be interested in, such as: "Image Shading Taking into Account Relativistic Effects" "Quadrature Prefiltering for High Quality Antialiasing" "Computing the Discrepancy with Applications to Supersampling Patterns", and for a limited time you can download the **full text** of these articles in PDF format from the TOG web page at: http://www.acm.org/tog/Current.html -- Holly From owner-globillum@imag.fr Thu Nov 21 15:51:31 1996 Return-Path: X-Lotus-Fromdomain: IBM RESEARCH From: "Holly Rushmeier" To: spencer@emily.cgrg.ohio-state.edu Cc: globillum@imag.fr Date: Thu, 21 Nov 1996 18:07:47 -0400 Subject: Re: reflection questions Status: R --0__=vfu87zv95JMeA0CfIvMoLJGFwwDa5RnyIRVAAtpdGQpKuV3CerLQVb1f Content-type: text/plain; charset=us-ascii The bibliographic reference is correct, and what the paper describes is the implementation of the Sanford-Robertson model to one reflection from a surface for infrared signature generation (since the bulk of the signature is emission, one bounce is a fairly small percentage of the signature, and multiple bounces don't add much.) Anyway, the ERIM page Pete referred to http://www.erim.org/on-line-docs/GUIDE/guide.frm.html was prepared by Ken Ellis, who can probably answer questions about the source of the various equations. If the email on web page doesn't work, try ellis@aaec.com. I believe he works for Atlantic Aerospace. He has a recent paper on first principle reflectance modeling you might find interesting: "First-Principles Coatings Reflectance Model Validation" Ellis, Jones, Chu, and Lynn Sixth Annual Ground Target Modeling and Validation Conference, Houghton,MI, 22-24 Aug. 1995 If you have trouble finding the paper, you could email to one of the information addresses on the ERIM home page at http://www.erim.org/ -- Holly To: globillum @ imag.fr cc: (bcc: Holly Rushmeier/Watson/IBM Research) From: spencer @ emily.cgrg.ohio-state.edu Date: 11/21/96 01:42:19 PM Subject: Re: reflection questions --0__=vfu87zv95JMeA0CfIvMoLJGFwwDa5RnyIRVAAtpdGQpKuV3CerLQVb1f On Thu, 21 Nov 1996, Peter Shirley wrote: > 2. A paper by [Rushmeier and Tynor, 90] is alluded to, with > no title or bibliography entry. What is it (I have a feeling > our friend HR can answer this one). From the SIGGRAPH Computer Graphics Bibliography Database comes: @InProceedings{Rushmeier:1990:IBI, author = "Holly E. Rushmeier and Stephen D. Tynor", title = "Incorporating the {BRDF} Into an Infrared Scene Generation System", year = "1990", month = apr, volume = "1311", booktitle = "Conference on Characterization, Propagation and Simulation of Infrared Scenes, SPIE Proceedings", address = "Orlando, Florida", } Is this information correct, Holly, or does it need adjustment? Stephen N. Spencer 614.292.3416 (v) Graphics Research Specialist spencer@siggraph.org 614.292.7776 (f) ACCAD - The Ohio State University spencer@cgrg.ohio-state.edu SIGGRAPH Director for Publications spencer@acm.org "After ecstasy, laundry." - Zen writing --0__=vfu87zv95JMeA0CfIvMoLJGFwwDa5RnyIRVAAtpdGQpKuV3CerLQVb1f-- From owner-globillum@imag.fr Thu Nov 21 10:34:01 1996 Return-Path: From: shirley@phong.cs.utah.edu (Peter Shirley) Subject: reflection questions To: globillum@imag.fr Date: Thu, 21 Nov 1996 09:23:07 -0700 (MST) Status: RO Hi all. I was recently pointed to the web page: http://www.erim.org/on-line-docs/GUIDE/guide.frm.html Which has a discussion of several BRDF models. It has several small errors, but also some very good information. I have two questions that arise from it I hope somebody can answer: 1. In Equation 8, the "glossy coating BRDF", there is a specular reflectance (surface term) and a subsurface term: rho0 [ 1-R(thetai) ] [ 1-R(thetar) ] / (PI n^2) where rho0 is the diffuse refectance of the substrate, thetai and thetar are angles to the normal, R is the surface (Fresnel) term, and n is the refractive index. This is very similar to a model I arrived at independently, so I want to track the source down. Anybody know where it is from? 2. A paper by [Rushmeier and Tynor, 90] is alluded to, with no title or bibliography entry. What is it (I have a feeling our friend HR can answer this one). Thanks Pete From owner-globillum@imag.fr Thu Nov 21 11:43:53 1996 Return-Path: Date: Thu, 21 Nov 1996 13:42:19 -0500 (EST) From: "Stephen N. Spencer" To: globillum@imag.fr Subject: Re: reflection questions Status: RO On Thu, 21 Nov 1996, Peter Shirley wrote: > 2. A paper by [Rushmeier and Tynor, 90] is alluded to, with > no title or bibliography entry. What is it (I have a feeling > our friend HR can answer this one). >From the SIGGRAPH Computer Graphics Bibliography Database comes: @InProceedings{Rushmeier:1990:IBI, author = "Holly E. Rushmeier and Stephen D. Tynor", title = "Incorporating the {BRDF} Into an Infrared Scene Generation System", year = "1990", month = apr, volume = "1311", booktitle = "Conference on Characterization, Propagation and Simulation of Infrared Scenes, SPIE Proceedings", address = "Orlando, Florida", } Is this information correct, Holly, or does it need adjustment? Stephen N. Spencer 614.292.3416 (v) Graphics Research Specialist spencer@siggraph.org 614.292.7776 (f) ACCAD - The Ohio State University spencer@cgrg.ohio-state.edu SIGGRAPH Director for Publications spencer@acm.org "After ecstasy, laundry." - Zen writing From owner-globillum@imag.fr Fri Nov 22 13:17:36 1996 Return-Path: From: "Nelson L. Max" Date: Fri, 22 Nov 1996 11:53:37 -0800 Reply-To: max2@llnl.gov To: globillum@imag.fr Subject: Cloud shading Status: R I was just looking out my window at some beautiful clouds, and I think I have finally figured out why their edges are dark! The clouds were lit by the sun from the upper right, at 90 degrees to my viewing direction, but their right hand and upper edges still looked dark when viewed against more distant clouds of the same white color. If each water droplet scattered or absorbed the same amount of light in all directions, the color would depend only on the integrated density of droplets along a viewing ray (column density), and not on their density distribution along the ray. If anything, one would expect the sunlit droplets at the edge of a cloud to scatter more light than those inside. The answer is that they probably do, but at the tenuous edge of the cloud, the probability of multiple scattering is lower, so that the highly forward scattering in the water droplets does not undergo enough multiple scattering for its direction to be randomized. Looking from the side, I saw less than my share of this forward scattered light, although the extinction (absorption) of these edge droplets still attenuated the light from behind according to their column density. When the sun is directly behind a cloud, the edges look much brighter, due to the forward scattering, so everything balances out. -- Nelson Max http://www.llnl.gov/graphics max2@llnl.gov Lawrence Livermore National Laboratory (510) 422-4074 7000 East Avenue fax (510) 423-8704 Livermore, CA 94550, USA From owner-globillum-imag@imag.fr Wed Nov 27 14:33:29 1996 Return-Path: From: shirley@phong.cs.utah.edu (Peter Shirley) Subject: International Conference on ISST To: globillum@imag.fr Date: Wed, 27 Nov 1996 14:28:09 -0700 (MST) Status: R I have not been to this conference, but will probably go since it is driving distance from me. More importantly, it is my karma to go. Excerpts from the announcement at http://www.lcc.uma.es/personal/mana/CISST2.html Title of session: Monte Carlo Methods for Physically Based Rendering and.... The conference will be held in the Monte Carlo Resort and Casino hotel, Las Vegas, Nevada, USA. If anybody has any comments on this conference, please share them. Pete From owner-globillum-imag@imag.fr Tue Dec 3 10:30:20 1996 Return-Path: From: Paul.Heckbert@HOSTESS.GRAPHICS.CS.CMU.EDU Date: Tue, 3 Dec 96 11:08:20 EST To: shirley@PHONG.CS.UTAH.EDU Subject: Re: International Conference on ISST Cc: globillum@imag.fr Status: RO Re: Peter Shirley's email about the conference: International Conference on Imaging Science, Systems, and Technology CISST'97 June 30 - July 2, 1997 Las Vegas, Nevada, USA http://www.lcc.uma.es/personal/mana/CISST2.html Hmmm, the web page says there will be a self-appointed program committee / session chairs / associate editors. Sounds quite suspicious, frankly. I wouldn't be surprised if their acceptance rate is near 100%. I would predict highly variable paper quality. There is an excellent water slide in Las Vegas, however! :-) I just participated in a workshop where only 3 out of 28 papers submitted were rejected, but it was still worthwhile, however. Are you familiar with the VIDEA story? Beware of VIDEA!, an amusing and troubling account of a bogus conference, reported by Purgathofer, Groeller, and Feda of the U of Vienna. From owner-globillum-imag@imag.fr Tue Dec 10 19:53:38 1996 Return-Path: From: "Ian Ashdown" To: Subject: Radiosity bibliography update Date: Tue, 10 Dec 1996 19:02:16 -0800 X-Msmail-Priority: Normal X-Priority: 3 Status: R ANNOUNCE: 96/12/15 Release of RADBIB96 -------------------------------------- RADBIB96 is a comprehensive bibliography of radiosity and related global illumination papers, theses, articles, and books. The total number of references is now 1,008 (including four U.S. patents on radiosity techniques). This bibliography is available in BibTex format as RADBIB96.BIB (with a release date of December 15, 1996) from: http://www.ledalite.com/library-/rrt.htm and as compressed RadBib96.Z from: ftp://hobbes.lbl.gov/pub/doc As always, it is time-consuming and sometimes difficult to track down conference papers and theses on radiosity and global illumination. If you know of a relevant reference that is not included in the bibliography, please let me know so that I can include it in the next release. --- Ian Ashdown, P. Eng. Research & Development Manager Ledalite Architectural Products Inc. http://www.ledalite.com From owner-globillum-imag@imag.fr Fri Dec 20 14:06:05 1996 Return-Path: Date: Fri, 20 Dec 1996 12:52:21 -0500 From: Eric Haines To: globillum@imag.fr Subject: new ray tracing bibliography available Cc: erich@hemlock.eye.com Status: R I have made the latest version of the ray tracing bibliography which Paul Heckbert and I compiled (with help from many others) available at: http://www.acm.org/tog/resources/bib/ Let me know of any errors or missing references. I've tried to limit new entries to those directly dealing with ray tracing itself as a rendering algorithm or that talk about monte carlo sampling or volume visualization using ray tracing (as opposed to references which mention ray tracing simply as another tool, which for the most part it has become). Eric Haines erich@acm.org From owner-globillum-imag@imag.fr Sat Dec 28 13:14:31 1996 Return-Path: From: "Ian Ashdown" To: Subject: Global illumination validation studies Date: Sat, 28 Dec 1996 12:31:32 -0800 X-Msmail-Priority: Normal X-Priority: 3 Status: RO Chas Ehrlich at Lawrence Berkeley National Lab uncovered these two Web pages: "Physically Accurate Lighting Simulation in Computer Graphics Software" URL: http://rmp.kiam1.rssi.ru/articles/pals/pals.htm "Comparison of Two Methods of Global Illumination Analysis" URL: http:://rmp.kiam1.rssi.ru/articles/cmgia/cmgia.htm I bring them to the attention of this mailing list because: (a) Very few papers have been written on the physical validation of radiosity and global illumination algorithms; (b) The information presented in these Web pages constitute complete technical reports, yet do not appear to have been otherwise published; and (c) The authors compare Lightscape, Radiance, and Specter (Integra Inc.) with some interesting conclusions. Ian Ashdown, P. Eng. Research & Development Manager Ledalite Architectural Products Inc. From owner-globillum-imag@imag.fr Sat Dec 28 21:26:43 1996 Return-Path: Sender: crs@uunet.uu.net Date: Sat, 28 Dec 1996 21:03:02 -0800 From: Chris Schoeneman To: Ian Ashdown Cc: globillum@imag.fr Subject: Re: Global illumination validation studies Status: RO Ian Ashdown wrote: > > Chas Ehrlich at Lawrence Berkeley National Lab uncovered these two Web > pages: > > "Physically Accurate Lighting Simulation in Computer Graphics Software" > URL: http://rmp.kiam1.rssi.ru/articles/pals/pals.htm > > "Comparison of Two Methods of Global Illumination Analysis" > URL: http://rmp.kiam1.rssi.ru/articles/cmgia/cmgia.htm This was very interesting reading. From what I know of LVS, most conclusions sounded pretty reasonable. I noted that they used LVS version 1.2.4. My guess is that version 1.3 (available for well over a year) would have given more accurate results, at least for the CUBE test. Version 2.0 would be better still. Both of these versions accurately solve an environment with an analytical solution (the inside of a cube where each face is a perfect diffuse emitter), while 1.2.4 (if I recall correctly) failed this test. In any case, I did find some unexpected conclusions. 1. In APART2 they're surprised by the specular reflection model used by LVS. They assume it's incorrect but it is in fact demonstrating the angular dependence of reflectivity. Whether the model is accurate could be the subject of a similar analysis. 2. In the DREAM0 evaluation they state that LVS doesn't have `cone' lights. Well of course LVS does have them (it calls them spot lights). 3. Also in DREAM0 they note bleeding of light from the red carpet on a corner in the cove with the blue carpet. It shouldn't be there and they say they can't explain the effect. It looks like a light leak, which they should recognize. I'd be more comfortable with their conclusions if they clearly stated that it wasn't a light leak and that the models were constructed to avoid light and shadow leaks. Still, since the ROOM model is from Lightscape it's safe to assume that it is so constructed. And since it fails to match Specter and Radiance, it's pretty clear that LVS 1.2.4 isn't as accurate as either. Perhaps it's my bias from having worked at Lightscape, but at a visceral level I generally find the Lightscape images much more realistic looking than either the Specter or Radiance images. Too bad they're not as accurate. Many thanks to Chas and the authors for making this known. Cheers, -chris From greg Mon Dec 30 14:20:44 1996 Return-Path: Date: Mon, 30 Dec 96 14:20:07 PST From: greg (Gregory J. Ward) To: Oek@int.keldysh.ru Subject: lighting simulation comparisons Cc: chas, globillum@imag.fr, iashdown@ledalite.com Status: R This is very good work (referring to the comparison between Lightscape, Spectre and Radiance at http://rmp.kiam1.rssi.ru/articles/pals/pals.htm). Is this going to be a technical report somewhere? I would like to learn more about Spectre also. I have followed this program through its various name changes, but never actually spoken to someone with a copy of it. It sounds like it has come a long way, and is worth a closer look. Can you send us a working web address for this product (the link on your report seems to be broken)? I was a bit disappointed at the quality of the Radiance renderings you showed, and I wonder if you used the new "rad" interface to generate them? This is an executive script that makes the control of calculation parameters and image filtering much more automatic and natural, and would reduce or eliminate many of the artifacts you are seeing, which are the result of poor parameter choices or (in the case of the aliasing artifacts) missing the final image filtering pass. This same program also has a GUI, called trad, which makes running and controlling the rendering process much easier. I was very pleased to see the in-depth analysis of the three calculation methods. I was particularly intrigued by Spectre's apparent ability to control the overall simulation accuracy. Since this quantity is intricately tied to the geometric modeling and the resolution of the illumination map, however, I am not sure exactly what is being controlled here. I notice in the comparison of absolute error, that Spectre did not seem to have as good a handle on its calculation as implied by this accuracy parameter. In my own research on global illumination, I have found such absolute error bounds to be extremely elusive. The work on this by Arvo and others has shown some promise for error limits at radiosity mesh points, but of course this says nothing about what's going on between mesh points, and this is for diffuse-only environments besides. Monte Carlo methods can offer statistical error estimates for arbitrary environments, but achieving specific accuracy tolerances at some pixels is next to impossible using conventional methods. (I won't scoop Eric Veach, who seems to have found a very promising new MC technique which I hope will appear in the literature sooner rather than later.) There were some other, very minor, errors in your exposition, which I would be happy to correct if you like. The main problem in my view was the way Radiance was used, which had a large effect on the results. I admit that it is not at all clear for the new user how to best apply this software, even if they have an excellent understanding of the underlying algorithms. I am hoping to remedy this situation with the publication of a book from Wiley, which will hopefully be available by this Summer. Please forward this also to Andrei, as I did not find his e-mail address. Thanks! -Greg Ward From greg Mon Dec 30 14:48:31 1996 Return-Path: Date: Mon, 30 Dec 96 14:47:56 PST From: greg (Gregory J. Ward) To: Oek@int.keldysh.ru Subject: P.S. to last message Cc: chas, globillum@imag.fr, iashdown@ledalite.com Status: R If you want to see some other examples of how close Radiance can come to reality (I always do), check out the following web page: http://sap.mit.edu/projects/studioimages.html This is work done independently by Philip Thompson and Jack DeValpine at MIT. -Greg From abkhod@gin.keldysh.ru Mon Jan 6 07:45:24 1997 Return-Path: Date: Mon, 06 Jan 1997 18:42:57 +0300 From: Andrei Khodulev Reply-To: abkhod@gin.keldysh.ru Organization: Integra To: globillum@imag.fr Cc: greg@hobbes.lbl.gov, crs@pop.net Subject: Re: lighting simulation comparisons Status: RO Some year and half ago we requested providers of physically accurate lighting simulation software to deliver their software for the purpose of evaluation. We did our best to perform as unbiased benchmarks as possible. The results has been published in Graphicon 96 and posted on our (KI) home page http://rmp.kiam1.rssi.ru/articles/pals since May 1996. As people behind Radiance (Greg Ward) and LVS (Chris Shoeneman) are not necessarily satisfied with the way their software has been used in comparisons we are ready to repeat the benchmarks following the additional information. We also welcome others who are willing to deliver their software for benchmarking. Andrei Khodulev, abkhod@gin.keldysh.ru Edward Kopylov, oek@gin.keldysh.ru P.S. There is also a paper "Comparison of two Methods of Global Illumination Analysis" devoted to comparison of Deterministic and Monte Carlo algorithms of global illumination analysis. http://rmp.kiam1.rssi.ru/articles/cmgia/ Andrei Khodulev. From owner-globillum-imag@imag.fr Tue Jan 7 11:50:24 1997 Return-Path: Sender: ajc@imag.fr Date: Tue, 07 Jan 1997 13:20:22 +0000 From: "Adrian J. Chung" Organization: Dept. of Computing, Imperial College To: globillum@imag.fr Subject: teamcad2@cc.gatech.edu X-Url: http://w3imagis.imag.fr/Membres/Francois.Sillion/GlobillumList.html Status: R Okay, okay... who subscribed to the teamcad2@cc.gatech.edu Majordomo mailing list? I infer that this is why John Tidmus (and perhaps a lot of other people) are receiving email meant for teamcad2 without having themselves subscribed. Although the subject areas of teamcad2 and globillum are perhaps closely related I think it is a bad idea to subscribe entire mailing lists to other mailing lists in this way because: * You can't unsubscribe yourself individually from the "super" mailing list only. * You might accidentally create a cycle between listservers. (What would happen if teamcad2 were to become a recipient of the globillum email?!?) * Shouldn't all members of globillum have been consulted before such a move being made? Did I miss the vote or something? Looking through the mailing list of teamcad2 I see that several members of globillum are subscribed individually and sometimes several times: Francois Sillion Francois Sillion F. Sillion Curiouser and curiouser... Adrian. -- PS. Under what conditions would 40 samples per pixel in MCPT be enough to visualise a double-refracted caustic? This is in reference to J. T. Kajiya's landmark SIGGraph '86 paper the "The Rendering Equation". The caustics cast in his tetrahedron of glass balls image seem so noise free. I wonder how they did it. PPS. The above PS is a thinly disguised attempt to keep this email message on topic for the mailing list. Sorry for all the clutter adding to the mailing list complaints... From owner-globillum-imag@imag.fr Tue Jan 7 23:37:36 1997 Return-Path: From: Francois Sillion Subject: Teamcad problem resolved To: globillum@imag.fr (Global Illumination List) Date: Wed, 8 Jan 1997 08:09:40 +0100 (MET) Reply-To: Francois.Sillion@imag.fr Status: R Dear globillumers, first of all, a happy new year to all ! Most of you have noticed a very annoying problem with the teamcad and teamcad2 mailing lists. These lists included the globillum alias, without having asked the globillum recipients or myself for approval. This was a simple mishap and the people at Georgia Tech are very sorry. Now I understand that globillum should have been removed from these lists. The confusion only grew because so many people responded to the first teamcad messages and copied their answers to the list! The second message I want to send to globillumers is that we are undergoing some technical changes here as globillum has been moved to a list server. Apparently everything works fine but it means that some people who have requested to be on the list have not been added yet. If you know anybody in this situation... tell them I'll work on it as soon as possible ! +------------------+------------------------------------------------------+ | Francois SILLION | iMAGIS - GRAVIR/IMAG, B.P. 53, 38041 Grenoble Cedex 9| | ' | France. Tel:+33 4 76 51 43 54 - Fax:+33 4 76 44 66 75| +------------------+----------+-------------------------------------------+ | Francois.Sillion@imag.fr | http://w3imagis.imag.fr/~Francois.Sillion | +-----------------------------+-------------------------------------------+ From owner-globillum-imag@imag.fr Thu Jan 9 10:03:50 1997 Return-Path: X-Lotus-Fromdomain: IBM RESEARCH From: "Holly Rushmeier" To: globillum@imag.fr Date: Thu, 9 Jan 1997 09:55:51 -0400 Subject: Need refs. about need Status: R Hi -- One of the people working on the appearance project at NIST asked me for "some references that talk about the need for measurements of appearance properties of materials." A lot of people ask about where to find catalogs of measurements etc., but I am having a hard time finding "citable" references for the need for measurements. If you have written anything, either technical paper or more informal "position" paper that could be cited about the need for measurements to support realistic rendering please let me know. Or, if you haven't written anything, but would be willing to be quoted about how your work would benefit by the availability of measurements, or measurement techniques, let me know. Thanks, Holly From owner-globillum-imag@imag.fr Wed Jan 15 18:06:06 1997 Return-Path: Date: Thu, 16 Jan 1997 02:12:01 +0100 From: Eduardo Bustillo Iceta To: globillum@imag.fr Subject: kd-tree Status: R Hi globillumers :) I am preparing a paper on a new globillum rendering technique and I am trying to implement several other methods in my rendering architecture for comparison and benchmarking. One of these methods is the photon map. Reading H.W. Jensen's "Global illumination using photon maps" paper there is a reference to Bentley's kd-tree M nearest point searching algorithm. Jensen explains that this algorithm can find the M nearest (euclidean distance) photons to any given point in a N point set in O(M log2 N) time. Due to the shortage of CS books in my school I have been unable to find Bentley's paper :( I have worked out another method creating 3 sorted lists (one for each coord.) and doing the following: -For the first coord. I search for the M closest 1D photons right and left from the nearest. -For the other coords. I also search right and left from the closest 1D point in the list and within a constantly updated range given by the longest euclidean distance of the M photons found to that point to update the M nearest photons list. The longest distance bounds the 1D range so that photons outside it must be farther away. This method is much worse than O(M log2 N) making it almost worthless. I have been thinking about how it could be performed using a kd-tree but it seems much more prepared to handle hypercubes than hyperspheres... I am sorry to put this question on the list as it might sound quite naive but if any of you could be kind enough to point me the right way (as in Bentley's), I would be really grateful as I have been thinking of changing to an octree structure or hanging myself :) Thanks a lot, Eduardo. --- Eduardo Bustillo Iceta Particular de Basterra 1 48990 Getxo (Vizcaya) SPAIN e-mail: ebic@jet.es ebic@acm.org From owner-globillum-imag@imag.fr Mon Jan 6 11:39:42 1997 Return-Path: Date: Mon, 06 Jan 1997 21:54:35 +0300 From: Andrei Khodulev Reply-To: abkhod@gin.keldysh.ru Organization: Keldysh Inst. of Appl. Math. To: greg@hobbes.lbl.gov Cc: globillum@imag.fr, chas@hobbes.lbl.gov, iashdown@ledalite.com Subject: Re: lighting simulation comparisons Status: RO Dear Greg, Hello from Andrei Khodulev, with whom You exchanged some letters in 1992. >I would like to learn more about Spectre also. I have followed >this program through its various name changes, but never actually >spoken to someone with a copy of it. >It sounds like it has come a long way, and is worth a closer >look. Can you send us a working web address for this product >(the link on your report seems to be broken)? Integra Inc. is in the process of establishing official page in English. For this reasons links are not available. At this point only Japanese page exist: http://www.kt.rim.or.jp/~integra/ Mr. A. Fujimoto, the president of Integra Inc., was asked about preparation of non-commercial version of SPECTER that can be used by others for comparison study analogous to our one. Please wait for answer from him. COMPARISON As You (and apparently LVS) are not satisfied with the way RADIANCE (LIGHTSCAPE) has been used we are going to repeat the comparison following your advises and with new software version(3.0 ?). Today we sent a message to globillum at this topic and welcome others who are willing to deliver their software for benchmarking. I think it will take finite time until all information is completed and conditions are agreed among the interested parties. >I was a bit disappointed at the quality of the Radiance renderings you >showed, and I wonder if you used the new "rad" interface to generate >them? > This is an executive script that makes the control of calculation >parameters and image filtering much more automatic and natural, and would >reduce or eliminate many of the artifacts you are seeing, which are the >result of poor parameter choices or (in the case of the aliasing artifacts) >missing the final image filtering pass. > > >This same program also has a GUI, called trad, which makes running and >controlling the rendering process much easier. > You pointed our serious mistake: we refer to RADIANCE 2.5 (and we actually used it for benchmarks!) while obsolete Reference Manual (for previous 2.4 version) was used. So, we knew nothing about 'trad'. What concerns to 'rad' we found it more convenient to call the batch programs ('oconv', 'rpict', 'ximage') directly as we need sometimes rather long calculations. Maybe we missed some possibilities offered by 'rad'. Filtering was not used at all. Apparently we met some problems with its usage. >I was particularly intrigued by Spectre's apparent ability to >control the overall simulation accuracy. Since this quantity is intricately >tied to the geometric modeling and the resolution of the illumination map, >however, I am not sure exactly what is being controlled here. > Have you seen the paper "Comparison of two Methods of Global Illumination Analysis" at http://rmp.kiam1.rssi.ru/articles/cmgia/monte_carlo.htm ? Section 3.1 of this paper contains detailed explanation of how accuracy is controlled in Specter. We'll be very grateful to You for any remarks. The reason for this request is that some readers find this part unclear. >I notice in the comparison of absolute error, that Spectre did >not seem to have as good a handle on its calculation as implied >by this accuracy parameter. In my own research on global >illumination, I have found such absolute error bounds to be >extremely elusive. > Yes, we also found that the accuracy control Specter provides is not always natural for user. Actually, the Specter's accuracy measure is frequently used in relative manner: we don't know how the value reported relates to perceptual quality, but we can rely that decreasing of this value twice will lead to twice as good image. >There were some other, very minor, errors in your exposition, >which I would be happy to correct if you like. > > >The main problem in my view was the way Radiance was used, which >had a large effect on the results. > Any remarks are welcome. > I admit that >it is not at all clear for the new user how to best apply this software, >even if they have an excellent understanding of the underlying algorithms. >I am hoping to remedy this situation with the publication of a book from >Wiley, which will hopefully be available by this Summer. > Is there any possibility to get draft of this book in electronic from? Thank you in advance. >If you want to see some other examples of how close Radiance can come to >reality (I always do), check out the following web page: > >http://sap.mit.edu/projects/studioimages.html > >This is work done independently by Philip Thompson and Jack DeValpine at >MIT. > Can we get scenes used to generate these images? We could use them in our comparison. With best regards, Edward Kopylov, Andrei Khodulev. From greg Tue Jan 21 12:18:44 1997 Return-Path: Date: Tue, 21 Jan 97 12:17:56 PST From: greg (Gregory J. Ward) To: abkhod@gin.keldysh.ru Subject: Re: lighting simulation comparisons Cc: chas, globillum@imag.fr, iashdown@ledalite.com Status: R Hi Andrei, I am just getting to comment on your web pages, and I'll just write about what I notice as I go through it (the comparison and validation pages): In http://rmp.kiam1.rssi.ru/articles/pals/radiance.htm, Section 3.1: Note that Radiance has not possibility to specify point or cone light sources at all, i.e. when the light starts from abstract point. As an approximation to point light in Radiance a small lighting sphere can be used. If by "cone light sources" you mean spotlights, there is a spotlight material type that can be used to produce light in cones, not that any such ideal exists in the real world. As for point sources, the spheres may be arbitrarily small. Radiance has not intelligent sampling of light sources. The only case that is handled properly is parallelograms. Light sources in form of sphere are not sampled at all in Radiance. Other sources are approximately rectangular (ref. to Radiance Digest, v2n5.2, 537 line). This is not entirely accurate. It is true that parallelograms are the only sources that are sampled exactly correctly, but the sampling of most other source shapes is approximately correct. Spheres are sampled over a cubic area, which though inaccurate in some sense, does not result in great inaccuracies in the result, and it is considerably faster than doing it exactly as a sphere. I hope you read all of the Radiance Digest section you reference, as Peter did find out that he had been making a mistake in his integration, and that Radiance was actually converging to the correct result. You mention that the conversion from IES luminaire files is "not correct." Again, it is an approximation, as is EVERYTHING in lighting simulation! It doesn't help matters to make inflammatory remarks, especially when you fail to make them for the other packages. None of the packages can model the arbitrarily strange shapes included in the IES specification, and Radiance simply chooses the closest approximating geometry, which is what the other packages must do, also. Section 3.2: Radiance does not "subdivide surfaces into patches." The algorithm employed never makes use of any explicit geometric subdivision of any kind, but relies instead on unorganized point value interpolation. The octree is used for point lookup, but does not decimate the scene. This way, values may be shared between surfaces and subsurfaces on an arbitrary topology, which is a unique feature of the system. You say that Radiance does not handle semispecular surfaces efficiently, when in fact it does, at least as efficiently as Specter. Except for the user-specified BRDF types, all light interactions are accounted for in Radiance, and the process proceeds efficiently from the point of measurement (i.e., the viewpoint) backwards to the light sources. Ideal specular surfaces are treated with the special material types you mention in order to avoid the source-finding problem of light-backwards ray tracing, and the corresponding shadow accuracy (i-map resolution) problem of light-forwards ray tracing. The efficiency enhancements you mention for limiting the cost of the virtual light source calculation are OPTIONAL. For people who insist on accuracy guarantees (which by the way are completely bogus, because light propogation is a probabilistic process), can change these parameters to guarantee results. The runaway creation of virtual sources is still avoided by geometry checks that are 100% reliable. Again, I would like to see a change in the summary, since Radiance does in fact model diffuse-specular interactions fully and correctly. Section 3.3: I agree that setting parameters is non-trivial, which is why I wrote the "rad" program, described in a paper at the 1995 Eurographics Workshop on Rendering. In general, direct accuracy controls are unreliable, but even so, Radiance parameters are tied to accuracy whenever it is possible or reasonable to do so. Section 3.4: You are rightly critical of Radiance 2.5's display mapping function. The next version of Radiance (3.1) includes a new program called "pcond," which contains a comprehensive tone mapping operator with strong ties to human vision. http://rmp.kiam1.rssi.ru/articles/pals/results.htm, Section 5.1.4: I thought this section demonstrated very well my point about the absolute control of accuracy, or lack thereof. That is to say, even though you have so-called "accuracy" settings in Specter, they do not in fact correspond to any kind of accuracy you can measure. Although absolute accuracy is a laudable goal, it is not a practical one when it comes to lighting simulation. All you can do is trade time for accuracy and peform convergence tests such as this on specific scenes. There is no technique that can guarantee lighting simulation accuracy in arbitrary environments. The best we can hope for is a statistical estimate based on Monte Carlo convergence tests, and such a criterion offers no guarantee that the process will EVER finish! Section 5.2: The Radiance rendering exhibits significant aliasing because the final (pfilt) pass was not made. This is an error in the way the rendering was performed that affects the appearance, but not the accuracy of the pixel values. The accuracy of the shadows is a function of the -dj as well as the -ds parameter, which should be controlled by the "rad" program I mentioned before. Section 5.3: Again, the complaint about Radiance images showing jaggies is the result of failing to filter the result properly with pfilt. This can be remedied by applying the "rad" program, which runs it automatically. For some reason, you did not include the time for Radiance rendering of the flower scene. In the bathroom (CG) scene, you say that Specter computed the image an "order of magnitude" (10 times) faster than Radiance, when your table shows times of 4.1 and 3 hours for the two systems, with Radiance being the faster. Something is wrong, here. In the final office scene (very nice, by the way), the rendering parameters obviously require adjustment. Once again, the "rad" program makes this process very intuitive, and I strongly suggest you use it. It also has a single "accuracy" control called "QUALITY", but does not attempt to tie this to numerical accuracy, which cannot be guaranteed, as we have witnessed from the Specter results. http://rmp.kiam1.rssi.ru/articles/pals/conclusion.htm, Section 6: In general, I agreed with your conclusions, despite my earlier remarks. Overall, I think you have provided the global illumination community a tremendous service, and we owe you a debt of gratitude. I hope that your analysis has a great influence on any future validation and comparison work, as a standard of excellence for others to match! -Greg From greg Tue Jan 21 12:29:07 1997 Return-Path: Date: Tue, 21 Jan 97 12:28:31 PST From: greg (Gregory J. Ward) To: abkhod@gin.keldysh.ru Subject: Re: lighting simulation comparisons Cc: chas, globillum@imag.fr, iashdown@ledalite.com Status: R P.S. to my previous comments. I forgot to mention that the latest version of Radiance (3.0) also has participating media, and can therefore simulate the same effects that Specter seems to. I do not know enough about Specter to comment on the accuracy of its model, but Radiance does apply a fairly rigorous PM model, with typical optimizations to minimize rendering time. These optimizations do require a degree of user control, however. From abkhod@gin.keldysh.ru Wed Jan 22 07:10:49 1997 Return-Path: Date: Wed, 22 Jan 1997 18:09:21 +0300 From: Andrei Khodulev Reply-To: abkhod@gin.keldysh.ru Organization: Keldysh Inst. of Appl. Math. To: "Gregory J. Ward" Cc: chas@hobbes.lbl.gov, globillum@imag.fr, iashdown@ledalite.com Subject: Re: lighting simulation comparisons Status: R Hello, Greg, Thank you for detailed analysis of our comparison study. It seems that we really failed to use some important features of Radiance. Here I comment on one trivial error, I'll answer in more details later. Anyhow we'll undertake new comparison with account for your remarks and suggestions. > For some reason, you did not include the time for Radiance rendering of > the flower scene. In the bathroom (CG) scene, you say that Specter > computed the image an "order of magnitude" (10 times) faster than > Radiance, when your table shows times of 4.1 and 3 hours for the two > systems, with Radiance being the faster. Something is wrong, here. There is a technical error in our text: one column was lost in the timing table. The correct table is: --------------------------------------------- Scene | Simulation + rendering time (hours) name |------------------------------------- | LVS | Specter | Radiance --------------------------------------------- APART2 | 86 | 0.3 | 3.7 DREAM0 | 5.4 | 2.3 | 4.3 FLOWER | 34 | 1.3 | 0.7 CG | 27 | 4.1 | 31 HONSHA | --- | 29 | 38 And one question to you. We downloaded the document http://radsite.lbl.gov:80/mgf/mgfdoc.ps.Z and can not read it. When seen via Ghostscript on IBM PC the document seems to be incorrectly formatted (too tight interline spacing). Can you suggest anything? With best regards, -Andrei. From greg Thu Jan 23 10:00:20 1997 Return-Path: Date: Thu, 23 Jan 97 09:59:59 PST From: greg (Gregory J. Ward) To: abkhod@gin.keldysh.ru Subject: Re: lighting simulation comparisons Status: RO Hi Andrei, I am puzzled as to why the CG scene took so long to render. Do you have any ideas? I would like very much to see the variable settings you use for rad in your final Radiance runs. I don't know what to say about the line spacing in mgfdoc.ps.Z, or what I can do about it. Why don't you try sending it to the printer instead of displaying it? -Greg From iashdown@ledalite.com Thu Jan 23 20:19:24 1997 Return-Path: From: "Ian Ashdown" To: Cc: Subject: Fw: lighting simulation comparisons Date: Thu, 23 Jan 1997 20:18:02 -0800 X-Msmail-Priority: Normal X-Priority: 3 Status: R Hello, Andrei. Greg Ward has been copying your correspondence with him on global illumination validation to me. One item that caught my attention was: >And one question to you. We downloaded the document > >http://radsite.lbl.gov:80/mgf/mgfdoc.ps.Z > >and can not read it. When seen via Ghostscript on IBM PC the document >seems to be incorrectly formatted (too tight interline spacing). Can you >suggest anything? I downloaded this file and examined it today. I had no problem in displaying or printing it. However, I was using GSView32 Version 2.0 (11/08/96 release) running under Windows NT. I gave up using the 16-bit version of Ghostscript for Windows 3.1 because it had so many bugs. Have you tried downloading the latest version of Ghostscript? Ian Ashdown, P. Eng. Research & Development Manager Ledalite Architectural Products Inc. http://www.ledalite.com From abkhod@gin.keldysh.ru Tue Jan 28 04:38:21 1997 Return-Path: Date: Tue, 28 Jan 1997 15:36:51 +0300 From: Andrei Khodulev Reply-To: abkhod@gin.keldysh.ru Organization: Keldysh Inst. of Appl. Math. To: "Gregory J. Ward" , Ian Ashdown Cc: oek@gin.keldysh.ru Subject: Re: lighting simulation comparisons Status: RO Hello, Greg and Ian, Please, CC further mail re:lighting simulation comparisons to oek@gin.keldysh.ru > I am puzzled as to why the CG scene took so long to render. Do you have > any ideas? I would like very much to see the variable settings you use > for rad in your final Radiance runs. > Please look at the report of that run: shapename: cg scenename: mc rpict -e rp.rep -t 60 -dt 0 -ab 3 -ad 1024 -lw 0 -vp 0.860900 -1.045500 1.784300 -vd -0.412400 0.923850 -1.699300 -vu -0.831400 1.862000 1.214100 -vh 77.319114 -vv 61.928369 -pa 0 -x 800 -y 600 mc.oct real 126:37:57.72 user 31:00:51.01 sys 5:01.05 > I don't know what to say about the line spacing in mgfdoc.ps.Z, or what > I can do about it. Why don't you try sending it to the printer instead > of displaying it? > >>>Ian Ashdown: >I downloaded this file and examined it today. I had no problem in >displaying >or printing it. However, I was using GSView32 Version 2.0 (11/08/96 >release) >running under Windows NT. I gave up using the 16-bit version of >Ghostscript >for Windows 3.1 because it had so many bugs. We tried GSVIEW32.EXE Version 2.0 1996-08-11 on Win95 and GSVIEW32.EXE Version 2.1 1996-11-04 on WinNT. All with the same effect. Being printed (we have to print it via GSView) it looks the same: the interline spacing is so little that 3 or more consecutive lines are overlapped. We never faced this problem with other PS docs. Say, the article "Making Global Illumination User-Friendly" (radsite.lbl.gov/radiance/papers/erw95.1/papers.ps.Z) looks quite well. The problem is, however, not urgent now as we can use HTML version of MGFDOC. With best regards, -Andrei From owner-globillum-imag@imag.fr Wed Jan 29 08:56:32 1997 Return-Path: Date: Wed, 29 Jan 1997 13:35:53 +0000 From: Lindsey Shackleton Organization: LightWork Design To: globillum@imag.fr Subject: Diffuse/Specular Reflection: Schlick's approximation Status: R Hi, Re: "An Inexpensive BRDF Model for Physically Based Rendering" C. Schlick EuroGraphics 94 VVol 13 number 3 I've been working my way through the above paper, and have come unstuck in several places. Any suggestions will be much appreciated. ________________________________________________________________________ Eqn 30. First imagine the terms without the normalisation factor, 4Pi, so it becomes: D(t,v,v',w) = G(v) G(v') Z(t) A(w) + ( 1 - G(v) G(v') ) __________ ______________ v v' v v' First I think this should actually be: D(t,v,v',w) = G(v) G(v') Z(t) A(w) + ( 1 - G(v) G(v') ) __________ __________ v v' v v' Surely this means that ALL the directional diffuse would be reemitted along v'. Shouldn't the ( 1 - G(v)G(v')/vv') be divided by 2Pi so that it is equally distributed over the hemisphere? ________________________________________________________________________ ________________________________________________________________________ - Eqn 32 D(t,v,v',w) = a + b B(t,v,v',w) + c Dirac-delta __ ______________ ______________ Pi 4 Pi v v' v' dV' a,b,c are weighting coefficients. Shouldn't this be D(t,v,v',w) = a Diffuse_refl + b B(t,v,v',w) + c Fresnel Dirac-delta ______________ ______________ ______________________ Pi Pi v' dV' B(t,v,v',w) is the previous D(t,v,v',w). First put the reflectance coefficients in, remove the unecessary vv'. Why was there a factor of 4 on the denominator, if Int[Z(t)A(w)] = Pi over the hemisphere for perfectly smooth isotropic reflectors? ________________________________________________________________________ I would be very grateful for any explanations, Lindsey Shackleton Software Engineer LightWork Design Ltd. From owner-globillum-imag@imag.fr Mon Feb 3 11:49:04 1997 Return-Path: Date: Mon, 3 Feb 1997 07:44:38 -0800 (PST) To: globillum@imag.fr From: iashdown@ledalite.com (Ian Ashdown) Subject: Global illumination bibliography Status: R ANNOUNCE: 97/02/01 Release of RADBIB97 -------------------------------------- RADBIB97 is a comprehensive bibliography of radiosity and related global illumination papers, theses, articles, and books. It currently includes 1,031 references, with some 15 new references being added per month. This bibliography is available in BibTex format as RADBIB97.BIB (with a release date of February 1, 1997) from: http://www.ledalite.com/library-/rrt.htm and as compressed RadBib97.bib.Z from: ftp://hobbes.lbl.gov/pub/doc As always, it is time-consuming and sometimes difficult to track down conference papers and theses on radiosity and global illumination. If you know of a relevant reference that is not included in the bibliography, please let me know so that I can include it in the next release. From owner-globillum-imag@imag.fr Thu Feb 20 10:49:10 1997 Return-Path: X-Quien: el1segag@localhost Date: Thu, 20 Feb 1997 18:25:37 +0100 From: Gonzalo Senuela Garcia To: globillum@imag.fr Subject: Two Pass (Radiosity and raytracing) programs vs Radiance Status: R Hello Everyone know a paper about a comparative analysis between Two Pass programs (Radiosity-raytracing) and Radiance (Greg Wards) programs - Gonzalo From owner-globillum-imag@imag.fr Fri Feb 21 15:10:49 1997 Return-Path: Date: Fri, 21 Feb 1997 17:06:21 -0500 From: swestin@ford.com (Stephen Westin ) To: holly@watson.ibm.com Cc: globillum@imag.fr Subject: Re: Need refs. about need Status: R > Hi -- > > One of the people working on the appearance project at NIST asked > me for "some references that talk about the need for measurements > of appearance properties of materials." A lot of people ask about where > to find catalogs of measurements etc., but I am having a hard time > finding "citable" references for the need for measurements. If you > have written anything, either technical paper or more informal > "position" paper that could be cited about the need for measurements > to support realistic rendering please let me know. Or, if you haven't > written anything, but would be willing to be quoted about how your > work would benefit by the availability of measurements, or measurement > techniques, let me know. > > Thanks, > Holly > > Found this dusty message just now; I didn't answer because, frankly, I've never convinced anyone here that better visual simulations, reflectance functions, reflectance measurements, etc, are needed. Sorry. Actually, you might contact someone in the Advanced Lighting Technology Group about this; they have at least played with optical simulations of the down-the-road view at night, and hired ERIM for a while to code something up for them. When I visited (a year ago? two years ago?), they said, "there's this parameter called 'gamma' in the program, and you can make the picture look bright or dark with it. Any idea what it does?" Sigh. I talked to Mahendra Dassanayake (mdassana@ford.com) and Balvant Patel (bpatel6@ford.com). You probably have run into the tendency of numerical simulation analysts to be from India :). -Steve P.S. I'm working on that SIGGRAPH review... From owner-globillum-imag@imag.fr Fri Feb 28 05:13:06 1997 Return-Path: From: Samuel.Boivin@inria.fr To: globillum@imag.fr Cc: boivin@bora.inria.fr Subject: FORM FACTORS COMPUTATION THROUGH SGI HARDWARE Date: Fri, 28 Feb 97 12:12:08 +0100 Status: RO Hello everybody, I have some questions that concern Hardware Acceleration for Form Factor Computation. So I tried all what is possible to compute off-screen(and 'on-screen') form factors using OpenGL. The problem is that the computation time I obtained is really BAD ! So does anybody have any information about programming off-screen rendering to EFFECTIVELY accelerate the computation time for form factors using the SGI hardware? You can find next all the solutions I tried: - OpenInventor SoOffScreenRender Class: computation time is incredibly slow: it is unusable. - GLXPixmaps with X11 Pixmaps: the computation time is DRAMATICALLY slow, therefore it is unusable too. 99.99 % computation time is in the GLReadPixels() OpenGL Command (?!?!?) - PBuffers on a Maximum Impact R10000 (195Mhz). The computation time is the following: 15.6sec to compute 300x300 resolution 2000 Z-Buffers with a 70 patches scene (then 140000 projections). For me, it is really unacceptable: MaxImpact has at least a 1.5Million polygons/second rendering capacity with Gouraud shading(there is probably no glReadPixels() call). In any case, I am only using Flat Shading and one light source, and this gives us a 10000 polygon/sec rendering capacity (!?!!): we had better computation time using Mesa Library(14.89 sec) to render this small scene on the same machine ! In my opinion, there are several problem levels: - Does PBuffers really use Hardware ? It doesn't seem to be the case since, using osview, we can see that Hardware lines(gfxc, gfxf...) gives 0.00% (?!?). So, if it doesn't use Hardware, why computation time is faster than using X Pixmaps(as PBuffers are Pixmaps Hardware) ? - There is a SGI paper on using hardware for radiosity: "Real Time Radiosity Through Parallel Processing and Hardware Acceleration", by D.R. Baum and J.M. Winget, Computer Graphics 1990(Symposium on Interactive 3D graphics) p67-75. Page 69: "Once the five hemi-cube are generated(top of hemi-cube and four sides), they are read back from frame buffer memory to host shared memory for processing". This paper is 7 years old and - in spite of the fact they were using multi-processing - they obtained results that I consider impossible to have today on a Maximum Impact R10k 195mhz ! I suspect that it is due to the fact that this technique was performed using GL Library, and we moved to OpenGL that is really slower. To finish with this very long mail: HOW TO USE HARDWARE WITH OFF-SCREEN RENDERING ?!?!? I don't want to open any window ! I just want to use Hardware, compute Z-Buffers(FLAT) and get the result images in real time: is it possible for a Max Impact to compute a 300x300 Z-Buffer of a 400000 patches scene and to get the result image in less than 1 sec ? Samuel. ||======================================|| || Samuel Boivin || ||======================================|| || I.N.R.I.A || || Batiment 24, Projet SYNTIM || || Domaine de Voluceau || || 78153 LE CHESNAY Cedex || || Tel: 01-39-63-51-86 || || Fax: 01-39-63-57-71 || || E-mail: Samuel.Boivin@inria.fr || ||======================================|| From owner-globillum-imag@imag.fr Fri Feb 28 07:30:42 1997 Return-Path: Date: Fri, 28 Feb 1997 08:59:45 -0500 From: swestin@ford.com (Stephen Westin ) To: Samuel.Boivin@inria.fr Cc: globillum@imag.fr Subject: Re: FORM FACTORS COMPUTATION THROUGH SGI HARDWARE Status: RO > - There is a SGI paper on using hardware for radiosity: "Real Time Radiosity > Through Parallel Processing and Hardware Acceleration", by D.R. Baum and J.M. > Winget, Computer Graphics 1990(Symposium on Interactive 3D graphics) p67-75. > Page 69: "Once the five hemi-cube are generated(top of hemi-cube and four > sides), they are read back from frame buffer memory to host shared memory for ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > processing". This paper is 7 years old and - in spite of the fact they were > using multi-processing - they obtained results that I consider impossible to > have today on a Maximum Impact R10k 195mhz ! I suspect that it is due to the > fact that this technique was performed using GL Library, and we moved to > OpenGL that is really slower. No, I suspect that the phrase I highlighted above is the key; SGI machines are generally highly optimized to render to the screen. I would not be at all surprised if off-screen rendering were much slower on most SGI machines. Maybe you are stuck with using the screen, then reading back the frame buffer. I would suggest a post to USENET group comp.sys.sgi.graphics; there are several SGI engineers who hang out there and give you the *real* answer. -Stephen H. Westin swestin@ford.com The information and opinions in this message are mine, not Ford's. From owner-globillum-imag@imag.fr Fri Feb 28 08:15:54 1997 Return-Path: From: "Ian Ashdown" To: Cc: Subject: Re: FORM FACTORS COMPUTATION THROUGH SGI HARDWARE Date: Fri, 28 Feb 1997 06:21:24 -0800 X-Msmail-Priority: Normal X-Priority: 3 Status: RO Samuel Boivin wrote: > I have some questions that concern Hardware Acceleration for Form Factor > Computation. So I tried all what is possible to compute off-screen(and > 'on-screen') form factors using OpenGL. The problem is that the computation > time I obtained is really BAD ! > So does anybody have any information about programming off-screen rendering to > EFFECTIVELY accelerate the computation time for form factors using the SGI > hardware? If you can find a copy of: Rushmeier, H. E., D. R. Baum, and D. E. Hall. 1991. "Aceelerating the Hemi-Cube Algorithm for Calculating Radiation Form Factors," Transactions of the ASME Vol. 113 (November), pp. 1044-1047. you can read about how they achieved speedup factors of up to 6.7 (for a hemicube resolution of 300) on an SGI Personal Iris W-4D20G. Ian Ashdown, P. Eng. Research & Development Manager Ledalite Architectural Products Inc. From owner-globillum-imag@imag.fr Fri Feb 28 08:20:02 1997 Return-Path: From: Samuel.Boivin@inria.fr To: globillum@imag.fr Subject: FORM FACTORS COMPUTATION THROUGH SGI HARDWARE Date: Fri, 28 Feb 97 15:18:20 +0100 Status: RO > No, I suspect that the phrase I highlighted above is the key; SGI > machines are generally highly optimized to render to the screen. I > would not be at all surprised if off-screen rendering were much slower > on most SGI machines. You are right: off-screen rendering is generally slower than "on-screen" rendering(but it depends on the technique you chose). But if you use the glReadPixels() function in your "render to screen" program, then you have quite similar computation time to these obtained with off-screen rendering. > Maybe you are stuck with using the screen, then reading back the frame > buffer. > > I would suggest a post to USENET group comp.sys.sgi.graphics; there > are several SGI engineers who hang out there and give you the *real* > answer. I already sent a message in the OpenGL usenet, and nobody answered me, or just with "did you read the faqs ?" ... So, I will send a message to comp.sys.sgi.graphics too. But I already sent several mails to SGI HOT-LINE in France and USA. They didn't arrive to resolve my problem. In France and in USA, there is still an opened phone-line on my problem(ref FR62888). I am still waiting about a solution. -Samuel From owner-globillum-imag@imag.fr Fri Feb 28 09:39:35 1997 Return-Path: Sender: atc@arlut.utexas.edu Date: Fri, 28 Feb 1997 09:28:39 -0600 From: "A. T. Campbell" To: Samuel.Boivin@inria.fr Cc: globillum@imag.fr Subject: Re: FORM FACTORS COMPUTATION THROUGH SGI HARDWARE Status: RO Another good reference for hardware form factor calculation is the following: Nelson Max and Michael J. Allison, "Linear Radiosity Approximation Using Vertex-to-Vertex Form Factors", Graphics Gems III, edited by David Kirk, Academic Press, 1992. -- A. T. Campbell, III atc@arlut.utexas.edu http://www.arlut.utexas.edu/~atc Applied Research Labs, University of Texas, PO Box 8029, Austin,TX 78713 From owner-globillum-imag@imag.fr Fri Feb 28 10:15:42 1997 Return-Path: Sender: crs@uunet.uu.net Date: Fri, 28 Feb 1997 08:59:44 -0800 From: Chris Schoeneman To: globillum@imag.fr Cc: boivin@bora.inria.fr Subject: Re: FORM FACTORS COMPUTATION THROUGH SGI HARDWARE Status: R Samuel.Boivin@inria.fr wrote: > > I have some questions that concern Hardware Acceleration for Form Factor > Computation. So I tried all what is possible to compute off-screen(and > 'on-screen') form factors using OpenGL. The problem is that the computation > time I obtained is really BAD ! > > - OpenInventor SoOffScreenRender Class: computation time is incredibly slow: > it is unusable. > > - GLXPixmaps with X11 Pixmaps: the computation time is DRAMATICALLY slow, > therefore it is unusable too. 99.99 % computation time is in the > GLReadPixels() OpenGL Command (?!?!?) Both of these do the same thing (render to pixmaps). They make an indirect rendering context, which sends all OpenGL commands through the X server. As you've discovered, that's slow. But read on to see the real problem. > - PBuffers on a Maximum Impact R10000 (195Mhz). The computation time is > the following: 15.6sec to compute 300x300 resolution 2000 Z-Buffers with a 70 > patches scene (then 140000 projections). For me, it is really unacceptable: > MaxImpact has at least a 1.5Million polygons/second rendering capacity with > Gouraud shading(there is probably no glReadPixels() call). In any case, I > am only using Flat Shading and one light source, and this gives us a 10000 > polygon/sec rendering capacity (!?!!): we had better computation time using > Mesa Library(14.89 sec) to render this small scene on the same machine ! You're not going to get anywhere near the top polygon rendering performance of the Max Impact with a 70 polygon scene. Think about it. You clear the 300x300 buffer, render 70 polygons, then read the pixels. The time it takes to render 70 polygons is miniscule compared to the time it takes to clear and read 90000 pixels. Try rendering 7000 polygons and see what happens to your `polygon' performance. The problem here was your measurement of performance. When you read 1.5M polygons/sec from the marketing brochures it means 1.5M polygons per second, not 1.5M polygons per second including reading and clearing the screen every 70 polygons. Are the marketing numbers misleading? No, they say exactly what they mean. Some suggestions for increasing performance. Use as large a buffer as you can make that's a multiple of 300x300. Clear the entire buffer, render your scene into each 300x300 subregion, then read the entire buffer in one call. That'll amortize the overhead of each clear and pixel read. If you're in a closed environment then every pixel in each 300x300 region will be written to. See the first issue of the Journal of Graphics Tools for a simple technique to avoid the screen clear completely. Make sure you're using a direct rendering context (the last parameter to glXCreateContext should be True). What's the light source for? Turn it off if you don't really need it. In any case, the pixel read will remain the bottleneck. > In my opinion, there are several problem levels: > - Does PBuffers really use Hardware ? Yes, if you use a direct rendering context. > - There is a SGI paper on using hardware for radiosity: "Real Time Radiosity > Through Parallel Processing and Hardware Acceleration", by D.R. Baum and J.M. > Winget, Computer Graphics 1990(Symposium on Interactive 3D graphics) p67-75. > ... I suspect that it is due to the > fact that this technique was performed using GL Library, and we moved to > OpenGL that is really slower. Definitely not. That'd be a brilliant move for SGI, ``with OpenGL get the graphics performance of 5 years ago, TODAY!'' It might well be due to the author's in-depth knowledge of the platform and the bottlenecks in rendering. Cheers, -chris From owner-globillum-imag@imag.fr Fri Feb 28 11:10:45 1997 Return-Path: Reply-To: Michael Herf To: globillum@imag.fr Subject: Re: FORM FACTORS COMPUTATION THROUGH SGI HARDWARE Date: Fri, 28 Feb 1997 13:14:50 -0500 From: Michael Herf Status: R Pixmap rendering is all done in software, so it should be slow. I imagine the Inventor class uses Pixmaps. pBuffers are the way to go on a RE, but on an Impact I wouldn't be surprised if they were in software. I don't think the framebuffer on the Impact has many spare bits. The backbuffer should be a good option in double-buffered mode on any SGI hardware, though some machines will draw in dithered 16-bit mode, so be careful about how much you trust that. glReadPixels always goes through host memory, so you're bound by the memory bandwidth there. I think the Impact gives you a generous 200 MB/sec, but even so it's not pretty. For an Impact, drawing 70 polygons is trivial, so you can consider your test a benchmark of glReadPixels. In answer to your question: you can certainly create a 300x300 image of a 400,000-patch scene in a backbuffer in < 1 second on this hardware. At this point you won't be depending on host memory for your throughput, and the hardware will be able to scream through rendering polygons. Again, maybe pbuffers will work in single-buffered mode on the Impact, but I don't know about this. In the broader scope, I think that hemicube radiosity really presents some architectural problems for all but the latest of graphics hardware. There's a huge overhead for using the bus between the hardware and the host CPU, but the constant "ping-ponging" back and forth means that efficient systems are hard to build. The newer SGI machines (O2 and Onyx2) have UMA (unified memory architecture), so the bus is not nearly as much of a bottleneck. As a point of reference, can someone post some empirical speed results from ray-casting (using appropriate subdivision) into "typical" scenes of a variety of sizes? I imagine that at the 70-patch level, software would be faster, and at the 400,000-patch level, hardware would win. But an approximate intersection point would be nice to have. mike From owner-globillum-imag@imag.fr Fri Feb 28 12:39:00 1997 Return-Path: From: "Dan Baum" Date: Fri, 28 Feb 1997 11:57:31 -0800 To: Chris Schoeneman , globillum@imag.fr Subject: Re: FORM FACTORS COMPUTATION THROUGH SGI HARDWARE Cc: boivin@bora.inria.fr Status: R Chris has made some excellent suggestions below. Additionally, if you overlap the remainder of the host based form-factor computation with the hemicube visiblity calculations you are performing on the hardware you will see additional time savings. On Feb 28, 8:59am, Chris Schoeneman wrote: > Subject: Re: FORM FACTORS COMPUTATION THROUGH SGI HARDWARE > Samuel.Boivin@inria.fr wrote: > > > > I have some questions that concern Hardware Acceleration for Form Factor > > Computation. So I tried all what is possible to compute off-screen(and > > 'on-screen') form factors using OpenGL. The problem is that the computation > > time I obtained is really BAD ! > > > > - OpenInventor SoOffScreenRender Class: computation time is incredibly slow: > > it is unusable. > > > > - GLXPixmaps with X11 Pixmaps: the computation time is DRAMATICALLY slow, > > therefore it is unusable too. 99.99 % computation time is in the > > GLReadPixels() OpenGL Command (?!?!?) > > Both of these do the same thing (render to pixmaps). They make an indirect > rendering context, which sends all OpenGL commands through the X server. > As you've discovered, that's slow. But read on to see the real problem. > > > - PBuffers on a Maximum Impact R10000 (195Mhz). The computation time is > > the following: 15.6sec to compute 300x300 resolution 2000 Z-Buffers with a 70 > > patches scene (then 140000 projections). For me, it is really unacceptable: > > MaxImpact has at least a 1.5Million polygons/second rendering capacity with > > Gouraud shading(there is probably no glReadPixels() call). In any case, I > > am only using Flat Shading and one light source, and this gives us a 10000 > > polygon/sec rendering capacity (!?!!): we had better computation time using > > Mesa Library(14.89 sec) to render this small scene on the same machine ! > > You're not going to get anywhere near the top polygon rendering > performance of the Max Impact with a 70 polygon scene. Think about it. > You clear the 300x300 buffer, render 70 polygons, then read the pixels. > The time it takes to render 70 polygons is miniscule compared to the time > it takes to clear and read 90000 pixels. Try rendering 7000 polygons and > see what happens to your `polygon' performance. > > The problem here was your measurement of performance. When you read 1.5M > polygons/sec from the marketing brochures it means 1.5M polygons per > second, not 1.5M polygons per second including reading and clearing the > screen every 70 polygons. Are the marketing numbers misleading? No, > they say exactly what they mean. > > Some suggestions for increasing performance. Use as large a buffer as > you can make that's a multiple of 300x300. Clear the entire buffer, > render your scene into each 300x300 subregion, then read the entire buffer > in one call. That'll amortize the overhead of each clear and pixel read. > > If you're in a closed environment then every pixel in each 300x300 region > will be written to. See the first issue of the Journal of Graphics Tools > for a simple technique to avoid the screen clear completely. > > Make sure you're using a direct rendering context (the last parameter to > glXCreateContext should be True). > > What's the light source for? Turn it off if you don't really need it. > > In any case, the pixel read will remain the bottleneck. > > > > In my opinion, there are several problem levels: > > - Does PBuffers really use Hardware ? > > Yes, if you use a direct rendering context. > > > > - There is a SGI paper on using hardware for radiosity: "Real Time Radiosity > > Through Parallel Processing and Hardware Acceleration", by D.R. Baum and J.M. > > Winget, Computer Graphics 1990(Symposium on Interactive 3D graphics) p67-75. > > ... I suspect that it is due to the > > fact that this technique was performed using GL Library, and we moved to > > OpenGL that is really slower. > > Definitely not. That'd be a brilliant move for SGI, ``with OpenGL get the > graphics performance of 5 years ago, TODAY!'' It might well be due to the > author's in-depth knowledge of the platform and the bottlenecks in rendering. > > Cheers, > -chris > >-- End of excerpt from Chris Schoeneman From owner-globillum-imag@imag.fr Fri Feb 28 12:49:36 1997 Return-Path: From: "Dan Baum" Date: Fri, 28 Feb 1997 12:14:59 -0800 To: Michael Herf , globillum@imag.fr Subject: Re: FORM FACTORS COMPUTATION THROUGH SGI HARDWARE Status: R > > In the broader scope, I think that hemicube radiosity really presents some > architectural problems for all but the latest of graphics hardware. > There's a huge overhead for using the bus between the hardware and the > host CPU, but the constant "ping-ponging" back and forth means that > efficient systems are hard to build. The newer SGI machines (O2 and > Onyx2) have UMA (unified memory architecture), so the bus is not > nearly as much of a bottleneck. A couple of comments on the above. First, with a scene of interesting complexity (minimum of several thousand polys rendered 5 times for each face of the cube), read back overhead shouldn't be that bad. Again,if you've got an MP machine think about overlapping your computations. Also, the Onyx2 is not what I would call a UMA architecture. We officially term is as SSMP, but you might want to think of it as NUMA (non-uniform memory access) in that there isn't a common system bus inbetween CPU and main memory. Main memory is distributed throughout the system with different access times depending on the location of memory. Obviously, the system tries to be intelligent to keep your data as close to the processor that operating on it. > > As a point of reference, can someone post some empirical speed results > from ray-casting (using appropriate subdivision) into "typical" scenes of > a variety of sizes? I imagine that at the 70-patch level, software would > be faster, and at the 400,000-patch level, hardware would win. But an > approximate intersection point would be nice to have. > > mike >-- End of excerpt from Michael Herf From owner-globillum-imag@imag.fr Mon Mar 3 12:05:49 1997 Return-Path: From: Samuel.Boivin@inria.fr To: globillum@imag.fr Cc: boivin@bora.inria.fr Subject: Re: FORM FACTORS COMPUTATION THROUGH SGI HARDWARE Date: Mon, 03 Mar 97 12:00:16 +0100 Status: R Chris Schoeneman wrote: > Both of these do the same thing (render to pixmaps). They make an indirect > rendering context, which sends all OpenGL commands through the X server. > As you've discovered, that's slow. But read on to see the real problem. You are right, but I knew that. So, it's my fault, I fear that I haven't been clear about my real problem. In fact, I spent several weeks to try each method about off-screen rendering and I spent several hours with SGI Hot-Line to understand the reasons of the bad performances I obtained. In fact, in my opinion, for GLXPixmaps, there is nothing to do, because of the same reasons you invoked. For Pbuffers(the last solution ?), I have the sensation it could be a good solution if you have a Infinite Reality or a Reality Monster. On a Maximum Impact, it is too slow. Maybe there is another idea: isn't it possible to put a (ubyte *) pointer to the memory area where pixels are stored ? I think It would be really faster than using glReadPixels() function, no ? > You're not going to get anywhere near the top polygon rendering > performance of the Max Impact with a 70 polygon scene. Think about it. > You clear the 300x300 buffer, render 70 polygons, then read the pixels. > The time it takes to render 70 polygons is miniscule compared to the time > it takes to clear and read 90000 pixels. Try rendering 7000 polygons and > see what happens to your `polygon' performance. Again, you are right. But if I have a 7000 polygon scene, I will approximately read 35000 buffers to compute form factors, then I think it will be really slow, since it takes a lot of time to do a single "glReadPixels()" call. > The problem here was your measurement of performance. When you read 1.5M > polygons/sec from the marketing brochures it means 1.5M polygons per > second, not 1.5M polygons per second including reading and clearing the > screen every 70 polygons. Are the marketing numbers misleading? No, > they say exactly what they mean. You are right again and that's what I said in my previous mail: ther is no read buffer in their performance measurements. But, 1.5 Million polygon per second doesn't mean anything for me. Indeed, when we read their performance announcements, you can't find: Buffer resolution(50x50 or 1000x1000 ?), percentage of bitmap occupation(10% or 90% ?), and -and it is really important- polygons configuration (I mean if they project the scene in a special order(sorted polygons), they can really accelerate the computation time). But that is not the real problem here. So if the numbers are not really exact, I don't think they are completely false. What I really would like to know is: what is done in glReadPixels() ? If you read the OpenGL Faqs, you can see that disabling fog, texture... accelerate the reading command execution ! WHY ?!?! For me reading the frame buffer is only a problem of getting memory address ! It has been stored somewhere, and I only what to get a pointer on this memory area ! There is nothing to compute ! > Some suggestions for increasing performance. Use as large a buffer as > you can make that's a multiple of 300x300. Clear the entire buffer, > render your scene into each 300x300 subregion, then read the entire buffer > in one call. That'll amortize the overhead of each clear and pixel read. > If you're in a closed environment then every pixel in each 300x300 region > will be written to. See the first issue of the Journal of Graphics Tools > for a simple technique to avoid the screen clear completely. OK, thank you for the information. I will apply this idea. > Make sure you're using a direct rendering context (the last parameter to > glXCreateContext should be True). Sure it is ! Otherwise, I can't use Hardware. > What's the light source for? Turn it off if you don't really need it. Sorry, I made a mistake. I didn't define any light source. And they are disabled before reading the buffer because it seems to accelerate the reading command !?!?! > Yes, if you use a direct rendering context. Sorry, I can't be agree. It is not the case on a Maximum Impact: I made a lot of tests, and each time the graphics card is not sollicited. And if you ask to SGI, they say you that Pbuffers uses Hardware on high/max Impact, RE2, IR and O2. So, I sent my code to SGI, and they try it on Maximum Impact and O2, and they saw that there is no Hardware use ! So they open a phone-line(FR-62888) about that problem... I am still waiting for an answer. > Definitely not. That'd be a brilliant move for SGI, ``with OpenGL get the > graphics performance of 5 years ago, TODAY!'' It might well be due to the > author's in-depth knowledge of the platform and the bottlenecks in rendering. Maybe. But, if you make some tests with pure GL read command and if you compare it to the same OpenGL command, you obtain very big differences ! The GL read command is several times faster than the OpenGL one !! -Samuel From owner-globillum-imag@imag.fr Mon Mar 3 13:05:13 1997 Return-Path: To: globillum@imag.fr Subject: Re: FORM FACTORS COMPUTATION THROUGH SGI HARDWARE Reply-To: Michael Herf Date: Mon, 03 Mar 1997 15:20:47 -0500 From: Michael Herf Status: R First, there is no such thing as a memory-mapped framebuffer on an SGI. This is part of the design spec. Everything is done through library calls, so when you call glReadPixels() the framebuffer is copied into a buffer in your program's address space. So you can't just assign a pointer and read. However, you should be able to get better rates on glReadPixels. I think that on the machines you're using GL_RGB (GL_ABGR_EXT on older machines) with GL_UNSIGNED_BYTE is a fast path. If, instead of bytes, you're reading into floats, the conversion is likely done in software, and you'll pay very dearly for it. Using these parameters, you should get speed equivalent to the IRIS-GL command. Try doing repeated glReadPixels from an on-screen region, using the same call you are using now. Measure the throughput in MB/sec. On the worst of SGI machines, I think you should get better than ~30 MB/sec. It's probably much better on the machines you're talking about. I would guess that your system profile isn't indicating the drawing time, since it's so little work for the hardware. As I remember, glReadPixels will show up as "user time" in gr_osview. mike From owner-globillum-imag@imag.fr Mon Mar 3 13:30:32 1997 Return-Path: Date: Mon, 3 Mar 1997 15:24:26 -0500 From: swestin@ford.com (Stephen Westin ) To: Samuel.Boivin@inria.fr Cc: globillum@imag.fr Subject: Re: FORM FACTORS COMPUTATION THROUGH SGI HARDWARE Status: R Samuel Boivin wrote: > Chris Schoeneman wrote: > > Definitely not. That'd be a brilliant move for SGI, ``with OpenGL get the > > graphics performance of 5 years ago, TODAY!'' It might well be due to the > > author's in-depth knowledge of the platform and the bottlenecks in rendering. > > Maybe. But, if you make some tests with pure GL read command and if you > compare it to the same OpenGL command, you obtain very big differences ! The > GL read command is several times faster than the OpenGL one !! Just a minute here. What pixel format are you using in the readback? If you're reading pixels that must be repacked after reading from the frame buffer, there will be sicgnificant overhead. I suspect that defaults may well be different from IRIS/GL and OpenGL. I also would expect that the optimum pixel format would vary with hardware type. Generally, OpenGL should run faster than IRIS/GL on the Impact series, as that's its native mode. Older graphics adapters, like IMPACT, would probably be faster with IRIS/GL. I think posting the kernel of your readback code would be useful; I bet Chris can help speed it up. -Stephen H. Westin swestin@ford.com The information and opinions in this message are mine, not Ford's. From owner-globillum-imag@imag.fr Mon Mar 3 15:23:20 1997 Return-Path: From: "Dan Baum" Date: Mon, 3 Mar 1997 14:15:29 -0800 To: Samuel.Boivin@inria.fr, globillum@imag.fr Subject: Re: FORM FACTORS COMPUTATION THROUGH SGI HARDWARE Cc: boivin@bora.inria.fr Status: R Hi Samuel: As has been pointed out by others, there is no way to access the framebuffer directly. It must be copied back using glReadPixels. Now the performance for glReadPixels depends on the machine you are running on and the amount of data you are reading back. There is overhead to setup the read transfer regardless of the number of pixels you are going to read back. So, to get maximum performance you have to treat this as a systems problem and tune to get maximum performance for your system. For example, try rendering several hemi-cubes into the framebuffer and then read them all back with a single glReadPixels(). On a Max Impact, glReadPixels() should be just as fast as IrisGL based pixel read unless you are using some odd conversion (I would assume you are reading the hemi-cube pixels back as unsigned integers). BTW, I'm not nearly as familiar with the Impact architecture and performance characteristics as I am with our high end machines. From owner-globillum-imag@imag.fr Tue Mar 4 10:05:25 1997 Return-Path: From: "Chris Thornborrow" Date: Tue, 4 Mar 1997 16:02:45 +0000 To: globillum@imag.fr Subject: Re: FORM FACTORS COMPUTATION THROUGH SGI HARDWARE Status: R > > Maybe. But, if you make some tests with pure GL read command and if you > > compare it to the same OpenGL command, you obtain very big differences ! The > > GL read command is several times faster than the OpenGL one !! This is one of the commonest complaints (usually its a complaint about the speed of writing pixels) when moving from GL to OpenGL. It is also a misconception. OpenGL has far more state information relating to pixel data and formats than GL had. The problem is that most people don't set the correct values for the operation they wish to perform. In OpenGL this will result in poor performance. I just looked for my piece of code to demonstrate this but its mysteriously vanished :-(. The one caveat is if you are running on old hardware some commands are faster in GL than OpenGL. Chris. -- ------------------------------------------------------------------------------- |Chris Thornborrow email : chris@manchester.sgi.com | |Silicon Graphics tel : +44 161 877 8801 ext 1309 | | | |Home Page URL : http://reality.sgi.com/chris_manchester/ | |Arthurian URL : http://reality.sgi.com/chris_manchester/arthur.html | ------------------------------------------------------------------------------- From owner-globillum-imag@imag.fr Tue Mar 4 10:12:55 1997 Return-Path: From: "Chris Thornborrow" Date: Tue, 4 Mar 1997 15:54:52 +0000 To: Michael Herf , globillum@imag.fr Subject: Re: FORM FACTORS COMPUTATION THROUGH SGI HARDWARE Status: R On Mar 3, 3:20pm, Michael Herf wrote: > Subject: Re: FORM FACTORS COMPUTATION THROUGH SGI HARDWARE > First, there is no such thing as a memory-mapped framebuffer on an SGI. > This is part of the design spec. Everything is done through library > calls, so when you call glReadPixels() the framebuffer is copied into a > buffer in your program's address space. So you can't just assign a > pointer and read. Well yes and no. The O2 does have a memory mapped frame buffer in one sense - the obvious sense :-). So technically it is possible to look into memory and see whats on the screen using a pointer and some jiggery pokery. Its the second part that worries me. I believe the exact way in which the frame buffer is organised in memory is documented *but* the documentation says that SGI reserve the right to alter it at any time. Therefore the only safe way to code is to do as suggested above and access through digital media libraries or opengl. You could peek and poke memory, I wouldn't advise it. However, this is irrelevant as the speed of reading the framebuffer is very fast through opengl as all that is really going on is a memcopy. Chris. -- ------------------------------------------------------------------------------- |Chris Thornborrow email : chris@manchester.sgi.com | |Silicon Graphics tel : +44 161 877 8801 ext 1309 | | | |Home Page URL : http://reality.sgi.com/chris_manchester/ | |Arthurian URL : http://reality.sgi.com/chris_manchester/arthur.html | ------------------------------------------------------------------------------- From owner-globillum-imag@imag.fr Mon Mar 10 13:34:50 1997 Return-Path: X-Lotus-Fromdomain: IBM RESEARCH From: "Holly Rushmeier" To: globillum@imag.fr Date: Mon, 10 Mar 1997 15:43:14 -0400 Subject: SIGGRAPH Sketches Status: R Hi globillumers-- Since the SIGGRAPH sketch chair, David Ebert, has been in high gear for publicity, you probably have already received e-mail about the sketches program. However one thing that you might have missed is that each accepted Sketch this year receives Conference Access registration."Conferences Access" means admission to essentially everything -- Courses, Papers, Panels, etc. You would have to pay for printed proceedings and CD-ROMS, (and you still have to pay to get yourself to Los Angeles and stay some where) but being able to go to the courses and papers of your choice for free is a pretty good deal. Both technical contributions and applications can be submitted as a sketch. For more information (such as how to submit sketches electronically), see http://www.siggraph.org/s97/contributors/programs/sketches. - Holly From owner-globillum-imag@imag.fr Sat Mar 15 14:20:33 1997 Return-Path: From: Bruce Walter Subject: Terminology question To: globillum@imag.fr Date: Sat, 15 Mar 1997 16:33:40 -0500 (EST) Status: RO Dear Globillum'ers, I've recently run into a seemingly difficult terminology question about what to call the quantities that we actually compute or attempt to compute in global illumination. We often refer to our results as radiance or radiant exitance, but what we actually compute and store does not correspond the definitions of these terms as given the IES/ANSI standard for illuminating engineering terminology. That terminology seems to fall into three categories: spectral radiometry, radiometry, and photometry. Spectral radiometric functions (e.g. spectral radiance) give the amount of light as a function of wavelength. They contain the most information and the others are derived from them by various wavelength weighting functions. Radiometric functions (e.g. radiance) weight power at all wavelengths equally and thus measure total power. Photometric functions (e.g. luminance) weight the light power by the human luminance response curve and measure human grayscale response. Radiometric functions are fine for heat transfer applications that are concerned about the flow of heat energy. Photometric functions are fine for grayscale image making. However as far as I can tell, there doesn't seem to be any standard terminology for the quantities needed to make color images. The usual standard for color response is the CIE 1931 Standard Colormetric Observer which defines colors by three values, XYZ which can be found by using three standard wavelength weighting functions. We compute a color image by weighting the spectral radiance by these three response functions. The Y response curve is the luminous response curve and thus is luminance. However there doesn't seem to be a name for X and Z channel results. Together the XYZ values are sometimes refered to as the tristimulus values, so it would seem correct to call our results the "tristimulus values of the spectral radiance". However that seems rather cumbersome, and it would be nicer to have a name for quantities which we actually compute and store. I'd like to propose a new set of terminology for "color photometry". Analogous to radiometry and photometry, it would give names for the spectral radiometric functions when weighted by the CIE XYZ response curves. The proposed corresponding terms are: Radiometry Photometry Color Photometry --------------------------------------------------------- radiance luminance tristimulance irradiance illuminance intristimulance radiant exitance luminous exitance tristimulus exitance I'd like to hear people's reactions. Do names for these quantities already exist? Are there better names? Do we need names for these quantities? It seems a little sloppy to keep refering to our results as the radiance when at best we really mean the spectral radiance and in practice we really mean what I'm calling the tristimulance. Bruce Walter Cornell Program of Computer Graphics p.s. Tristimulus values do not necessarily refer to the CIE 1931 XYZ values. It is also used in the literature to refer to values generated by other three channel color models. So we would need to be careful to specify which color model we are using when we want to be precise. p.p.s. I wanted to call it the chrominance, but this term is already in use and often means the portion of the color which is "orthogonal" to the luminance. Using tristimulance instead avoids this confusion. From owner-globillum-imag@imag.fr Wed Mar 19 10:41:10 1997 Return-Path: From: cn1@irz301.inf.tu-dresden.de (Nguyen, D.C.) Subject: paper for coherence-based RT-accel. methods To: globillum@imag.fr (Global Illumination List) Date: Wed, 19 Mar 1997 19:23:57 +0200 (MESZ) Status: R Hi, Here is my first attempt writing a paper in english :) "An exploration of coherence-based acceleration methodes using the ray tracing kernel G/GX " located at: http://www.rz.tu-ilmenau.de/~juhu/Papers/IWK.ps.gz It handles some problems of coherence-based accel. methods, comparison results, possibilities & limitations of hybrid methods etc. It also proposes an algorithm making BSP-trees balanced. As an alternative to the shadow-volume method for softshadows, a new approach using the ext. Light-Buffer and Clipping beams to avoid unecessary Monte-Carlo rays for direct-lighting is also described. Could someone please proofread it ? (My english is really *bad*!) Thanks, --JuHu From owner-globillum-imag@imag.fr Mon Mar 24 11:39:15 1997 Return-Path: From: Bruce Walter Subject: Re: Terminology question To: globillum@imag.fr Date: Mon, 24 Mar 1997 13:39:58 -0500 (EST) Status: R At the risk of beating a dead horse, I'll post a update to my terminology posting of a week ago. I've received a few replies but all off list. So far my terminology proposal has been greeted with a collective yawn. This is not surprising as terminology issues are like credit card bills. Not very exciting but you will end up in big trouble if you don't deal with them. Even I am not all that thrilled by my proposed "tristimulance" terminology, and I'd be happy to endorse a better suggestion if one is put forward. But I think that there is something unsatisfactory about our current use of terminology and specifically the term "radiance". If we accept the ANSI/IES illuminating engineering terminology standard, then the term radiance has a precise definition, and it precisely describes a quantity which is useless for computer graphics. It measures radiated power regardless of its wavelength. If I'm warming my feet by a roaring fire, radiance is useful for telling me how close I can get before my socks are in danger of catching on fire, but it does not describe what I will actually see with my eyes. The current usage often seems be (and I too am guilty of this): "I'll say 'radiance' (since I'm used to the term and others use it too) because its obvious that I don't actually mean 'radiance' (as defined in the ANSI/IES standard) and therefore my audience will figure out what I actually mean (even if I'm not sure myself)". If we want to continue using the term radiance we should really decide what we mean by it. It is fine for describing monochromatic light, but that's only useful for some pedagogical purposes. We could claim that it is a shorthand for the spectral radiance, but we should recognize that that is an implicit redefinition of the term radiance. Also we aren't really after spectral radiance. I don't know anyone who actually stores a spectra at each of their pixels (at least not in computer graphics). And we don't bother to compute the spectral radiance outside of the visible band, not because its not significant, but because it doesn't affect what really are interested in. So what is it that we are really interested in computing and what should we call it? This may all seem like hair splitting, but what is the point of having precisely defined terms unless we use them precisely? So I would challenge people to either specify what it is they actually mean when they say radiance, or to find some alternate terminology to use instead. Let me quickly respond to a few comments that I received: - CIE and IES standards committees are very slow moving bodies, do not coordinate with each other, and are not necessarily receptive to outside suggestions. Thus the chance of affecting the official standards is slim. > I believe the graphics community should follow standards where they exist and are applicable, but we also have the right to define our own terminology where no appropiate standard exists. - Is the "tri" in tristimulance really necessary, what if you are using a different number of weighting functions. How about stimulance instead? > The tristimulance terminology is specifically intended for color vision in the phototopic range where the three color channel approximation is nearly universal. It is also intended to be derivative the somewhat standard terminology "tristimulus values". Other quantities might be termed stimulance, though there would be some objections if these quantities did not correspond to actual stimuli. - Why not just call it the "color of the radiance"? > Radiance by definition does not contain the color information. It would be at least as correct (and I would argue probably more correct) to call it the "color of the luminance". In my opinion, neither one is really satisfactory or terribly precise. Bruce Walter From owner-globillum-imag@imag.fr Tue Apr 1 10:18:03 1997 Return-Path: Date: Tue, 01 Apr 1997 13:03:08 +0100 To: "Ian Ashdown" From: "Tralvex Yeap (T.Rex)" Subject: Re: New global illumination bibliography Cc: Status: R --MimeMultipartBoundary Content-Type: text/plain; charset="us-ascii" Dear Ian, At 09:33 31/03/97 -0800, Ian Ashdown wrote: >There is a wonderful *annotated* global illumination bibliography that >has been put together by Travlex Yeap. You can access it at: > > http://www.scs.leeds.ac.uk/mscytsy/md/abs-mnu.htm > Just to keep you updated, your 1031 bibliography have been converted to a 2 frames hyperlink format for easy reference... http://www.scs.leeds.ac.uk/mscytsy/md/abs-ian0.htm for direct access. Rdgs, - t - mscytsy@scs.leeds.ac.uk * http://www.singnet.com.sg/~tyeap "Give to the world the best you have and the best will come back to you" --MimeMultipartBoundary-- From owner-globillum-imag@imag.fr Wed Apr 2 13:09:00 1997 Return-Path: Date: Wed, 2 Apr 1997 07:25:01 -0800 (PST) To: globillum@imag.fr From: iashdown@ledalite.com (Ian Ashdown) Subject: ANNOUNCE: Radiosity Bibliography Update Status: R --MimeMultipartBoundary Content-Type: text/plain; charset="us-ascii" ANNOUNCE: 97/04/01 Release of RADBIB97.BIB ------------------------------------------ RADBIB97 is a comprehensive bibliography of radiosity and related global illumination papers, theses, articles, and books. It currently includes 1,106 references. This bibliography is available in BibTex format as RADBIB97.BIB (with a release date of April 1, 1997) from: http://www.ledalite.com/library-/rrt.htm and as compressed RadBib97.Z from: ftp://hobbes.lbl.gov/pub/doc As always, it is time-consuming and sometimes difficult to track down conference papers and theses on radiosity and global illumination. If you know of a relevant reference that is not included in the bibliography, please let me know so that I can include it in the next release. --MimeMultipartBoundary-- From owner-globillum-imag@imag.fr Thu Apr 17 13:09:34 1997 Return-Path: Date: Thu, 17 Apr 1997 15:21:20 -0400 To: globillum@imag.fr From: "Andrew J. Willmott" Subject: Tech report on radiosity methods Status: R --MimeMultipartBoundary Content-Type: text/plain; charset="us-ascii" I just wanted to announce that a technical report on our investigation of the various radiosity algorithms out there is available on the web at: http://www.cs.cmu.edu/~radiosity/emprad-tr.html The abstract is reproduced below: --- An Empirical Comparison of Radiosity Algorithms Andrew J. Willmott and Paul S. Heckbert This report presents an extensive empirical comparison of matrix, progressive, and wavelet radiosity algorithms for simulating diffuse interreflection in three-dimensional scenes. The algorithms are tested in their basic forms, without advanced variations such as clustering, discontinuity meshing, or Monte Carlo techniques. The three algorithms were implemented in a common code base to facilitate direct empirical comparison. A number of parameterized scenes were designed to test the basic methods' ability to deal with such issues as singularities, occlusion, high reflectance, and scene complexity. Each algorithm was run on the set of scenes at several parameter settings, and results were examined in terms of their error, speed, and memory consumption. For the basic algorithms as we implemented them, our results show: Progressive radiosity with substructuring is best for simple scenes, but for moderately complex scenes it is outperformed by wavelet radiosity using the Haar basis. Wavelet methods use an immense amount of memory; without clustering they become totally impractical for complex scenes. The problem is particularly severe for higher order bases, less so for Haar. Visibility handling was also found to be a critical problem with higher order wavelets. This study also provides a general framework for comparisons of global illumination techniques. --- Cheers, Andrew --- mailto:a.willmott@cs.cmu.edu ------- http://www.cs.cmu.edu/~ajw --- --MimeMultipartBoundary-- From owner-globillum-imag@imag.fr Mon May 19 10:02:38 1997 Received: from hobbes.lbl.gov (hobbes.lbl.gov [128.3.12.38]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id KAA16219 for ; Mon, 19 May 1997 10:02:37 -0700 Received: from lbl.gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA03168; Mon, 19 May 97 10:01:03 PDT Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id KAA25326; Mon, 19 May 1997 10:01:04 -0700 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by imag.imag.fr (8.8.1/8.6.9) with SMTP id SAA06323 for ; Mon, 19 May 1997 18:09:42 +0200 (MET DST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id JAA01266 for <@sgi.engr.sgi.com:globillum@imag.fr>; Mon, 19 May 1997 09:09:40 -0700 env-from (bwade@cthulhu.engr.sgi.com) Received: from amie.engr.sgi.com (amie.engr.sgi.com [198.29.108.214]) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id JAA07565 for <@cthulhu.engr.sgi.com:globillum@imag.fr>; Mon, 19 May 1997 09:09:39 -0700 Received: from pc-amie (pc-amie.engr.sgi.com [198.29.108.199]) by amie.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via SMTP id JAA12589 for ; Mon, 19 May 1997 09:09:38 -0700 Message-Id: <3.0.1.32.19970519090938.00a93260@amie.engr.sgi.com> X-Sender: bwade@amie.engr.sgi.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 19 May 1997 09:09:38 -0700 To: From: Bretton Wade Subject: Re: Software patents In-Reply-To: <199705181620.JAA28909@mercury.uniserve.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" Status: R --MimeMultipartBoundary Content-Type: text/plain; charset="us-ascii" And was everyone on this list presented as a co-creator? Seriously, can you give any more details? Thanks, Bretton At 09:20 AM 5/18/97 -0700, Ian Ashdown wrote: >You may be interested to know that on May 28, 1996, the United States >Patent Office awarded the following two patents: > > US Patent Number: 5,521,852 > 5,521,853 (continuation) > Title: Method and System for Designing Lighting > Installations > Inventors: John D. Hibbs > Douglas J. Stang > Assignee: Holophane Lighting, Inc. > Newark, Ohio > >There are no less than 42 claims between these two patents, and they are >very broad in scope. They pertain to any computer graphics program that >attempts to model physically realistic lighting. > >Ian Ashdown, P. Eng. | READ THE BOOK! | >Research & Development Manager | Radiosity: A Programmer's Perspective | >Ledalite Architectural Products | Wiley & Sons 1994 | >Visit http://www.ledalite.com | (Sneaky Internet Advertising) | > > -- Bretton Wade (bwade@engr.sgi.com) --MimeMultipartBoundary-- From owner-globillum-imag@imag.fr Mon May 19 13:14:34 1997 Received: from hobbes.lbl.gov (hobbes.lbl.gov [128.3.12.38]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id NAA16423 for ; Mon, 19 May 1997 13:14:33 -0700 Received: from lbl.gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA03662; Mon, 19 May 97 13:12:58 PDT Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id NAA06252; Mon, 19 May 1997 13:12:59 -0700 Received: from relay2.mail.uk.psi.net (sys1.london.uk.psi.net [154.32.108.2]) by imag.imag.fr (8.8.1/8.6.9) with ESMTP id UAA08338 for ; Mon, 19 May 1997 20:51:42 +0200 (MET DST) Received: from lightwork.co.uk (lightwork.co.uk [195.152.206.2]) by relay2.mail.uk.psi.net (8.8.4/) with SMTP id TAA10863; Mon, 19 May 1997 19:41:18 +0100 (BST) Received: by lightwork.co.uk (SMI-8.6/SMI-SVR4) id TAA10823; Mon, 19 May 1997 19:40:43 +0100 Received: from owl(192.9.200.2) by roo via smap (V1.3) id sma010821; Mon May 19 19:40:21 1997 Received: from hermia by owl.lightwork.co.uk (SMI-8.6/SMI-SVR4) id TAA22723; Mon, 19 May 1997 19:40:10 +0100 Message-Id: <33809D23.56AF@lightwork.co.uk> Date: Mon, 19 May 1997 19:34:11 +0100 From: Neil Gatenby Reply-To: neil@lightwork.co.uk Organization: LightWork Design Ltd X-Mailer: Mozilla 3.0 (WinNT; I) Mime-Version: 1.0 To: Bretton Wade Cc: globillum@imag.fr Subject: Re: Software patents References: <3.0.1.32.19970519090938.00a93260@amie.engr.sgi.com> Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" Status: R --MimeMultipartBoundary Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bretton Wade wrote: > > And was everyone on this list presented as a co-creator? > > Seriously, can you give any more details? > > Thanks, > Bretton > > At 09:20 AM 5/18/97 -0700, Ian Ashdown wrote: > >You may be interested to know that on May 28, 1996, the United States > >Patent Office awarded the following two patents: > > > > US Patent Number: 5,521,852 > > 5,521,853 (continuation) > > Title: Method and System for Designing Lighting > > Installations > > Inventors: John D. Hibbs > > Douglas J. Stang > > Assignee: Holophane Lighting, Inc. > > Newark, Ohio > > > >There are no less than 42 claims between these two patents, and they are > >very broad in scope. They pertain to any computer graphics program that > >attempts to model physically realistic lighting. The two attached files were collated from http://www.uspto.gov/ the first details the patents, the second is the list of patents referenced by these patents Neil --MimeMultipartBoundary-- From owner-globillum-imag@imag.fr Mon May 19 16:56:26 1997 Received: from hobbes.lbl.gov (hobbes.lbl.gov [128.3.12.38]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id QAA16996 for ; Mon, 19 May 1997 16:56:26 -0700 Received: from lbl.gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA04205; Mon, 19 May 97 16:54:50 PDT Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id QAA18070; Mon, 19 May 1997 16:54:55 -0700 Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [129.34.139.18]) by imag.imag.fr (8.8.1/8.6.9) with ESMTP id AAA11191 for ; Tue, 20 May 1997 00:57:41 +0200 (MET DST) Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id SAA03508; Mon, 19 May 1997 18:56:16 -0400 Received: from watngi01.watson.ibm.com (watngi01.watson.ibm.com [9.2.235.20]) by mailhub1.watson.ibm.com (8.8.2/01-15-97) with SMTP id SAA32164; Mon, 19 May 1997 18:56:42 -0400 Received: by watngi01.watson.ibm.com(Lotus SMTP MTA v1.05 (305.3 1-15-1997)) id 8525649C.007E0610 ; Mon, 19 May 1997 18:56:30 -0400 X-Lotus-Fromdomain: IBM RESEARCH From: "Holly Rushmeier" To: neil@lightwork.co.uk Cc: bwade@relay.engr.SGI.COM, globillum@imag.fr Message-Id: <8525649C.0075B959.00@watngi01.watson.ibm.com> Date: Mon, 19 May 1997 18:55:27 -0400 Subject: Re: Software patents Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" Status: R I find patents very hard to read and I probably misinterpret them. There are a lot of alarming sounding patents. Since IBM is big on patenting, there is a patent search web page from IBM for searching on text etc. if you want to find more. http://patent.womplex.ibm.com/ Besides locating the patent, you can read the full text from gif images of the actual patent, or just get ascii text of all the claims. The patent Ian mentioned seems from my naive point of view to be impossible to defend -- they describe a lot of well-known stuff like a simple adaptive subdivision scheme for meshing. Another odd example is, 5590062 "Simulator for producing various living environments mainly for visual perception" seems to patent VR for looking at realistic 3D environments. I like the part on page 41 that says "The 3-D space is not limited to the internal space ... a plain in the Mesozoic era where dinosaurs exist can be simulated just for fun." I suppose there is a good legal reason for saying something like this. I also suppose there is a reason they reference Chernoff's paper on multivariate visualization with faces. Then there is 4928250 "System for deriving radiation images" (aka the hemicube patent) and the 16 patents that reference it including the hierarchical z-buffer and something called "Image Processing Apparatus" that has to do with ray casting in radiosity calculations. Three patents reference the patent on ray casting for view factors including 5546327 "Apparatus for calculating geometrical view factor", just issued last August which seems to patent using a hemisphere instead of the hemicube. Following various links also leads to 5619627 "Multiple-level occulting using a mask buffer" that describes an "Occulting apparatus" which just seems to be a method for finding hidden surfaces fast, not as mysterious an apparatus as you might think. I was surprised to find 5363477 "Method for displaying an image of an object surface using a luminance transformationin accordance with a non-linear characteristic" that sounds like a patent on the notion of tone mapping for synthetic images. You can also search by assignee, for example to see all of Pixar's patents, e.g. 5239624 "Pseudo-random point sampling techniques in computer graphics". Anyway, if you get depressed over this , try the "Gallery of Obscure Patents" at http://patent.womplex.ibm.com/gallery.html which includes "Wacky Patent of the Month." On the other hand, the fact that some one was able to patent a hat that looks like a fried egg might depress you even more. -- Holly From owner-globillum-imag@imag.fr Tue May 20 09:50:32 1997 Received: from hobbes.lbl.gov (hobbes.lbl.gov [128.3.12.38]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id JAA17843 for ; Tue, 20 May 1997 09:50:31 -0700 Received: from lbl.gov by hobbes.lbl.gov (3.2/SMI-3.2) id AA06869; Tue, 20 May 97 09:48:55 PDT Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id JAA13023; Tue, 20 May 1997 09:46:36 -0700 Received: from ibis.doc.ic.ac.uk (ibis.doc.ic.ac.uk [146.169.12.90]) by imag.imag.fr (8.8.1/8.6.9) with SMTP id OAA29782 for ; Tue, 20 May 1997 14:41:25 +0200 (MET DST) Received: by ibis.doc.ic.ac.uk (Smail3.1.28.1 #8) id m0wTnlY-0002ndC; Tue, 20 May 97 13:11 BST Message-Id: Date: Tue, 20 May 97 13:11 BST To: globillum@imag.fr From: ajc@doc.ic.ac.uk (Adrian J. Chung) References: <8525649C.0075B959.00@watngi01.watson.ibm.com> X-Mailer: vmail-0.06alpha Subject: Re: Software patents Status: RO "Holly Rushmeier" wrote: > I find patents very hard to read and I probably misinterpret > them. There are a lot of alarming sounding patents. IANAL. Any lawyers on this list? > Since IBM is big on patenting, there is a patent search web page from IBM > for searching on text etc. if you want to find more. > > http://patent.womplex.ibm.com/ Thank's for the URL. Bookmarked. I'm sure many of you are familiar with the Electronic Frontier Foundation page on intellectual property: http://www.eff.org/pub/Intellectual_property/ Useful for some legal insight on software law. Not sure how biased it is though. > The patent Ian mentioned seems from my naive point of view to be > impossible to defend -- they describe a lot of well-known stuff like > a simple adaptive subdivision scheme for meshing. Maybe they're hoping to capitalise on it in the same way E-Data has been with patent 4528643, which claims rights to all methods of electronic multimedia distribution. In this case the patent predates the now "well known" nature of WWW. ( See http://www.lpf.org/Patents/edata.html for the anti-software-patent point of view of the case) If worse comes to worse perhaps the Net will treat enforced software patents as damage and route around them. (to misquote John Gillmore) This was certainly a major motivating factor behind the PNG standard as a GIF replacement. I can see it now. Huge Monte Carlo rendering farms being set up in the Caribbean (or other legal havens) servicing contracts from US based companies. Adrian "your milage may vary" -- DISCLAIMER: URLs quoted in the above message should not in anyway imply that the author, the department, or indeed the institution from which the email is sent are in any sense libertarian. Copyright 1997 by Adrian J. Chung. It may be quoted in part for strictly non-commercial use only. From owner-globillum-imag@imag.fr Wed May 28 11:37:45 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA28154 for ; Wed, 28 May 1997 11:37:44 -0700 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA13336 for ; Wed, 28 May 1997 11:40:43 -0700 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id LAA11272; Wed, 28 May 1997 11:36:05 -0700 Received: from sys3.cambridge.uk.psi.net (sys3.cambridge.uk.psi.net [154.32.106.10]) by imag.imag.fr (8.8.1/8.6.9) with ESMTP id TAA05629 for ; Wed, 28 May 1997 19:25:23 +0200 (MET DST) Received: from lightwork.co.uk (lightwork.co.uk [195.152.206.2]) by sys3.cambridge.uk.psi.net (8.8.4/) with SMTP id SAA19108 for ; Wed, 28 May 1997 18:25:18 +0100 (BST) Received: by lightwork.co.uk (SMI-8.6/SMI-SVR4) id SAA20124; Wed, 28 May 1997 18:24:47 +0100 Received: from owl(192.9.200.2) by roo via smap (V1.3) id sma020122; Wed May 28 18:24:33 1997 Received: from hermia by owl.lightwork.co.uk (SMI-8.6/SMI-SVR4) id SAA08832; Wed, 28 May 1997 18:24:32 +0100 Message-ID: <338C68CD.4C30@lightwork.co.uk> Date: Wed, 28 May 1997 18:18:05 +0100 From: Neil Gatenby Reply-To: neil@lightwork.co.uk Organization: LightWork Design Ltd X-Mailer: Mozilla 3.0 (WinNT; I) MIME-Version: 1.0 To: globillum@imag.fr Subject: jobs Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" Status: R --MimeMultipartBoundary Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit For jobs in global illumination, and other areas of 3D graphics, see http://www.lightwork.com/vacancies/ For global illumination, follow the "Software Engineer - Lighting Simulation and Radiosity" thread. Neil -- Neil Gatenby, Software lead, LightWork Design Limited. mailto:neil@lightwork.co.uk http://www.lightwork.com Tel: +44 114 266 8404 ext 118 FAX: +44 114 266 1383 --MimeMultipartBoundary-- From owner-globillum-imag@imag.fr Fri Jun 6 13:20:27 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA10588 for ; Fri, 6 Jun 1997 13:20:26 -0700 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA19141 for ; Fri, 6 Jun 1997 13:23:22 -0700 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id NAA02925; Fri, 6 Jun 1997 13:18:50 -0700 Received: from redemption.uniserve.com (redemption.uniserve.com [204.191.197.254]) by imag.imag.fr (8.8.1/8.6.9) with SMTP id VAA03266 for ; Fri, 6 Jun 1997 21:38:01 +0200 (MET DST) Received: from ian [204.191.197.127] by redemption.uniserve.com with smtp (Exim 1.62 #1) id 0wa4pi-0004bb-00; Fri, 6 Jun 1997 12:37:58 -0700 X-Sender: iashdown@pop.uniserve.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" To: globillum@imag.fr From: iashdown@ledalite.com (Ian Ashdown) Subject: 97/06/01 Release of RADBIB97.BIB Message-Id: Date: Fri, 6 Jun 1997 12:37:58 -0700 Status: R --MimeMultipartBoundary Content-Type: text/plain; charset="us-ascii" ANNOUNCE: 97/06/01 Release of RADBIB97.BIB ------------------------------------------ RADBIB97 is a comprehensive bibliography of radiosity and related global illumination papers, theses, articles, and books. It currently includes 1,152 references. This bibliography is available in BibTex format as RADBIB97.BIB (with a release date of June 1, 1997) from: http://www.ledalite.com/library-/rrt.htm ftp://ftp.ledalite.com/pub/radbib97.bib - Ian Ashdown --MimeMultipartBoundary-- From owner-globillum-imag@imag.fr Mon Jun 9 12:24:46 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA01140 for ; Mon, 9 Jun 1997 12:24:45 -0700 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA01843 for ; Mon, 9 Jun 1997 11:29:46 -0700 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id LAA06280; Mon, 9 Jun 1997 11:25:19 -0700 Received: from HOSTESS.GRAPHICS.CS.CMU.EDU (HOSTESS.GRAPHICS.CS.CMU.EDU [128.2.206.188]) by imag.imag.fr (8.8.1/8.6.9) with SMTP id TAA13181 for ; Mon, 9 Jun 1997 19:39:15 +0200 (MET DST) From: Paul.Heckbert@HOSTESS.GRAPHICS.CS.CMU.EDU Message-Id: <199706091739.TAA13181@imag.imag.fr> Date: Mon, 9 Jun 97 13:18:21 EDT To: globillum@imag.fr Subject: read comparison before St Etienne? Status: R If you are coming to the Eurographics Workshop on Rendering in St Etienne, France next week (see http://www.emse.fr/RENDERING97/) then I would like to suggest that you read a tech report "An Empirical Comparison of Radiosity Algorithms" http://www.cs.cmu.edu/~radiosity/emprad-tr.html as my co-author and I would enjoy getting feedback on this work at the workshop, and we feel it could be an interesting topic of discussion there. Some of our conclusions: * Wavelet radiosity without clustering and matrix radiosity are memory hogs. (esp. matrix radiosity and higher order wavelets; HR not so bad) This was previously known; our results show how bad they are. * Visibility handling in wavelet radiosity algorithms is poor, consequently higher order wavelets are not currently practical. * Progressive radiosity with substructuring is often a better choice than wavelet radiosity. Paul Heckbert Computer Science Dept., Carnegie Mellon University 5000 Forbes Ave, Pittsburgh PA 15213-3891, USA ph@cs.cmu.edu http://www.cs.cmu.edu/~ph From owner-globillum-imag@imag.fr Wed Jun 11 12:15:59 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA04608 for ; Wed, 11 Jun 1997 12:15:59 -0700 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA10479 for ; Wed, 11 Jun 1997 12:18:50 -0700 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id MAA17770; Wed, 11 Jun 1997 12:14:11 -0700 Received: from redemption.uniserve.com (redemption.uniserve.com [204.191.197.254]) by imag.imag.fr (8.8.1/8.6.9) with SMTP id UAA06911 for ; Wed, 11 Jun 1997 20:18:22 +0200 (MET DST) Received: from ian [204.191.197.53] by redemption.uniserve.com with smtp (Exim 1.62 #1) id 0wbryJ-0006mc-00; Wed, 11 Jun 1997 11:18:16 -0700 X-Sender: iashdown@pop.uniserve.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" To: globillum@imag.fr From: iashdown@ledalite.com (Ian Ashdown) Subject: Spectroradiometric data Message-Id: Date: Wed, 11 Jun 1997 11:18:16 -0700 Status: R --MimeMultipartBoundary Content-Type: text/plain; charset="us-ascii" One of our most common excuses for using the simplistic RGB color model in global illumination-based rendering is that "there are no spectroradiometric data for commonly available materials." This has undoubtably been true in the past, but this excuse is beginning to wear thin. If you are looking for such data, try: http://www.lut.fi/ltkk/tite/research/color/lutcs_readme.html - Ian Ashdown P.S. - I'm sure they are many more sites out there with equally useful data. I only found this particular one because I was (am still am) looking for an algorithm to convert DIN RAL codes to their equivalent Munsell values. Any suggestions on where to look for this information (short of actually the DIN standards ;+) would be much appreciated. --MimeMultipartBoundary-- From owner-globillum-imag@imag.fr Thu Jun 12 04:42:02 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id EAA05856 for ; Thu, 12 Jun 1997 04:42:01 -0700 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id EAA13118 for ; Thu, 12 Jun 1997 04:45:00 -0700 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id EAA13927; Thu, 12 Jun 1997 04:40:02 -0700 Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.23]) by imag.imag.fr (8.8.1/8.6.9) with ESMTP id KAA28823 for ; Thu, 12 Jun 1997 10:41:52 +0200 (MET DST) Received: by mail3.microsoft.com with Internet Mail Service (5.0.1458.30) id ; Thu, 12 Jun 1997 01:44:16 -0700 Message-ID: <011290D45A8ACF119B8B00805FD471D60321993B@RED-24-MSG.dns.microsoft.com> From: Andrew Glassner To: globillum@imag.fr, "'iashdown@ledalite.com'" Subject: RE: Spectroradiometric data Date: Thu, 12 Jun 1997 01:41:25 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.30) Status: R This has long been a pet peeve of mine as well. You can find a bunch of public-domain standard curves and some standard and unusual reflectance data at http://www.research.microsoft.com/research/graphics/glassner/work/projec ts/pdis/pdis.htm Gregory Ward Larson has also made this available in MGF style at http://radsite.lbl.gov/mgf/HOME.html -Andrew > ---------- > From: iashdown@ledalite.com[SMTP:iashdown@ledalite.com] > Sent: Wednesday, June 11, 1997 11:18 AM > To: globillum@imag.fr > Subject: Spectroradiometric data > > One of our most common excuses for using the simplistic RGB > color model in global illumination-based rendering is that > "there are no spectroradiometric data for commonly available > materials." > > This has undoubtably been true in the past, but this excuse > is beginning to wear thin. If you are looking for such data, > try: > > http://www.lut.fi/ltkk/tite/research/color/lutcs_readme.html > > - Ian Ashdown > > P.S. - I'm sure they are many more sites out there with > equally useful data. I only found this particular one because > I was (am still am) looking for an algorithm to convert DIN > RAL codes to their equivalent Munsell values. Any suggestions > on where to look for this information (short of actually > the DIN standards ;+) would be much appreciated. > From owner-globillum-imag@imag.imag.fr Fri Jun 13 11:11:11 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA07898 for ; Fri, 13 Jun 1997 11:11:06 -0700 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA19519 for ; Fri, 13 Jun 1997 11:14:04 -0700 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id LAA16672; Fri, 13 Jun 1997 11:09:17 -0700 Received: from inf.ethz.ch (root@neptune.ethz.ch [129.132.10.10]) by imag.imag.fr (8.8.1/8.8.5) with SMTP id OAA05884 for ; Fri, 13 Jun 1997 14:39:37 +0200 (MET DST) Received: from barks (barks.inf.ethz.ch [129.132.10.212]) by inf.ethz.ch (8.6.10/8.6.10) with ESMTP id OAA25807 for ; Fri, 13 Jun 1997 14:39:36 +0200 Received: (lippert@localhost) by barks (950413.SGI.8.6.12/8.6.9) id OAA15558 for globillum@imag.fr; Fri, 13 Jun 1997 14:39:35 +0200 From: "Lars Lippert" Message-Id: <9706131439.ZM15556@barks.inf.ethz.ch> Date: Fri, 13 Jun 1997 14:39:34 -0600 X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: globillum@imag.fr Subject: Volume Rendering in Java Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" Status: R --MimeMultipartBoundary Content-Type: text/plain; charset=us-ascii Hi, I just wanted to announce that an interactive web-based volume renderer can now be tested. The program is written as an applet, that runs inside Web pages. The concept behind this software is a hierarchical (wavelet-based) representation of the volume data-set. The data is rendered directly from wavelet-space and thus requires a minumum of memory. The applet presents a novel way of presenting volumetric data on the Internet. The user can manipulate an inferior quality version of 3-D volume interactively in order to set up the viewing parameters, and when they are correct the image refines progressively. The rendering perfomance depends on the network bandwidth and the available hardware platform. Simply point your internet browser to: http://www.inf.ethz.ch/personal/lippert/EVOLVE/ Please feel free to contact me with comments, suggestions, or bug-reports. I only ran the program on my Indy and PC , but one of the nice feature of Java is that it runs on all architectures. If this is not the case, please let me know. Lars -- _________________________________________________________________________ Lars Lippert Computer Graphics Research Group Institute for Information Systems Swiss Federal Institute of Technology Zuerich Tel.: +41-1-632 71 21 Email: lippert@inf.ethz.ch Fax : +41-1-632 11 72 Office: IFW E45.2 http://www.inf.ethz.ch/personal/lippert _________________________________________________________________________ --MimeMultipartBoundary-- From mscytsy@scs.leeds.ac.uk Wed Jun 18 06:45:24 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA14557 for ; Wed, 18 Jun 1997 06:45:08 -0700 Received: from csunb0.leeds.ac.uk (csunb0.leeds.ac.uk [129.11.144.2]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA20781 for ; Wed, 18 Jun 1997 06:48:02 -0700 Received: from cspcx23 (cspcx23.leeds.ac.uk [129.11.147.23]) by csunb0.leeds.ac.uk (8.6.12/8.6.12) with SMTP id OAA16453; Wed, 18 Jun 1997 14:30:51 +0100 Message-Id: <2.2.32.19970618133015.005c45ac@csirisa> X-Sender: mscytsy@csirisa X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 18 Jun 1997 14:30:15 +0100 To: iashdown@ledalite.com, renambot@irisa.fr, fiction@pressroom.com, alz@lanminds.com, ali@eel.ufl.edu, pawel@proffa.cc.tut.fi, vlad@hops.cs.jhu.edu, accmdq@mail.telepac.pt, greg@floyd, abraham@sp.ac.sg, neil@lightwork.co.uk, ttwong@unixg.ubc.ca, Wim.Dumon@cs.kuleuven.ac.be, mart@dcre.leeds.ac.uk, rcl@scs.leeds.ac.uk From: "Tralvex Yeap (T.Rex)" Subject: Executive Summary: Flowchart of Radiosity + VR System Status: R Hi all, If I had make any mistake in the _Methods_ please keep me updated. Thanks. Flowchart of Radiosity VR System ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Model +---> Environment Methods | | ~~~~~~~ | | o Mesh Template Methods | | o Decomposition Methods | v o Discontinuity Meshing | Surface o Topological Data Structures & Operators | Meshing o Texture Mapping | | ------------------------------ | | | | Cohen Taxonomy of FF algorithms | v o Analytical | Form Factor o Numerical: Hemicube, coutour, | Calculation Monte Carlo, Hierarchical, Uniform... | | Nusselt, Cubic Tetrahedral, | | ------------------------------ | | o Iterative Method | v o Relaxation - Jacobi, Gauss-Seidel, | Solve Linear Southwell, Progressive refinement | Radiosity Eqn o Hierarchical subdivision | | o Hierachical Basis fn & Wavelets |-------->| o Importance-Based | | ------------------------------ | v | 3D Scene o Bilinear Interpolation | Visualisation o Gouraud shading | | o Phong | | o Texture mapping | | | v +---- VR Engine References: 1. Ashdown, Radiosity, A Programmer's Perspective 2. Cohen et al, Radiosity & Realistic Image Synthesis 3. Glasnner, Principles of Digital Image Synthesis 2nd volume. 4. Sillion et al., Radiosity and Global Illumination n. Various papers. Best Regards, - t - mscytsy@scs.leeds.ac.uk * http://www.singnet.com.sg/~tyeap "Give to the world the best you have and the best will come back to you" From owner-globillum-imag@imag.imag.fr Wed Jun 18 10:20:50 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA14819 for ; Wed, 18 Jun 1997 10:20:49 -0700 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA21383 for ; Wed, 18 Jun 1997 10:23:44 -0700 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id KAA25724; Wed, 18 Jun 1997 10:19:19 -0700 Received: from adeskgate.autodesk.com (adeskgate.autodesk.com [198.93.152.11]) by imag.imag.fr (8.8.1/8.8.5) with ESMTP id SAA14615 for ; Wed, 18 Jun 1997 18:04:58 +0200 (MET DST) Received: from autodesk.autodesk.com by adeskgate.autodesk.com (8.6.12/SMI-5.3) with ESMTP id JAA19403; Wed, 18 Jun 1997 09:04:07 -0700 Received: from hqhubmu1.autodesk.com by autodesk.autodesk.com (8.6.12/4.4BSD) with ESMTP id JAA05628; Wed, 18 Jun 1997 09:03:54 -0700 Received: from ccinternet.autodesk.com (ccinternet [144.111.240.144]) by hqhubmu1.autodesk.com (8.7.5/8.7.3) with SMTP id JAA21836 for ; Wed, 18 Jun 1997 09:03:52 -0700 (PDT) Received: from ccMail by ccinternet.autodesk.com (IMA Internet Exchange 2.11 (Pre-release) Enterprise) id 0002051F; Wed, 18 Jun 1997 09:03:11 -0700 Mime-Version: 1.0 Date: Wed, 18 Jun 1997 11:59:38 -0700 Message-ID: <0002051F.4149@autodesk.com> From: eric.haines@autodesk.com (Eric Haines) Subject: Ray tracing bibliography updated To: globillum Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" Content-Description: cc:Mail note part Status: R --MimeMultipartBoundary Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Globillumers, I've updated the free ray tracing bibliography with a number of new references (many thanks to Steve Warren at Sandia). The bibliography is available at: http://www.acm.org/tog/resources/bib/ Please do let me know of any additions/corrections you know of, Eric Haines erich@acm.org --MimeMultipartBoundary-- From owner-globillum-imag@imag.imag.fr Mon Jun 23 12:40:20 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA04123 for ; Mon, 23 Jun 1997 12:40:19 -0700 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA19295 for ; Mon, 23 Jun 1997 12:43:18 -0700 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id MAA17897; Mon, 23 Jun 1997 12:38:48 -0700 Received: from ns1.arlut.utexas.edu (ns1.arlut.utexas.edu [129.116.212.1]) by imag.imag.fr (8.8.1/8.8.5) with ESMTP id RAA16375 for ; Mon, 23 Jun 1997 17:52:10 +0200 (MET DST) Received: from mail-firewall.arlut.utexas.edu (ns1.arlut.utexas.edu [129.116.212.1]) by ns1.arlut.utexas.edu (8.8.5/8.8.5) with ESMTP id KAA12978; Mon, 23 Jun 1997 10:48:38 -0500 (CDT) Received: from sting.arlut.utexas.edu (sting.arlut.utexas.edu [129.116.128.90]) by mail-firewall.arlut.utexas.edu (8.8.5/8.8.5) with ESMTP id KAA12971; Mon, 23 Jun 1997 10:48:37 -0500 (CDT) Received: from sting (localhost [127.0.0.1]) by sting.arlut.utexas.edu (8.8.5/8.7.3) with SMTP id KAA24180; Mon, 23 Jun 1997 10:48:35 -0500 (CDT) Sender: atc@arlut.utexas.edu Message-ID: <33AE9AD3.6263@arlut.utexas.edu> Date: Mon, 23 Jun 1997 10:48:35 -0500 From: "A. T. Campbell" X-Mailer: Mozilla 3.01 (X11; I; HP-UX A.09.07 9000/770) MIME-Version: 1.0 To: Neil Gatenby CC: "'globillum@imag.fr'" Subject: Re: Proceedings of Graphics Interface 97 References: <01BC7FBC.CC783360@hermia.lightwork> Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" Status: R --MimeMultipartBoundary Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Neil Gatenby wrote: > > Hi; > > Could anyone tell me how I can get hold of a copy of the proceedings of Graphics Interface 97? I have tried searching on the web, but to no avail. > > Thanks in advance, > > Neil Electronic copies of all the papers from GI '97 are available from the conference's web page: http://www.dgp.toronto.edu/gi/gi97/home.html Hardcopies of the proceedings may be purchased from Morgan Kaufmann Publishers. Their web page's URL is the following: http://www.mkp.com/ -- A. T. Campbell, III atc@arlut.utexas.edu http://www.arlut.utexas.edu/~atc Applied Research Labs, University of Texas, PO Box 8029, Austin,TX 78713 --MimeMultipartBoundary-- From mscytsy@scs.leeds.ac.uk Thu Jun 19 10:37:59 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA16028 for ; Thu, 19 Jun 1997 10:37:51 -0700 Received: from csunb0.leeds.ac.uk (csunb0.leeds.ac.uk [129.11.144.2]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA26665 for ; Thu, 19 Jun 1997 10:40:40 -0700 Received: from cspcx20 (cspcx20.leeds.ac.uk [129.11.147.20]) by csunb0.leeds.ac.uk (8.6.12/8.6.12) with SMTP id SAA10751; Thu, 19 Jun 1997 18:22:37 +0100 Message-Id: <2.2.32.19970619162108.005ab958@csirisa> X-Sender: mscytsy@csirisa X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 19 Jun 1997 17:21:08 +0100 To: iashdown@ledalite.com, renambot@irisa.fr, fiction@pressroom.com, alz@lanminds.com, ali@eel.ufl.edu, pawel@proffa.cc.tut.fi, vlad@hops.cs.jhu.edu, accmdq@mail.telepac.pt, greg@floyd, abraham@sp.ac.sg, neil@lightwork.co.uk, ttwong@unixg.ubc.ca, Wim.Dumon@cs.kuleuven.ac.be, mart@dcre.leeds.ac.uk, rcl@scs.leeds.ac.uk From: "Tralvex Yeap (T.Rex)" Subject: Supercomputer and Earth as enclosed Environment Status: RO Hi all, Assuming that we have UNLIMITED computation power machine, does it make sense to take Earth as the hemisphere, and thus an enclosed environment? Or the solar system as a closed environment? Based on Raditive Heat Transfer techniques (Siegel, 1992), it seems possible. Best Regards, - t - mscytsy@scs.leeds.ac.uk * http://www.singnet.com.sg/~tyeap "Give to the world the best you have and the best will come back to you" From owner-globillum-imag@imag.imag.fr Mon Jun 23 15:56:33 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA04291 for ; Mon, 23 Jun 1997 15:56:32 -0700 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA19877 for ; Mon, 23 Jun 1997 15:59:30 -0700 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id PAA29817; Mon, 23 Jun 1997 15:55:01 -0700 Received: from HOSTESS.GRAPHICS.CS.CMU.EDU (HOSTESS.GRAPHICS.CS.CMU.EDU [128.2.206.188]) by imag.imag.fr (8.8.1/8.8.5) with SMTP id XAA26345 for ; Mon, 23 Jun 1997 23:17:13 +0200 (MET DST) From: Paul.Heckbert@HOSTESS.GRAPHICS.CS.CMU.EDU Message-Id: <199706232117.XAA26345@imag.imag.fr> Date: Mon, 23 Jun 97 17:06:54 EDT To: globillum@imag.fr Subject: reflectance model visualizer Status: RO A reflectance model visualizer is available in SGI executable form and C++ source code form at http://www.cs.cmu.edu/~ph/src/illum/ The program should be portable to other machines that support the Xforms user interface library and X windows without too much difficulty. This program is a fairly general viewer for bidirectional reflectance distribution functions (BRDF's). It was written by some students and myself in a graduate course in global illumination that I taught in Fall 1996. The program implements the following reflectance models: Phong Cook-Torrance Oren-Nayar He et al. I demonstrated the program at the Eurographics Workshop on Rendering in St. Etienne, France last week, and there was enough interest that I decided to release it more generally. enjoy! Paul Heckbert Computer Science Dept., Carnegie Mellon University 5000 Forbes Ave, Pittsburgh PA 15213-3891, USA ph@cs.cmu.edu http://www.cs.cmu.edu/~ph From owner-globillum-imag@imag.imag.fr Wed Jun 25 14:55:34 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA06653 for ; Wed, 25 Jun 1997 14:55:33 -0700 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA28162 for ; Wed, 25 Jun 1997 14:58:29 -0700 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id OAA18265; Wed, 25 Jun 1997 14:53:59 -0700 Received: from horus.imag.fr (horus.imag.fr [129.88.38.2]) by imag.imag.fr (8.8.1/8.8.5) with ESMTP id OAA16211 for ; Wed, 25 Jun 1997 14:45:25 +0200 (MET DST) Received: from dirc.bris.ac.uk (dirc.bris.ac.uk [137.222.10.51]) by horus.imag.fr (8.8.1/8.6.9) with SMTP id OAA02857 for ; Wed, 25 Jun 1997 14:45:23 +0200 (MET DST) Received: from luna.cs.bris.ac.uk by dirc.bris.ac.uk with SMTP (XT-PP) with ESMTP; Wed, 25 Jun 1997 13:43:11 +0100 Received: from danno.cs.bris.ac.uk (danno.cs.bris.ac.uk [137.222.102.2]) by luna.cs.bris.ac.uk (8.8.6/8.8.5) with SMTP id NAA04949 for ; Wed, 25 Jun 1997 13:40:14 +0100 (BST) Received: from localhost by danno.cs.bris.ac.uk (SMI-8.6/SMI-SVR4) id NAA13131; Wed, 25 Jun 1997 13:40:28 +0100 Date: Wed, 25 Jun 1997 13:40:27 +0100 (BST) From: "P. Larsen" X-Sender: larsen@danno To: globillum@imag.fr Subject: URGENT - Freeware/Shareware Radiosity package Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" Status: RO --MimeMultipartBoundary Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, my name is Phillip Larsen and I am a MSc student at the University of Bristol, England. I am writing my dissertation on radiosity and need to get hold of a radiosity package which I can build on for my dissertation. The system configuration I will be running the program on is a Sun workstation with the Solaris operating system. If anyon knows where I can get hold of a freeware/shareware radiosity package with accompanying sourcecode I would really appreciate it if you would send me a line saying how and where I could find it. Thankyou for taking the time to read this message. Yours sincerely Phillip Andre' Larsen --MimeMultipartBoundary-- From owner-globillum-imag@imag.imag.fr Thu Jun 26 17:58:35 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA08036 for ; Thu, 26 Jun 1997 17:58:30 -0700 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA05710 for ; Thu, 26 Jun 1997 18:01:28 -0700 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id RAA27025; Thu, 26 Jun 1997 17:56:56 -0700 Received: from droopy.cs.kuleuven.ac.be (root@droopy.cs.kuleuven.ac.be [134.58.41.10]) by imag.imag.fr (8.8.1/8.8.5) with ESMTP id WAA21052 for ; Thu, 26 Jun 1997 22:55:00 +0200 (MET DST) Received: from flater.cs.kuleuven.ac.be (philippe@flater.cs.kuleuven.ac.be [134.58.45.35]) by droopy.cs.kuleuven.ac.be (8.8.5/8.8.5) with ESMTP id VAA14573; Thu, 26 Jun 1997 21:29:26 +0200 (MET DST) Received: (from philippe@localhost) by flater.cs.kuleuven.ac.be (8.8.6/8.8.6) id VAA04735; Thu, 26 Jun 1997 21:29:14 +0200 (MET DST) From: Philippe Bekaert Message-Id: <199706261929.VAA04735@flater.cs.kuleuven.ac.be> Subject: Radiosity Software Available for Free In-Reply-To: from "P. Larsen" at "Jun 25, 97 01:40:27 pm" To: globillum@imag.fr Date: Thu, 26 Jun 1997 21:29:13 +0200 (MET DST) Cc: larsen@cs.bris.ac.uk (P. Larsen), stuerzl@cs.unc.edu, kadi@irisa.fr, Paul.Heckbert@HOSTESS.GRAPHICS.CS.CMU.EDU X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" Status: RO --MimeMultipartBoundary Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Last week at the Eurographics Rendering Workshop in St-Stienne, France, I gave a demo of the photorealistic renderer called "RenderPark", we are developping in the context of our research here in Leuven (Belgium). The renderer currently offers: - Galerkin radiosity (both gathering and shooting) with (or without) hierarchical refinement, higher order approximations, clustering, view-importance, ... - stochastic ray radiosity - ray-casting, classic and stochastic ray-tracing It is known to compile and run fine on a SUN Sparcstation (with LEO graphics hardware and the Nth Protable GL), under Linux (with Mesa, a free OpenGL like graphics library) and on a number of SGI machines (with OpenGL). You can retrieve the source code and example scene files (MGF format) from the URL: http://www.cs.kuleuven.ac.be/cwis/research/graphics/RENDERPARK/ You can build on it for your research too if you like (hooks are provided already for your ultimate rendering algorithm). Best regards, Philippe. -- /~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\ \ Philippe Bekaert | If anything can go wrong, it will, but / / Computer Graphics Research Group | ... we're prepared for it (Switzerland) \ \ Department of Computer Science | ... we don't care (Greece) / / K.U.Leuven - Belgium | ... what the heck, it's been going \ \ | wrong for centuries already (Portugal) / / http://www.cs.kuleuven.ac.be/ | ... it's the fault of the Walloons \ \ ~philippe/ | (Flanders) / /__________________________________| ... we deserve it (Wallonie) \ \ | ... as long as there's vodka we don't / / Not everything that is written | care (Russia) \ \ here is my employers opinion, | ... how much money do I loose? / / sometimes not even mine. | (The Netherlands) \ \__________________________________|_________________________________________/ --MimeMultipartBoundary-- From owner-globillum-imag@imag.imag.fr Mon Jun 30 16:10:04 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA12931 for ; Mon, 30 Jun 1997 16:09:05 -0700 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA17955 for ; Mon, 30 Jun 1997 16:12:01 -0700 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id QAA23340; Mon, 30 Jun 1997 16:07:25 -0700 Received: from HOSTESS.GRAPHICS.CS.CMU.EDU (HOSTESS.GRAPHICS.CS.CMU.EDU [128.2.206.188]) by imag.imag.fr (8.8.1/8.8.5) with SMTP id XAA19065; Mon, 30 Jun 1997 23:22:43 +0200 (MET DST) From: Paul.Heckbert@HOSTESS.GRAPHICS.CS.CMU.EDU Message-Id: <199706302122.XAA19065@imag.imag.fr> Date: Mon, 30 Jun 97 17:14:58 EDT To: K-myszk@u-aizu.ac.jp, ajw@cs.cmu.edu, alan.chalmers@BRIS.AC.UK, almagro@goliat.ugr.es, blasi@labri.u-bordeaux.fr, bremond@LCPC.FR, chense@LIVEPICTURE.COM, colin@lightwork.co.uk, cyril.soler@imag.fr, danix@cs.huji.ac.il, david.gargan@cs.tcd.ie, david.hedley@bristol.ac.uk, david.zareski@Bentley.Com, dischler@ENSIL.UNILIM.FR, dorsey@graphics.lcs.mit.edu, dumont@LCPC.FR, ebic@JET.ES, elf@DGP.TORONTO.EDU, eric@graphics.cornell.edu, f.w.jansen@TWI.TUDELFT.NL, fournier@cs.ubc.ca, francois.sillion@imag.fr, frank.suykens@cs.kuleuven.ac.be, fredo.durand@imag.fr, george.drettakis@imag.fr, gibsons@cs.man.ac.uk, globillum@imag.fr, gs@gup.uni-linz.ac.at, heidrich@informatik.uni-erlangen.de, henrik@MENTAL.COM, holly@watson.ibm.com, htschirm@IMMD9.INFORMATIK.UNI-ERLANGEN.DE, jolivet@unilim.fr, jordi.regincos@ima.udg.es, kadauber@IMMD9.INFORMATIK.UNI-ERLANGEN.DE, kadi@irisa.fr, keller@informatik.uni-kl.de, lalonde@cs.ubc.ca, mancini@ELEC.ENST.FR, max2@llnl.gov, mbolin@CS.UOREGON.EDU, mcnamara@cs.bris.ac.uk, meinds@NATLAB.RESEARCH.PHILIPS.COM, nick.gray@cs.tcd.ie, paquete@iro.umontreal.ca, per@MENTAL.COM, peroche@emse.fr, ph@cs.cmu.edu, pheng@CSE.CUHK.EDU.HK, philipd@cs.kuleuven.ac.be, philippe.bekaert@cs.kuleuven.ac.be, poulin@iro.umontreal.ca, prikryl@acm.org, roelens@emse.fr, rougeron@emse.fr, rt@acm.org, schaefer@graphics.cs.uni-bonn.de, slusallek@informatik.uni-erlangen.de, stamminger@informatik.uni-erlangen.de, steven.collins@cs.tcd.ie, stuerzl@cs.unc.edu, ttwong@acm.org, uselton@nas.nasa.gov, wilkie@CG.TUWEIN.AC.AT, william.leeson@cs.tcd.ie, xavier@ima.udg.es, y.chrysanthou@CS.UCL.AC.UK, ydw@cs.kuleuven.ac.be, zaninetti@emse.fr, zl@MATHS.BATH.AC.UK Subject: alagha@compsci.bristol.ac.uk Status: R The list of participants at the Eurographics Workshop on Rendering in St Etienne, France that I collected there a few days ago has been turned into a web page that is being generously maintained by Francois Sillion: http://safran.imag.fr/Membres/Francois.Sillion/egwkgr.html There you can find links and email addresses of most of the participants, helping you to locate their papers and pictures. Check it out! -Paul Paul Heckbert Computer Science Dept., Carnegie Mellon University 5000 Forbes Ave, Pittsburgh PA 15213-3891, USA ph@cs.cmu.edu http://www.cs.cmu.edu/~ph From owner-globillum-imag@imag.imag.fr Tue Jul 1 13:57:24 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA14610 for ; Tue, 1 Jul 1997 13:57:23 -0700 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA22312 for ; Tue, 1 Jul 1997 14:00:19 -0700 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id NAA20282; Tue, 1 Jul 1997 13:55:44 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by imag.imag.fr (8.8.1/8.8.5) with SMTP id TAA09290 for ; Tue, 1 Jul 1997 19:13:23 +0200 (MET DST) Received: from odin.corp.sgi.com (odin.corp.sgi.com [192.26.51.194]) by deliverator.sgi.com (950413.SGI.8.6.12/951211.SGI.AUTO) via ESMTP id KAA22091; Tue, 1 Jul 1997 10:13:12 -0700 env-from (gregl@radiate.asd.sgi.com) Received: from giraffe.asd.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id KAA26500; Tue, 1 Jul 1997 10:13:04 -0700 Received: from radiate.asd.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id KAA20174; Tue, 1 Jul 1997 10:12:57 -0700 Received: by radiate.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id KAA05298; Tue, 1 Jul 1997 10:12:49 -0700 Date: Tue, 1 Jul 1997 10:12:49 -0700 From: gregl@radiate.asd.sgi.com (Greg Larson) Message-Id: <199707011712.KAA05298@radiate.asd.sgi.com> To: globillum@imag.fr Subject: Siggraph gathering Status: R Dear Siggraph-bound Globillumers: Each year at Siggraph, we try to get together to discuss common issues and share ideas. This year, I'd like to suggest we plan in advance so that we have the best chance of squeezing a meeting into what is always an overcrowded week. I would therefore like to suggest the following time for our get together: Thursday, August 7th, 1-2pm, location TBA We'll probably end up in one of the Birds-of-a-Feather rooms like we did the last two years, and there is always a board near the registration or merchandise pick-up areas where BOF gatherings are posted. This is where we will post the final meeting location and verify the time. If anyone has a compelling reason why this is a poor choice of time (e.g., it conflicts with Microsoft's announcement that they will be purchasing Sony and relocating Japan next to Puget Sound), please let me know. To get the ball rolling, we will have a special guest from the National Institute of Standards and Technology (formerly NBS), Dr. Fern Hunt, who will give an informal overview of a NIST project to standardize reflectance measurements and models for use in computer graphics and paint manufacturing. Of particular interest is a new database called NEF, recently declassified by the CIA, which contains a wealth of data on the reflectance properties (including spectral and directional BRDFs) for common exterior materials. NIST is coordinating the dissemination of this information, with help from a number of people in the industry. For more information on the NIST appearance project, look up: http://math.nist.gov/mcsd/Staff/RLipman/appearance/ Hope to see you there! -Greg _____________________________________________________________________ Gregory Ward Larson (the computer artist formerly known as Greg Ward) Silicon Graphics, Inc. Computer Science Department 2011 N. Shoreline Blvd., M/S 07U-553 537 Soda Hall, UC Berkeley Mountain View, CA 94043-1389 Berkeley, CA 94720-1776 (415) 933-4878, -2663 fax (510) 642-3631, -5775 fax gregl@sgi.com on Tues., Thurs. and Fri. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-globillum-imag@imag.imag.fr Tue Jul 1 14:22:02 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA14663 for ; Tue, 1 Jul 1997 14:21:53 -0700 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA22340 for ; Tue, 1 Jul 1997 14:24:48 -0700 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id OAA21840; Tue, 1 Jul 1997 14:20:15 -0700 Received: from safran.imag.fr (safran.imag.fr [129.88.42.9]) by imag.imag.fr (8.8.1/8.8.5) with ESMTP id JAA29790; Tue, 1 Jul 1997 09:04:05 +0200 (MET DST) Received: (from sillion@localhost) by safran.imag.fr (8.6.10/8.6.9) id JAA25526; Tue, 1 Jul 1997 09:03:43 +0200 From: Francois Sillion Message-Id: <199707010703.JAA25526@safran.imag.fr> Subject: List of participants (*th EG workshop on rendering) To: Paul.Heckbert@HOSTESS.GRAPHICS.CS.CMU.EDU Date: Tue, 1 Jul 1997 09:03:43 +0200 (MDT) Cc: K-myszk@u-aizu.ac.jp, ajw@cs.cmu.edu, alan.chalmers@BRIS.AC.UK, almagro@goliat.ugr.es, blasi@labri.u-bordeaux.fr, bremond@LCPC.FR, chense@LIVEPICTURE.COM, colin@lightwork.co.uk, cyril.soler@imag.fr, danix@cs.huji.ac.il, david.gargan@cs.tcd.ie, david.hedley@bristol.ac.uk, david.zareski@Bentley.Com, dischler@ENSIL.UNILIM.FR, dorsey@graphics.lcs.mit.edu, dumont@LCPC.FR, ebic@JET.ES, elf@DGP.TORONTO.EDU, eric@graphics.cornell.edu, f.w.jansen@TWI.TUDELFT.NL, fournier@cs.ubc.ca, francois.sillion@imag.fr, frank.suykens@cs.kuleuven.ac.be, fredo.durand@imag.fr, george.drettakis@imag.fr, gibsons@cs.man.ac.uk, globillum@imag.fr, gs@gup.uni-linz.ac.at, heidrich@informatik.uni-erlangen.de, henrik@MENTAL.COM, holly@watson.ibm.com, htschirm@IMMD9.INFORMATIK.UNI-ERLANGEN.DE, jolivet@unilim.fr, jordi.regincos@ima.udg.es, kadauber@IMMD9.INFORMATIK.UNI-ERLANGEN.DE, kadi@irisa.fr, keller@informatik.uni-kl.de, lalonde@cs.ubc.ca, mancini@ELEC.ENST.FR, max2@llnl.gov, mbolin@CS.UOREGON.EDU, mcnamara@cs.bris.ac.uk, meinds@NATLAB.RESEARCH.PHILIPS.COM, nick.gray@cs.tcd.ie, paquete@iro.umontreal.ca, per@MENTAL.COM, peroche@emse.fr, ph@cs.cmu.edu, pheng@CSE.CUHK.EDU.HK, philipd@cs.kuleuven.ac.be, philippe.bekaert@cs.kuleuven.ac.be, poulin@iro.umontreal.ca, prikryl@acm.org, roelens@emse.fr, rougeron@emse.fr, rt@acm.org, schaefer@graphics.cs.uni-bonn.de, slusallek@informatik.uni-erlangen.de, stamminger@informatik.uni-erlangen.de, steven.collins@cs.tcd.ie, stuerzl@cs.unc.edu, ttwong@acm.org, uselton@nas.nasa.gov, wilkie@CG.TUWEIN.AC.AT, william.leeson@cs.tcd.ie, xavier@ima.udg.es, y.chrysanthou@CS.UCL.AC.UK, ydw@cs.kuleuven.ac.be, zaninetti@emse.fr, zl@MATHS.BATH.AC.UK In-Reply-To: <199706302122.XAA19065@imag.imag.fr> from "Paul.Heckbert@HOSTESS.GRAPHICS.CS.CMU.EDU" at Jun 30, 97 05:14:58 pm Reply-To: Francois.Sillion@imag.fr X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" Status: R --MimeMultipartBoundary Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit A small correction is in order: while the address given below works as of today, a more correct (and stable) address would be http://www-imagis.imag.fr/~Francois.Sillion/egwkgr.html > The list of participants at the Eurographics Workshop on Rendering in > St Etienne, France that I collected there a few days ago has been turned > into a web page that is being generously maintained by Francois Sillion: > > http://safran.imag.fr/Membres/Francois.Sillion/egwkgr.html > > There you can find links and email addresses of most of the participants, > helping you to locate their papers and pictures. > Check it out! +------------------+------------------------------------------------------+ | Francois SILLION | iMAGIS - GRAVIR/IMAG, B.P. 53, 38041 Grenoble Cedex 9| | ' | France. Tel:+33 4 76 51 43 54 - Fax:+33 4 76 63 55 80| +------------------+----------+-------------------------------------------+ | Francois.Sillion@imag.fr | http://w3imagis.imag.fr/~Francois.Sillion | +-----------------------------+-------------------------------------------+ --MimeMultipartBoundary-- From owner-globillum-imag@imag.imag.fr Mon Jul 7 15:29:01 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA22964 for ; Mon, 7 Jul 1997 15:29:01 -0700 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA05156 for ; Mon, 7 Jul 1997 15:31:57 -0700 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id PAA17789; Mon, 7 Jul 1997 15:27:22 -0700 Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by imag.imag.fr (8.8.1/8.8.5) with SMTP id XAA06985 for ; Mon, 7 Jul 1997 23:44:28 +0200 (MET DST) Received: from odin.corp.sgi.com (odin.corp.sgi.com [192.26.51.194]) by deliverator.sgi.com (950413.SGI.8.6.12/951211.SGI.AUTO) via ESMTP id OAA16528; Mon, 7 Jul 1997 14:43:58 -0700 env-from (gregl@radiate.asd.sgi.com) Received: from giraffe.asd.sgi.com by odin.corp.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id OAA00745; Mon, 7 Jul 1997 14:43:53 -0700 Received: from radiate.asd.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) id OAA24798; Mon, 7 Jul 1997 14:43:29 -0700 Received: by radiate.asd.sgi.com (950413.SGI.8.6.12/940406.SGI.AUTO) id OAA11921; Mon, 7 Jul 1997 14:43:28 -0700 Date: Mon, 7 Jul 1997 14:43:28 -0700 From: gregl@radiate.asd.sgi.com (Greg Larson) Message-Id: <199707072143.OAA11921@radiate.asd.sgi.com> To: globillum@imag.fr Subject: Re: Siggraph gathering Status: R Regarding the earlier proposal to hold the Siggraph '97 Globillum meeting on Thursday at 1pm, Paul Heckbert wrote suggesting that we move up the time so he doesn't have to miss his student's presentation at the 2 o'clock session. Therefore, I'm recommending that those who can convene at: Thursday, August 7th, at 12:30pm, location TBA We'll reserve one of the birds-of-a-feather rooms and mark the time and place on the BOF board that is usually situated near the materials pick-up. Feel free to grab a bite to eat and bring it with you. In years past, we've tried to pick up food for everyone, but usually that's a fiasco, so you're on your own this year. We probably won't get serious until 1 o'clock still, so if you can't make it at 12:30, just come when you can. Hope to see you there! -Greg _____________________________________________________________________ Gregory Ward Larson (the computer artist formerly known as Greg Ward) Silicon Graphics, Inc. Computer Science Department 2011 N. Shoreline Blvd., M/S 07U-553 537 Soda Hall, UC Berkeley Mountain View, CA 94043-1389 Berkeley, CA 94720-1776 (415) 933-4878, -2663 fax (510) 642-3631, -5775 fax gregl@sgi.com on Tues., Thurs. and Fri. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-globillum-imag@imag.imag.fr Tue Jul 8 12:37:38 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA24288 for ; Tue, 8 Jul 1997 12:37:37 -0700 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA09608 for ; Tue, 8 Jul 1997 12:40:33 -0700 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id MAA12207; Tue, 8 Jul 1997 12:35:58 -0700 Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.41]) by imag.imag.fr (8.8.1/8.8.5) with ESMTP id UAA27289 for ; Tue, 8 Jul 1997 20:32:21 +0200 (MET DST) Received: by INET-01-IMC with Internet Mail Service (5.0.1458.49) id <32KF2X21>; Tue, 8 Jul 1997 11:32:19 -0700 Message-ID: <011290D45A8ACF119B8B00805FD471D60349C93C@RED-24-MSG.dns.microsoft.com> From: Andrew Glassner To: "'globillum@imag.fr'" Subject: New errata for PoDIS Date: Tue, 8 Jul 1997 11:32:14 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Status: R I've just updated the errata for Principles of Digital Image Synthesis. You can find the complete list at: http://www.research.microsoft.com/research/graphics/glassner/work/projec ts/pdis/errata.htm --- Andrew Glassner | glassner@microsoft.com | +1(206)703-0120 http://www.research.microsoft.com/research/graphics/glassner/ From owner-globillum-imag@imag.imag.fr Wed Jul 9 21:52:30 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA26396 for ; Wed, 9 Jul 1997 21:52:26 -0700 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA15983 for ; Wed, 9 Jul 1997 21:55:20 -0700 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id VAA22219; Wed, 9 Jul 1997 21:50:45 -0700 Received: from mercury.uniserve.com (mercury.uniserve.com [204.191.197.248]) by imag.imag.fr (8.8.1/8.8.5) with ESMTP id GAA28711 for ; Thu, 10 Jul 1997 06:27:33 +0200 (MET DST) Received: from helios (van0404.tvs.net [204.191.197.104]) by mercury.uniserve.com with ESMTP id VAA07361 for ; Wed, 9 Jul 1997 21:27:22 -0700 (PDT) Message-Id: <199707100427.VAA07361@mercury.uniserve.com> Reply-To: From: "Ian Ashdown" To: Subject: Interesting radiosity papers Date: Wed, 9 Jul 1997 21:28:17 -0700 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" Status: R --MimeMultipartBoundary Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Papers on global illumination are beginning to appear in some decidedly non-traditional journals. The following two papers (one accepted for publication, the other submitted) may be of interest to some of you: Atkinson, K., and D. Chen. 1997. "A Fast Matrix-Vector Multiplication Method for Solving the Radiosity Equation." Submitted for publication. Atkinson, K., and G. Chandler. 1997. "The Collocation Method for Solving the Radiosity Equation for Unoccluded Surfaces." To appear in Journal of Integral Equations & Applications." Both papers are available in Postscript format from Kendall Atkinson's home page at: http://www.math.uiowa.edu/~atkinson/papers.html For those of you who have thoroughly researched the literature, you may recognize Dr. Kendall as the author of the 1976 book, "A Survey of Numerical Methods for the Solution of Fredholm Intergral Equations of the Second Kind." The above two papers are no less rigorous in their treatment of the subject. - Ian Ashdown --MimeMultipartBoundary-- From owner-globillum-imag@imag.imag.fr Sat Jul 12 15:31:49 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA00052 for ; Sat, 12 Jul 1997 15:31:48 -0700 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA00550 for ; Sat, 12 Jul 1997 15:34:42 -0700 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id PAA12266; Sat, 12 Jul 1997 15:29:57 -0700 Received: from mercury.uniserve.com (mercury.uniserve.com [204.191.197.248]) by imag.imag.fr (8.8.1/8.8.5) with ESMTP id XAA20704 for ; Sat, 12 Jul 1997 23:49:26 +0200 (MET DST) Received: from helios (dy1-41.van.tvs.net [204.244.156.50]) by mercury.uniserve.com with ESMTP id OAA19687 for ; Sat, 12 Jul 1997 14:49:20 -0700 (PDT) Message-Id: <199707122149.OAA19687@mercury.uniserve.com> Reply-To: From: "Ian Ashdown" To: Subject: Global illumination bibliography update Date: Sat, 12 Jul 1997 14:50:12 -0700 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" Status: R --MimeMultipartBoundary Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit ANNOUNCE: 97/07/15 Release of RADBIB97.BIB ------------------------------------------ RADBIB97 is a comprehensive bibliography of radiosity and related global illumination papers, theses, articles, and books. It currently includes 1,164 references. This bibliography is available in BibTex format as RADBIB97.BIB (with a release date of July 15, 1997) from: http://www.ledalite.com/library-/rrt.htm ftp://ftp.ledalite.com/pub/radbib97.bib As always, it is time-consuming and sometimes difficult to track down conference papers and theses on radiosity and global illumination. If you know of a relevant reference that is not included in the bibliography, please let me know so that I can include it in the next release. Ian Ashdown, P. Eng. | READ THE BOOK! | Research & Development Manager | Radiosity: A Programmer's Perspective | Ledalite Architectural Products | Wiley & Sons 1994 | Visit http://www.ledalite.com | (Sneaky Internet Advertising) | --MimeMultipartBoundary-- From owner-globillum-imag@imag.imag.fr Wed Jul 16 02:47:24 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id CAA04602 for ; Wed, 16 Jul 1997 02:47:24 -0700 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id CAA13015 for ; Wed, 16 Jul 1997 02:50:17 -0700 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id CAA17616; Wed, 16 Jul 1997 02:45:39 -0700 Received: from ux3.sp.cs.cmu.edu (UX3.SP.CS.CMU.EDU [128.2.198.103]) by imag.imag.fr (8.8.1/8.8.5) with SMTP id IAA00561 for ; Wed, 16 Jul 1997 08:47:26 +0200 (MET DST) Received: from GS190.SP.CS.CMU.EDU by ux3.sp.cs.cmu.edu id aa25424; 16 Jul 97 2:46 EDT X-Sender: ajw@ux1.sp.cs.cmu.edu Message-Id: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" Date: Wed, 16 Jul 1997 02:46:32 -0400 To: globillum@imag.fr From: "Andrew J. Willmott" Subject: More radiosity software... Status: R --MimeMultipartBoundary Content-Type: text/plain; charset="us-ascii" Just a reminder that the radiosity software and experimental system used in our comparison of radiosity methods is available from http://www.cs.cmu.edu/~radiosity/dist. (The comparison was presented at the recent Eurographics Workshop on Rendering.) The software supports matrix, progressive, and wavelet radiosity (bases: M2/M3/F2/F3), T-vertex elimination, and more. The code is set up to compile under Irix, but it should be easily portable to anything with a C++ compiler and an OpenGL library. Cheers, Andrew --- mailto:a.willmott@cs.cmu.edu ------- http://www.cs.cmu.edu/~ajw --- --MimeMultipartBoundary-- From owner-globillum-imag@imag.imag.fr Tue Jul 22 11:55:59 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA07838 for ; Tue, 22 Jul 1997 11:55:58 -0700 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA06607 for ; Tue, 22 Jul 1997 11:58:50 -0700 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id LAA22872; Tue, 22 Jul 1997 11:54:08 -0700 Received: from m1.cs.man.ac.uk (0@m1.cs.man.ac.uk [130.88.13.4]) by imag.imag.fr (8.8.1/8.8.5) with SMTP id PAA06657 for ; Tue, 22 Jul 1997 15:25:17 +0200 (MET DST) Received: from rdf010.cs.man.ac.uk by m1.cs.man.ac.uk (4.1/SMI-4.1:AL6) id AA28172; Tue, 22 Jul 97 14:25:16 BST Date: Tue, 22 Jul 97 14:25:14 BST From: Simon Gibson Message-Id: <9707221325.AA08828@rdf010.cs.man.ac.uk> To: globillum@imag.fr Subject: notations and terminology document Status: R Hello all, I am trying to track down the .ps or .tex file on notations and terminology used for global illumination research that is linked from the Eurographics working group on rendering home page. The ftp link to tiber.nist.gov/pub/holly/symb.tex is dead. Does anybody know if the documents are available from anywhere else? Thanks Simon From owner-globillum-imag@imag.imag.fr Tue Jul 22 13:47:08 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA07959 for ; Tue, 22 Jul 1997 13:47:07 -0700 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA07030 for ; Tue, 22 Jul 1997 13:49:59 -0700 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id NAA28598; Tue, 22 Jul 1997 13:45:15 -0700 Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [198.81.209.6]) by imag.imag.fr (8.8.1/8.8.5) with ESMTP id VAA18996 for ; Tue, 22 Jul 1997 21:25:22 +0200 (MET DST) Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.8.5/07-11-97) with ESMTP id PAA04906; Tue, 22 Jul 1997 15:24:16 -0400 Received: from watngi01.watson.ibm.com (watngi01.watson.ibm.com [9.2.235.20]) by mailhub1.watson.ibm.com (8.8.2/07-14-97) with SMTP id PAA39819; Tue, 22 Jul 1997 15:25:19 -0400 Received: by watngi01.watson.ibm.com(Lotus SMTP MTA v1.06 (346.4 3-18-1997)) id 852564DC.006AADA5 ; Tue, 22 Jul 1997 15:25:12 -0400 X-Lotus-FromDomain: IBM RESEARCH From: "Holly Rushmeier" To: gibsons@cs.man.ac.uk cc: globillum@imag.fr Message-ID: <852564DC.00697E94.00@watngi01.watson.ibm.com> Date: Tue, 22 Jul 1997 15:23:49 -0400 Subject: Re: notations and terminology document Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" Status: R --MimeMultipartBoundary Content-type: text/plain; charset=us-ascii Hi -- The files on tiber.nist.gov/pub/holly left NIST when I did. I still have the files, but I can't make them available via ftp because of the fire wall here. I'm emailing symb.tex to Simon. If anyone has a site where they can keep the documents I will be happy to email them to you, and the Eurographics links can be updated. -- Holly From: gibsons @ cs.man.ac.uk Date: 07/22/97 02:25:14 PM CET Subject: notations and terminology document Hello all, I am trying to track down the .ps or .tex file on notations and terminology used for global illumination research that is linked from the Eurographics working group on rendering home page. The ftp link to tiber.nist.gov/pub/holly/symb.tex is dead. Does anybody know if the documents are available from anywhere else? Thanks Simon --MimeMultipartBoundary-- From owner-globillum-imag@imag.imag.fr Tue Jul 22 15:12:06 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA08068 for ; Tue, 22 Jul 1997 15:12:05 -0700 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA07778 for ; Tue, 22 Jul 1997 15:14:57 -0700 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id PAA04332; Tue, 22 Jul 1997 15:10:15 -0700 Received: from safran.imag.fr (safran.imag.fr [129.88.42.9]) by imag.imag.fr (8.8.1/8.8.5) with ESMTP id XAA22021; Tue, 22 Jul 1997 23:20:47 +0200 (MET DST) Received: (from sillion@localhost) by safran.imag.fr (8.6.10/8.6.9) id XAA14356; Tue, 22 Jul 1997 23:20:46 +0200 From: Francois Sillion Message-Id: <199707222120.XAA14356@safran.imag.fr> Subject: Re: notations and terminology document To: holly@watson.ibm.com (Holly Rushmeier) Date: Tue, 22 Jul 1997 23:20:46 +0200 (MDT) Cc: gibsons@cs.man.ac.uk, globillum@imag.fr In-Reply-To: <852564DC.00697E94.00@watngi01.watson.ibm.com> from "Holly Rushmeier" at Jul 22, 97 03:23:49 pm Reply-To: Francois.Sillion@imag.fr X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" Status: R --MimeMultipartBoundary Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sorry about this, I do have the files and putting them on our ftp server is on my todo list... I will do that tomorrow! > > Hi -- > The files on tiber.nist.gov/pub/holly left NIST when I did. > I still have the files, but I can't make them available via ftp because > of the fire wall here. I'm emailing symb.tex to Simon. If anyone has > a site where they can keep the documents I will be happy to email > them to you, and the Eurographics links can be updated. > > -- Holly > > +------------------+------------------------------------------------------+ | Francois SILLION | iMAGIS - GRAVIR/IMAG, B.P. 53, 38041 Grenoble Cedex 9| | ' | France. Tel:+33 4 76 51 43 54 - Fax:+33 4 76 63 55 80| +------------------+----------+-------------------------------------------+ | Francois.Sillion@imag.fr | http://w3imagis.imag.fr/~Francois.Sillion | +-----------------------------+-------------------------------------------+ --MimeMultipartBoundary-- From owner-globillum-imag@imag.imag.fr Fri Jul 25 03:55:12 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id DAA11484 for ; Fri, 25 Jul 1997 03:55:12 -0700 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id DAA20872 for ; Fri, 25 Jul 1997 03:58:01 -0700 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id DAA04579; Fri, 25 Jul 1997 03:53:15 -0700 Received: from safran.imag.fr (safran.imag.fr [129.88.42.9]) by imag.imag.fr (8.8.1/8.8.5) with ESMTP id KAA02024 for ; Fri, 25 Jul 1997 10:49:19 +0200 (MET DST) Received: (from sillion@localhost) by safran.imag.fr (8.6.10/8.6.9) id KAA10215 for globillum@imag.fr; Fri, 25 Jul 1997 10:49:18 +0200 From: Francois Sillion Message-Id: <199707250849.KAA10215@safran.imag.fr> Subject: Think about it... To: globillum@imag.fr (Global Illumination List) Date: Fri, 25 Jul 1997 10:49:18 +0200 (MDT) Reply-To: Francois.Sillion@imag.fr X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" Status: R --MimeMultipartBoundary Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi globillumers, We are still looking for post-docs, in the next three years. I will be at SIGGRAPH and could talk to interested people. So if you are finishing a PhD soon, or if you want some change in your life, and if you like the beautiful mountains of the french alps, think about it... > POSTDOCTORAL/RESEARCH ASSOCIATE POSITIONS > AVAILABLE FOR PROJECTS ON LIGHTING SIMULATION > at iMAGIS, Grenoble, FRANCE > > The iMAGIS research group is part of the French national research > organisations CNRS and INRIA, and of Grenoble Universities UJF and > INPG. iMAGIS researchers have had a strong presence in the > international computer graphics community, regularly publishing at the > SIGGRAPH and Eurographics conferences and workshops, as well as in the > major scientific journals of the domain. > (for more information see http://www-imagis.imag.fr) > > The iMAGIS research group will be participating in two European Union > funded Long Term Research (LTR) projects. These projects are related > to radiosity and lighting algorithms, with special focus on making > radiosity usable (data acquisition, complex scenes, automatic > simulation control and interactive updates) and on developing practical > algorithms for extended lighting effects (glossy reflection, > participating media). > > We are searching for two motivated young researchers for a postdoctoral > or research associate position. Candidates should hold a Ph.D. or > M.Sc. (or equivalents depending on country of origin), specialised in > the domain of lighting simulation (radiosity, stochastic methods > etc.). Candidates with equivalent experience in the development of > lighting simulation software will also be considered. Good spoken and > written English skills are a necessity. > > The duration of this employment will be 2-3 years; the starting date is > autumn 1997. The second position could have a later starting date > (summer 1998 latest). The timing details are still somewhat flexible > at this stage. > > The persons appointed will be primarily responsible for the production > of the LTR deliverables (software, demos, reports and scientific > publications), and participating in meetings with partners (in Spain, > Germany and the UK). This work will be performed in the context of the > research software development effort of iMAGIS, and thus will include > an important research-oriented component. The work will be performed > in close collaboration with the principal investigators of these > projects, Francois Sillion, George Drettakis and Claude Puech. > > For holders of Ph.D.'s part of their time will be available for > personal research in the context of the iMAGIS research group. The > distribution of time and responsibilities is negociable and will be > adapted individually. > > Salary will be commensurate with experience; for a postdoctoral > position they will be in the standard range of French research > organisations postdoc salaries. > > Candidates interested in these positions should contact either Francois > Sillion (Francois.Sillion@imag.fr) or George Drettakis > (George.Drettakis@imag.fr). We are also reacheable by > FAX at +33 4 76 63 55 80. > > It will be possible to meet with promising applicants at the SIGGRAPH > and Eurographics conferences. Potential candidates are thus encouraged > to express interest as soon as possible. > +------------------+------------------------------------------------------+ | Francois SILLION | iMAGIS - GRAVIR/IMAG, B.P. 53, 38041 Grenoble Cedex 9| | ' | France. Tel:+33 4 76 51 43 54 - Fax:+33 4 76 63 55 80| +------------------+--------+---------------------------------------------+ | Francois.Sillion@imag.fr | http://www-imagis.imag.fr/~Francois.Sillion | +---------------------------+---------------------------------------------+ --MimeMultipartBoundary-- From gregl@radiate.engr.sgi.com Mon Aug 11 11:54:39 1997 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA08760 for ; Mon, 11 Aug 1997 11:54:37 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id LAA06259; Mon, 11 Aug 1997 11:52:44 -0700 env-from (gregl@radiate.engr.sgi.com) Received: from radiate.engr.sgi.com (radiate.engr.sgi.com [192.26.72.11]) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id LAA23445; Mon, 11 Aug 1997 11:52:43 -0700 Received: (from gregl@localhost) by radiate.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA27541; Mon, 11 Aug 1997 11:52:42 -0700 Date: Mon, 11 Aug 1997 11:52:42 -0700 From: gregl@radiate.engr.sgi.com (Greg Larson) Message-Id: <199708111852.LAA27541@radiate.engr.sgi.com> To: globillum@imag.fr Subject: Siggraph Globillum Meeting Cc: drb@sgi.com Status: R Well, since no one volunteered to take notes at the Globillum meeting on Thursday at Siggraph, you're stuck with my ratty minutes again this year. There was some confusion on the time for the meeting -- some thought it was to start at 12:30, and some thought 1:00. Since the judges of the all-important Siggraph T-shirt contest had the room until 1:00, the few of us who showed up at 12:30 went around and (re)introduced ourselves outside while we waited for the room and for the others to arrive. By the time 1pm rolled around, there were quite a few of us who had been introduced, and folks were still trickling into the room, so I apologize that not everyone got a proper chance to hear the early birds' names. We had quite a turnout this year, and I attempted to get everyone's names down, but I'm sure I missed a few (and misspelled a few more). Nevertheless, I've included this list of names at the bottom, in case you find a friend there who can tell you about the meeting first-hand. After the aforementioned haphazard introductions, Fern Hunt of the National Institute of Standards and Technology gave a scheduled presentation of the work she is doing on BRDF measurement and characterization with Mary McKnight and others at NIST, in cooperation with industry. Dr. Hunt is one of a few mathematicians at NIST who are attempting to predict BRDFs (bidirectional reflection distribution functions) from paint compositions and application techniques. Specifically, they are asking the question, "If you have some material, and you know its physical characteristics and topography, what else do you need to know to recreate its appearance; what accuracy levels are needed?" NIST of course has some of the most (if not THE most) sophisticated equipment for measuring surface reflectance and topography, and they are very interested in working with industry and research institutions to make this information more useful and available. Bob Lipman (also of NIST) then talked about a newly available database of BRDFs for various common materials, collected by the CIA for use in analyzing satellite images. Recently declassified (and simultaneously defunded), the NEF database (obviously stands for "Nonconventional Exploitation Factors") contains hundreds(?) of exterior finishes and natural materials, characterized by full spectral reflectance models and measurements. It was meticulously created by the National Imaging and Mapping Agency, and represents a huge effort. I strongly recommend to anyone interested in material reflectance data that they go check it out. For more information, see the following web sites: http://math.nist.gov/mcsd/Staff/RLipman/appearance/ http://math.nist.gov/mcsd/Staff/RLipman/brdf/nefhome.html The interface to the database currently runs only under Solaris, and Bob is looking to create a simpler interface to access the data under other systems, as well as seeing if the current interface can be ported. (His initial attempts to do so failed for unknown reasons.) Fern Hunt can be reached at , (301) 975-3887. Bob Lipman is at , (301) 975-3829. Fern also reminded the group that they are still looking for someone for a post-doc position in realistic image synthesis funded by the National Research Council, for which they are taking applications until Jan. 15, 1998. They promised to have an announcement soon at the following URL: http://rap.nas.edu/lab/NIST/ (Bear in mind that there is a U.S. citizenship requirement for this position.) Next, I brought up a subject that has been popular at past globillum meetings, which is lighting and level of realism in the entertainment (i.e., film animation) industry. Specifically, I was wondering why global illumination is not more widely used for producing digital effects, which to my eye still look pretty fake due to poor lighting and color. Larry Gritz (of Pixar) had quite a bit to say on this topic, since he has spent some time on both sides of the fence. As the author of the Blue Moon Rendering Tools, Larry knows that global illumination techniques can be quite effective at improving the realism of rendered environments, even within the Renderman specification. However, he has seen expert "lighters," as they're called, do a much better job producing convincing effects for movies like "Toy Story" without any kind of global calculations going on. In fact, Larry said that global effects can often be exactly what you DON'T want when lighting a scene, since the addition of a light in one corner can screw up the lighting you just tweaked to perfection in the other corner. Alain Fournier of the University of British Columbia and Mayur Patel of Disney Engineering also participated in the conversation (among others), and in the end there seemed to be some agreement that there is a lot of room for improvement in existing animation systems. Specifically, there must be some way to ease the burden lighting places on scene design with better global illumination that still does not diminish creative control. Anything they can do to keep the computer graphics from jumping off the screen and saying "Hey, I was done with computer graphics!" would be great by me. Finally, Paul Heckbert (of Carnegie Mellon University) brought up the issue of code sharing, and suggested that we post announcements to the group if we have some code or results we want to share via the internet. No one seemed to object to this, given how light traffic on globillum usually is. Anyway, to get the ball rolling, here are a few links that people volunteered: Wavelet Radiosity Testbed (Andrew Wilmott): http://www.cs.cmu.edu/~radiosity/dist/ Interactive BRDF editor (Paul Heckbert and students): http://www.cs.cmu.edu/~ph/src/illum/ BRDF comparison (Szymon Rusinkiewicz): http://www-graphics.stanford.edu/~smr/cs348c/paper.html Blue Moon Rendering Tools (Larry Gritz): http://www.seas.gwu.edu/student/gritz/bmrt.html Instant Radiosity (Alex Keller -- see Siggraph '97 paper): http://www.uni-kl.de/AG-Heinrich/Alex.html (Actually, I couldn't find the link, but Alex said he had one.) Validation studies (Karol Myszkowski): http://www.u-aizu.ac.jp/~k-myszk/valid Radiance (how could I miss the opportunity for a plug?): http://radsite.lbl.gov/radiance/HOME.html Materials and Geometry Format (ditto): http://radsite.lbl.gov/mgf/HOME.html Also, I plan to announce a high dynamic-range format within TIFF for images using a logL (u',v') color system in 32-bits/pixel, which is even better than the one used in Radiance since it is not gamut-limited. This will be released as part of Sam Leffler's TIFF library. I hope to have it ready (with an X11 viewer) by the end of this month. And now, the list of attendees in alfabetickal order: Ashdown, Ian (ByHeart Software) Bala, Kavita (MIT) Baranoski, Gladimir Christensen, Per (Mental Ray) Fajardo, Marco Foo, Sing (Blue Sky Studios) Fournier, Alain (Univ. of British Columbia) Gatenby, Niel (LightWorks) Gritz, Larry (Pixar) Haines, Eric (Autodesk) Hanrahan, Pat (Stanford Univ.) Heckbert, Paul (Carnegie Mellon Univ.) Heidrich, Wolfgang (University of Erlangen) Herf, Michael (Carnegie Mellon Univ.) Hunt, Fern (NIST) Keller, Alex (Universitat Kaiserslautern) Kolb, Craig (Stanford) LaFortune, Eric (Cornell Univ.) Larson, Greg (SGI) Lipman, Bob (NIST) Marshner, Steve Max, Nelson (LLL and UC Davis) Meyer, Gary (Univ. of Oregon) Myszkowski, Karol (Univ. of Aizu) Patel, Mayur (Disney Engineering) Patow, Glastvo Pattanaik, Sumant (Cornell Univ.) Phar, Matt (Stanford Univ.) Ruff, Barry (RIT?) Rushmeier, Holly (IBM T.J. Watson Research) Rushwold, Andrew Rusinkiewicz, Szymon (Stanford Univ.) Shirley, Pete (Univ. of Utah) Sillion, Francois (IMAGIS, University of Grenoble) Slusallek, Phillipp (University of Erlangen) Stuerzling, Wolfgang (Austria) Tamstorf, Rasmus Uselton, Sam (NASA) Van Wensen, Henrik (Mental Ray) Van Wyk, Skip (Univ. of New Mexico) Veach, Eric (Stanford Univ.) Wade, Bretton (SGI) Waltner, Bruce (Cornell Univ.) Westin, Steve (Cornell University) Wilmott, Andrew (Carnegie Mellon Univ.) Worley, Steve Zimmerman, Kurt (Indiana Univ.) Forgive me if I munged your name or forgot your affiliation, or missed you altogether! Take it as an excuse to send mail to globillum with a correction and a little information on your interests and background.... All the best, -Greg _____________________________________________________________________ Gregory Ward Larson (the computer artist formerly known as Greg Ward) Silicon Graphics, Inc. Computer Science Department 2011 N. Shoreline Blvd., M/S 07U-553 537 Soda Hall, UC Berkeley Mountain View, CA 94043-1389 Berkeley, CA 94720-1776 (415) 933-4878, -2663 fax (510) 642-3631, -5775 fax gregl@sgi.com on Tues., Thurs. and Fri. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-globillum-imag@imag.imag.fr Tue Aug 12 11:56:17 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA12360 for ; Tue, 12 Aug 1997 11:56:17 -0700 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA22556 for ; Tue, 12 Aug 1997 11:59:07 -0700 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id LAA02872; Tue, 12 Aug 1997 11:54:16 -0700 Received: from bcgn.grignon.inra.fr (bcgn.grignon.inra.fr [192.93.95.1]) by imag.imag.fr (8.8.1/8.8.5) with ESMTP id MAA29436 for ; Tue, 12 Aug 1997 12:09:22 +0200 (MET DST) Received: from ultra2 (ultra2 [192.93.95.4]) by bcgn.grignon.inra.fr (8.8.4/8.8.4) with SMTP id MAA03214 for ; Tue, 12 Aug 1997 12:09:15 +0200 (MET DST) Sender: chelle@bcgn.grignon.inra.fr Message-ID: <33F035D0.76BD@bcgn.grignon.inra.fr> Date: Tue, 12 Aug 1997 11:07:12 +0100 From: Michael Chelle X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: globillum@imag.fr Subject: Distance point-triangle Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" Status: R --MimeMultipartBoundary Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Is there a formula or an efficient algorithm to compute the distance between a point and a triangle (ie the minimum distance)? Thanks in advance Michael -- Michael CHELLE INRA | email : chelle@bcgn.grignon.inra.fr Station de Bioclimatologie | phone : +33 1 30 81 55 31 78850 THIVERVAL-GRIGNON (France) | fax : +33 1 30 81 55 63 --MimeMultipartBoundary-- From alz@raycast.com Tue Aug 12 16:04:26 1997 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA12877 for ; Tue, 12 Aug 1997 16:04:26 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id QAA14462 for <@sgi.engr.sgi.com:greg@pink.lbl.gov>; Tue, 12 Aug 1997 16:02:43 -0700 env-from (alz@raycast.com) Received: from radiate.engr.sgi.com (radiate.engr.sgi.com [192.26.72.11]) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id QAA06239 for <@cthulhu.engr.sgi.com:greg@pink.lbl.gov>; Tue, 12 Aug 1997 16:02:41 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by radiate.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id QAA29828 for ; Tue, 12 Aug 1997 16:02:40 -0700 Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id QAA06227 for ; Tue, 12 Aug 1997 16:02:39 -0700 Received: from lanshark.lanminds.com (lanshark.lanminds.com [140.174.208.11]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id QAA14426 for ; Tue, 12 Aug 1997 16:02:38 -0700 env-from (alz@raycast.com) Received: from raycast.com (hat-ppp8.lanminds.com [208.1.127.118]) by lanshark.lanminds.com (8.8.6/8.8.5) with SMTP id QAA29980 for ; Tue, 12 Aug 1997 16:02:35 -0700 (PDT) Received: from zmachine (localhost) by raycast.com (4.1/SMI-4.1) id AA00252; Sun, 22 Dec 91 10:12:12 PST Sender: adz@raycast.com Message-Id: <2954D57B.41C67EA6@raycast.com> Date: Sun, 22 Dec 1991 10:12:11 -0800 From: Al Zimmerman X-Mailer: Mozilla 3.01 (X11; I; SunOS 4.1.3_U1 sun4c) Mime-Version: 1.0 To: Greg Larson Subject: Re: Siggraph Globillum Meeting References: <199708111852.LAA27541@radiate.engr.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO Hi Greg, I'm sure you are asked this alot but....... Please explain the name change. Al Z From greg Tue Aug 12 16:18:34 1997 Received: (from greg@localhost) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) id QAA12934; Tue, 12 Aug 1997 16:18:34 -0700 Date: Tue, 12 Aug 1997 16:18:34 -0700 From: greg (Gregory W. Larson) Message-Id: <199708122318.QAA12934@pink.lbl.gov> To: Al Zimmerman Subject: Re: Siggraph Globillum Meeting References: <199708111852.LAA27541@radiate.engr.sgi.com> Status: R I changed my name when I got married in '85, but didn't bother changing it at work. I took the opportunity when switching jobs to switch names, which has caused some confusion. I guess it just isn't done.... -G From owner-globillum-imag@imag.imag.fr Wed Aug 13 05:55:11 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA13482 for ; Wed, 13 Aug 1997 05:55:11 -0700 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id FAA02133 for ; Wed, 13 Aug 1997 05:58:00 -0700 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id FAA05250; Wed, 13 Aug 1997 05:53:07 -0700 Received: from mtigwc03.worldnet.att.net (mtigwc03.worldnet.att.net [204.127.131.34]) by imag.imag.fr (8.8.1/8.8.5) with ESMTP id NAA10820 for ; Wed, 13 Aug 1997 13:43:08 +0200 (MET DST) Received: from espresso ([207.147.208.138]) by mtigwc03.worldnet.att.net (post.office MTA v2.0 0613 ) with SMTP id AAA8025; Wed, 13 Aug 1997 11:42:06 +0000 Received: by localhost with Microsoft MAPI; Wed, 13 Aug 1997 16:40:29 -0700 Message-ID: <01BCA807.9BCD6D20@mherf@worldnet.att.net> From: Michael Herf Reply-To: "herf@cmu.edu" To: "'Alexander Keller AG Heinrich'" , "'globillum@imag.fr'" Subject: RE: SIGGRAPH GlobIllum Meeting Date: Wed, 13 Aug 1997 16:39:54 -0700 X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4008 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" Status: R --MimeMultipartBoundary Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Alex. I was at your demo directly after the papers session at SIGGRAPH. My first question: Is the reason that an O2 is required the stencil planes or the accumulation buffer speed? With regards to the accumulation buffer, I just wrote a special-case version at work that runs on PCs. The accumulation buffer in OpenGL handles arbitrary combinations of images, and each time glAccum is called it converts the pixels to floating-point format and then does a multiply per pixel to add them -- not too efficient! (Some implementations may optimize this in integer, but the multiply remains.) If you instead assume that you just want to "average" a number of images equally -- the most common case for the accumulation buffer -- you can implement the same thing in software (using glReadPixels to read into a local buffer) with very good performance. My implementation is doing better than 30 accumulation buffer operations per second (a special case of glAccum) at 640x480 in 24-bit RGB, which is more than enough for decent results with your algorithm. The basic idea is to restrict yourself to one or two adds per pixel, and then make the return step do an optimized scale to average the output. (This requires a 16-16-16 bit intermediate image. All this work doesn't buy you anything on a RealityEngine, but it might be cool to see a port to lower-end machines. I think that performance wouldn't hinder you, since $400 cards on the PC can double the O2's polygon performance in many cases. thanks, mike On Wednesday, August 13, 1997 1:02 AM, Alexander Keller AG Heinrich [SMTP:keller@informatik.uni-kl.de] wrote: > Hi! > > Since I returned from SIGGRAPH yesterday, I was not able to > supply the link to my CAL-content on Instant Radiosity > earlier. On my page on reports and software you can download > the CAL-content as presented on SIGGRAPH 97. The software > will run on any system larger or equal to an SGI O2. Note > that the speed of the demo software could be improved even > more if shadow maps, display lists, etc. were applied. > The file cal.tar.gz is installed by creating a directory > and un-tar-ing the file in that directory. Then netscape > is started, where a bried explanation of the algorithm > and how to run it is supplied. > > The link to the software page is > > http://www.uni-kl.de/AG-Heinrich/Software.html > > > Have fun testing Instant Radiosity... > > Best regards, > Alex > -- > Alexander Keller | > FB Informatik, Geb. 36/212 | Tel.: +49-631-205-3345 > Universitaet Kaiserslautern | Fax.: +49-631-205-3270 > Postfach 3049 | keller@informatik.uni-kl.de > D-67653 Kaiserslautern, GERMANY | http://www.uni-kl.de/AG-Heinrich/Alex.html --MimeMultipartBoundary-- From owner-globillum-imag@imag.imag.fr Tue Aug 19 12:16:42 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA24941 for ; Tue, 19 Aug 1997 12:16:41 -0700 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA24510 for ; Tue, 19 Aug 1997 12:19:28 -0700 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id MAA06526; Tue, 19 Aug 1997 12:14:32 -0700 Received: from austin.cs.unc.edu (austin.cs.unc.edu [152.2.128.87]) by imag.imag.fr (8.8.1/8.8.5) with SMTP id UAA05949 for ; Tue, 19 Aug 1997 20:42:08 +0200 (MET DST) Received: from catfish.cs.unc.edu by austin.cs.unc.edu (8.6.10/UNC_10_05_96) id OAA25751; Tue, 19 Aug 1997 14:42:06 -0400 Received: from localhost (localhost [127.0.0.1]) by catfish.cs.unc.edu (8.8.6/8.8.6) with SMTP id OAA17005 for ; Tue, 19 Aug 1997 14:42:05 -0400 (EDT) Date: Tue, 19 Aug 1997 14:42:03 -0400 (EDT) From: Wolfgang Stuerzlinger To: globillum@imag.fr Subject: Software announcement (+small correction) Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" Status: R --MimeMultipartBoundary Content-Type: TEXT/PLAIN; charset=US-ASCII My (correct) name is Wolfgang Stuerzlinger and I am currently a visiting post-graduate researcher at UNC Chapel Hill (originally from Univ. Linz, Austria, so Greg's entry is almost correct :-). My WWW-page is at: http://www.cs.unc.edu/~stuerzl. Parts of my globillum code (e.g. hemispherical projection, discontinuity meshing) and almost all my publications are available there. Wolfgang P.S.: My current entry on reseach interests in globillum reads: In the area of globillum I am doing research on hardware accelerated methods for displaying results of diffuse+glossy+mirror globillum simulations. Also I am interested in hardware accelerated methods for solving the rendering equation. -- Wolfgang Stuerzlinger Dept. of Computer Science, UNC, Chapel Hill, NC 27599-3175 stuerzl@cs.unc.edu http://www.cs.unc.edu/~stuerzl --MimeMultipartBoundary-- From tralvex@computer.org Thu Aug 28 04:22:17 1997 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id EAA05170 for ; Thu, 28 Aug 1997 04:22:06 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id EAA13785 for <@sgi.engr.sgi.com:greg@pink.lbl.gov>; Thu, 28 Aug 1997 04:20:07 -0700 env-from (tralvex@computer.org) Received: from radiate.engr.sgi.com (radiate.engr.sgi.com [192.26.72.11]) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id EAA05245 for <@cthulhu.engr.sgi.com:greg@pink.lbl.gov>; Thu, 28 Aug 1997 04:20:00 -0700 Received: from giraffe.asd.sgi.com (giraffe.asd.sgi.com [192.26.72.158]) by radiate.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id EAA15911 for ; Thu, 28 Aug 1997 04:19:50 -0700 Received: from sgi.sgi.com by giraffe.asd.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/951211.SGI) for id EAA23105; Thu, 28 Aug 1997 04:19:45 -0700 Received: from csunb0.leeds.ac.uk (csunb0.leeds.ac.uk [129.11.144.2]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id EAA13739 for ; Thu, 28 Aug 1997 04:19:43 -0700 env-from (tralvex@computer.org) Received: from cspcx20 (cspcx20.leeds.ac.uk [129.11.147.20]) by csunb0.leeds.ac.uk (8.6.12/8.6.12) with SMTP id MAA11559; Thu, 28 Aug 1997 12:00:10 +0100 Message-Id: <2.2.32.19970828095907.0060e4dc@csirisa> X-Sender: mscytsy@csirisa X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 28 Aug 1997 10:59:07 +0100 To: iashdown@ledalite.com, renambot@irisa.fr, fiction@pressroom.com, alz@lanminds.com, ali@eel.ufl.edu, pawel@assari.cc.tut.fi, vlad@hops.cs.jhu.edu, accmdq@mail.telepac.pt, gregl@sgi.com, abraham@sp.ac.sg, neil@lightwork.co.uk, ttwong@unixg.ubc.ca, Wim.Dumon@cs.kuleuven.ac.be, mart@dcre.leeds.ac.uk, rcl@scs.leeds.ac.uk, wbt@graphics.cornell.edu, bes@phoenix.cs.utah.edu, dpg@graphics.cornell.edu, eric@graphics.cornell.edu, pmh@monk.cs.wustl.edu, gibsons@cs.man.ac.uk From: "Tralvex Yeap (T.Rex)" Subject: Radiosity for Virtual Reality Systems and Huge links Status: R Hi guys, I have finish my MSc thesis and have setup a permanant website for that over at University of Leeds - http://dream.leeds.ac.uk/cuddles/rover The site contains the thesis itself, images, hyperlink abstracts and biblio., huge collection of links on radiosity papers on the Web, free radiosity software on the web, and many others. Thanks for everything and I hope you'll find the resources compiled there useful for your work. Best Regards, - t - tralvex@computer.org * http://www.singnet.com.sg/~tyeap "Give to the world the best you have and the best will come back to you" From merlin@uni-paderborn.de Fri Aug 29 00:50:32 1997 Received: from pbinfo (uni-paderborn.de [131.234.22.30]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA06130 for ; Fri, 29 Aug 1997 00:50:31 -0700 Received: from IDENT-NONSENSE@ijssel (port 32970 [131.234.16.11]) by pbinfo.uni-paderborn.de with ESMTP id <52313-15046>; Fri, 29 Aug 1997 09:48:24 +0200 Received: from ijssel (localhost [127.0.0.1]) by ijssel.uni-paderborn.de (8.7.3/8.7.3) with SMTP id JAA00442 for ; Fri, 29 Aug 1997 09:48:18 +0200 (MET DST) Sender: merlin@uni-paderborn.de Message-ID: <34067EC0.10EC@uni-paderborn.de> Date: Fri, 29 Aug 1997 09:48:16 +0200 From: Olaf Schmidt Organization: University of Paderborn X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5 sun4u) MIME-Version: 1.0 To: greg Subject: Re: Radiosity for Virtual Reality Systems References: <199708281712.KAA05425@pink.lbl.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: R Hello, > I have finish my MSc thesis and have setup a permanant website for that over > at University of Leeds - http://dream.leeds.ac.uk/cuddles/rover > > The site contains the thesis itself, images, hyperlink abstracts and biblio., > huge collection of links on radiosity papers on the Web, free radiosity > software on the web, and many others. > Thank you very much for this excellent website. Unfortunately I have some problems when I try to access the paper collection, the videos and VRMLs (e.g. The requested URL /cuddles/rover/sport/rad.1/book.at/modildsf.ps was not found on this server). Is there something going wrong ? Best regards, Olaf Schmidt -- *************************************************************************** ** Olaf Schmidt e-mail merlin@uni-paderborn.de ** ** ** ** http://www.uni-paderborn.de/fachbereich/AG/monien/PERSONAL/merlin.html** ** ** ** University of Paderborn office F2.403 ** ** Dept. of Computer Science fax +49 +5251 60-6697 ** ** Fuerstenallee 11 voice +49 +5251 60-6722 ** ** 33102 Paderborn, Germany ** **-----------------------------------------------------------------------** ** private: ** ** ** ** Rotheweg 108 phone +49 +5251 48691 ** ** 33102 Paderborn ** ** ** *************************************************************************** From owner-globillum-imag@imag.imag.fr Fri Aug 29 12:40:19 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA06684 for ; Fri, 29 Aug 1997 12:40:19 -0700 Received: from listserv.lbl.gov (listserv.lbl.gov [128.3.254.140]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA14956 for ; Fri, 29 Aug 1997 12:43:07 -0700 Received: from imag.imag.fr by listserv.lbl.gov (SMI-8.6/SMI-SVR4) id MAA08565; Fri, 29 Aug 1997 12:41:24 -0700 Received: from adeskgate.autodesk.com (adeskgate.autodesk.com [198.93.152.11]) by imag.imag.fr (8.8.1/8.8.5) with ESMTP id UAA14005 for ; Fri, 29 Aug 1997 20:41:05 +0200 (MET DST) Received: from autodesk.autodesk.com by adeskgate.autodesk.com (8.6.12/SMI-5.3) with ESMTP id LAA11450; Fri, 29 Aug 1997 11:40:23 -0700 Received: from hqhubmu1.autodesk.com by autodesk.autodesk.com (8.6.12/4.4BSD) with ESMTP id LAA02084; Fri, 29 Aug 1997 11:40:13 -0700 Received: from ccinternet.autodesk.com (ccinternet [144.111.240.144]) by hqhubmu1.autodesk.com (8.7.5/8.7.3) with SMTP id LAA17655 for ; Fri, 29 Aug 1997 11:40:11 -0700 (PDT) Received: from ccMail by ccinternet.autodesk.com (IMA Internet Exchange 2.11 (Pre-release) Enterprise) id 00099F68; Fri, 13 Jun 1997 11:41:19 -0700 Mime-Version: 1.0 Date: Fri, 29 Aug 1997 14:38:29 -0700 Message-ID: <00099F68.4149@autodesk.com> From: eric.haines@autodesk.com (Eric Haines) Subject: ACM TOG article(s) of interest To: globillum Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" Content-Description: cc:Mail note part Status: R --MimeMultipartBoundary Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit The latest issue of ACM TOG is out. The first article in particular should be of interest to globillumers. Here's the table of contents: Volume 16, Number 3 (July 1997) Global illumination using local linear density estimation, Bruce Walter, Philip M. Hubbard, Peter Shirley and Donald P. Greenberg Color image quantization by minimizing the maximum intercluster distance, Zhigang Xiang Smooth invariant interpolation of rotations, F. C. Park and Bahram Ravani Some characterizations of families of surfaces using functional equations, Enrique Castillo and Andres Iglesias The symmetric analogue of the polynomial power basis, J. Sanchez-Reyes Abstracts and index terms for these articles are available at http://www.acm.org/pubs/contents/journals/tog/1997-16/ The ACM TOG site, http://www.acm.org/tog/, also has pointers to various online resources for computer graphics researchers and educators. Eric Haines erich@acm.org --MimeMultipartBoundary-- From mscytsy@scs.leeds.ac.uk Tue Sep 2 01:27:14 1997 Received: from csunb0.leeds.ac.uk (csunb0.leeds.ac.uk [129.11.144.2]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA10281 for ; Tue, 2 Sep 1997 01:27:13 -0700 Received: from csirisa.leeds.ac.uk (csirisa.leeds.ac.uk [129.11.144.129]) by csunb0.leeds.ac.uk (8.6.12/8.6.12) with ESMTP id IAA06695 for ; Tue, 2 Sep 1997 08:52:05 +0100 Received: from csgi64.scs.leeds.ac.uk by csirisa.leeds.ac.uk; Tue, 2 Sep 1997 08:45:59 +0100 Received: from localhost by csgi64.scs.leeds.ac.uk; Tue, 2 Sep 1997 08:45:59 +0100 Date: Tue, 2 Sep 1997 08:45:58 +0100 (BST) From: "Tralvex Yeap (T.Rex)" X-Sender: mscytsy@csgi64 To: "Gregory W. Larson" Subject: Re: www problems In-Reply-To: <199708291708.KAA06523@pink.lbl.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: R On Fri, 29 Aug 1997, Gregory W. Larson wrote: Hi, > Thank you very much for this excellent website. Unfortunately I have > some > problems when I try to access the paper collection, the videos and > VRMLs > (e.g. The requested URL /cuddles/rover/sport/rad.1/book.at/modildsf.ps > was not found on this server). Is there something going wrong ? > > Best regards, > Olaf Schmidt You might have notice the icon "CD Only". As the total space would be 450mb, and we are only given 25mb on the website, I have chose to put the Video, VRML, papers on the CDROM. Considering the I got all the resources from the website, you might want to do some seek and conquer thingy. But if you still cannot find it, I'll attach as a file to you? Alternatively I could upload it to a FTP site for your download? From owner-globillum-imag@imag.imag.fr Fri Sep 5 09:56:51 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA17631 for ; Fri, 5 Sep 1997 09:56:50 -0700 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA19206 for ; Fri, 5 Sep 1997 09:59:29 -0700 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id JAA02028; Fri, 5 Sep 1997 09:52:07 -0700 Received: from lms02.us1.ibm.com (lms02.ny.us.ibm.com [198.133.22.25]) by imag.imag.fr (8.8.1/8.8.5) with SMTP id RAA11135 for ; Fri, 5 Sep 1997 17:07:28 +0200 (MET DST) Received: from d01lms03.pok.ibm.com by lms02.us1.ibm.com (AIX 4.1/UCB 5.64/4.03) id AA16746; Fri, 5 Sep 1997 15:07:02 GMT Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D01AU041 id 5010300008757645; Fri, 5 Sep 1997 11:03:15 -0400 From: Holly Rushmeier To: , Cc: Subject: COMPUTING REVIEWS Category Editor Duties Message-Id: <5010300008757645000002L052*@MHS> Date: Fri, 5 Sep 1997 11:03:15 -0400 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" Status: R --MimeMultipartBoundary Content-Type: text/plain Hi -- Appended is a note from the editor of Computing Reviews, who is looking for a Category Editor for computer graphics. This job is an important service to the computing community. I've mentioned the position to several people, but apparently no one has come forward yet. If you are interested, please contact Neal directly. Also, please distribute this to anyone you know who you think is qualified and might be interested. Thanks, Holly ---------------------- Forwarded by Holly Rushmeier/Watson/IBM on 09/05/97 10:51 AM --------------------------- neal @ cse.fau.edu 07/29/97 08:44 AM To: holly @ watson.ibm.com cc: neal @ cse.fau.edu (bcc: Holly Rushmeier/Watson/IBM Research) Subject: COMPUTING REVIEWS Category Editor Duties Holly, as promised yesterday, attached is a description of the functions of a COMPUTING REVIEWS Category Editor. We are searching for someone to fill the I.3--Computer Graphics position. Please see the January 1997 edition of COMPUTING REVIEWS for a listing of the complete Computing Classification System taxonomy, or see http://www.acm.org/class/1991 or the ACM home page for links to COMPUTING REVIEWS and its charter, editorial board, etc. Please contact me with any questions you have. Neal --------------------------------------------------------- Neal Coulter Computer Science and Engineering Department Florida Atlantic University Boca Raton, FL 33431 561-367-3983 561-367-2800 (fax) neal@cse.fau.edu FUNCTIONS OF CATEGORY EDITORS These guidelines were drafted by Jean E. Sammet in 1985 and updated in 1994. The basic functions of each Category Editor (CE) are to improve the quality and to increase the quantity of reviews for Computing Reviews (CR). ACM Headquarters is responsible for producing CR. The separate responsibilities of HQ and the category editors follow. ACM Headquarters Basic Responsibilities 1. acquiring material (with input from CEs for unusual material) 2. maintaining reviewer database (additions, deletions, and changes) 3. assigning priorities for reviewing 4. assigning material to specific reviewers 5. receiving, processing, and editing the reviews and scheduling them for publication Category Editor's Responsibilities 1. Provide advice and aid to HQ and Editor-in-Chief (EIC) for special projects (as requested by HQ or EIC) 2. Specify items that deserve quickly published reviews. Guidelines for priority identification: a. Do this even for journals that already receive high coverage. b. Do not do this for ACM journals, because HQ sometimes works from page proofs of these. c. For journals or proceedings that HQ does not normally receive, the CE must send a copy of the paper to HQ, or the coverage will be delayed while HQ obtains the document. d. Specify articles in ACM SIG newsletters that should be reviewed. 3. Examine reviews after they are sent to Headquarters (normally sent to CEs within 5 working days after it arrives at HQ). Guidelines for review examination: a. Notify ACM HQ within one week of receipt of changes needed for categories and/or General Terms, and your evaluation of each review. Rate the review on a scale from 1--5 for technical content (TE), completeness (CO), and clarity (CL). Electronic mail should be used if possible. Mail to reviews@cr.acm.org. If using regular mail, send to: ACM Computing Reviews, 1515 Broadway, 17th Floor, New York, NY 10036. b. Notify ACM HQ within one week of reviews that are not acceptable to publish or require substantial revision. Particular attention should be paid to the length of reviews. Reviews of books should be between 250 and 800 words, depending on the length and/or importance of the book. Reviews of papers or book chapters should be between 100 and 250 words. There is no length limit for Comparative, Feature, and Scholarly reviews. The Managing Editor, Associate Editor, and Assignment Editor work closely with reviewers to keep these special reviews to an appropriate length. c. Make suggestions to help reviewer improve future reviews. Do this in any time period you feel is appropriate and use any format you are comfortable with. 4. Collaborate with ACM HQ (Assignment Editor) to suggest Comparative book reviews. In special cases, the CE and assignment editor may also get involved in single book review problems. Suggest reviewers for Comparative reviews. 5. Notify HQ of "obscure" documents not normally reviewed---but needing review---and suggest reviewers, if possible. This includes proceedings, journals not normally received at HQ, university press publications, videotapes, and books from obscure publishers. Provide HQ with full source information, author, and title. 6. Notify HQ of new journals along with recommendation of level of coverage (full, moderate, or occasional). 7. Suggest specific reviewers to HQ for specific documents whenever appropriate. Timing is critical and notification by CE to HQ must be rapid, or this won't work. 8. Recruit reviewers for your area. If possible, use specific approaches unique to your area. Rate reviewers. 9. Recruit outstanding and well-known experts to review special items, under the condition that this does not interfere with normal HQ operations. This will only be effective if based on personal contact and special arrangements. 10. Write reviews yourself at least twice a year. 11. Review your portion of the category tree and make recommendations for changes as requested by the EIC. 12. Prepare index terms for items not in the category tree as requested by the EIC. 13. Recommend important conference papers for review. Solicit Scholarly and Feature reviews. General note: Because no single CE is likely to be equally familiar with all the topics under the category, it is permissible (and encouraged) for each Category Editor to find one or more assistants to carry out many of the above tasks for a subcategory, or to provide advice. This should be done on an informal basis. The CE retains authority and responsibility. --MimeMultipartBoundary-- From owner-globillum-imag@imag.imag.fr Mon Sep 8 11:43:48 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA22489 for ; Mon, 8 Sep 1997 11:43:43 -0700 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA03196 for ; Mon, 8 Sep 1997 11:46:24 -0700 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id LAA26220; Mon, 8 Sep 1997 11:40:16 -0700 Received: from cs.uct.ac.za (root@cs.uct.ac.za [137.158.128.249]) by imag.imag.fr (8.8.1/8.8.5) with SMTP id SAA25114 for ; Mon, 8 Sep 1997 18:56:35 +0200 (MET DST) Received: from tai.cs.uct.ac.za by cs.uct.ac.za with smtp (Smail3.1.29.1 #11) id m0x86re-00098RC; Mon, 8 Sep 97 18:40 SAT (+0200) Received: by tai.cs.uct.ac.za (951211.SGI.8.6.12.PATCH1042/ika.02) id SAA19984; Mon, 8 Sep 1997 18:40:38 +0200 From: "Wolfram Kresse" Message-Id: <9709081840.ZM19982@tai> Date: Mon, 8 Sep 1997 18:40:37 +0000 X-Face: .4|Jp[=9'pK#xl6x&l>D4xycaCh FF=0.5 - if A is at a vertex of the emitter, I've got a problem... By naive empirical analysis, I managed to find a solution for the following cases (A at an emitter vertex): /|E / |____ | / /R | / / |/___/ (side view) - if emitter and receiver are rectangular, the FF at the vertex is 0.25*(1+cos(alpha)). (alpha= angle between emitter and receiver) _______ \ |E \ b2 | \ | \ | \ | b1 \ | ______\| / \ / \ /____________\R (front view) - if alpha is a right angle, and the angle of the emitter is beta2 (b2), and the angle between the receiver edge in the emitter plane and the emitter is beta1 (b1), and beta=b1+b2 (are you still with me? :) ), then the FF is 0.25*(cos(beta1)-cos(beta)). ...well, that's as far as I got. It seems already that the combination of these two cases (varying alpha *and* beta1/beta) isn't that simple that it can be figured out just by writing down some values and trying. My hope is that there is a (or several) formula for the general case (e.g. the result seems also to depend on how I approach the receiver vertex - and thus on the angle of the receiver). One simple way to 'solve' it, is just to move the receiver vertex away from the emitter plane, but this looks more like a workaround and it might even lead to other problems. - is this how everybody does it ;-) or are there other ways to get a correct FF value for these cases? Any suggestions/help appreciated. Thanks! Cheers, Wolfram -- +-------+-----Wolfram Kresse---------------------------------------------+ | _ _ | wkresse@igd.fhg.de http://www.igd.fhg.de/~wkresse | | +-------------------------+-----------------+--------------------+ | -O-O- |"Meeneemeeneemeenee" | CU l8r, LE g8r! | | > |"Yes,that's right,Twiki."+-----------------+ | _____ +-----+-----+-------------+ | U | 8^) | :u) | +-------+-----+-----+ --MimeMultipartBoundary-- From owner-globillum-imag@imag.imag.fr Mon Sep 8 12:54:08 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA22625 for ; Mon, 8 Sep 1997 12:54:07 -0700 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA04178 for ; Mon, 8 Sep 1997 12:56:52 -0700 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id MAA00838; Mon, 8 Sep 1997 12:51:44 -0700 Received: from mail.uniserve.com (dns1-van.uniserve.com [204.244.163.48]) by imag.imag.fr (8.8.1/8.8.5) with SMTP id VAA28869 for ; Mon, 8 Sep 1997 21:22:05 +0200 (MET DST) Received: from ian [204.244.158.195] by mail.uniserve.com with smtp (Exim 1.70 #1) id 0x89Qn-0004un-00; Mon, 8 Sep 1997 12:25:06 -0700 X-Sender: iashdown@pop.uniserve.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" To: globillum@imag.fr From: iashdown@ledalite.com (Ian Ashdown) Subject: RADBIB97 - September 1st release Message-Id: Date: Mon, 8 Sep 1997 12:25:06 -0700 Status: R --MimeMultipartBoundary Content-Type: text/plain; charset="us-ascii" ANNOUNCE: 97/09/01 Release of RADBIB97.BIB and GITHESIS.BIB ----------------------------------------------------------- RADBIB97 is a comprehensive bibliography of radiosity and related global illumination papers, theses, articles, and books. It currently includes 1,219 references -- 55 new additions since the 97/07/15 release! This bibliography is available in BibTex format as RADBIB97.BIB (with a release date of September 1, 1997) from: http://www.ledalite.com/library-/rrt.htm ftp://ftp.ledalite.com/pub/radbib97.bib Also available from this site is an abridged version of RADBIB97.BIB called GITHESIS.BIB. This bibliography includes 138 references to radiosity and global illumination theses. As always, it is time-consuming and sometimes difficult to track down conference papers and theses on radiosity and global illumination. If you know of a relevant reference that is not included in these bibliographies, please let us know so that we can include it in the next release. Partial financial support for the maintenance of these bibliographies has been provided by the ACM SIGGRAPH Special Projects. Ian Ashdown, P. Eng. | READ THE BOOK! | Research & Development Manager | Radiosity: A Programmer's Perspective | Ledalite Architectural Products | Wiley & Sons 1994 | Visit http://www.ledalite.com | (Sneaky Internet Advertising) | Book Review: http://www.ercb.com/ddj/1996/ddj.9605.html Book Order: https://www.wiley.com/compbooks/catalog/30444-1.htm Free Software: http://www.ledalite.com/software/software.htm --MimeMultipartBoundary-- From greg Tue Sep 9 11:08:42 1997 Received: (from greg@localhost) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA25029; Tue, 9 Sep 1997 11:08:41 -0700 Date: Tue, 9 Sep 1997 11:08:41 -0700 From: greg (Gregory W. Larson) Message-Id: <199709091808.LAA25029@pink.lbl.gov> To: globillum@imag.fr Subject: new extended-range TIFF library Cc: drb@sgi.com, malik@cs.berkeley.edu, debevec@cs.berkeley.edu Status: R Hi All, As promised, I have put together some web pages describing a new addition to Sam Leffler's TIFF library, with facilities for reading and writing high dynamic-range images. See: http://www.sgi.com/Technology/pixformat/ The format is based on a 16-bit log encoding of luminance, plus a 16-bit encoding of color in CIE (u',v') coordinates. This allows the format to cover the full range of human vision in imperceptible steps. In fact, the encoding covers over 38 orders of magnitude, which means that you don't have to worry about exposure when storing your global illumination calculations. I have included over 100 example images, mostly Radiance renderings but some scanned images from Debevec and Malik's '97 Siggraph paper and my own experiments. I'm hoping this will encourage people to download and compile the library and viewer and start playing around with tone-mapping algorithms and the like. For those of you who want to experiment with image-based rendering algorithms, I have also included 5 cylindrical (360 degree) panoramas. Let me know if you have any problems, questions or suggestions. -Greg _____________________________________________________________________ Gregory Ward Larson (the computer artist formerly known as Greg Ward) Silicon Graphics, Inc. Computer Science Department 2011 N. Shoreline Blvd., M/S 07U-553 537 Soda Hall, UC Berkeley Mountain View, CA 94043-1389 Berkeley, CA 94720-1776 (650) 933-4878, -2663 fax (510) 642-3631, -5775 fax gregl@sgi.com on Tues., Thurs. and Fri. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From mcohen@MICROSOFT.com Tue Sep 9 12:31:06 1997 Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.23]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA25207 for ; Tue, 9 Sep 1997 12:31:05 -0700 Received: by mail3.microsoft.com with Internet Mail Service (5.0.1459.27) id ; Tue, 9 Sep 1997 12:29:50 -0700 Message-ID: <28347281A2B5CF119AB000805FD4186603E08601@RED-77-MSG.dns.microsoft.com> From: "Michael Cohen (Research)" To: "'greg@pink.lbl.gov'" Subject: RE: new extended-range TIFF library Date: Tue, 9 Sep 1997 12:28:51 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1459.27) Status: R I can't seem to get to your page > http://www.sgi.com/Technology/pixformat/ > Maybe Microsoft's firewall prevents people here from looking at SGI pages ;-). Do you know if others are having problems. -michael From greg Tue Sep 9 13:28:31 1997 Received: (from greg@localhost) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) id NAA25292; Tue, 9 Sep 1997 13:28:31 -0700 Date: Tue, 9 Sep 1997 13:28:31 -0700 From: greg (Gregory W. Larson) Message-Id: <199709092028.NAA25292@pink.lbl.gov> To: "Michael Cohen (Research)" Subject: RE: new extended-range TIFF library Status: R Hi Michael, I don't know what the problem is -- Holly accessed it from IBM and it worked OK, and I can get to it from my UCB machine. All I can suggest is that you try it again later, or else complain to whoever is cutting off the SGI website. (I know you meant this as a joke, but....) -G From mcohen@MICROSOFT.com Tue Sep 9 13:53:47 1997 Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.42]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA25353 for ; Tue, 9 Sep 1997 13:53:46 -0700 Received: by INET-02-IMC with Internet Mail Service (5.0.1459.27) id ; Tue, 9 Sep 1997 13:51:50 -0700 Message-ID: <28347281A2B5CF119AB000805FD4186603E08602@RED-77-MSG.dns.microsoft.com> From: "Michael Cohen (Research)" To: "'greg@pink.lbl.gov'" Subject: SGI vs. MS Date: Tue, 9 Sep 1997 13:51:42 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1459.27) Status: R So, the story I get is that SGI blocks hits from MS because some idiots at Microsoft wrote a web-crawler that continually poked SGI sites or something. Anyway, I'll find a way around it. -Michael From owner-globillum-imag@imag.fr Fri Oct 3 12:21:57 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA27767 for ; Fri, 3 Oct 1997 12:21:39 -0700 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA25201 for ; Fri, 3 Oct 1997 12:24:18 -0700 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id MAA27574; Fri, 3 Oct 1997 12:19:11 -0700 Received: from mail.uniserve.com (dns1-van.uniserve.com [204.244.163.48]) by imag.imag.fr (8.8.5/8.8.5) with SMTP id SAA18727 for ; Fri, 3 Oct 1997 18:59:52 +0200 (MET DST) Received: from p1-10.van.tvs.net [204.244.158.89] by mail.uniserve.com with smtp (Exim 1.70 #1) id 0xHB4h-0003lA-00; Fri, 3 Oct 1997 09:59:35 -0700 X-Sender: iashdown@pop.uniserve.com (Unverified) X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" To: globillum@imag.fr From: iashdown@ledalite.com (Ian Ashdown) Message-Id: Date: Fri, 3 Oct 1997 09:59:35 -0700 Status: R --MimeMultipartBoundary Content-Type: text/plain; charset="us-ascii" ANNOUNCE: 97/10/01 Release of RADBIB97.BIB and GITHESIS.BIB ----------------------------------------------------------- RADBIB97 is a comprehensive bibliography of radiosity and related global illumination papers, theses, articles, and books. It currently includes 1,237 references -- 18 new additions since the 97/09/01 release. This bibliography is available in BibTex format as RADBIB97.BIB (with a release date of October 1, 1997) from: http://www.ledalite.com/library-/rrt.htm ftp://ftp.ledalite.com/pub/radbib97.bib Also available from this site is an abridged version of RADBIB97.BIB called GITHESIS.BIB. This bibliography includes 145 references to radiosity and global illumination theses -- 7 new additions since the 97/09/01 release. As always, it is time-consuming and sometimes difficult to track down conference papers and theses on radiosity and global illumination. If you know of a relevant reference that is not included in these bibliographies, please let us know so that we can include it in the next release. Partial financial support for the maintenance of these bibliographies has been provided by the ACM SIGGRAPH Special Projects. Ian Ashdown, P. Eng. | READ THE BOOK! Research & Development Manager | Radiosity: A Programmer's Perspective Ledalite Architectural Products | Wiley & Sons 1994 Visit http://www.ledalite.com | (http://www.amazon.com) --MimeMultipartBoundary-- From owner-globillum-imag@imag.fr Tue Oct 7 13:14:15 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA02779 for ; Tue, 7 Oct 1997 13:14:15 -0700 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA11430 for ; Tue, 7 Oct 1997 13:16:54 -0700 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id NAA07939; Tue, 7 Oct 1997 13:11:42 -0700 Received: from ladybug.seas.gwu.edu (ladybug.seas.gwu.edu [128.164.9.8]) by imag.imag.fr (8.8.5/8.8.5) with ESMTP id PAA18931 for ; Tue, 7 Oct 1997 15:20:28 +0200 (MET DST) Received: from seas.gwu.edu (felix.seas.gwu.edu [128.164.9.3]) by ladybug.seas.gwu.edu (v8) with ESMTP id JAA00173 for ; Tue, 7 Oct 1997 09:20:14 -0400 (EDT) Received: (from musgrave@localhost) by seas.gwu.edu (8.8.7/8.7.1) id JAA21547; Tue, 7 Oct 1997 09:20:06 -0400 (EDT) Date: Tue, 7 Oct 1997 09:20:06 -0400 (EDT) From: Ken Musgrave Message-Id: <199710071320.JAA21547@seas.gwu.edu> To: globillum@imag.fr Subject: Clouds, imaged nicely Cc: sylee@seas.gwu.edu Status: R One of my students at GWU, Sang Yoon Lee, has implemented Nelson Max's high-albedo anisotropic multiple scattering model in my cloud models with adaptive level of detail. The resulting images are worth a look (I've wanted to see such results for years!): www.seas.gwu.edu/student/sylee Enjoy! -Ken From greg Fri Oct 10 11:30:32 1997 Received: (from greg@localhost) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA06568; Fri, 10 Oct 1997 11:30:31 -0700 Date: Fri, 10 Oct 1997 11:30:31 -0700 From: greg (Gregory W. Larson) Message-Id: <199710101830.LAA06568@pink.lbl.gov> To: globillum@imag.fr Subject: webmover program Status: R Hi Everyone, I just wrote a program that has nothing to do with global illumination, but I don't belong to any appropriate groups so I thought I'd announce it here, anyway. It's a little utility for checking and moving web pages. It's especially useful for translating web pages you want to publish on a CD-ROM in ISO-9660 format. I am faced with this task myself, translating the Radiance web pages for a CD-ROM to accompany the book Rob Shakespeare and I wrote on Radiance for Morgan Kaufmann. (Plug: the book should be out early next year.) If you've ever had to go through a large web site, renaming files and fixing links, you know what a pain it can be. This program does it for you, and it's fast and it's free (with no warranty!). Here's the help screen: Usage: webmover [-u|-i|-d][-v] base_URL orig_dir/[html] [new_dir/[html]] Or: webmover -h[elp] Arguments to webmover and their interpretation: base_URL The starting point for this website (beginning with "http://") orig_dir/[html] The original directory [and front page] relative to base_URL If [html] is left off, then we assume "index.html" newdir/[html] The destination directory [and front page] relative to base_URL This new directory must not exist. If this argument is left off, webmover just checks pages. Options to webmover and their meanings: -u Convert to UNIX file naming conventions and newline -i Convert to ISO-9660 file naming conventions -d Convert to DOS file naming conventions and newline -v Verbose reporting of progress to stdout Assumptions made by webmover: o Only move what front page references, directly and indirectly o Overhead references (above front page directory) are not moved o No non-printing, non-white characters are desired in pages o Symbolic links are followed and not treated specially o Hard links are made to destination whenever possible o Hard links are preserved among files The following file suffixes are recognized: ____UNIX____ISO____ html htm jpeg jpg tiff tif tar.Z trz ps.Z psz tar.gz tgz ps.gz pgz text txt jfif jff ------------------------------- To pick it up, just follow the URL below: file://radsite.lbl.gov/rad/pub/translators/webmover.c Feel free to share this with whomever you like. It's public domain. -Greg _____________________________________________________________________ Gregory Ward Larson (the computer artist formerly known as Greg Ward) Silicon Graphics, Inc. Computer Science Department 2011 N. Shoreline Blvd., M/S 07U-553 537 Soda Hall, UC Berkeley Mountain View, CA 94043-1389 Berkeley, CA 94720-1776 (650) 933-4878, -2663 fax (510) 642-3631, -5775 fax gregl@sgi.com on Tues., Thurs. and Fri. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-globillum-imag@imag.fr Wed Oct 22 11:06:03 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA21958 for ; Wed, 22 Oct 1997 11:06:03 -0700 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA22936 for ; Wed, 22 Oct 1997 11:08:36 -0700 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id LAA25527; Wed, 22 Oct 1997 11:03:20 -0700 Received: from phong.cs.utah.edu (phong.cs.utah.edu [128.110.4.52]) by imag.imag.fr (8.8.5/8.8.5) with SMTP id SAA05530 for ; Wed, 22 Oct 1997 18:56:18 +0200 (MET DST) Received: (from shirley@localhost) by phong.cs.utah.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) id KAA08066 for globillum@imag.fr; Wed, 22 Oct 1997 10:46:33 -0600 From: shirley@phong.cs.utah.edu (Peter Shirley) Message-Id: <199710221646.KAA08066@phong.cs.utah.edu> Subject: Grad recruiting at Utah To: globillum@imag.fr Date: Wed, 22 Oct 1997 10:46:33 -0600 (MDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" Status: R --MimeMultipartBoundary Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I apologize for this potential misuse of the list-- I would like to spread the word that we are trying to increase our grad population size at Utah, and if possible please pass on the following tidbits to your seniors considering grad school (in graphics or not): 1) Almost all students get assitantships 2) Cohen/Johnson/Shirley/Riesenfeld/Hansen/Smits here as either profs or postdocs-- that is two modeling, two rendering, and two viz people. 3) Much equipemnt including Origin2000 with RealityMonster 4) Free online application-- see www.cs.utah.edu As for lifestyle, this is the best place I know of for outdoorsy types that still want to be able to see an art-film or get an expresso or microbrew. It is probably not a good place for true urbanites or people that want a small town. Thanks, Pete Shirley shirley@cs.utah.edu PS-- obligatory globillum material-- I just returned from Pacific Graphics 97 and Parallel Rendering 97. I saw three different talks that had radiosity solutions on models with more than 0.5 million initial patches. Also, it was mentioned that the next version of doom has full radiosity solutions! --MimeMultipartBoundary-- From owner-globillum-imag@imag.fr Fri Oct 24 13:28:07 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA25065 for ; Fri, 24 Oct 1997 13:28:06 -0700 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA03664 for ; Fri, 24 Oct 1997 13:30:41 -0700 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id NAA25356; Fri, 24 Oct 1997 13:25:28 -0700 Received: from adeskgate.autodesk.com (adeskgate.autodesk.com [198.93.152.11]) by imag.imag.fr (8.8.5/8.8.5) with ESMTP id RAA26415 for ; Fri, 24 Oct 1997 17:48:23 +0200 (MET DST) Received: from autodesk.autodesk.com by adeskgate.autodesk.com (8.6.12/SMI-5.3) with ESMTP id IAA16556; Fri, 24 Oct 1997 08:47:07 -0700 (PDT) Received: from hqhubmu1.autodesk.com by autodesk.autodesk.com (8.6.12/4.4BSD) with ESMTP id IAA19892; Fri, 24 Oct 1997 08:46:55 -0700 Received: from ccinternet.autodesk.com (ccinternet [144.111.240.144]) by hqhubmu1.autodesk.com (8.7.5/8.7.3) with SMTP id IAA15681 for ; Fri, 24 Oct 1997 08:46:53 -0700 (PDT) Received: from ccMail by ccinternet.autodesk.com (IMA Internet Exchange 2.11 Enterprise) id 001748AC; Fri, 24 Oct 1997 08:47:05 -0700 Mime-Version: 1.0 Date: Fri, 24 Oct 1997 11:45:08 -0700 Message-ID: <001748AC.4149@autodesk.com> From: eric.haines@autodesk.com (Eric Haines) Subject: ACM Digital Library open to all To: globillum Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" Content-Description: cc:Mail note part Status: R --MimeMultipartBoundary Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I'd like to mention a resource here that is worth knowing about: ACM Transactions on Graphics and all other ACM journals are now searchable online via ACM's Digital Library. Also, many articles are becoming available in digital form to subscribers. Until the end of the year the search engine is available to anyone for free. The Digital Library is located at: http://www.acm.org/dl/ As an example, here are the publications found when searching on radiosity or global illumination as keywords (excuse the margins): 1) 30 Radiosity and hybrid methods; La'szlo' Neumann ; ACM Trans. Graph. 14, 3 (Jul. 1995), Pages 233 - 265 2) 20 Global illumination of glossy environments using wavelets and importance; Per H.Christensen ; ACM Trans. Graph. 15, 1 (Jan. 1996), Pages 37 - 71 3) 10 Extending the radiosity method to include specularly reflecting and translucent materials; Holly E.Rushmeier ; ACM Trans. Graph. 9, 1 (Jan. 1990), Pages 1 - 27 4) 10 Global illumination using local linear density estimation; Bruce Walter ; ACM Trans. Graph. 16, 3 (Jul. 1997), Pages 217 - 259 5) 10 Global illumination using local linear density estimation; Bruce Walter ; ACM Trans. Graph. 16, 3 (Jul. 1997), Pages 217 - 259 6) 10 Multiresolution analysis for surfaces of arbitrary topological type; Michael Lounsbery ; ACM Trans. Graph. 16, 1 (Jan. 1997), Pages 34 - 73 7) 10 Clustering for glossy global illumination; Per H.Christensen ; ACM Trans. Graph. 16, 1 (Jan. 1997), Pages 3 - 33 8) 10 Smooth B-spline illumination maps for bidirectional ray tracing; Richard A.Redner ; ACM Trans. Graph. 14, 4 (Oct. 1995), Pages 337 - 362 9) 10 Adjoint equations and random walks for illumination computation; S. N.Pattanaik ; ACM Trans. Graph. 14, 1 (Jan. 1995), Pages 77 - 102 I've noticed that unfortunately the older years of some journals are not yet part of the Digital Library, which seems to go back to about 1985. Eric Haines erich@acm.org --MimeMultipartBoundary-- From owner-globillum-imag@imag.fr Thu Oct 30 13:55:50 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA02699 for ; Thu, 30 Oct 1997 13:55:50 -0800 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA28523 for ; Thu, 30 Oct 1997 13:58:25 -0800 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id NAA05509; Thu, 30 Oct 1997 13:52:57 -0800 Received: from lorraine.loria.fr (lorraine.loria.fr [152.81.1.17]) by imag.imag.fr (8.8.5/8.8.5) with ESMTP id PAA01132 for ; Thu, 30 Oct 1997 15:15:28 +0100 (MET) Received: from cloe.loria.fr (cloe.loria.fr [152.81.3.123]) by lorraine.loria.fr (8.8.7/8.8.7/8.8.7/JCG) with ESMTP id PAA24560 for ; Thu, 30 Oct 1997 15:15:26 +0100 (MET) From: Nicolas Holzschuch Received: (from holzschu@localhost) by cloe.loria.fr (8.7.4/8.7.3) id PAA06361 for globillum@imag.fr; Thu, 30 Oct 1997 15:15:25 +0100 (MET) Message-Id: <199710301415.PAA06361@cloe.loria.fr> Subject: Test scenes To: globillum@imag.fr Date: Thu, 30 Oct 1997 15:15:25 +0100 (MET) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" Status: R --MimeMultipartBoundary Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello globillumers, I just had a message from a student, asking for some test scenes to check his radiosity program. I immediately thought of this nice set of 10 test scenes that was released for the fifth Eurographics Workshop on Rendering (by Peter Shirley, if my memory serves me well). However, I couldn't remember where to find them. Can anyone help me? Nicolas Holzschuch --MimeMultipartBoundary-- From greg Thu Oct 30 14:09:48 1997 Received: (from greg@localhost) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) id OAA02716; Thu, 30 Oct 1997 14:09:48 -0800 Date: Thu, 30 Oct 1997 14:09:48 -0800 From: greg (Gregory W. Larson) Message-Id: <199710302209.OAA02716@pink.lbl.gov> To: Nicolas Holzschuch Subject: Re: Test scenes Cc: globillum@imag.fr Status: R > Hello globillumers, > I just had a message from a student, asking > for some test scenes to check his radiosity > program. I immediately thought of this nice > set of 10 test scenes that was released for > the fifth Eurographics Workshop on Rendering > (by Peter Shirley, if my memory serves me > well). However, I couldn't remember where > to find them. > > Can anyone help me? > > Nicolas Holzschuch Peter Shirley's test scenes are together with a bunch of scenes taken from Radiance at the MGF web site: http://radsite.lbl.gov/mgf/ There is also a free parser library for reading the data, documentation, etc. -Greg _____________________________________________________________________ Gregory Ward Larson (the computer artist formerly known as Greg Ward) Silicon Graphics, Inc. Computer Science Department 2011 N. Shoreline Blvd., M/S 07U-553 537 Soda Hall, UC Berkeley Mountain View, CA 94043-1389 Berkeley, CA 94720-1776 (650) 933-4878, -2663 fax (510) 642-3631, -5775 fax gregl@sgi.com on Tues., Thurs. and Fri. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-globillum-imag@imag.fr Fri Oct 31 11:38:08 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA03922 for ; Fri, 31 Oct 1997 11:38:07 -0800 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA03376 for ; Fri, 31 Oct 1997 11:40:44 -0800 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id LAA20420; Fri, 31 Oct 1997 11:35:33 -0800 Received: from idefix.cs.kuleuven.ac.be (root@idefix.cs.kuleuven.ac.be [134.58.41.7]) by imag.imag.fr (8.8.5/8.8.5) with ESMTP id LAA21501 for ; Fri, 31 Oct 1997 11:07:44 +0100 (MET) Received: from flater.cs.kuleuven.ac.be (philippe@flater.cs.kuleuven.ac.be [134.58.45.35]) by idefix.cs.kuleuven.ac.be (8.8.6/8.8.6) with ESMTP id LAA05495; Fri, 31 Oct 1997 11:07:34 +0100 (MET) Received: (from philippe@localhost) by flater.cs.kuleuven.ac.be (8.8.6/8.8.6) id LAA00725; Fri, 31 Oct 1997 11:07:27 +0100 (MET) From: Philippe Bekaert Message-Id: <199710311007.LAA00725@flater.cs.kuleuven.ac.be> Subject: Re: Test scenes In-Reply-To: <199710301415.PAA06361@cloe.loria.fr> from Nicolas Holzschuch at "Oct 30, 97 03:15:25 pm" To: Nicolas.Holzschuch@loria.fr (Nicolas Holzschuch) Date: Fri, 31 Oct 1997 11:07:27 +0100 (MET) Cc: globillum@imag.fr X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" Status: R --MimeMultipartBoundary Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > I just had a message from a student, asking > for some test scenes to check his radiosity > program. I immediately thought of this nice Here's one of my favourites: Everyone knows that if all surfaces in a scene have relfectance and emittance equal to 0.5, the total radiance will be 1 everywhere. It's one of the few cases where you have an analytical solution, regardless of the scene geometry. Actually, this is true as long as the sum of the reflectance and emittance is everywhere equal to one. This doesn't mean that the reflectances have to be equal everywhere: Take e.g. a labyrinth scene with a few patches that are almost perfect emittors (emittance 0.99 and reflectance 0.01) while all others are almost perfect reflectors (emittance 0.01 and reflectance 0.99). Also in this case, the total radiance will be equal to one everywhere, but it's a very nice experiment to test out what your radiosity implementation does with it. It was suggested to me by Laszlo and Attila Neumann. Regards, Philippe. -- /~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\ \ Philippe Bekaert | If anything can go wrong, it will, but / / Computer Graphics Research Group | ... we're prepared for it (Switzerland) \ \ Department of Computer Science | ... we don't care (Greece) / / K.U.Leuven - Belgium | ... what the heck, it's been going \ \ | wrong for centuries already (Portugal) / / http://www.cs.kuleuven.ac.be/ | ... it's the fault of the Walloons \ \ ~philippe/ | (Flanders) / /__________________________________| ... we deserve it (Wallonie) \ \ | ... as long as there's vodka we don't / / Not everything that is written | care (Russia) \ \ here is my employers opinion, | ... how much money do I loose? / / sometimes not even mine. | (The Netherlands) \ \__________________________________|_________________________________________/ --MimeMultipartBoundary-- From owner-globillum-imag@imag.fr Fri Oct 31 12:00:51 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA03946 for ; Fri, 31 Oct 1997 12:00:51 -0800 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA03422 for ; Fri, 31 Oct 1997 12:03:28 -0800 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id LAA21828; Fri, 31 Oct 1997 11:58:14 -0800 Received: from idefix.cs.kuleuven.ac.be (root@idefix.cs.kuleuven.ac.be [134.58.41.7]) by imag.imag.fr (8.8.5/8.8.5) with ESMTP id QAA10790 for ; Fri, 31 Oct 1997 16:28:17 +0100 (MET) Received: from flater.cs.kuleuven.ac.be (philippe@flater.cs.kuleuven.ac.be [134.58.45.35]) by idefix.cs.kuleuven.ac.be (8.8.6/8.8.6) with ESMTP id QAA14592 for ; Fri, 31 Oct 1997 16:28:08 +0100 (MET) Received: (from philippe@localhost) by flater.cs.kuleuven.ac.be (8.8.6/8.8.6) id QAA02163; Fri, 31 Oct 1997 16:28:06 +0100 (MET) From: Philippe Bekaert Message-Id: <199710311528.QAA02163@flater.cs.kuleuven.ac.be> Subject: test scenes To: globillum@imag.fr Date: Fri, 31 Oct 1997 16:28:06 +0100 (MET) X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" Status: R --MimeMultipartBoundary Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Some people doubt whether it is true that the total radiance in a diffuse scene will be everywhere equal to one if the sum of emittance and reflectance is everyhwere equal to one. Well ... they are right: it's not always true. I forgot to mention that the scenes should be closed. But the proof (for closed scenes) is as follows: Consider first the "radiosity case": L_i = E_i + rho_i sum_j F_ij L_j My claim is that if E_i + rho_i = 1 for all patches i, then also L_i = 1 for all patches. Proof: fill L_i = 1 for all patches in the radiance equation: 1 = E_i + rho_i sum_j F_ij 1 sum_j F_ij = 1 in a closed environment, so this would imply: 1 = E_i + rho_i and that's exactly what I supposed. It *is* a proof because the solution of the radiance equation is unique. The proof without discretising is very similar. And the result can be generalized to non diffuse environments: the radiance leaving any point in any direction will be equal to one if the sum of selfemitted radiance L_e(x, theta_out) + albedo rho(x, theta_out) equals 1 for all points x and directions theta_out, with rho(x, theta_out) = integral over hemisphere at x of brdf f_r(x, theta_in, theta_out) times cos(angle between theta_in and normal at x) times differential solid angle around theta_in Sorry for wasting your time if you already knew this. Best regards, Philippe. -- /~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\ \ Philippe Bekaert | If anything can go wrong, it will, but / / Computer Graphics Research Group | ... we're prepared for it (Switzerland) \ \ Department of Computer Science | ... we don't care (Greece) / / K.U.Leuven - Belgium | ... what the heck, it's been going \ \ | wrong for centuries already (Portugal) / / http://www.cs.kuleuven.ac.be/ | ... it's the fault of the Walloons \ \ ~philippe/ | (Flanders) / /__________________________________| ... we deserve it (Wallonie) \ \ | ... as long as there's vodka we don't / / Not everything that is written | care (Russia) \ \ here is my employers opinion, | ... how much money do I loose? / / sometimes not even mine. | (The Netherlands) \ \__________________________________|_________________________________________/ --MimeMultipartBoundary-- From owner-globillum-imag@imag.fr Tue Nov 4 03:52:41 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id DAA08305 for ; Tue, 4 Nov 1997 03:52:41 -0800 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id DAA15246 for ; Tue, 4 Nov 1997 03:55:15 -0800 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id DAA04795; Tue, 4 Nov 1997 03:50:00 -0800 Received: from santos.doc.ic.ac.uk (d2EarJ8xK+E1+7X6yyqe2wjqw/k40ilg@santos.doc.ic.ac.uk [146.169.2.42]) by imag.imag.fr (8.8.5/8.8.5) with SMTP id LAA27017 for ; Tue, 4 Nov 1997 11:24:23 +0100 (MET) Received: from peaberry.doc.ic.ac.uk [146.169.12.8] ([KzpNU4iLe92V+XjmCR2zgInuMJSgIo5N]) by santos.doc.ic.ac.uk with smtp (Exim 1.62 #2) id 0xSgAI-0006zD-00; Tue, 4 Nov 1997 10:24:54 +0000 Received: from ajc by peaberry.doc.ic.ac.uk with local (Exim 1.62 #2) id 0xSgAC-0000ZF-00; Tue, 4 Nov 1997 10:24:48 +0000 From: Adrian James Chung To: globillum@imag.fr Subject: Global illumination mailing list has been spammed Message-Id: Date: Tue, 4 Nov 1997 10:24:48 +0000 Status: R Sorry to have to bring up something that has little to do with computer graphics, but the serious problem of spam has finally reached the globillum listserver. You no doubt would have received (perhaps twice) unsolicited commercial email (UCE) with the following headers: Return-path: Envelope-to: ajc@doc.ic.ac.uk Delivery-date: Mon, 3 Nov 1997 22:34:51 +0000 Received: from pigeon.doc.ic.ac.uk [146.169.5.10] ([vdpgkE0wQyuWqrqL+lUNOKRqmUZux2eI]) by santos.doc.ic.ac.uk with smtp (Exim 1.62 #2) id 0xSV57-0006Ja-00; Mon, 3 Nov 1997 22:34:49 +0000 Received: from imag.imag.fr [129.88.30.1] by pigeon.doc.ic.ac.uk with esmtp (Exim 0.55 #3) id E0xSV4b-0001PG-00; Mon, 3 Nov 1997 22:34:17 +0000 Received: from baghdad.savoynet.com (root@baghdad.savoynet.com [204.157.255.21]) by imag.imag.fr (8.8.5/8.8.5) with ESMTP id XAA25613 for ; Mon, 3 Nov 1997 23:22:54 +0100 (MET) From: twilling@swain.savoynet.com Message-Id: <199711032222.XAA25613@imag.imag.fr> Date: Mon, 3 Nov 1997 18:21:56 -0500 X-Sender: twilling@swain.savoynet.com X-Advertisement: Click here to be removed. To: twilling@swain.savoynet.com Subject: United Circuits I have taken great pains to fit a personalised and highly tuned spam filter on my college email box in order to make this channel of communication usable again. Naturally I have implemented an unconditional bypass for all the mailing lists that I have subscribed to. I consider the information posted to this forum very valuable and would hate to have to apply anti-spam filtering to messages posted here, lest I lose an article of considerable importance. In this context, I ask what actions will the list maintainers be taking to prevent more UCE from flooding this list, making unfair usage of resources (list server, disk quota), and if left unchecked rendering this mailing list unusable? Will someone be reporting this to news:news.admin.net-abuse.email and news:news.admin.net-abuse.sightings ? Any comments welcome. (Perhaps better if discussed off this forum. Make sure it doesn't resemble spam.) Adrian -- For details http://spam.abuse.net/spam/ PS. Okay, I finally thought of an on-topic question. What modelling software do you professionals use to construct your test scenes? Is it commercial? Is there something I can download off the Net for any UNIX box running X, (with source) ? And handles parametric curved surfaces? I find that text editing a scripted modelling language falls far short of a real GUI-interface modeller. From owner-globillum-imag@imag.fr Tue Nov 4 15:07:40 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA09192 for ; Tue, 4 Nov 1997 15:07:40 -0800 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA18067 for ; Tue, 4 Nov 1997 15:10:15 -0800 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id PAA11263; Tue, 4 Nov 1997 15:05:03 -0800 Received: from mail.uniserve.com ([204.244.163.48]) by imag.imag.fr (8.8.5/8.8.5) with SMTP id RAA22463 for ; Tue, 4 Nov 1997 17:23:26 +0100 (MET) Received: from p1-24.van.tvs.net [204.244.158.103] by mail.uniserve.com with smtp (Exim 1.70 #1) id 0xSlk0-0005xx-00; Tue, 4 Nov 1997 08:22:08 -0800 X-Sender: iashdown@pop.uniserve.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" To: globillum@imag.fr From: iashdown@ledalite.com (Ian Ashdown) Subject: Interesting radiosity paper Message-Id: Date: Tue, 4 Nov 1997 08:22:08 -0800 Status: R --MimeMultipartBoundary Content-Type: text/plain; charset="us-ascii" For those of you who teach global illumination, there is a just- published survey paper that may be of interest: Nievergelt, Yves. 1997. "Radiosity in Illumination Engineering," UMAP Journal 18(2):167-178 (Summer). The paper provides an overview of the radiosity equation and its application to the engineering design of lighting systems, with topic headings such as "Lambertian Surfaces," "Luminous Flux," "Form Factors for Lambertian Surfaces," "Setting Up Radiosity Systems," "Solving Large Radiosity Systems," "How Southwell's Method is Used," and "Inverse Problems." As you may have surmised, it is entirely concerned with applied mathematics. I like this paper because it offers a fresh perspective from a mathematician's point of view. More important, it poses four open questions in the mathematics of global illumination that should interest motivated graduate students. (Even better, what is the relationship between radiosity systems and Ansel Adam's 1941 photograph "Moonrise, Hernandez, New Mexico?") UMAP is the Journal of Undergraduate Mathematics and its Applications. If radiosity in illumination engineering doesn't garner your attention, you might consider some of the other articles, including "Communication Games and the Canadian Constitution," "The Mathematics of Scuba Diving," and "How Does the NFL Rate Passers?" It's an interesting publication. Ian Ashdown, P. Eng. | READ THE BOOK! Research & Development Manager | Radiosity: A Programmer's Perspective Ledalite Architectural Products | Wiley & Sons 1994 Visit http://www.ledalite.com | (http://www.amazon.com) --MimeMultipartBoundary-- From owner-globillum-imag@imag.fr Thu Nov 6 18:26:07 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA12546 for ; Thu, 6 Nov 1997 18:26:06 -0800 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA28099 for ; Thu, 6 Nov 1997 18:28:40 -0800 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id SAA19117; Thu, 6 Nov 1997 18:23:26 -0800 Received: from safran.imag.fr (safran.imag.fr [129.88.42.9]) by imag.imag.fr (8.8.5/8.8.5) with ESMTP id RAA28404; Thu, 6 Nov 1997 17:08:27 +0100 (MET) Received: (from sillion@localhost) by safran.imag.fr (8.6.10/8.6.9) id RAA29644; Thu, 6 Nov 1997 17:08:18 +0100 From: Francois Sillion Message-Id: <199711061608.RAA29644@safran.imag.fr> Subject: Globillum SPAMMING fix (only read if you care) To: ajc@doc.ic.ac.uk (Adrian James Chung) Date: Thu, 6 Nov 1997 17:08:17 +0100 (MET) Cc: globillum@imag.fr (Global Illumination List) In-Reply-To: from "Adrian James Chung" at Nov 4, 97 10:24:48 am Reply-To: Francois.Sillion@imag.fr X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" Status: R --MimeMultipartBoundary Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi all, Sorry to bother you, but I wanted to re-assure you all that whenever a SPAM-like message is sent to globillum, I protest in all the ways I am aware of. In the latest case, I had the sender domain added to our local black list, and also manually removed the globillum address from the marketer's web site. I will not send such a message every time a problem happens, but be sure I do everything I can to avoid such problems. > Any comments welcome. (Perhaps better if discussed off this > forum. Make sure it doesn't resemble spam.) > > For details http://spam.abuse.net/spam/ +------------------+------------------------------------------------------+ | Francois SILLION | iMAGIS - GRAVIR/IMAG, B.P. 53, 38041 Grenoble Cedex 9| | ' | France. Tel:+33 4 76 51 43 54 - Fax:+33 4 76 63 55 80| +------------------+--------+---------------------------------------------+ | Francois.Sillion@imag.fr | http://www-imagis.imag.fr/~Francois.Sillion | +---------------------------+---------------------------------------------+ --MimeMultipartBoundary-- From owner-globillum-imag@imag.fr Sat Nov 29 00:04:32 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA20757 for ; Sat, 29 Nov 1997 00:04:32 -0800 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA12321 for ; Sat, 29 Nov 1997 00:07:03 -0800 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id AAA28220; Sat, 29 Nov 1997 00:01:44 -0800 Received: from netcomsv. (uu2news.netcom.com [163.179.3.15]) by imag.imag.fr (8.8.5/8.8.5) with SMTP id IAA05218 for ; Sat, 29 Nov 1997 08:44:56 +0100 (MET) Received: by netcomsv. (SMI-8.6/SMI-SVR4) id XAA08802; Fri, 28 Nov 1997 23:44:38 -0800 >Received: from ponfar.pdi.com by pdi.pdi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/(911001.SGI)1.4-PDI.RELAY) for <@pdi.pdi.com:globillum@imag.fr> id PAA10539; Wed, 26 Nov 1997 15:43:42 -0800 Received: from pdi.com by netcomsv.netcom.com; Fri, 28 Nov 1997 23:44 PST Received: from ponfar.pdi.com by pdi.pdi.com via ESMTP (951211.SGI.8.6.12.PATCH1502/(911001.SGI)1.4-PDI.RELAY) for <@pdi.pdi.com:globillum@imag.fr> id PAA10539; Wed, 26 Nov 1997 15:43:42 -0800 Received: by ponfar.pdi.com (940816.SGI.8.6.9/(911001.SGI)1.2-PDI) for globillum@imag.fr id PAA23986; Wed, 26 Nov 1997 15:43:42 -0800 From: wexler@pdi.com (Dan Wexler) Message-Id: <199711262343.PAA23986@ponfar.pdi.com> Subject: Quantization To: globillum@imag.fr Date: Wed, 26 Nov 1997 15:43:42 -0800 (PST) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" Status: RO --MimeMultipartBoundary Content-Type: text/plain; charset=US-ASCII What is the best way to quantize floating point RGB colors (0 to 1) into 8-bit integers? Is the answer different for different output devices? Daniel Wexler R&D Staff, Pacific Data Images --MimeMultipartBoundary-- From owner-globillum-imag@imag.fr Sat Nov 29 08:45:52 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA21032 for ; Sat, 29 Nov 1997 08:45:52 -0800 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA13556 for ; Sat, 29 Nov 1997 08:48:22 -0800 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id IAA04395; Sat, 29 Nov 1997 08:43:03 -0800 Received: from merckx.graphics.cornell.edu (MERCKX.GRAPHICS.CORNELL.EDU [128.84.247.147]) by imag.imag.fr (8.8.5/8.8.5) with SMTP id RAA24662 for ; Sat, 29 Nov 1997 17:20:09 +0100 (MET) Received: by merckx.graphics.cornell.edu (5.65/DEC-Ultrix/4.3) id AA00495; Sat, 29 Nov 1997 11:19:59 -0500 Message-Id: <9711291619.AA00495@merckx.graphics.cornell.edu> Received: by beauty.graphics.cornell.edu (1.37.109.8/16.2) id AA02933; Sat, 29 Nov 1997 11:19:57 -0500 Date: Sat, 29 Nov 1997 11:19:57 -0500 From: "Stephen H. Westin" To: wexler@pdi.com Cc: globillum@imag.fr In-Reply-To: <199711262343.PAA23986@ponfar.pdi.com> (wexler@pdi.com) Subject: Re: Quantization Reply-To: westin@graphics.cornell.edu Status: RO > What is the best way to quantize floating point RGB colors (0 to 1) > into 8-bit integers? Is the answer different for different output > devices? Well, the quantization should probably be non-linear, as the eye is more sensitive to quantization in dark areas of the image. I prefer using a gamma correction of 2.2, which then can be re-corrected for a particular output device. I would also add random dither before quantization to reduce visible quantization artifacts further. How about pixel_val = (int) ( 255.0 * pow ( float_val, 0.45 ) * drand48() ); for a start? This will o correct for a gamma of 2.2222... o scale to the range 0:255 o add 0.5 for correct rounding o add random noise in the range -0.5:0.5 There's a bit of inconsistency here, as we're assuming nonlinearity in the output device, but adding noise that's uniformly distributed. But I think it will work pretty well. From owner-globillum-imag@imag.fr Sun Nov 30 22:04:08 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA22860 for ; Sun, 30 Nov 1997 22:04:07 -0800 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA18352 for ; Sun, 30 Nov 1997 22:06:37 -0800 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id WAA23317; Sun, 30 Nov 1997 22:01:18 -0800 Received: from phong.cs.utah.edu (phong.cs.utah.edu [128.110.4.52]) by imag.imag.fr (8.8.5/8.8.5) with SMTP id GAA14802 for ; Mon, 1 Dec 1997 06:31:29 +0100 (MET) Received: (from shirley@localhost) by phong.cs.utah.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) id WAA12371 for globillum@imag.fr; Sun, 30 Nov 1997 22:30:45 -0700 From: shirley@phong.cs.utah.edu (Peter Shirley) Message-Id: <199712010530.WAA12371@phong.cs.utah.edu> Subject: conference data? To: globillum@imag.fr Date: Sun, 30 Nov 1997 22:30:45 -0700 (MST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" Status: RO --MimeMultipartBoundary Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi gang. I have updated the conference announcements on my web-page: http://www.cs.utah.edu/~shirley/ This includes the rendering workshop page (which I had a little trouble finding-- please add links to this on your own pages!). I know I am missing several workshops-- updates appreciated. Thanks, Pete /***********************************************************************/ /* */ /* Free online forms grad application */ /* http://www.cs.utah.edu/admissions-webform.html */ /* */ /* Faculty job ad */ /* http://www.cs.utah.edu/ad-faculty.html */ /* */ /***********************************************************************/ --MimeMultipartBoundary-- From owner-globillum-imag@imag.fr Mon Dec 1 11:00:32 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA23370 for ; Mon, 1 Dec 1997 11:00:31 -0800 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA20630 for ; Mon, 1 Dec 1997 11:02:59 -0800 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id KAA18603; Mon, 1 Dec 1997 10:57:37 -0800 Received: from adeskgate.autodesk.com (adeskgate.autodesk.com [198.93.152.11]) by imag.imag.fr (8.8.5/8.8.5) with ESMTP id SAA03425 for ; Mon, 1 Dec 1997 18:42:08 +0100 (MET) Received: from autodesk.autodesk.com by adeskgate.autodesk.com (8.6.12/SMI-5.3) with ESMTP id JAA28737; Mon, 1 Dec 1997 09:40:58 -0800 (PST) Received: from hqhubmu1.autodesk.com by autodesk.autodesk.com (8.6.12/4.4BSD) with ESMTP id JAA21676; Mon, 1 Dec 1997 09:40:53 -0800 Received: from ccinternet.autodesk.com (ccinternet [144.111.240.144]) by hqhubmu1.autodesk.com (8.7.5/8.7.3) with SMTP id JAA13471 for ; Mon, 1 Dec 1997 09:40:51 -0800 (PST) Received: from ccMail by ccinternet.autodesk.com (IMA Internet Exchange 2.12 Enterprise) id 002408C3; Mon, 1 Dec 1997 09:40:33 -0800 Mime-Version: 1.0 Date: Mon, 1 Dec 1997 12:37:56 -0800 Message-ID: <002408C3.4149@autodesk.com> From: eric.haines@autodesk.com (Eric Haines) Subject: Radiosity research peaks in 1994? To: globillum Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" Content-Description: cc:Mail note part Status: RO --MimeMultipartBoundary Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I just ran across an interesting resource. See the graph at: http://liinwww.ira.uka.de/bibliography/Graphics/rad.html near the bottom. It shows the raw number of references in the radiosity bibliography peaked in 1994 (for comparison, ray tracing peaks in 1990). It's also interesting to look at SIGGRAPH's comprehensive bibliography graphed in this way: 1983 has the most articles published, with other peaks (though decreasing) in 1991 and 1995 (4 year cycle? ;-> ). Eric Haines erich@acm.org --MimeMultipartBoundary-- From owner-globillum-imag@imag.fr Mon Dec 1 11:43:36 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA23454 for ; Mon, 1 Dec 1997 11:43:36 -0800 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA20701 for ; Mon, 1 Dec 1997 11:46:04 -0800 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id LAA22064; Mon, 1 Dec 1997 11:40:37 -0800 Received: from pop.uniserve.com (pop.uniserve.com [204.244.156.3]) by imag.imag.fr (8.8.5/8.8.5) with SMTP id TAA08295 for ; Mon, 1 Dec 1997 19:59:42 +0100 (MET) Received: from p3-06.van.tvs.net [204.244.158.181] by pop.uniserve.com with smtp (Exim 1.73 #1) id 0xcb49-0004dG-00; Mon, 1 Dec 1997 10:59:33 -0800 X-Sender: iashdown@pop.uniserve.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" To: globillum@imag.fr From: iashdown@ledalite.com (Ian Ashdown) Subject: Re: Radiosity research peaks in 1994? Message-Id: Date: Mon, 1 Dec 1997 10:59:33 -0800 Status: R --MimeMultipartBoundary Content-Type: text/plain; charset="us-ascii" > I just ran across an interesting resource. See the graph at: > > http://liinwww.ira.uka.de/bibliography/Graphics/rad.html > > near the bottom. It shows the raw number of references in the > radiosity bibliography peaked in 1994 (for comparison, ray tracing > peaks in 1990). It's also interesting to look at SIGGRAPH's > comprehensive bibliography graphed in this way: 1983 has the most > articles published, with other peaks (though decreasing) in 1991 and > 1995 (4 year cycle? ;-> ). > > Eric Haines > erich@acm.org > Ah, but it's the *quality* of the papers that really matters. There are still many open questions in radiative transfer/radiosity theory, and from what I have seen of the publications over the past few years, 1994 was the beginning of a trend towards investigating the deeper problems. For whatever reason, most the really interesting work is now being done in Europe, Asia and the Far East. Cornell's legacy unfortunately appears to be on the wane in North America. P.S. - the latest RADBIB97.BIB and GITHESIS.BIB bibliographies are being released later today. I managed to find only nine new references for global illumination in the past two months instead of the usual fifteen to thirty. Hmm ... Ian Ashdown, P. Eng. | READ THE BOOK! Research & Development Manager | Radiosity: A Programmer's Perspective Ledalite Architectural Products | Wiley & Sons 1994 Visit http://www.ledalite.com | (http://www.amazon.com) --MimeMultipartBoundary-- From owner-globillum-imag@imag.fr Tue Dec 2 09:23:39 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA24596 for ; Tue, 2 Dec 1997 09:23:39 -0800 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA26006 for ; Tue, 2 Dec 1997 09:26:08 -0800 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id JAA08619; Tue, 2 Dec 1997 09:20:41 -0800 Received: from pop.uniserve.com (pop.uniserve.com [204.244.156.3]) by imag.imag.fr (8.8.5/8.8.5) with SMTP id OAA04974 for ; Tue, 2 Dec 1997 14:55:47 +0100 (MET) Received: from p1-37.van.tvs.net [204.244.158.116] by pop.uniserve.com with smtp (Exim 1.73 #1) id 0xcsmi-0006TR-00; Tue, 2 Dec 1997 05:54:45 -0800 Reply-To: "Ian Ashdown" From: "Ian Ashdown" To: Subject: ANNOUNCE: Radiosity Bibliography Update (December 1997) Date: Tue, 2 Dec 1997 05:55:16 -0800 Message-ID: <01bcff29$eb452310$749ef4cc@helios> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Status: R --MimeMultipartBoundary Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit ANNOUNCE: 97/12/01 Release of RADBIB97.BIB and GITHESIS.BIB ----------------------------------------------------------- RADBIB97 is a comprehensive bibliography of radiosity and related global illumination papers, theses, articles, and books. It currently includes 1,246 references -- 9 new additions since the 97/10/01 release. This bibliography is available in BibTex format as RADBIB97.BIB (with a release date of December 1, 1997) from: http://www.ledalite.com/library-/rrt.htm ftp://ftp.ledalite.com/pub/radbib97.bib Also available from this site is an abridged version of RADBIB97.BIB called GITHESIS.BIB. This bibliography includes 149 references to radiosity and global illumination theses -- 4 new additions since the 97/10/01 release. As always, it is time-consuming and sometimes difficult to track down conference papers and theses on radiosity and global illumination. If you know of a relevant reference that is not included in these bibliographies, please let us know so that we can include it in the next release. Partial financial support for the maintenance of these bibliographies has been provided by the ACM SIGGRAPH Special Projects. -- Ian Ashdown, P. Eng. | READ THE BOOK! Research & Development Manager | Radiosity: A Programmer's Perspective Ledalite Architectural Products | Wiley & Sons 1994 http://www.ledalite.com | http://www.amazon.com --MimeMultipartBoundary-- From owner-globillum-imag@imag.fr Tue Dec 2 12:28:57 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA25005 for ; Tue, 2 Dec 1997 12:28:57 -0800 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA27075 for ; Tue, 2 Dec 1997 12:31:27 -0800 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id MAA22835; Tue, 2 Dec 1997 12:25:53 -0800 Received: from relay2.mail.uk.psi.net (relay1.mail.uk.psi.net [154.32.105.6]) by imag.imag.fr (8.8.5/8.8.5) with ESMTP id RAA17914 for ; Tue, 2 Dec 1997 17:40:10 +0100 (MET) Received: from elvis.lightwork (lightwork.co.uk [195.152.206.2]) by relay2.mail.uk.psi.net (8.8.5/) with ESMTP id QAA05377 for ; Tue, 2 Dec 1997 16:40:08 GMT Received: by elvis.lightwork with Internet Mail Service (5.0.1457.3) id ; Tue, 2 Dec 1997 16:39:20 -0000 Message-ID: <8815647C7041D111A3010060B06BE1C00B064E@elvis.lightwork> From: Tim Hammond To: globillum@imag.fr Cc: self Subject: Query regarding probability sampling Date: Tue, 2 Dec 1997 16:39:19 -0000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" Status: R --MimeMultipartBoundary Content-Type: text/plain Hi, I would be grateful if anyone on the list could provide me with any useful suggestions on the following: I'm currently working on code designed to shoot photons at random into a scene from a variety of light sources. This will involve a considerable amount of random sampling. For example, given a set of lights we need to determine at random which light to shoot a photon from. Then if the light source is made up of multiple polygons, which polygon do we shoot from and whereabouts on the polygon. Finally what will the initial direction of the photon be? The solution we intend to implement involves a certain amount of preprocessing for each test so that we end up with a probability distribution that can be quickly sampled to return a random selection (a light say) during shooting of photons. The goal is a generic process which, when given a set of N outcomes and N weights generates a data structure. This data structure will then need to be interrogated by a function which takes a random float in the range [0,1) and as quickly as possible returns one of the outcomes. The probability of returning any given outcome is proportional to the weight assigned to that outcome (for example for lights we would assign weights according to the output power of each light). Currently I am thinking about implementing the data structure produced by pre-processing as either a lookup table or a binary tree. The lookup table approach is very fast, but more memory intensive, whilst the binary tree approach would use less memory, but be slower. To clarify the problem, here is a very simple example. Take a scene with 5 light sources with respective powers of 50W 10W 5W 20W and 15W. In our current binary tree approach we would divide the region [0,1) as follows: Values in the range [0, 0.5) represent choosing the first light, values in the range [0.5, 0.6) the second, values in the range [0.6, 0.65) the third, values in the range [0.65, 0.85) the fourth and values in the range [0.85, 1) the fifth To then actually convert from a random number in the range [0,1) to a light, the lights could be arranged in a binary tree something like the following: [P<0.65] 0 [P>=0.65] / \ [P<0.6] O O [P>=0.85] / \ / \ O 3 4 5 / \ 1 2 At the first level of the tree, testing of whether the random value P is < or >= 0.65 (chosen so that roughly the same numbers of lights fall on each side) takes us down either the left or right branch. Further tests then occur at each level, for example P is < or >= 0.6 for the left-hand branch, until we arrive at a light. In a lookup table approach we have to subdivide the range [0,1) into a set of bins, the size of which is determined by the relative size of the smallest weight in the list of possible outcomes. Given the number of bins we can immediately convert a random float in the range [0,1) into an array index which points at one of the outcomes. As I said before this approach is very fast, but uses more memory, especially in cases where there is a large relative difference in weights between the most likely and least likely outcomes (we are forced to use a lot of small bins in order to include every possible outcome). I am keen to hear from anyone who has experience in this area or anyone who can suggest improvements to the solutions I have outlined above, or indeed any better solutions. Many thanks, Tim. Tim Hammond, Software Engineer, LightWork Design Ltd. tim.hammond@lightwork.co.uk http://www.lightwork.com Tel:+44 (0)114 266 8404 ext 242 Fax:+44 (0)114 266 1383 --MimeMultipartBoundary-- From owner-globillum-imag@imag.fr Tue Dec 2 13:51:05 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA25262 for ; Tue, 2 Dec 1997 13:51:05 -0800 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA27607 for ; Tue, 2 Dec 1997 13:53:34 -0800 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id NAA28144; Tue, 2 Dec 1997 13:48:13 -0800 Received: from teapot.llnl.gov (nelson@teapot.llnl.gov [128.115.19.100]) by imag.imag.fr (8.8.5/8.8.5) with SMTP id WAA03999 for ; Tue, 2 Dec 1997 22:20:27 +0100 (MET) Received: by teapot.llnl.gov (951211.SGI.8.6.12.PATCH1502/951211.SGI.AUTO) id NAA13829; Tue, 2 Dec 1997 13:17:47 -0800 From: "Nelson L. Max" Message-Id: <9712021317.ZM13827@teapot.llnl.gov> Date: Tue, 2 Dec 1997 13:17:45 -0800 In-Reply-To: Tim Hammond "Query regarding probability sampling" (Dec 2, 4:39pm) References: <8815647C7041D111A3010060B06BE1C00B064E@elvis.lightwork> Reply-to: max2@llnl.gov X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: Tim Hammond , globillum@imag.fr Subject: Re: Query regarding probability sampling Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" Status: R --MimeMultipartBoundary Content-Type: text/plain; charset=us-ascii If you want complete accuracy in the lookup table, you need to make all the weights be rational numbers, and make the size of the table the common denominator (the least common multiple of all the denominators when each fraction is in "reduced" form, with no common factors in the numerator and denominator). I think this is worse than you indicated. How about a compromise between the two methods: let a smaller table point to a (possibly internal) node of the tree, at which to begin the search. -- email: max2@llnl.gov Nelson Max, Mail Stop L-307 http://www.llnl.gov/graphics Lawrence Livermore National Laboratory phone (510) 422-4074 7000 East Avenue fax (510) 423-4139 Livermore, CA 94550, USA --MimeMultipartBoundary-- From owner-globillum-imag@imag.fr Tue Dec 2 15:26:45 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA25423 for ; Tue, 2 Dec 1997 15:26:45 -0800 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA28000 for ; Tue, 2 Dec 1997 15:29:15 -0800 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id PAA05081; Tue, 2 Dec 1997 15:23:54 -0800 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by imag.imag.fr (8.8.5/8.8.5) with SMTP id XAA07116 for ; Tue, 2 Dec 1997 23:31:40 +0100 (MET) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id OAA17266 for <@sgi.engr.sgi.com:globillum@imag.fr>; Tue, 2 Dec 1997 14:31:37 -0800 env-from (bwade@sgi.com) Received: from amie.engr.sgi.com (amie.engr.sgi.com [150.166.55.164]) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id OAA11546 for <@cthulhu.engr.sgi.com:globillum@imag.fr>; Tue, 2 Dec 1997 14:31:37 -0800 Received: from pc-amie (pc-amie.engr.sgi.com [150.166.55.165]) by amie.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via SMTP id OAA03092 for ; Tue, 2 Dec 1997 14:31:33 -0800 Message-Id: <3.0.5.32.19971202143133.00a4a480@amie.engr.sgi.com> X-Sender: bwade@amie.engr.sgi.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 02 Dec 1997 14:31:33 -0800 To: globillum@imag.fr From: Bretton Wade Subject: Re: Query regarding probability sampling In-Reply-To: <8815647C7041D111A3010060B06BE1C00B064E@elvis.lightwork> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" Status: R --MimeMultipartBoundary Content-Type: text/plain; charset="us-ascii" >an array index which points at one of the outcomes. As I said before >this approach is very fast, but uses more memory, especially in cases >where there is a large relative difference in weights between the most >likely and least likely outcomes (we are forced to use a lot of small >bins in order to include every possible outcome). I would go with the table approach. This is grossly simplified, but the table grows linearly with the number of lights if the light source power values are all approximately the same order of magnitude (This statement is clearly subject to verification). Can you characterize the typical scene? If you were going to have lots of scenes with 1000 suns and 1 flashlight, the table might not be a reasonable approach. If you had 100 light sources at 100W and one light source at 1W, you would be using approximately 40Kb (assuming the table stored a 4 byte pointer). In a commercial, high end rendering product, I would consider even 100 times this requirement to be modest if the gain is significant, especially if the model is already so complex as to include 101 distinct light sources. >If you want complete accuracy in the lookup table, you need to make all the >weights be rational numbers, and make the size of the table the common >denominator (the least common multiple of all the denominators when each >fraction is in "reduced" form, with no common factors in the numerator and >denominator). I think this is worse than you indicated. Would it be reasonable to simply reject sources which are extremely unlikely to contribute? In the example above, eliminating the 1W light source (with an occurrence probability of 1e-4) reduces a 40Kb table to 400 bytes. Doing this clearly helps to reduce the table size, but it is easy to imagine a scene with a sun and a flashlight where the point of interest is illuminated only by the flashlight. Perhaps a very coarse pre-process which propogates importance from the viewpoint(s) would be useful. -- Bretton Wade (bwade@sgi.com) Cosmo Software - A Silicon Graphics Company --MimeMultipartBoundary-- From owner-globillum-imag@imag.fr Tue Dec 2 18:17:05 1997 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA25775 for ; Tue, 2 Dec 1997 18:17:05 -0800 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA28863 for ; Tue, 2 Dec 1997 18:19:34 -0800 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id SAA14870; Tue, 2 Dec 1997 18:14:13 -0800 Received: from grande.dcc.unicamp.br (dcc.unicamp.br [143.106.1.11]) by imag.imag.fr (8.8.5/8.8.5) with ESMTP id CAA14437 for ; Wed, 3 Dec 1997 02:55:58 +0100 (MET) Received: from amazonas.dcc.unicamp.br (amazonas3 [143.106.7.11]) by grande.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id XAA10596; Tue, 2 Dec 1997 23:47:16 -0200 (EDT) Received: from coruja.dcc.unicamp.br (coruja [143.106.24.80]) by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id XAA06695; Tue, 2 Dec 1997 23:47:13 -0200 (EDT) Received: (from stolfi@localhost) by coruja.dcc.unicamp.br (8.8.5/8.8.5) id XAA07543; Tue, 2 Dec 1997 23:47:13 -0200 (EDT) Date: Tue, 2 Dec 1997 23:47:13 -0200 (EDT) Message-Id: <199712030147.XAA07543@coruja.dcc.unicamp.br> From: Jorge Stolfi To: Tim Hammond Cc: globillum@imag.fr Subject: Re: Query regarding probability sampling MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: multipart/mixed; boundary="MimeMultipartBoundary" In-Reply-To: <8815647C7041D111A3010060B06BE1C00B064E@elvis.lightwork> References: <8815647C7041D111A3010060B06BE1C00B064E@elvis.lightwork> Reply-To: stolfi@dcc.unicamp.br Status: R --MimeMultipartBoundary Content-Type: text/plain; charset=iso-8859-1 > To then actually convert from a random number in the range [0,1) to a > light, the lights could be arranged in a binary tree something like the > following: > > > [P<0.65] 0 [P>=0.65] > / \ > [P<0.6] O O [P>=0.85] > / \ / \ > O 3 4 5 > / \ > 1 2 > > At the first level of the tree, testing of whether the random value P is > < or >= 0.65 (chosen so that roughly the same numbers of lights fall on > each side) takes us down either the left or right branch. Further tests > then occur at each level, for example P is < or >= 0.6 for the left-hand > branch, until we arrive at a light. > > In a lookup table approach we have to subdivide the range [0,1) into a > set of bins, the size of which is determined by the relative size of the > smallest weight in the list of possible outcomes. Given the number of > bins we can immediately convert a random float in the range [0,1) into > an array index which points at one of the outcomes. You can also precompute a vector s[i] = sum{ p[j] : j < i }, where p[j] is the desired probability of chosing item j. Then you generate a random P in [0 _ 1], and use binary search on s to locate an i such that s[i] < P < s[i+i]. This is simpler than building a binary tree, and at least as fast if coded with care. Moreover, if you expect a large number of items with similar probabilities, you can use linear interpolation (i.e. round(P*n) \pm K) to guess an initial range for the binary search. --stolfi --MimeMultipartBoundary-- From image-based-rendering-owner@austin.cs.unc.edu Sun Dec 7 21:58:34 1997 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA02764 for ; Sun, 7 Dec 1997 21:58:29 -0800 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id VAA27973 for <@sgi.engr.sgi.com:greg@pink.lbl.gov>; Sun, 7 Dec 1997 21:55:58 -0800 env-from (image-based-rendering-owner@austin.cs.unc.edu) Received: from radiate.engr.sgi.com (radiate.engr.sgi.com [192.26.72.11]) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id VAA23118 for <@cthulhu.engr.sgi.com:greg@pink.lbl.gov>; Sun, 7 Dec 1997 21:55:57 -0800 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by radiate.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id VAA17798 for ; Sun, 7 Dec 1997 21:55:52 -0800 Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id VAA22984; Sun, 7 Dec 1997 21:54:35 -0800 Received: from austin.cs.unc.edu (austin.cs.unc.edu [152.2.128.87]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id VAA27831; Sun, 7 Dec 1997 21:54:32 -0800 env-from (image-based-rendering-owner@austin.cs.unc.edu) Received: (from majordom@localhost) by austin.cs.unc.edu (8.8.8/8.8.8) id AAA16174 for image-based-rendering-outgoing; Mon, 8 Dec 1997 00:27:41 -0500 (EST) X-Authentication-Warning: austin.cs.unc.edu: majordom set sender to owner-image-based-rendering@cs.unc.edu using -f Received: from pop.uniserve.com (pop.uniserve.com [204.244.156.3]) by austin.cs.unc.edu (8.8.8/8.8.8) with SMTP id AAA16169 for ; Mon, 8 Dec 1997 00:27:37 -0500 (EST) Received: from p5-47.van.tvs.net [204.244.163.158] by pop.uniserve.com with smtp (Exim 1.73 #1) id 0xeviz-0000LQ-00; Sun, 7 Dec 1997 21:27:22 -0800 Reply-To: "Ian Ashdown" From: "Ian Ashdown" To: Subject: Image-Based Rendering Bibliography Date: Sun, 7 Dec 1997 21:27:21 -0800 Message-ID: <01bd0399$f5426250$0100007f@helios> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000E_01BD0356.E71F2250" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-image-based-rendering@cs.unc.edu Precedence: bulk Status: R This is a multi-part message in MIME format. ------=_NextPart_000_000E_01BD0356.E71F2250 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Fellow IBR colleagues: Attached is the first release of the Image-Based Rendering Bibliography, IBR.BIB. There are currently 55 references in the bibliography -- more will be added as we continue to research the literature. IBR.BIB will be hosted by http://www.ledalite.com, and future releases will be announced (not e-mailed) as they become available. Funding for the ongoing maintenance of this bibliography is provided by byHeart Consultants Limited (West Vancouver, BC) and an ACM SIGGRAPH Special Projects grant. Ian Ashdown, P. Eng. | READ THE BOOK! Research & Development Manager | Radiosity: A Programmer's Perspective Ledalite Architectural Products | Wiley & Sons 1994 http://www.ledalite.com | http://www.amazon.com ------=_NextPart_000_000E_01BD0356.E71F2250 Content-Type: application/octet-stream; name="ibr.bib" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="ibr.bib" \Sort{ Mode{on} Collation{mixed} SortTypeOrder{key,pattern,name} NameOrder{ascending} Key{{author,editor}} KeyOrder{ascending,nulls first} Pattern{author+editor: "doron"} PatternOrder{last} StringSort{ascending} } % IBR.BIB - Image-Based Rendering Bibliography % -------------------------------------------- % % Prepared by % % Ian Ashdown, VP Engineering % byHeart Consultants Limited % byheart@acm.org % % Date: December 1, 1997 % % This bibliography includes references to original papers, articles, = and % books on image-based rendering algorithms. % % Funding for the ongoing maintenance of this bibliography is provided = by % byHeart Consultants Limited (West Vancouver, BC) and an ACM SIGGRAPH % Special Projects grant. @INBOOK{Adelson91-PFEEV, author =3D {E. H. Adelson and J. R. Bergen}, editor =3D {M. Landy and J. A. Movshon}, year =3D 1991, title =3D {Computational Models of Visual Processing}, chapter =3D {1 (The Plenoptic Function and the Elements of Early = Vision)}, publisher =3D {MIT Press}, address =3D {Cambridge, MA} } @INPROCEEDINGS{Arvo94-IJPOC*, author =3D {James Arvo}, year =3D 1994, title =3D {The {Irradiance} {Jacobian} for {Partially} {Occluded} = {Polyhedral} {Sources}}, booktitle =3D {Computer Graphics Proceedings, Annual Conference = Series, 1994 (ACM SIGGRAPH '94 Proceedings)}, pages =3D {343--350}, keywords =3D {irradiance gradient, irradiance Jacobian, isolux = contours, light field, mesh generation, vector irradiance} } @MISC{Ashdown93-NFPMA*, author =3D {Ian Ashdown}, month =3D {October 12}, year =3D 1993, title =3D {Near-Field Photometric Method and Apparatus}, note =3D {Ledalite Architectural Products Inc.}, howpublished =3D {United State Patent 5,253,036}, keywords =3D {Near-Field Photometry, Goniophotometry, Light Fields, Illuminance Prediction} } @ARTICLE{Ashdown93-NFPNA*, author =3D {Ian Ashdown}, month =3D {Winter}, year =3D 1993, title =3D {Near-{Field} {Photometry}: {A} {New} {Approach}}, journal =3D {Journal of the Illuminating Engineering Society}, volume =3D 22, number =3D 1, pages =3D {163--180}, note =3D {Available from http://www.ledalite.com}, keywords =3D {Photometry, Light Fields, Hemicubes} } @INPROCEEDINGS{Ashdown95-NFPMM*, author =3D {Ian Ashdown}, year =3D 1995, title =3D {Near-{Field} {Photometry}: {Measuring} and {Modeling} = {Complex} 3-{D} {Light} {Sources}}, booktitle =3D {ACM SIGGRAPH '95 Course Notes - Realistic Input for = Realistic Images}, chapter =3D 3, pages =3D {1--15}, note =3D {Available from http://www.ledalite.com}, keywords =3D {Complex Light Sources, Photometry, Hemicubes, Light = Fields} } @INPROCEEDINGS{Ashdown97-MNFPP*, author =3D {Ian Ashdown and Ron Rykowski}, month =3D {August}, year =3D 1997, title =3D {Making Near-Field Photometry Practical}, booktitle =3D {1997 IESNA Conference Proceedings}, pages =3D {368-389}, note =3D {Available from http://www.ledalite.com}, address =3D {Seattle, WA}, organization =3D {Illuminating Engineering Society of North America}, keywords =3D {Data Compression, Light Field, Luminance Field = Photometry, Sequential Transform, Wavelets} } @ARTICLE{Ashdown98-MNFPP*, author =3D {Ian Ashdown and Ron Rykowski}, month =3D {Winter}, year =3D 1998, title =3D {Making Near-Field Photometry Practical}, journal =3D {Journal of the Illuminating Engineering Society}, volume =3D 27, number =3D 1, note =3D {Available from http://www.ledalite.com}, keywords =3D {Data Compression, Light Field, Luminance Field = Photometry, Sequential Transform, Wavelets} } @INPROCEEDINGS{Belhumeur96-WSIOU, author =3D {Peter N. Belhumeur and David J. Kriegman}, month =3D {June}, year =3D 1996, title =3D {What Is the Set of Images of an Object Under All Possible = Lighting Conditions?}, booktitle =3D {Proceedings of the IEEE Conference on Computer Vision = and Pattern Recognition} } @INPROCEEDINGS{Benton82-SHS, author =3D {S. Benton}, year =3D 1983, title =3D {Survey of Holographic Stereograms}, booktitle =3D {Processing and Display of Three-Dimensional Data}, volume =3D 367, pages =3D {15--22}, publisher =3D {SPIE - The International Society for Optical = Engineering}, address =3D {Bellingham, WA} } @ARTICLE{Bolles87-EPIAA, author =3D {R. C. Bolles and H. H. Baker and D. H. Marimont}, year =3D 1987, title =3D {Epipolar-Plane Image Analysis: An Approach to Determine = Structure from Motion}, journal =3D {International Journal of Computer Vision}, volume =3D 1, number =3D 7, pages =3D {7--55} } @INPROCEEDINGS{Bourque97-ACIBV, author =3D {E. Bourque and G. Dudek}, month =3D {October}, year =3D 1997, title =3D {Automatic Creation of Image-Based Virtual Reality}, booktitle =3D {Sensor Fusion and Decentralized Control in Autonomous = Robotic Systems}, volume =3D 3209, pages =3D {292--303}, note =3D {ISBN 0819426415}, publisher =3D {SPIE - The International Society for Optical = Engineering}, address =3D {Bellingham, WA} } @INPROCEEDINGS{Chen93-VIIS*, author =3D {Shenchang Eric Chen and Lance Williams}, year =3D 1993, title =3D {View Interpolation for Image Synthesis}, booktitle =3D {Computer Graphics Proceedings, Annual Conference Series = (Proc. SIGGRAPH '93)}, pages =3D {279--288} } @MISC{Chen95-CPIMS, author =3D {Shenchang Eric Chen and G. S. P. Miller}, month =3D {March 7}, year =3D 1995, title =3D {Cylindrical to Planar Image Mapping Using Scanline = Coherence}, howpublished =3D {United States Patent 5,396,583} } @INPROCEEDINGS{Chen95-QVIBA*, author =3D {Shenchang Eric Chen}, year =3D 1995, title =3D {QuickTime VR - An Image-Based Approach to Virtual = Environment Navigation}, booktitle =3D {Computer Graphics Proceedings, Annual Conference Series = (Proc. SIGGRAPH '95)}, pages =3D {29--38} } @ARTICLE{Chevrier97-VITTA*, author =3D {C. Chevrier}, year =3D 1997, title =3D {A View Interpolation Technique Taking Into Account Diffuse = and Specular Inter-Reflections}, journal =3D {Visual Computer}, volume =3D 13, number =3D 7, pages =3D {330--341} } @INPROCEEDINGS{Darsa97-NSEIS, author =3D {L. Darsa and B. C. Silva and A. Varshney}, month =3D {April}, year =3D 1997, title =3D {Navigating Static Environments Using Image-Space = Simplification and Morphing}, booktitle =3D {Proc. 1997 Symposium on Interactive 3D Graphics}, pages =3D {25--34} } @INPROCEEDINGS{Debevec96-MRAPH*, author =3D {P. E. Debevec and C. J. Taylor and J. Malik}, year =3D 1996, title =3D {Modeling and Rendering Architecture From Photographs: A = Hybrid Geometry- and Image-Based Approach}, booktitle =3D {Computer Graphics Proceedings, Annual Conference Series = (Proc. SIGGRAPH ' 96)}, pages =3D {11--20} } @TECHREPORT{Evgeniou96-IBRAT, author =3D {T. Evgeniou}, year =3D 1996, title =3D {Image-Based Rendering Using Algebraic Techniques}, number =3D {Technical Report A. I. Memo 1592}, institution =3D {Massachusetts Institute of Technology} } @TECHREPORT{Faugeras93-WCTIT*, author =3D {Olivier Faugeras and Luc Robert}, month =3D {July}, year =3D 1993, title =3D {What Can Two Images Tell Us About a Third One?}, number =3D {Technical Report RR-2018}, note =3D {Available fromhttp:// www.inria.fr}, institution =3D {INRIA - The French Institute for Research in Computer = Science and Control} } @TECHREPORT{Faugeras95-TDRUS*, author =3D {Olivier Faugeras and Stephane Laveau and Luc Robert and = Gabriella Csurka and Cyril Zeller}, month =3D {June}, year =3D 1995, title =3D {3-D Reconstruction of Urban Scenes from Sequences of = Images}, number =3D {Technical Report RR-2572}, note =3D {Available from http://www.inria.fr}, institution =3D {INRIA - The French Institute for Research in Computer = Science and Control} } @TECHREPORT{Faugeras97-NMEPG*, author =3D {Olivier Faugeras and T. Papadopoulo}, month =3D {July}, year =3D 1997, title =3D {A Nonlinear Method for Estimating the Projective Geometry = of Three Views}, number =3D {Technical Report RR-3221}, note =3D {Available from http://www.inria.fr}, institution =3D {INRIA - The French Institute for Research in Computer = Science and Control} } @ARTICLE{Fua96-TAIBG, author =3D {P. Fua and Y. G. Leclerc}, year =3D 1996, title =3D {Taking Advantage of Image-Based and Geometry-Based = Constraints to Recover 3-D Surfaces}, journal =3D {CVIU: Computer Vision and Image Understanding}, volume =3D 64, number =3D 1, pages =3D 111 } @ARTICLE{Gershun39-SPLF*, author =3D {A. Gershun}, year =3D 1939, title =3D {Svetovoe {Pole} ({The} {Light} {Field}, in {English})}, journal =3D {Journal of Mathematics and Physics}, volume =3D {XVIII}, pages =3D {51--151}, publisher =3D {Massachusetts Institute of Technology}, keywords =3D {photometry, radiometry, light fields, vector flux} } @INPROCEEDINGS{Gortler96-L*, author =3D {Steven J. Gortler and Radek Grzeszczuk and Richard = Szeliski and Michael F. Cohen}, year =3D 1996, title =3D {The Lumigraph}, booktitle =3D {Computer Graphics Proceedings, Annual Conference Series = (Proc. SIGGRAPH '96)}, pages =3D {43--54} } @MASTERSTHESIS{Greger96-IV*, author =3D {Gene S. Greger}, month =3D {August}, year =3D 1996, title =3D {The Irradiance Volume}, address =3D {Ithaca, NY}, school =3D {Cornell University}, keywords =3D {Irradiance Volume, Light Fields, Global Illumination} } @INPROCEEDINGS{Gu97-PGTPP*, author =3D {Xianfeng Gu and Steven J. Gortler and Michael F. Cohen}, editor =3D {J. Dorsey and Ph. Slusallek}, year =3D 1997, title =3D {Polyhedral Geometry and the Two-Plane Parameterization}, booktitle =3D {Rendering Techniques '97 (Proc. Eighth Eurographics = Workshop on Rendering)}, pages =3D {1--12}, publisher =3D {Springer Wien}, address =3D {New York, NY} } @INPROCEEDINGS{Halle94-HSDIS, author =3D {M. W. Halle}, year =3D 1994, title =3D {Holographic Stereograms as Discrete Imaging Systems}, booktitle =3D {Practical Holography VIII}, volume =3D 2176, publisher =3D {SPIE - The International Society for Optical = Engineering}, address =3D {Bellingham, WA} } @ARTICLE{Hausner97-MELV*, author =3D {Alejo Hausner}, month =3D {January-March}, year =3D 1997, title =3D {Multiple Expansion of the Light Vector}, journal =3D {IEEE Transactions on Visualization}, volume =3D 3, number =3D 1, pages =3D {12--22}, keywords =3D {Light Field, Area Light Source, Spherical Harmonics} } @INPROCEEDINGS{Hlavac96-ASRVI*, author =3D {V. Hlavac and A. Leonardis and T. Werner}, year =3D 1996, title =3D {Automatic Selection of Reference Views for Image-Based = Scene Representations}, booktitle =3D {Lecture Notes in Computer Science}, pages =3D {526--535}, note =3D {Proceedings of European Conference on Computer Vision '96 = (ECCV '96)}, publisher =3D {Springer Verlag}, address =3D {New York, NY} } @INPROCEEDINGS{Hsu94-VIUEP, author =3D {R. Hsu and K. Kodama and H. Harashima}, month =3D {November}, year =3D 1994, title =3D {View Interpolation Using Epipolar Plane Images}, booktitle =3D {Proc. First IEEE International Conference on Image = Processing}, volume =3D 2, organization =3D {745--749} } @INPROCEEDINGS{Ihm97-RSLF*, author =3D {Insung Ihm and Sanghoon Park and Rae Kyoung Lee}, year =3D 1997, title =3D {Rendering of Spherical Light Fields}, booktitle =3D {Proceedings of Pacific Graphics '97} } @INPROCEEDINGS{Katayama95-VISDI, author =3D {A. Katayama and K. Tanaka and T. Oshino and H. Tamura}, title =3D {A View-Independent Stereoscopic Display Using Interpolation = of Multi-Viewpoint Images}, booktitle =3D {Stereoscopic Displays and Virtual Reality Systems II}, volume =3D 2409, pages =3D {11--20}, publisher =3D {SPIE - The International Society for Optical = Engineering}, address =3D {Bellingham, WA} } @ARTICLE{Koenderink80-PIRSS, author =3D {J. J. Koenderink and A. J. Van Doorn}, month =3D {July}, year =3D 1980, title =3D {Photometric {Invariants} {Related} to {Solid} {Shape}}, journal =3D {Optica Acta}, volume =3D 27, number =3D 7, pages =3D {981--996}, keywords =3D {photometric invariants, isophotes, light fields} } @ARTICLE{Koenderink83-GMGMT, author =3D {J. J. Koenderink and A. J. Van Doorn}, month =3D {June}, year =3D 1983, title =3D {Geometrical {Modes} as a {General} {Method} to {Treat} = {Diffuse} {Interreflections} in {Radiometry}}, journal =3D {Journal of the Optical Society of America}, volume =3D 73, number =3D 6, pages =3D {843--850}, keywords =3D {interreflections, Lambertian surfaces, photometric = modes, light fields, vector flux} } @ARTICLE{Koenderink93-ICPGS, author =3D {J. J. Koenderink and A. J. Van Doorn}, month =3D {May}, year =3D 1993, title =3D {Illuminance {Critical} {Points} on {Generic} {Smooth} = {Surfaces}}, journal =3D {Journal of the Optical Society of America Series A}, volume =3D 10, number =3D 5, pages =3D {844--854}, keywords =3D {Lambertian surfaces, illuminance, light fields, vector = flux} } @PHDTHESIS{Langer94-SCRM, author =3D {Ira Michael Samuel Langer}, year =3D 1994, title =3D {Shading Computations on the Radiation Manifold}, school =3D {McGill University}, keywords =3D {Shape-from-Shading, Global Illumination, Light Field} } @TECHREPORT{Laveau94a-TDSRC*, author =3D {Stephane Laveau and Olivier Faugeras}, month =3D {February}, year =3D 1994, title =3D {3-D Scene Representation as a Collection of Images}, number =3D {Technical Report RR-2205}, note =3D {Available from http:www.inria.fr}, institution =3D {INRIA - The French Institute for Research in Computer = Science and Control} } @INPROCEEDINGS{Laveau94b-TDSRC, author =3D {Stephane Laveau and Olivier Faugeras}, month =3D {October}, year =3D 1994, title =3D {3-D Scene Representation as a Collection of Images}, booktitle =3D {Proceedings of the Twelfth International Conference on = Pattern Recognition}, pages =3D {689--691}, address =3D {Jerusalem, Israel} } @ARTICLE{Levin71-PCLCA*, author =3D {Robert E. Levin}, year =3D 1971, title =3D {Photometric Charactertistics of Light Controlling = Apparatus}, journal =3D {Illuminating Engineering}, volume =3D 66, number =3D 4, pages =3D {205--215} } @INPROCEEDINGS{Levoy96-LFR*, author =3D {Marc Levoy and Pat Hanrahan}, year =3D 1996, title =3D {Light Field Rendering}, booktitle =3D {Computer Graphics Proceedings, Annual Conference Series = (Proc. SIGGRAPH '96)}, pages =3D {31--42} } @INPROCEEDINGS{McMillan95-PMIBR*, author =3D {Leonard McMillan and Gary Bishop}, year =3D 1995, title =3D {Plenoptic Modeling: An Image-Based Rendering System}, booktitle =3D {Computer Graphics Proceedings, Annual Conference Series = (Proc. SIGGRAPH '95)}, pages =3D {39--46} } @PHDTHESIS{McMillan97-IBATD*, author =3D {Leonard McMillan}, year =3D 1997, title =3D {An Image-Based Approach to Three-Dimensional Computer = Graphics}, number =3D {Technical Report TR97-013}, address =3D {Chapel Hill, North Carolina}, school =3D {Department of Computer Science, University of North = Carolina at Chapel Hill} } @BOOK{Moon81-PF*, author =3D {Parry Moon and Domina Eberle Spencer}, year =3D 1981, title =3D {The {Photic} {Field}}, publisher =3D {MIT Press}, address =3D {Cambridge, MA}, keywords =3D {radiometry, photometry, light fields, vector flux} } @INPROCEEDINGS{Nimeroff94-ERNIE*, author =3D {Jeffry S. Nimeroff and Eero Simoncelli and Julie Dorsey}, month =3D {June}, year =3D 1994, title =3D {Efficient Re-Rendering of Naturally Illuminated = Environments}, booktitle =3D {Fifth Eurographics Workshop on Rendering}, pages =3D {359--373}, address =3D {Darmstadt, Germany} } @INPROCEEDINGS{Pulli97-VBRVR*, author =3D {Kari Pulli and Michael Cohen and Tom Duchamp and Hugues = Hoppe and Linda Shapiro and Werner Stuetzle}, editor =3D {J. Dorsey and Ph. Slusallek}, month =3D {June}, year =3D 1997, title =3D {View-Based Rendering: Visualizing Real Objects from Scanned = Range and Color Data}, booktitle =3D {Rendering Techniques '97 (Proc. Eighth Eurographics = Workshop on Rendering)}, pages =3D {23--34}, publisher =3D {Springer wien} } @INPROCEEDINGS{Seitz95-PVVSI*, author =3D {Steven M. Seitz and C. R. Dyer}, month =3D {June}, year =3D 1995, title =3D {Physically-Valid View Synthesis by Image Interpolation}, booktitle =3D {IEEE Computer Society Workshop: Representation of = Visual Scenes}, pages =3D {18--27}, publisher =3D {IEEE Computer Society Press}, address =3D {Los Alamitos, CA} } @TECHREPORT{Seitz96-TIBSR, author =3D {Steven M. Seitz}, year =3D 1996, title =3D {Toward Image-Based Scene Representation Using View = Morphing}, institution =3D {Computer Sciences Department, University of = Wisconsin-Madison} } @INPROCEEDINGS{Szeliski95-DMVSR*, author =3D {Richard Szeliski and Sing Bing Kang}, month =3D {June}, year =3D 1995, title =3D {Direct Methods for Visual Scene Reconstruction}, booktitle =3D {IEEE Computer Society Workshop: Representations of = Visual Scenes}, publisher =3D {IEEE Computer Society Press}, address =3D {Los Alamitos, CA} } @PHDTHESIS{Thornton96-AIBTD, author =3D {Kenneth B. Thornton}, year =3D 1996, title =3D {Accurate Image-Based 3D Object Registration and = Reconstruction}, address =3D {Seattle, WA}, school =3D {University of Washington} } @INPROCEEDINGS{Werner95-RRWO, author =3D {T. Werner and R. D. Hersch and V. Hlavac}, month =3D {June}, year =3D 1995, title =3D {Rendering Real-World Objects Using View Interpolation}, booktitle =3D {Proceedings of the Fifth International Conference on = Computer Vision}, pages =3D {957--962}, publisher =3D {IEEE Press} } @INPROCEEDINGS{Werner96-CRVIB*, author =3D {T. Werner and V. Hlavac and A. Leonardis and T. Pajdla}, year =3D 1996, title =3D {Choosing Reference Views for Image-Based Representation}, booktitle =3D {Lecture Notes in Computer Science}, volume =3D 1175, pages =3D {459--466}, note =3D {Proceedings of SOFSEM '96}, publisher =3D {Springer Verlag}, address =3D {New York, NY} } @INPROCEEDINGS{Wong97-IBRCI*, author =3D {Tien-Tsin Wong and Pheng-Ann Heng and Siu-Hang Or and = Wai-Yin Ng}, editor =3D {J. Dorsey and Ph. Slusallek}, month =3D {June}, year =3D 1997, title =3D {Image-Based Rendering with Controllable Illumination}, booktitle =3D {Rendering Techniques '97 (Proc. Eighth Eurographics = Workshop on Rendering)}, pages =3D {13--22}, publisher =3D {Springer Wien}, address =3D {New York, NY} } @INPROCEEDINGS{Wong97-IIBO*, author =3D {Tien-Tsin Wong and Pheng-Ann Heng and Siu-Hang Or and = Wai-Yin Ng}, year =3D 1997, title =3D {Illuminating Image-Based Objects}, booktitle =3D {Proceedings of Pacific Graphics '97} } @INPROCEEDINGS{Xiong97-CIBVR, author =3D {Y. Xiong and K. Turkowski}, year =3D 1997, title =3D {Created Image-Based VR Using a Self-Calibrating Fisheye = Lens}, booktitle =3D {Proceedings of the IEEE Computer Society Conference on = Pattern Recognition and Image Processing}, pages =3D 237, publisher =3D {IEEE Computer Society Press} } @ARTICLE{Yamauti26-LFDSI*, author =3D {Zito Yamauti}, month =3D {November}, year =3D 1926, title =3D {The {Light} {Flux} {Distribution} of a {System} of {Interreflecting} {Surfaces}}, journal =3D {Journal of the Optical Society of America}, volume =3D 13, pages =3D {561--571}, keywords =3D {interreflections, Fredholm integrals}, comments =3D {the first paper on Fredholm integrals in radiative = transfer theory} } ------=_NextPart_000_000E_01BD0356.E71F2250-- From owner-globillum-imag@imag.fr Mon Jan 26 22:28:23 1998 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by pink.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA03515 for ; Mon, 26 Jan 1998 22:28:23 -0800 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA02987 for ; Mon, 26 Jan 1998 22:30:15 -0800 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id WAA27521; Mon, 26 Jan 1998 22:24:46 -0800 Received: from nit.Stanford.EDU (nit.Stanford.EDU [171.64.77.197]) by imag.imag.fr (8.8.5/8.8.5) with ESMTP id GAA16673 for ; Tue, 27 Jan 1998 06:46:15 +0100 (MET) Received: (from ericv@localhost) by nit.Stanford.EDU (8.7.5/8.7.1) id VAA23168 for globillum@imag.fr; Mon, 26 Jan 1998 21:46:15 -0800 (PST) From: Eric Veach Message-Id: <199801270546.VAA23168@nit.Stanford.EDU> Subject: Thesis available online To: globillum@imag.fr Date: Mon, 26 Jan 1998 21:46:15 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hello everyone, For those who are interested, my thesis is now available online: Robust Monte Carlo Methods for Light Transport Simulation Eric Veach Ph.D. dissertation Stanford University December 1997 http://graphics.stanford.edu/papers/veach_thesis/ It describes techniques such as Metropolis light transport, multiple importance sampling, and bidirectional path tracing in more detail than in the corresponding papers. It also includes quite a bit of new material, including studies of: - the inherent limitations of unbiased Monte Carlo methods - new variance reduction techniques - the history of reciprocity principles and important exceptions to them - the derivation of a new reciprocity principle that applies to materials that transmit as well as reflect light [i.e. BTDF's as well as BRDF's] You can find the abstract and table of contents on the web page, as well as Postscript and PDF versions of the thesis. Best regards, Eric From owner-globillum-imag@imag.fr Sat Jan 31 06:38:23 1998 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by positron.CS.Berkeley.EDU (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA26396 for ; Sat, 31 Jan 1998 06:38:21 -0800 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA26018 for ; Sat, 31 Jan 1998 06:44:21 -0800 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id GAA14993; Sat, 31 Jan 1998 06:38:51 -0800 Received: from phoenix.cs.utah.edu (phoenix.cs.utah.edu [155.99.209.77]) by imag.imag.fr (8.8.5/8.8.5) with SMTP id PAA23098 for ; Sat, 31 Jan 1998 15:12:09 +0100 (MET) Received: (from shirley@localhost) by phoenix.cs.utah.edu (950413.SGI.8.6.12/950213.SGI.AUTOCF) id HAA00557 for globillum@imag.fr; Sat, 31 Jan 1998 07:12:06 -0700 From: shirley@phoenix.cs.utah.edu (Peter Shirley) Message-Id: <199801311412.HAA00557@phoenix.cs.utah.edu> Subject: Sky luminance models To: globillum@imag.fr Date: Sat, 31 Jan 1998 07:12:06 -0700 (MST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hi all. I have a student working on creating sky dome radiance functions. A couple of questions: 1) Are any of you aware of newer models than the classic CIE models? I seem to remember Nishita discussing a recent one and I can't find it in his papers. 2) Does the CIE luminance function include the sun or not? Its description in Wyszecki&Stiles implies it does not, but its actual form has a sun-like spike in it that does not look like forward scattering. Thanks, Pete From owner-globillum-imag@imag.fr Sat Jan 31 07:02:58 1998 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by positron.CS.Berkeley.EDU (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA26413 for ; Sat, 31 Jan 1998 07:02:56 -0800 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA26073 for ; Sat, 31 Jan 1998 07:08:56 -0800 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id HAA15104; Sat, 31 Jan 1998 07:03:26 -0800 Received: from kiultra.eml.hiroshima-u.ac.jp (kiultra.eml.hiroshima-u.ac.jp [133.41.51.161]) by imag.imag.fr (8.8.5/8.8.5) with ESMTP id PAA23974 for ; Sat, 31 Jan 1998 15:40:33 +0100 (MET) Received: from vaio.nisken.fuee.fukuyama-u.ac.jp (vaio.nisken.fuee.fukuyama-u.ac.jp [163.145.94.29]) by kiultra.eml.hiroshima-u.ac.jp (8.8.5+2.7Wbeta5/3.6Wbeta5) with SMTP id XAA11833; Sat, 31 Jan 1998 23:37:12 +0900 (JST) Message-ID: <34D33526.2A2C@eml.hiroshima-u.ac.jp> Date: Sat, 31 Jan 1998 23:28:54 +0900 From: Tomoyuki Nishita Reply-To: nis@eml.hiroshima-u.ac.jp Organization: Fukuyama University X-Mailer: Mozilla 3.03Gold (Win95; I) MIME-Version: 1.0 To: Peter Shirley CC: globillum@imag.fr Subject: Re: Sky luminance models References: <199801311412.HAA00557@phoenix.cs.utah.edu> Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Status: RO Hi Dr. Peter Shirley; > Nishita discussing a recent one and I can't find it > in his papers. I use the classic CIE model. >2) Does the CIE luminance function include the sun or not? I believe that it does not include the sun. > but its actual form has a sun-like spike in it that does > not look like forward scattering. I think that it due to strong forward scattering from aerosols particles. Tomoyuki Nishita Professor Dept. of Electronic and Electrical Engineering Faculty of Engineering Fukuyama University Higashimura-cho, Fukuyama, 729-02 Japan Work phone: +81-849-36-2111(ext.4731) Fax number: +81-849-36-2023 nis@eml.hiroshima-u.ac.jp http://www.eml.hiroshima-u.ac.jp/~nis From owner-globillum-imag@imag.fr Mon Feb 2 04:37:44 1998 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by positron.CS.Berkeley.EDU (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id EAA28372 for ; Mon, 2 Feb 1998 04:37:37 -0800 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id EAA03798 for ; Mon, 2 Feb 1998 04:43:34 -0800 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id EAA12482; Mon, 2 Feb 1998 04:38:02 -0800 Received: from relay1.mail.uk.psi.net (relay1.mail.uk.psi.net [154.32.105.6]) by imag.imag.fr (8.8.5/8.8.5) with ESMTP id LAA06155 for ; Mon, 2 Feb 1998 11:07:35 +0100 (MET) Received: from elvis.lightwork (lightwork.co.uk [195.152.206.2]) by relay1.mail.uk.psi.net (8.8.5/) with ESMTP id KAA02958 for ; Mon, 2 Feb 1998 10:07:20 GMT Received: by elvis.lightwork with Internet Mail Service (5.0.1457.3) id <11VZA0C1>; Mon, 2 Feb 1998 10:06:46 -0000 Message-ID: <8815647C7041D111A3010060B06BE1C0149375@elvis.lightwork> From: Neil Gatenby To: shirley@phoenix.cs.utah.edu, globillum@imag.fr Subject: RE: Sky luminance models Date: Mon, 2 Feb 1998 10:06:44 -0000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Status: R Pete; when you say "the classic CIE models" do you mean CIE 1973? I think CIE 1994 has one more sky ... an intermediate sky, but maybe that was there in 73, too ... dunno. Anyway, quoting from CIE Technical Report CIE 110-1994 "Spatial Distribution of Daylight - Luminance Distributions of Various Reference Skies" ISBN 3 900 734 52 6 They say on pg 1 ... "The skies treated in this report do not include direct sunlight" I think the spike you are seeing is to be expected ... the sky dome being illuminated most markedly where the sun is. best wishes Neil On Saturday, January 31, 1998 2:12 PM, shirley@phoenix.cs.utah.edu [SMTP:shirley@phoenix.cs.utah.edu] wrote: > > Hi all. I have a student working on creating sky dome > radiance functions. A couple of questions: > > 1) Are any of you aware of newer models than the > classic CIE models? I seem to remember > Nishita discussing a recent one and I can't find it > in his papers. > > 2) Does the CIE luminance function include the sun or not? > Its description in Wyszecki&Stiles implies it does not, > but its actual form has a sun-like spike in it that does > not look like forward scattering. > > Thanks, > > Pete From gwlarson Mon Feb 2 09:27:14 1998 Received: (from gwlarson@localhost) by positron.CS.Berkeley.EDU (950413.SGI.8.6.12/950213.SGI.AUTOCF) id JAA28660; Mon, 2 Feb 1998 09:27:13 -0800 Date: Mon, 2 Feb 1998 09:27:13 -0800 From: gwlarson (Gregory Ward Larson) Message-Id: <199802021727.JAA28660@positron.CS.Berkeley.EDU> To: shirley@phoenix.cs.utah.edu (Peter Shirley) Subject: Re: Sky luminance models Status: R Hi Pete, If you haven't already, do check out the Perez sky model, which is much better than any of the CIE models. Richard Perez teaches at SUNY in Albany, I believe. The articles I have of his appeared in "Solar Energy," one from 1990 and another from 1992. I just did a web search and found the following page, which seems to indicate that he's moved to USC: http://www-rcf.usc.edu/~rhperez/ There appears to be NO data at this site, however, and I am wondering if it's even the same guy. If you can't find his papers, I can make lousy copies of mine for you. There's also an intermediate sky model, introduced by the CIE more recently. Though it's not as complete as Perez's work, it's still better than the clear and overcast approximations. -Greg From owner-globillum-imag@imag.fr Mon Feb 2 09:27:48 1998 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by positron.CS.Berkeley.EDU (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA28668 for ; Mon, 2 Feb 1998 09:27:46 -0800 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA04799 for ; Mon, 2 Feb 1998 09:33:42 -0800 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id JAA20954; Mon, 2 Feb 1998 09:28:10 -0800 Received: from monster.igd.fhg.de (monster.igd.fhg.de [153.97.128.43]) by imag.imag.fr (8.8.5/8.8.5) with SMTP id QAA28616 for ; Mon, 2 Feb 1998 16:09:00 +0100 (MET) From: wkresse@igd.fhg.de Received: from michelangelo.igd.fhg.de by monster.igd.fhg.de (5.x/SMI-4.1) id AA27061; Mon, 2 Feb 1998 16:07:42 +0100 Received: by michelangelo.igd.fhg.de (950413.SGI.8.6.12/SMI-4.0) id QAA21078; Mon, 2 Feb 1998 16:07:41 +0100 Date: Mon, 2 Feb 1998 16:07:41 +0100 Message-Id: <9802021607.ZM21077@michelangelo> In-Reply-To: shirley@phoenix.cs.utah.edu (Peter Shirley) "Sky luminance models" (Jan 31, 7:12) References: <199801311412.HAA00557@phoenix.cs.utah.edu> X-Face: .4|Jp[=9'pK#xl6x&l>D4xycaCh Hi all. I have a student working on creating sky dome > radiance functions. A couple of questions: > > 1) Are any of you aware of newer models than the > classic CIE models? I seem to remember > Nishita discussing a recent one and I can't find it > in his papers. > Perez et al. (1993) are introducing a sky model which is a generalization of the CIE standard clear sky formula and includes 5 parameters that can be adjusted to account for any luminance distribution ranging from totally overcast to very clear. The parameters describe the darkening of the horizon region in respect to the zenith, the luminance gradient near the horizon, the relative intensity as well as the width of the circumsolar region, and the relative intensity of the backscattered light received at the earth's surface. The CIE clear sky can also be expressed by appropriate settings of these parameters. These parameters can be simplified to 'sky clearness' and 'sky brightness', which can also be derived from actually measured sky data with horizontal diffuse and normal incident direct irradiance. Perez R., Seals R., Michalsky J., "All-Weather Model for Sky Luminance Distribution - Preliminary Configuration and Validation", Solar Energy, Vol. 50, No. 3, 1993, pp.235-245 Perez R., Ineichen P., Seals R., Michalsky J., Stewart R., "Modelling Daylight Availability and Irradiance Components from Direct and Global Irradiance", Solar Energy, Vol. 44, No. 5, 1990, pp.271-289 > 2) Does the CIE luminance function include the sun or not? > Its description in Wyszecki&Stiles implies it does not, > but its actual form has a sun-like spike in it that does > not look like forward scattering. > No, the direct sunlight has to be accounted for explicitely since it is described by a narrow angle several levels of magnitude brighter than the diffuse skylight of the hemisphere. The higher intensity near the circumsolar region represented in the models is probably caused by some kind of scattering effect. The same is true for the Perez model. Cheers, Wolfram -- +-------+-----Wolfram Kresse---------------------------------------------+ | _ _ | wkresse@igd.fhg.de http://www.igd.fhg.de/~wkresse | | +-------------------------+-----------------+--------------------+ | -O-O- |"Meeneemeeneemeenee" | CU l8r, LE g8r! | | > |"Yes,that's right,Twiki."+-----------------+ | _____ +-----+-----+-------------+ | U | 8^) | :u) | +-------+-----+-----+ "Life is complex. It has real and imaginary components." From owner-globillum-imag@imag.fr Fri Feb 13 13:47:39 1998 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by positron.CS.Berkeley.EDU (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA19304 for ; Fri, 13 Feb 1998 13:47:35 -0800 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA12919 for ; Fri, 13 Feb 1998 13:53:12 -0800 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id NAA06637; Fri, 13 Feb 1998 13:47:36 -0800 Received: from adeskgate.autodesk.com (adeskgate.autodesk.com [198.93.152.11]) by imag.imag.fr (8.8.5/8.8.5) with ESMTP id WAA23517 for ; Fri, 13 Feb 1998 22:24:05 +0100 (MET) Received: from autodesk.autodesk.com by adeskgate.autodesk.com (8.6.12/SMI-5.3) with ESMTP id NAA22690; Fri, 13 Feb 1998 13:23:31 -0800 (PST) Received: from hqhubmu1.autodesk.com by autodesk.autodesk.com (8.6.12/4.4BSD) with ESMTP id NAA28667; Fri, 13 Feb 1998 13:21:46 -0800 (PST) Received: from ccinternet.autodesk.com (ccinternet [144.111.240.144]) by hqhubmu1.autodesk.com (8.7.5/8.7.3) with SMTP id NAA00274; Fri, 13 Feb 1998 13:21:45 -0800 (PST) Received: from ccMail by ccinternet.autodesk.com (IMA Internet Exchange 2.12 Enterprise) id 0037C07C; Fri, 13 Feb 1998 13:24:38 -0800 Mime-Version: 1.0 Date: Fri, 13 Feb 1998 16:21:09 -0800 Message-ID: <0037C07C.4149@autodesk.com> From: eric.haines@autodesk.com (Eric Haines) Subject: rendering comparisons available on web To: globillum Cc: scott owen Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Status: RO Due to an email request, I've put some old (7 years old or older) rendering comparison images on the web. They're at my homepage: http://www.acm.org/tog/editors/erich/index.html About 2/3rds of the way down you'll see thumbnails of sets of images showing some rendering techniques compared. Techniques include z-buffering, traditional ray tracing, stochastic ray tracing, meshed radiosity, and a ray tracing/radiosity blend (tres funky). Feel free to use them for educational purposes as you wish. Eric Haines erich@acm.org From owner-globillum-imag@imag.fr Mon Feb 16 12:39:35 1998 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by positron.CS.Berkeley.EDU (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA21813 for ; Mon, 16 Feb 1998 12:39:02 -0800 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA26830 for ; Mon, 16 Feb 1998 12:43:51 -0800 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id MAA02730; Mon, 16 Feb 1998 12:38:18 -0800 Received: from adeskgate.autodesk.com (adeskgate.autodesk.com [198.93.152.11]) by imag.imag.fr (8.8.5/8.8.5) with ESMTP id TAA27516 for ; Mon, 16 Feb 1998 19:14:44 +0100 (MET) Received: from autodesk.autodesk.com by adeskgate.autodesk.com (8.6.12/SMI-5.3) with ESMTP id KAA20248; Mon, 16 Feb 1998 10:14:11 -0800 (PST) Received: from hqhubmu1.autodesk.com by autodesk.autodesk.com (8.6.12/4.4BSD) with ESMTP id KAA13791; Mon, 16 Feb 1998 10:12:21 -0800 Received: from ccinternet.autodesk.com (ccinternet [144.111.240.144]) by hqhubmu1.autodesk.com (8.7.5/8.7.3) with SMTP id KAA08661 for ; Mon, 16 Feb 1998 10:12:20 -0800 (PST) Received: from ccMail by ccinternet.autodesk.com (IMA Internet Exchange 2.12 Enterprise) id 00384465; Mon, 16 Feb 1998 10:16:16 -0800 Mime-Version: 1.0 Date: Mon, 16 Feb 1998 13:12:01 -0800 Message-ID: <00384465.4149@autodesk.com> From: eric.haines@autodesk.com (Eric Haines) Subject: articles of possible interest To: globillum Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Description: cc:Mail note part Status: RO The _journal of graphics tools_ has just published some articles which ar= e = likely to be of interest to globillumers. Attached is Ronen Barzel's = announcement. Note that the abstracts and some additional information are= = available online. Eric ----------- Contents of volume 2 number 2: = "The Close Objects Buffer: A Sharp Shadow Detection Technique for Rad= iosity Methods" A. C. Telea and C. W. A. M. van Overveld (abstract, images at http://www.acm.org/jgt/papers/TeleaVanOverve= ld97) = "Sampling with Hammersley and Halton Points" Tien-Tsin Wong, Wai-Shing Luk, and Pheng-Ann Heng. = (abstract, demo, source, images at http://www.acm.org/jgt/papers/WongLukHeng97) = "A Fast Triangle-Triangle Intersection Test" Tomas M=F6ller (abstract, source at http://www.acm.org/jgt/papers/Moller97) = "Rendering Radiosity Solutions by Adaptive Gathering" A. J. Chung and A. J. Field. = (abstract, images at http://www.acm.org/jgt/papers/ChungField97) = = For further information, see http://www.acm.org/jgt, or contact the publi= sher: = A K Peters, Ltd. 289 Linden Street, Wellesley, MA 02181 = Phone (781) 235-2210 Fax (781) 235-2204 = editorial@akpeters.com = = Or, if you have any questions, feel free to contact me. Thanks. = -Ronen Barzel = Editor-in-Chief, Journal of Graphics Tools ronen@pixar.com From owner-globillum@imag.fr Fri Mar 13 11:22:23 1998 Received: from floyd.lbl.gov (floyd.lbl.gov [128.3.12.33]) by positron.CS.Berkeley.EDU (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA25473 for ; Fri, 13 Mar 1998 11:22:22 -0800 Received: from lbl.gov (lbl.gov [128.3.254.23]) by floyd.lbl.gov (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA24535 for ; Fri, 13 Mar 1998 11:28:15 -0800 Received: from imag.imag.fr by lbl.gov (SMI-8.6/SMI-SVR4) id LAA03094; Fri, 13 Mar 1998 11:22:36 -0800 Received: (from daemon@localhost) by imag.imag.fr (8.8.5/8.8.5) id OAA26619 for globillum-imag-outgoing; Fri, 13 Mar 1998 14:48:24 +0100 (MET) From: Francois Sillion Message-Id: <199803131347.OAA02649@safran.imag.fr> Subject: Globillum list -- actions taken to avoid spamming To: globillum@imag.fr (Global Illumination List) Date: Fri, 13 Mar 1998 14:47:45 +0100 (MET) Reply-To: Francois.Sillion@imag.fr X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R Hello globillumers, As you know the 'globillum list' has been a target of several spam messages in the past. Our institution decided to apply a general policy with mailing lists, in order to avoid such inconvenience. Namely, postings to the list will be restricted to registered list members. I think this is compatible with our list, since most messages are coming from members anyway. But I needed to inform you because it means that you can only post from the e-mail address that is know to the list. It may be a slight problem for those with multiple e-mail addresses. More importantly, some sites are using a single email alias in the list, to serve all users locally that are interested in global illumination. These aliases must be replaced by the complete list of email addresses of individual people. Please contact me if you are in this situation, otherwise your local members will not be able to post. at least the following groups should correct the problem: > gi-students@graphics.cornell.edu (Cornell Students) > globillum@duticg.twi.tudelft.nl (Delft University of Technology graphics group) > globillum@loria.fr (LORIA Laboratory) > gimagis@safran.imag.fr (Global Illumination group at iMAGIS/IMAG) > az@robots.oxford.ac.uk (Andrew Zisserman) > glbi@cophos.co.at (Zumtobel Licht GmbH) +------------------+------------------------------------------------------+ | Francois SILLION | iMAGIS - GRAVIR/IMAG, B.P. 53, 38041 Grenoble Cedex 9| | ' | France. Tel:+33 4 76 51 43 54 - Fax:+33 4 76 63 55 80| +------------------+--------+---------------------------------------------+ | Francois.Sillion@imag.fr | http://www-imagis.imag.fr/~Francois.Sillion | +---------------------------+---------------------------------------------+ From gwlarson Fri Mar 13 11:31:57 1998 Received: (from gwlarson@localhost) by positron.CS.Berkeley.EDU (950413.SGI.8.6.12/950213.SGI.AUTOCF) id LAA25510; Fri, 13 Mar 1998 11:31:56 -0800 Date: Fri, 13 Mar 1998 11:31:56 -0800 From: gwlarson (Gregory Ward Larson) Message-Id: <199803131931.LAA25510@positron.CS.Berkeley.EDU> To: Francois.Sillion@imag.fr Subject: Re: Globillum list -- actions taken to avoid spamming Status: RO Hi Francois, You'll probably get a ton of messages like this, so I just want to be the first. My "official" e-mail address is not one I can send e-mail from. It is a receiving-only address, "gregl@sgi.com". It is eventually forwarded to "gwlarson@positron.CS.Berkeley.EDU", the address from which I normally send e-mail. Can you tell me how to correct this in the globillum database? Perhaps you can tell everyone. Thanks, and it was really good to see you at the jury meeting! -Greg _____________________________________________________________________ Gregory Ward Larson (the computer artist formerly known as Greg Ward) Silicon Graphics, Inc. Computer Science Department 2011 N. Shoreline Blvd., M/S 07U-553 537 Soda Hall, UC Berkeley Mountain View, CA 94043-1389 Berkeley, CA 94720-1776 (650) 933-4878, -2663 fax (510) 642-3631, -5775 fax gregl@sgi.com on Tues., Thurs. and Fri. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-globillum@imag.fr Mon Mar 16 06:14:01 1998 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA00244 for ; Mon, 16 Mar 1998 06:13:59 -0800 Received: (from daemon@localhost) by imag.imag.fr (8.8.5/8.8.5) id PAA29379; Mon, 16 Mar 1998 15:13:13 +0100 (MET) Date: Mon, 16 Mar 1998 15:13:13 +0100 (MET) Message-Id: <199803161413.PAA29379@imag.imag.fr> To: gwlarson From: Majordomo@imag.fr Subject: Welcome to globillum Reply-To: Majordomo@imag.fr Status: R -- Welcome to the globillum mailing list! If you ever want to remove yourself from this mailing list, you can send mail to "Majordomo@imag.fr" with the following command in the body of your email message: unsubscribe globillum gwlarson@positron.CS.Berkeley.EDU Here's the general information for the list you've subscribed to, in case you don't already have it: [Last updated on: Wed Jan 22 9:36:39 1997] The `globillum' mailing list is an electronic discussion forum focusing on all issues raised by the computer simulation of `global illumination' effects. The mailing list was created by Greg Ward in 1989, and subsequently managed by Paul Heckbert. It is currently managed by Francois Sillion. `Global Illumination' is the term used to describe the inter-reflection effets taking place between a collection of radiating objects. It is often contrasted to 'local illumination', that is the computation of the reflected radiance on a surface due to a single light source. The mailing list is intended mainly for the discussion of research issues in global illumination. Most members are either students or work in academic institutions, but there are no access restrictions. Be warned however that many threads deal with academic issues such as focused conferences or workshops. How can I subscribe? Please do not register directly with Majordomo. Instead, Send E-mail to globillum-request@imag.fr, clearly indicating your affiliation and a one or two-line description of your interests in global illumination. Note that this is not an automated service, but a real person at the end of the line! the reason for this is that I would like to keep some more information about who participates in the list, as well as keeping it focused. If you have subscribed to the list, you should have received the address of a Web page, giving you access to all previous discussions on the list. From gwlarson@radiate.engr.sgi.com Mon Mar 16 16:31:07 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by positron.CS.Berkeley.EDU (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA01797 for ; Mon, 16 Mar 1998 16:31:05 -0800 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id QAA13937; Mon, 16 Mar 1998 16:30:44 -0800 (PST) mail_from (gwlarson@radiate.engr.sgi.com) Received: from radiate.engr.sgi.com (radiate.engr.sgi.com [192.26.72.11]) by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id QAA428049; Mon, 16 Mar 1998 16:30:42 -0800 (PST) Received: (from gwlarson@localhost) by radiate.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id QAA03381; Mon, 16 Mar 1998 16:30:41 -0800 Date: Mon, 16 Mar 1998 16:30:41 -0800 From: gwlarson@radiate.engr.sgi.com (Greg Larson) Message-Id: <199803170030.QAA03381@radiate.engr.sgi.com> To: francois.sillion@imag.fr Subject: Slimane's whereabouts Status: R Hi Francois, Well, it seems that Slimane has been working here since mid-January. Sorry I didn't follow up on him. He's working under Remi Arnaud, and he says he's enjoying it very much. It sounds to me like he's doing some very interesting work in the performer group. Anyway, here's his e-mail if you want to write to him. (He told me he keeps meaning to drop you a note.) -Greg ----------- >From remi@remi Mon Mar 16 16:23:13 1998 Received: from remi.engr.sgi.com (remi.engr.sgi.com [150.166.37.25]) by radiate.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id QAA03371 for ; Mon, 16 Mar 1998 16:23:13 -0800 Received: (from remi@localhost) by remi.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id QAA11971; Mon, 16 Mar 1998 16:23:13 -0800 From: remi@remi (Rémi Arnaud) Message-Id: <199803170023.QAA11971@remi.engr.sgi.com> Subject: Re: Slimane To: gwlarson (Greg Larson) Date: Mon, 16 Mar 1998 16:23:13 -0800 (PST) Cc: merzouk@france (slimane merzouk) In-Reply-To: <199803170008.QAA03358@radiate.engr.sgi.com> from "Greg Larson" at Mar 16, 98 04:08:11 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 1078 Status: R Greg Larson wrote: > > Hi Remi, > > You probably don't know me, but I'm a friend of Francois Sillion's who > interviewed Slimane when he first came here looking for work last year. > Francois was asking after him, wondering whether we'd hired him or not, > and I had to say I didn't know. Five minutes ago, I ran into Slimane > on the B7-8 bridge, and asked him how he is doing. He says he really > enjoys working in your group, and has been meaning to write to Francois > to give him an update. I was going to go ahead myself and let Francois > know he is alive and well, but I'd like to send him Slimane's e-mail > address. For some reason, maybe I'm spelling his name wrong, but I > can't find him using "locate" or any of the usual means. Can you help? shure, he is not in locate as SGI maintains only employes in the database. merzouk@france.engr.sgi.com should work. Say hello to Francois for me _ / _ _ |_) _ ._ _ o /\ |_)|\ | /\ | || \ | \(/_| | || /--\| \| \|/--\|_||_/ _____________________________________________________________________ Gregory Ward Larson (the computer artist formerly known as Greg Ward) Silicon Graphics, Inc. Computer Science Department 2011 N. Shoreline Blvd., M/S 07U-553 537 Soda Hall, UC Berkeley Mountain View, CA 94043-1389 Berkeley, CA 94720-1776 (650) 933-4878, -2663 fax (510) 642-3631, -5775 fax gregl@sgi.com on Tues., Thurs. and Fri. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-globillum@imag.fr Mon May 11 14:44:36 1998 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA14452 for ; Mon, 11 May 1998 14:44:31 -0700 Received: (from daemon@localhost) by imag.imag.fr (8.8.5/8.8.5) id XAA20146 for globillum-imag-outgoing; Mon, 11 May 1998 23:00:23 +0200 (MET DST) Message-Id: <3.0.5.32.19980511140144.00b97190@amie.engr.sgi.com> X-Sender: bwade@amie.engr.sgi.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 11 May 1998 14:01:44 -0700 To: globillum@imag.fr From: Bretton Wade Subject: attenuation in water Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R Hi globillumers, I'm seeking information about attenuation of light in seawater. Does anybody have any pointers? I'm not really interested in scattering due to particles in suspension, only clean, clear water. TIA, Bretton -- Bretton Wade (bwade@sgi.com) Cosmo Software - A Silicon Graphics Company From owner-globillum@imag.fr Mon May 11 15:11:21 1998 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA14495 for ; Mon, 11 May 1998 15:11:20 -0700 Received: (from daemon@localhost) by imag.imag.fr (8.8.5/8.8.5) id XAA21225 for globillum-imag-outgoing; Mon, 11 May 1998 23:28:41 +0200 (MET DST) Reply-To: "Ian Ashdown" From: "Ian Ashdown" To: "Bretton Wade" Cc: Subject: Re: attenuation in water Date: Mon, 11 May 1998 14:30:28 -0700 Message-ID: <01bd7d24$04c73260$2d2aa8c0@ledalite045.ledalite.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R >Hi globillumers, > >I'm seeking information about attenuation of light in seawater. Does >anybody have any pointers? I'm not really interested in scattering due to >particles in suspension, only clean, clear water. > Hi, Bretton. There is some basic information in Chapter 28, "Underwater Lighting" of the IES Lighting Handbook, Eighth Edition. It includes a discussion of the absorption coefficient (which is wavelength-dependent) , plus scattering information. The chapter includes 17 references, although these should be sufficient: Lankes, L. R. 1970. "Optics and the Physical Parameters of the Sea," Opt. Spectra 4(5):42-49. Smith, R. C., and K. S. Baker. 1981. "Optical Properties of the Clearest Natural Waters (200-800 nm)," Applied Optics 20(2):177-184. Duntley, S. Q. 1963. "Light in the Sea," J. Optical Society of America 53(2):214-233. Austin, R. W. 1970. "Assessing Underwater Visibility," Opt. Spectra 4(5):34-39. Kinney, J. A., S. M. Luria and D. O. Weitzman. 1967. "Visibility of Colors Underwater," J. Optical Society of America 57(6):802-809. Ian Ashdown, P. Eng, LC Head of Research Ledalite Architectural Products Inc. http://www.ledalite.com From owner-globillum@imag.fr Thu May 14 09:52:58 1998 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA19483 for ; Thu, 14 May 1998 09:52:56 -0700 Received: (from daemon@localhost) by imag.imag.fr (8.8.5/8.8.5) id RAA25024 for globillum-imag-outgoing; Thu, 14 May 1998 17:17:26 +0200 (MET DST) Reply-To: "Ian Ashdown" From: "Ian Ashdown" To: Subject: IES Lighting Handbook Date: Thu, 14 May 1998 08:18:35 -0700 Message-ID: <01bd7f4b$902d3b00$2d2aa8c0@ledalite045.ledalite.com> MIME-Version: 1.0 Status: R Several people has asked me about the availability of the Illuminating Engineering Society of North America's "IES Lighting Handbook" that I referenced in an earlier message. It appears that Amazon Books (www.amazon.com) is selling the 1987 IES Lighting Handbook Applications Volume. I have no idea where they are obtaining copies of this book, as it was superceded by the IES Lighting Handbook, Eighth Edition in 1993. (Even so, all the good stuff is in the companion 1987 IES Lighting Handbook Reference Volume. The two volume were combined to form a 990-page "handbook" for the 1993 edition.) The IES Lighting Handbook, Eighth Edition, is available directly from the Illuminating Engineering Society of North America: Tel: (212) 248-5000 Fax: (212) 248-5017 URL: www.iesna.org The cost of the book is $389.00 US for non-members and $225.00 US for members. Please note that the handbook does *not* include the IESNA Lighting Library. Of particular interest may be IES LM-63, "Standard File Format for Electronic Transfer of Photometric Data" ($10.00 members, $18.00 non-members) and ANSI/IES RP-16, "Nomenclature and Definitions for Illuminating Engineering" ($10.00 members, $15.00 non-members). The entire IESNA Lighting Library is available for $999.00 For members and $1,800.00 for non-members. (If you think this is expensive, check out the cost of the Commission Internationale de l'Eclairage [http://www.cie.co.at/cie/] publications.) Ian Ashdown, P. Eng, LC Head of Research Ledalite Architectural Products Inc. http://www.ledalite.com From owner-globillum@imag.fr Fri May 22 10:27:15 1998 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA05560 for ; Fri, 22 May 1998 10:27:14 -0700 Received: (from daemon@localhost) by imag.imag.fr (8.8.5/8.8.5) id SAA22880 for globillum-imag-outgoing; Fri, 22 May 1998 18:20:01 +0200 (MET DST) Message-ID: From: "Michael Cohen (Research)" To: "'globillum@imag.fr'" Subject: FW: wavelet radiosity with triangular mesh Date: Fri, 22 May 1998 09:19:57 -0700 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R Someone want to take this? -Michael > -----Original Message----- > From: Berruyer [SMTP:berruyer@AVO.fr] > Sent: Friday, May 22, 1998 1:25 AM > To: Michael Cohen (Research) > Subject: wavelet radiosity with triangular mesh > > Hello, > I'm currently working on a radiosity project consisting in > comparing different algorithms. I'm now facing the wavelet > problem. As a matter of fact, all the radiosity litterature that i've read > only considers quadrilateral polygons. > Would you mind telling me if there have been researches > about wavelet radiosity with a triangular mesh ? > In this case, do you know where i could get any information ? >   > Thanks in anticipation. >   > Benoît BERRUYER > berruyer@avo.fr From owner-globillum@imag.fr Mon May 25 11:26:40 1998 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA09162 for ; Mon, 25 May 1998 11:26:39 -0700 Received: (from daemon@localhost) by imag.imag.fr (8.8.5/8.8.5) id QAA20934 for globillum-imag-outgoing; Mon, 25 May 1998 16:58:23 +0200 (MET DST) From: Nicolas Holzschuch Message-Id: <199805251456.QAA14725@yutz.loria.fr> Subject: Something is nagging me... To: globillum@imag.fr Date: Mon, 25 May 1998 16:56:12 +0200 (MDT) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: RO Hello fellow globillumers, there is an idea that has been nagging me for some time, and I thought I would share it with the list. I couldn't help noticing there is a Workshop on Rendering for our research results, there is Siggraph for our outstanding research results. However, there is nothing to discuss the specific problems occuring in implementations of large rendering systems. I'm thinking of large, polyvalent rendering systems, with several global illumination algorithms, that deal with 500 K input polygons on a daily basis. I'm thinking about softwares like Vision, Genesis, etc. So here is the question: are there people out there interested in discussing problems specific to these issues? Expose how you deal with 500 K input polygons and 1 Gb of memory? How long does it take you to do the Soda Hall (with furnitures)? Nicolas Holzschuch Researcher, ISA Research Team, INRIA, Nancy, France. From owner-globillum@imag.fr Wed Jun 3 12:57:15 1998 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA03936 for ; Wed, 3 Jun 1998 12:57:13 -0700 Received: (from daemon@localhost) by imag.imag.fr (8.8.5/8.8.5) id NAA29265 for globillum-imag-outgoing; Wed, 3 Jun 1998 13:03:20 +0200 (MET DST) Message-ID: <8815647C7041D111A3010060B06BE1C0288D1D@elvis.lightwork> From: Neil Gatenby To: globillum@imag.fr Subject: gonio-photometry Date: Wed, 3 Jun 1998 12:02:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R Hi all; Does anyone know of any companies or academic institutions that can provide a gonio-photometer service for measuring the BRDFs of everyday materials? Does anyone have any experiences with such services? Does anyone know where any such data is available, to download? I know about the NIST site, with lots of data that you can't see! And I know of a European site that has some fascinating watercress BRDF data (all I need is the BRDF data for lettuce I can render a really nice salad!) any help much appreciated Neil From owner-globillum@imag.fr Wed Jun 3 13:26:26 1998 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA04028 for ; Wed, 3 Jun 1998 13:26:25 -0700 Received: (from daemon@localhost) by imag.imag.fr (8.8.5/8.8.5) id VAA29548 for globillum-imag-outgoing; Wed, 3 Jun 1998 21:56:16 +0200 (MET DST) Date: Wed, 3 Jun 1998 11:03:55 -0700 (PDT) From: Alain Fournier Message-Id: <199806031803.LAA14704@pedigree.cs.ubc.ca> To: Neil@lightwork.co.uk, globillum@imag.fr Subject: Re: gonio-photometry Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R We will soon here at UBC be able to allow people to design, simulate and conduct their own experiments (including measuring BRDF) across the web on our facility (called ACME, for ACtive MEasurement facility). It will be at leat a few weeks before we are ready, but stay tuned. "(all I need is the BRDF data for lettuce I can render a really nice salad!)" Yes, but what about the vinaigrette (dressing is the most important part of salad, without it it's just grass). From owner-globillum@imag.fr Sun Jun 7 16:42:24 1998 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA09379 for ; Sun, 7 Jun 1998 16:42:23 -0700 Received: (from daemon@localhost) by imag.imag.fr (8.8.5/8.8.5) id BAA03905 for globillum-imag-outgoing; Mon, 8 Jun 1998 01:20:44 +0200 (MET DST) Message-Id: <9806072320.AA10011@merckx.graphics.cornell.edu> Date: Sun, 7 Jun 1998 19:20:04 -0400 From: Eric Lafortune To: Neil@lightwork.co.uk Cc: globillum@imag.fr Subject: Re: gonio-photometry Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: RO Neil Gatenby wrote: > Does anyone know of any companies or academic institutions that can provide > a gonio-photometer service for measuring the BRDFs of everyday materials? > > Does anyone have any experiences with such services? Does anyone know where > any such data is available, to download? Should you be happy with just an example, we have full hemispherical BRDF data for blue latex paint available at our web site: http://www.graphics.cornell.edu/online/measurements/ The data were measured by Sing Foo, and we used them in our Siggraph'97 paper "Non-Linear Approximation of Reflectance Functions". I've just added some graphs of the function in the plane of incidence, to give a first impression of its shape. It's an interesting start for experiments. With Steve Westin (westin@graphics.cornell.edu) in charge of the measurement lab, we are doing more measurements, which may become available in the future. However, it is unlikely that we will ever be a service bureau. Kind regards, Eric Lafortune. From image-based-rendering-owner@cs.unc.edu Thu Jun 11 11:05:08 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by positron.CS.Berkeley.EDU (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA20640 for ; Thu, 11 Jun 1998 11:05:06 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA19358 for <@sgi.engr.sgi.com:gwlarson@positron.cs.berkeley.edu>; Thu, 11 Jun 1998 11:04:31 -0700 (PDT) mail_from (image-based-rendering-owner@cs.unc.edu) Received: from radiate.engr.sgi.com (radiate.engr.sgi.com [130.62.245.56]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id LAA29835 for <@cthulhu.engr.sgi.com:gwlarson@positron.cs.berkeley.edu>; Thu, 11 Jun 1998 11:04:26 -0700 (PDT) mail_from (image-based-rendering-owner@cs.unc.edu) Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by radiate.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id LAA13576 for ; Thu, 11 Jun 1998 11:04:13 -0700 Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA52077; Thu, 11 Jun 1998 11:04:02 -0700 (PDT) mail_from (image-based-rendering-owner@cs.unc.edu) Received: from austin.cs.unc.edu (austin.cs.unc.edu [152.2.128.87]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA19187; Thu, 11 Jun 1998 11:04:01 -0700 (PDT) mail_from (image-based-rendering-owner@cs.unc.edu) Received: (from majordom@localhost) by austin.cs.unc.edu (8.8.8/8.8.8) id NAA24037 for image-based-rendering-outgoing; Thu, 11 Jun 1998 13:35:55 -0400 (EDT) X-Authentication-Warning: austin.cs.unc.edu: majordom set sender to owner-image-based-rendering@cs.unc.edu using -f Received: from degusse.iro.umontreal.ca (degusse.IRO.UMontreal.CA [132.204.24.51]) by austin.cs.unc.edu (8.8.8/8.8.8) with ESMTP id NAA24032 for ; Thu, 11 Jun 1998 13:35:47 -0400 (EDT) Received: from sutherland.IRO.UMontreal.CA (sutherland.IRO.UMontreal.CA [132.204.26.143]) by degusse.iro.umontreal.ca (8.8.8/8.8.8) with ESMTP id NAA29309; Thu, 11 Jun 1998 13:35:32 -0400 (EDT) Received: from iro.umontreal.ca (vandam.IRO.UMontreal.CA [132.204.26.147]) by sutherland.IRO.UMontreal.CA (8.7.5/8.7.3) with ESMTP id NAA23686; Thu, 11 Jun 1998 13:35:17 -0400 (EDT) Message-ID: <35801555.86656AD9@iro.umontreal.ca> Date: Thu, 11 Jun 1998 13:35:17 -0400 From: Martin Blais Organization: DIRO-UdeM X-Mailer: Mozilla 4.05 [en] (X11; I; IRIX64 6.2 IP28) MIME-Version: 1.0 To: Global Illumination List , IBR List Subject: Wanted: EGWR proceedings (your conference copies). Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-image-based-rendering@cs.unc.edu Precedence: bulk Status: R Hi global and image-based illuminationerers. I know some of you who attend the EGWR actually buy the "published" proceedings after the conference (the nice, very expensive ones). Unfortunately, a masters student like me cannot afford those (yet :-). I know this is probably a shot in the dark, but I'm very interested in buying your conference version (the cheaper, photocopies-like version you receive at EGWR itself). So if you want to get rid of them, I'll give you a few bucks for them, and we can meet at SIGGRAPH'98 to do the exchange. If you're interested, you can contact me at blais@iro.umontreal.ca Best regards to all, M. P.S. Apologies to those people both on the globillum and IBR lists, you'll receive this post twice. -- \-----------------------------------------------------------/ \ Martin Blais Universite de Montreal / / mailto:blais@iro.umontreal.ca Computer graphics lab. \ / http://www.iro.umontreal.ca/~blais \ "Lui parler de tout, de rien; de rien surtout, c'est ce qui nous tracasse le plus." ---Nor, "Des nouvelles du Bon Dieu" From owner-globillum@imag.fr Wed Jun 17 04:53:37 1998 Received: from imag.imag.fr ([129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id EAA03214 for ; Wed, 17 Jun 1998 04:53:36 -0700 (PDT) Received: (from daemon@localhost) by imag.imag.fr (8.8.5/8.8.5) id LAA06682 for globillum-imag-outgoing; Wed, 17 Jun 1998 11:39:27 +0200 (MET DST) Date: Wed, 17 Jun 1998 11:36:49 +0200 (MDT) Message-Id: <199806170936.LAA08522@yutz.loria.fr> From: Nicolas Holzschuch To: globillum@imag.fr Subject: PhD thesis bursary Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R Hello fellow globillumers, We are looking for a PhD student, starting september 1998. The PhD would be funded by a CIFRE convention. The student would be working with the ISA research team, following our research on global illumination algorithms and hierarchical radiosity. Since the bursary is a CIFRE, there will be some part of interaction with industries. Applications and requests for further information should be directed to Jean-Claude Paul (Jean-Claude.Paul@inria.fr). Nicolas Holzschuch ISA research team, INRIA-Lorraine. From owner-globillum@imag.fr Wed Jun 17 05:14:05 1998 Received: from imag.imag.fr ([129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id FAA03242 for ; Wed, 17 Jun 1998 05:14:03 -0700 (PDT) Received: (from daemon@localhost) by imag.imag.fr (8.8.5/8.8.5) id MAA10391 for globillum-imag-outgoing; Wed, 17 Jun 1998 12:46:28 +0200 (MET DST) From: Nicolas Holzschuch Message-Id: <199806171043.MAA08700@yutz.loria.fr> Subject: Re: PhD thesis bursary To: Nicolas.Holzschuch@loria.fr (Nicolas Holzschuch) Date: Wed, 17 Jun 1998 12:43:46 +0200 (MDT) Cc: globillum@imag.fr In-Reply-To: <199806170936.LAA08522@yutz.loria.fr> from "Nicolas Holzschuch" at Jun 17, 98 11:36:49 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R > Hello fellow globillumers, Sorry for the double posting. I forgot to mention that if you want to know more about the ISA research team, you can take a look at our web page, http://www.loria.fr/equipes/isa/ Nicolas Holzschuch ISA research team, INRIA Lorraine http://www.loria.fr/~holzschu/ > We are looking for a PhD student, starting september 1998. The PhD > would be funded by a CIFRE convention. The student would be working > with the ISA research team, following our research on global > illumination algorithms and hierarchical radiosity. > > Since the bursary is a CIFRE, there will be some part of interaction > with industries. > > Applications and requests for further information should be directed > to Jean-Claude Paul (Jean-Claude.Paul@inria.fr). > > Nicolas Holzschuch > ISA research team, INRIA-Lorraine. > From owner-globillum@imag.fr Tue Jun 23 08:14:04 1998 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id IAA02319 for ; Tue, 23 Jun 1998 08:14:02 -0700 (PDT) Received: (from daemon@localhost) by imag.imag.fr (8.8.5/8.8.5) id QAA26166 for globillum-imag-outgoing; Tue, 23 Jun 1998 16:09:25 +0200 (MET DST) From: Francois Sillion Message-Id: <199806231408.QAA04576@safran.imag.fr> Subject: no subject (file transmission) To: globillum@imag.fr (Global Illumination List) Date: Tue, 23 Jun 1998 16:08:47 +0200 (MDT) Reply-To: Francois.Sillion@imag.fr X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R Dear Globillumers, I feel terrible for taking so long to come back to the issue of email address filtering on globillum. Some of you might be wondering why their messages took so long to appear on the list. As I said, our administrators here decided to prevent posting to mailing lists from non-members. Since the filter is based on the email address used to register you in the list, any email sent from another address will be blocked. I am appending in the next message the current list of addresses I have. Please take a minute to check that your address is correct, and is the one used when you *send* messages. Some people certainly have a problem, if they use a different email address for receiving and sending messages. I don't have a real answer for them, the only workaround I can see is to add both of their addresses (they may then receive two copies of each and every message). When the duplication is due to an anti-spam scheme, one might hope that one of the two copies will be blocked as "spam" :-) Anyway, you should ALWAYS be careful when sending email to the list and check that you are sending from the "authorized" address. I am also appending a number of messages which were blocked by our system. Again, please excuse the delay. The authors of all these messages should definitely contact me to solve the problem. Please contact me if you have any questions or want your address changed. +------------------+------------------------------------------------------+ | Francois SILLION | iMAGIS - GRAVIR/IMAG, B.P. 53, 38041 Grenoble Cedex 9| | ' | France. Tel:+33 4 76 51 43 54 - Fax:+33 4 76 63 55 80| +------------------+--------+---------------------------------------------+ | Francois.Sillion@imag.fr | http://www-imagis.imag.fr/~Francois.Sillion | +---------------------------+---------------------------------------------+ ------------------------------------------------------------------------ Messages that got blocked: please read and make sure they did not come from you! ------------------------------------------------------------------------ Subject: BOUNCE globillum@imag.imag.fr: Non-member submission from ["Stephen H. Westin" ] Subject: Re: IES Lighting Handbook Reply-To: westin@graphics.cornell.edu References: <01bd7f4b$902d3b00$2d2aa8c0@ledalite045.ledalite.com> Ian Ashdown wrote: > The IES Lighting Handbook, Eighth Edition, is available directly from = > the Illuminating Engineering Society of North America: > > Tel: (212) 248-5000 > Fax: (212) 248-5017 > URL: www.iesna.org > > The cost of the book is $389.00 US for non-members and $225.00 US for = > members. And note that membership dues are less than the difference; it's worth joining just to save money on the handbook. -Stephen H. Westin Any information or opinions in this message are mine: they do not represent the position of Cornell University or any of its sponsors. ------------------------------------------------------------------------ Subject: BOUNCE globillum@imag.imag.fr: Non-member submission from [Fredo Durand ] Date: Tue, 19 May 1998 10:40:53 +0200 From: Fredo Durand Organization: iMAGIS Subject: siggraph 98 papers on the net Hi, with the help of Tim Rowley, I've gathered a lot of links on the electronic versions of the papers that will be presented at siggraph this year. They are available at http://www-imagis.imag.fr/Membres/Fredo.Durand/Book/sig98.html Not all papers are available at the moment, if you know a link I have forgotten or missed, please let me know. By the way, these are part of my collection of computer graphics links where you can find web pages of researchers, labs, conferences, image galleries, code, etc. http://www-imagis.imag.fr/~Fredo.Durand/book.html Fredo Durand iMAGIS Grenoble, France http://www-imagis.imag.fr/~Fredo.Durand ------------------------------------------------------------------------ Subject: BOUNCE globillum@imag.imag.fr: Non-member submission from ["Ian Ashdown" ] From: "Ian Ashdown" To: Cc: Subject: UNIX-based radiosity renderer available Date: Thu, 21 May 1998 09:37:31 -0700 Dr. Ugur Gudukbay (gudukbay@CS.Bilkent.Edu.TR) and his students at the Department of Computer Engineering and Information Science, Bilkent University (Ankara, Turkey) have kindly ported my hopelessly Windows-centric Helios Radiosity Renderer to the UNIX operating environment. If anyone is looking for C++ source code for a basic but effective progressive radiosity renderer, you can download helios_tar.tar from http://www.cs.bilkent.edu.tr/~gudukbay/home.html. Ian Ashdown, P. Eng. | READ THE BOOK! Vice President, R & D | Radiosity: A Programmer's Perspective byHeart Consultants Limited | John Wiley & Sons 1994 West Vancouver, BC (Canada) | http://mypage.direct.ca/b/byheart ------------------------------------------------------------------------ Subject: BOUNCE globillum@imag.imag.fr: Non-member submission from ["A. T. Campbell, III" ] Date: Fri, 22 May 1998 14:35:49 -0500 From: "A. T. Campbell, III" Subject: new job/address Friends/Colleagues/etc., I have recently started a job at Schlumberger. My new contact information, effective immediately, is below: e-mail: atcampbell@slb.com address: Schlumberger Austin Product Center 8311 North FM 620 Austin, Texas 78726 USA phone: (512)331-3382 My home address has not changed Thanks for your time. -- A. T. Campbell, III (atcampbell@slb.com) Phone:(512)331-3382 Fax:(512)331-3387 Schlumberger Austin Product Center, 8311 N. FM 620, Austin, TX 78726 ------------------------------------------------------------------------ Subject: BOUNCE globillum@imag.imag.fr: Non-member submission from ["Andrew J. Willmott" ] Date: Fri, 22 May 1998 21:34:55 -0400 To: berruyer@AVO.fr From: "Andrew J. Willmott" Subject: Re: FW: wavelet radiosity with triangular mesh Cc: globillum@imag.fr >> Hello, >> I'm currently working on a radiosity project consisting in >> comparing different algorithms. I'm now facing the wavelet >> problem. As a matter of fact, all the radiosity litterature that i've read >> only considers quadrilateral polygons. >> Would you mind telling me if there have been researches >> about wavelet radiosity with a triangular mesh ? >> In this case, do you know where i could get any information ? >> >> Thanks in anticipation. >> >> Benot BERRUYER >> berruyer@avo.fr I know that at least Philippe Bekaert and I have adapted wavelet radiosity to triangular meshes. (I think there are also some triangular coefficients listed in Peter Schroeder's thesis.) I have a technical note online at http://www.cs.cmu.edu/~radiosity/notes/note-coeffs.[ps|pdf] which discusses wavelet radiosity operations in a matrix-oriented setting, lists the necessary coefficients for these operations, and gives some examples of how to use them. It includes coefficients for the M[2-3], F[2-3] bases for both quadrilaterals and triangles. You may also want to download Philippe et. al's RenderPark and/or my 'rad' radiosity program and try looking at the code. They can be found at: http://www.cs.kuleuven.ac.be/cwis/research/graphics/RENDERPARK http://www.cs.cmu.edu/~radiosity/dist Cheers, Andrew --- mailto:a.willmott@cs.cmu.edu ------- http://www.cs.cmu.edu/~ajw --- ------------------------------------------------------------------------ Subject: BOUNCE globillum@imag.imag.fr: Non-member submission from ["Stephen H. Westin" ] Date: Tue, 2 Jun 1998 11:46:40 -0400 From: "Stephen H. Westin" To: globillum@imag.fr Subject: Thesis on-line My old Master's thesis (from 1992) has made it to the Web: Also available are: o '92 SIGGRAPH paper (full text and images) o Images from the paper, thesis, and SIGGRAPH talk o Microgeometry for a Gaussian rough surface, used in the paper and the thesis ------------------------------------------------------------------------ Subject: BOUNCE globillum@imag.imag.fr: Non-member submission from ["Stephen H. Westin" ] Subject: Re: gonio-photometry > Hi all; > > Does anyone know of any companies or academic institutions that can provide > a gonio-photometer service for measuring the BRDFs of everyday materials? > > Does anyone have any experiences with such services? Does anyone know where > any such data is available, to download? We have a gonioreflectometer that I think of as being on the verge of operational. While we have no plans to offer a measurement service, we have posted one measured BRDF, with hopes for more in the future. See ------------------------------------------------------------------------ Subject: BOUNCE globillum@imag.imag.fr: Non-member submission from [hertjwr@us.ibm.com] From: hertjwr@us.ibm.com To: globillum@imag.fr cc: pellelgrini@imc.pi.cnr.it Date: Sun, 21 Jun 1998 12:54:03 -0400 Subject: form factors on line Hi Globillumers -- I don't remember anyone else bringing this up, but I have been a little out of touch so maybe I missed it. Anyway, I just found that Jack Howell's "Catalog of Radiation Heat Transfer Configuration Factors" is now on line (it used to be only in a book that you could only find in some Engineering libraries). It's at: http://sage.me.utexas.edu/~howell/ Section C is not completely filled in, so perhaps it is still a work in progress. At least now everyone can have access to infamous cow factors: http://sage.me.utexas.edu/~howell/sectionb/b-63.html -- Holly Rushmeier holly@watson.ibm.com From owner-globillum@imag.fr Tue Jun 23 08:26:37 1998 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id IAA02336 for ; Tue, 23 Jun 1998 08:26:34 -0700 (PDT) Received: (from daemon@localhost) by imag.imag.fr (8.8.5/8.8.5) id QAA26233 for globillum-imag-outgoing; Tue, 23 Jun 1998 16:09:57 +0200 (MET DST) From: Francois Sillion Message-Id: <199806231409.QAA04591@safran.imag.fr> Subject: GLOBILLUM: new messages and important email-address issue To: globillum@imag.fr (Global Illumination List) Date: Tue, 23 Jun 1998 16:09:18 +0200 (MDT) Reply-To: Francois.Sillion@imag.fr X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R ------------------------------------------------------------------------ ### Global Illumination mailing list # # # append the following to your .mailrc file # # send corrections/additions to globillum-request@imag.fr # (which is forwarded to Francois Sillion) # The preferred way to send mail to everyone on the list is to mail to # globillum (aliased below), where a master copy of list is being maintained. # Maneesh Agrawala; PhD Student, Stanford University alias agrawala maneesh@uni.Stanford.EDU # Farah Al-Agha; University of Bristol, England. # I am interested in the following areas: Hierarchical Radiosity, # Discontinuity meshing, virual studio, Augmented reality and virtual reality. alias alagha alagha@cs.bris.ac.uk # Mike Allison alias mallison mike@documentum.com # Carlos Urena Almagro; ETS Ingenieria Informatica; # Universidad de Granada; 18071 Granada; Spain alias almagro almagro@goliat.ugr.es # John Amanatides, York U, Toronto alias amanatides amana@cs.yorku.ca # Jason Andreas; illipse Inc # CG interests; natural-phenomena, more specifically, realistic # lightning simulation, plants/trees, and clouds to go with the lightning alias andreas jandreas@ultranet.com # Jean-Christophe Arnu; IUP Ingenierie de Systemes Informatiques de Toulouse alias arnu isi2g7@cict.fr # Jim Arvo; California institute of technology alias arvo arvo@cs.caltech.edu # Ian Ashdown; Ledalite Architectural Products Inc.; Langley, B.C.; Canada alias ashdown iashdown@ledalite.com # Godavarthy Sreenadha Babu ; University of South Carolina # I am looking at single pass algorithms for accurate solutions to global # illumination problem. My major focus right now is on wavelets, sparse # representation of the integral operators and error analysis of the # integral solution. alias babu godavart@cs.sc.edu # Sanjay Bakshi; SGI alias bakshi sbakshi@aw.sgi.com # Kavita Bala; MIT graphics group alias bala kaybee@graphics.lcs.mit.edu # Gladimir V.G. Baranoski; University of Calgary alias baranoski gbaranos@cpsc.ucalgary.ca # Rui Bastos; Graduate Student, University of North Carolina at Chapel Hill alias bastos bastos@cs.unc.edu # Dan Baum, Silicon Graphics alias baum drb@sgi.com # Philippe Bekaert; K. U. Leuven (Belgium) alias bekaert philippe@idefix.cs.kuleuven.ac.be # Sergio Gonzalo Besuievsky; Universitat de Girona alias besuievsky gonzalo@baloo.udg.es # Christian-A. Bohn; Dept. Visualization and Media Systems Design (VisWiz,VMSD) # Institute for Media Communication (IMK), GMD. alias bohn bohn@gmd.de # Samuel Boivin ; INRIA alias boivin Samuel.Boivin@inria.fr # Chris Borel; SST-8, MS D438; Los Alamos National Lab; Los Alamos, NM 87545 # interests: simulation of lighting under vegetative canopies alias cborel cborel@lanl.gov # Kadi Bouatouch; IRISA; Campus de Beaulieu; 35042 Rennes Cedex; France # interests: ray tracing, sampling, realism, physics & perception alias bouatouch Kadi.Bouatouch@irisa.fr # Chris Buckalew, Cal Poly alias buckalew buckalew@polyslo.calpoly.edu # Eduardo Bustillo Iceta; # My main interests are Monte Carlo radiosity, meshing techniques, # BDRF modelization and artificial intelligence alias bustillo epabuice@bicc00.bi.ehu.es # Emilio Camahort; University of TExas Austin alias camahort ecamahor@cs.utexas.edu # Alvin T. Campbell III; Schlumberger Austin Product Center 8311 North FM 620 # Austin, Texas 78726 USA phone: (512)331-3382 # interests: global illumination, heat transfer, animation, scientific vis. alias campbell atcampbell@slb.com # Pedro Cano Olivares; Universidad de Granada, Spain alias canoolivares pcano@goliat.ugr.es # Marcos C. C. Carrard; University of Ijuí (Brazil) alias carrard carrard@sede.unijui.tche.br # Mateu Sbert Casasayas # interests: doing thesis on Monte Carlo radiosity alias casasayas sbert@lsi.upc.es # Alan Chalmers; Dept. of Computer Science; University of Bristol; # University Walk; Bristol; BS8 1TR; United Kingdom # interests: large parallel MIMD computers for radiosity and ray tracing alias achalmers alan@compsci.bristol.ac.uk # Michael Chelle alias chelle chelle@bcgn.grignon.inra.fr # Eric Chen, Apple alias chen chense@rlspace.com # Niels J. Christensen; Technical U. Denmark; B. 116, DK-2800 Lyngby; Denmark alias nchristensen iftnjc83@vm.uni-c.dk # Per H. Christensen; mental images, Fasanenstrasse 81, D-10623 Berlin, Germany # interests: global illumination, photorealistic rendering, shape from shading alias pchristensen per@mental.com # Adrian J. Chung; Imperial College of Science, Technology and Medicine, London #Computationally intensive applications like those found in global illumination #pose are typically developed with the implicit assumption of a high-end #uniprocessor with practically infinite RAM. My research focuses on the porting #issue, particularly when making use of parallelism. alias chung ajc@doc.ic.ac.uk # Michael Cohen, Microsoft alias mcohen mcohen@microsoft.com # Steven Collins; Image Synthesis Group, Trinity college, Dublin # Interests: light ray tracing, illumination from transparent objects, # distribution ray tracing, wavefront tracking. alias collins Steven.Collins@cs.tcd.ie # Antonio Costa; Comp. Graphics & CAD; INESC; # Largo Mompilher 22; 4100 Porto Portugal alias costa acc@asterix.inescn.pt # Cornell Students, includes Himlan & others; but not Greenberg or Arvo alias cornell_students gi-students@graphics.cornell.edu # Andre Mauricio CUNHA CAMPOS; ISIMA, Clermon-Ferrand, France alias cunha andre@sp.isima.fr # Brian Curless; Stanford # interests: zonal radiosity methods alias curless curless@candor.Stanford.EDU # Jubin P. Dave; U. of New Hampshire alias jdave jd@kepler.unh.edu # DENIEL Jean-Marc; CSTB, 11 rue Henri Picherit,B.P. 82341,44323 Nantes Cedex 3 alias deniel deniel@cstb.fr # David L. DiLaura; Senior Instructor, Civil and Architectural Engineering; # University of Colorado; Boulder, CO 80309 alias dilaura dilaura@bechtel.colorado.edu # Akio Doi; SUNY Stony brook. # My interest fields are a global illumination model, radiosity, volume # rendering, volume graphics, and so on. alias doi doi@sbcs.cs.sunysb.edu # Gavin Donaldson-Selby; Technikon Natal, Durban, South Africa. # application of global illumination techniques (and software) in stage # lighting design. alias donaldson artlite@iaccess.za # Julie Dorsey; Assistant Professor, Architecture, MIT alias dorsey dorsey@graphics.lcs.mit.edu # George Drettakis, iMAGIS/IMAG, BP 53 F-38041 Grenoble Cedex 09 France # interests: sampling and filtering techniques for GI, quality & error metrics alias drettakis George.Drettakis@imag.fr # Emmanuel Dumont; Universite de Montreal # rendering of natural phenomena alias dumont dumont@iro.umontreal.ca # Fredo Durand; iMAGIS, Grenoble, France alias fdurand Fredo.Durand@imag.fr # Philip Dutre; Computer Graphics Research Group, Katholieke Universiteit Leuven # Interests: Monte Carlo solutions for global illumination, adaptive # probability density functions, potential-driven algorithms alias dutre Philip.Dutre@cs.kuleuven.ac.be # Pavol Elias; Technical University Vienna alias elias elias@cg.tuwien.ac.at # Dieter Fellner; Bonn University, Germany alias fellner fellner@cs.uni-bonn.de # James A Ferwerda; Cornell University alias ferwerda jaf@graphics.cornell.edu # Eugene Fiume, U. of Toronto alias fiume elf@dgp.utoronto.ca # David Forsyth alias forsyth daf@CS.Berkeley.EDU # Alain Fournier, U. of British Columbia, Vancouver BC, Canada alias fournier fournier@cs.ubc.ca # Don Fussell, U. of Texas, Austin alias fussell fussell@cs.utexas.edu # Gonzalo Cerruela Garcia; # I am doctoral student in Computer Science . I interesting in Radiosity # method for global illumination . alias garcia el1segag@sun630.uco.es # Robert Garmann; University of Dortmund # rendering, hierarchical methods, monte-carlo-methods, parallel computing alias garmann garmann@ls7.informatik.uni-dortmund.de # Neil Gatenby, Manchester Computing Centre, Manchester, England # interests: alternatives to hemicube, accurate numerical form factors alias gatenby neil@lightwork.co.uk # Joe Geigel; Pittsburgh Supercomputing Center alias geigel geigel@psc.edu # Reid Gershbein; Stanford University alias gershbein rsg@uni.stanford.edu # Simon Gibson # Interests: Hierarchical Radiosity: Error-Estimates/Mesh Optimisation/Parallel # Implementations/Dynamic Environments and use in Virtual Reality. alias gibson gibsons@cs.man.ac.uk # Stephen Gifford, Electrical and Computer Engineering Dept, Carnegie Mellon # interests: implemented radiosity/ray tracing hybrid on Connection Machine alias gifford Stephen.Gifford@maps.cs.cmu.edu # Andrew Glassner, Microsoft alias glassner glassner@microsoft.com # Narendra Goel, Wayne State U. alias goel ngoel@cs.wayne.edu # Martin Grabenstein; Mental Images alias grabenstein martin@mental.de # Chuck Grant, Lawrence Livermore Lab alias grant grant1@llnl.gov # Don Greenberg c/o Fran Brown, Cornell U. alias greenberg dpg@graphics.cornell.edu # Larry Gritz ; Pixar alias gritz lg@pixar.com # Leo Guibas; CS Dept, Stanford U. / DEC Systems Research Center, Palo Alto alias guibas guibas@cs.stanford.edu # Eric Haines, 3D/Eye alias haines erich@acm.org # Pat Hanrahan, Stanford U. alias hanrahan hanrahan@cs.stanford.edu # Brian W. Heal; School of Information Science; Portsmouth Polytechnic; # Mercantile House; Hampshire Terrace; Portsmouth, PO1 2EG; United Kingdom # interests: rendering octree models, post-hidden-surface-removal rendering alias heal healb@csovax.portsmouth.ac.uk # Paul Heckbert; Computer Science Dept.; Carnegie Mellon University; # 5000 Forbes Ave; Pittsburgh PA 15213-3891; USA # interests: finite element & integral equation methods for global illumination alias heckbert ph@cs.cmu.edu # David Hedley alias hedley hedley@cs.bris.ac.uk # Wolfgang Heidrich; University of Erlangen # I am a PhD student at the University of Erlangen with research interests in # both global illumination and hardware accellerated rendering alias heidrich heidrich@informatik.uni-erlangen.de # Steve Hollasch; Microsoft alias hollasch stevehol@MICROSOFT.com # Nicolas Holzschuch. INRIA Lorraine. alias holzschuch Nicolas.Holzschuch@loria.fr # Helen H. Hu; Univ. of Utah alias helenhu hhh@facility.cs.utah.edu # Philip Hubbard; Washington University # My research interests include global illumination and time-critical # algorithms for the real-time display of global-illumination solutions. alias hubbard pmh@cs.wustl.edu # Alexander Ivanov alias ivanov Alexander.Ivanov@comlab.ox.ac.uk # A. M. Jelle Post; TU Delft # physically correct lighting studies in the architects designing stage. alias jelle zeno@euronet.nl # Henrik Wann Jensen; Institute of Graphical Communication # Technical University of Denmark; Building 116; 2800 Lyngby; Denmark alias jensen henrik@mental.com # J. P. Jessel; Institut de Recherche en Informatique de Toulouse; # Universite Paul Sabatier; 31062 Toulouse; France # interests: parallel radiosity and ray tracing algorithms on Transputers alias jessel jessel@irit.fr # Graham Jones; Oxford U. alias gjones graham@robots.oxford.ac.uk # Fern Hunt; NIST alias hunt fern.hunt@nist.gov # Vincent Jolivet; Faculte des Sciences de LIMOGES alias jolivet jolivet@unilim.fr # Kazufumi Kaneda; Electric Machinery Lab, Hiroshima U. alias kaneda kin@eml.hiroshima-u.ac.jp # Konrad F. KARNER; Institute for Computer Graphics; # Graz University of Technology alias karner karner@icg.tu-graz.ac.at # Alexander Keller ; Universitaet Kaiserslautern. Fachbereich Informatik # D-67653 Kaiserslautern. Postfach 3049. alias keller keller@informatik.uni-kl.de # Lawrence Kesteloot; # I'm a graduate student at the University of North Carolina. My interests # are global illumination through path tracing and other monte carlo methods. alias kesteloot kesteloo@cs.unc.edu # Slawomir Kilanowski; Software engineer developing 3D graphics applications. # Owner of one-man software company rendering development services. # Specific interests in global illumination: Fast, robust methods for # calculation of interreflected light in architectual visualization. alias kilanowski metagram@pwr.wroc.pl # Dave Kirk alias kirk davidk@nvidia.com # Arjan Kok; TNO-FEL, P.O.Box 96864, 2509 JG 's-Gravenhage, The Netherlands alias kok kok@fel.tno.nl # Craig Kolb, Stanford (but email address is Princeton) alias kolb cek@cs.princeton.edu # Juhana Kouhia; # I'm mathematics student (with studies in physics) and just interested # in the theory of global illumination. alias kouhia kouhia@nic.funet.fi # Wolfram Kresse ; Fraunhofer IGD, Darmstadt # Our group is developing a tool for Raytracing, Radiosity and # VR model preparation. alias kresse wkresse@igd.fhg.de # Subodh Kumar; Computer Science, UNC, Chapel Hill NC 27599 alias kumar kumar@cs.unc.edu # Eric Lafortune; Cornell University Progra of COmputer Graphics # interests: mathematical models and Monte Carlo techniques alias lafortune eric@graphics.cornell.edu # Paul Lalonde, U. of British Columbia alias lalonde lalonde@cs.ubc.ca # Mathias Lang; DACOS Software GmbH. Software engeneer at SAP alias lang mathias.lang@sap-ag.de # Michael Langer; NEC Research Institute. # I am computer vision researcher interested in how material and shape # properties of surfaces can be automatically recovered from images. alias langer langer@research.nj.nec.com # George Leaver; University of Manchester, England # currently undertaking an M.Sc in the Computer Graphics Unit of the university. # Interests: Higher Order Radiosity and NURBS alias leaver leaverg@cs.man.ac.uk # Justin Legakis; MIT alias legakis legakis@graphics.lcs.mit.edu # Marc Levoy, CS Dept, Stanford U. alias levoy levoy@cs.stanford.edu # Bob Lewis; CS Dept; U. of British Columbia; # 6356 Agricultural Road; Vancouver, BC V6T 1W5; Canada # interests: 3-D texture, ray tracing, radiosity, parallelism alias blewis bobl@cs.ubc.ca # Lewis; Dept. Geography; University College London # 26 Bedford Way; London WC1H 0AP; UK # I don't use a first name, "I'm known just as Lewis" # interests: modeling canopy reflectance, remote sensing alias plewis plewis@ps.ucl.ac.uk # Robert Lipman, NIST # I work on a project related to the reflectance (appearance) of materials alias lipman robert.lipman@nist.gov # Lars Lippert; Swiss Federal Institute of Technology Zuerich # I am a research assistant and I am working on my PhD-Thesis. I am generally # interested in global illumination and multiresolution approaches. alias lippert lippert@inf.ethz.ch # Dani Lischinski; Hebrew University of Jerusalem alias lischinski danix@cs.huji.ac.il # LORIA laboratory; (Nancy, France) INRIA-lorraine, CRIN alias loria globillum@loria.fr # Celine Loscos; iMAGIS, Grenoble, France alias loscos Celine.Loscos@imag.fr # Hugh McCabe; University College Dublin, Ireland alias mccabe hugh.mccabe@ucd.ie # Ann Mc Namara; Univ. of Bristol, Vision & Graphics Lab. alias mcnamara mcnamara@cs.bris.ac.uk # Alois Maierhofer ; TU Graz (Austria) alias maierhofer ali@icg.tu-graz.ac.at # Eric Maisel; IRISA, Rennes, France alias maisel maisel@irisa.fr # Dinesh Manocha; UNC # interested in problems related to modeling and rendering. # recent work on problems in display large datasets ( polygons or NURBS) # and eventually radiositizing them. alias manocha manocha@cs.unc.edu # Mathieu Marache ; LORIA #marache = Mathieu Marache = Mathieu.Marache@loria.fr # John Mardaljevic; De Montfort University alias mardaljevic jm@dmu.ac.uk # Daniele Marini; Eidomatics Lab, Computer Science Dept, Univ. of Milan; Italy # interests: radiosity, ray tracing, parallel processing (Meiko) alias marini marini@imiucca.csi.unimi.it # Ignacio Martin Campos # Universitat Politecnica de Catalunya # interests: radiosity and dynamic environments alias imartin imartin@ima.udg.es # Nelson Max, Lawrence Livermore Lab alias max max2@llnl.gov # Daniel Meneveaux; IRISA, Rennes, France alias meneveaux dmenevea@irisa.fr # Christian Metge; Institut de Recherche en Informatique de Toulouse; # Universite Paul Sabatier; 31062 Toulouse; France # interests: parallel discrete radiosity and ray tracing algorithms # (Transputers, workstation networks) alias metge metge@irit.fr # Don Mitchell, Microsoft alias dmitchell donm@microsoft.com # Tomas Moller; Lund Institute of Technology # developping a radiosity program for use with Virtual Reality applications. alias moller tompa@clarus.se # Hassan Moubaraki; MIC (Media Integration and Communications) # ATR Research Labs in Kyoto, Japan # My research topics include computer animation and graphics (facial # animation) and I am interested in some research issues in global illumination. alias moubaraki moubarak@mic.atr.co.jp # Gordon Mueller; Univ. Bonn # My research interests are widespread: # efficient raytracing and radiosity in general; alias gmueller mueller@graphics.cs.uni-bonn.de # Ken Musgrave; The George Washington University # Interests: natural phenomena, e.g., light propagation in nature. alias musgrave musgrave@seas.gwu.edu # Karol Myszkowski; The University of Aizu # My interest in global illumination are focused on practical lighting # simulation algorithms handling complex environments, experimental validation # of such algorithms, psyhophysiological aspects of image display. alias myszkowski k-myszk@u-aizu.ac.jp # Fabrice Neyret; I.N.R.I.A. Rocquencourt, Projet Syntim alias neyret Fabrice.Neyret@imag.fr # Nguyen Duc Cuong; TU Dresden alias nguyen cn1@irz.inf.tu-dresden.de # Jeffry Nimeroff; Penn University alias nimeroff jnimerof@graphics.cis.upenn.edu # Tomoyuki Nishita; Electric Machinery Lab, Hiroshima U. alias nishita nis@eml.hiroshima-u.ac.jp # Eric Paquette; Universite' de Montre'al # Student, Master's degree at Universite de Montreal (Canada) # Interested in radiosity, monte-carlo and ray-tracing techniques used for # global illumination. alias paquette bs527@freenet.carleton.ca # Christopher Patmore; Programming Research Group; Oxford U. # interests: skylight radiosity alias patmore cjp@prg.oxford.ac.uk # Gustavo Patow; University of Girona # My main interest is finding faster ways to compute photorrealistic # images, specially solving the global illumination problem (or parts of # it! :-) ) in a fast and more or less accurate way alias patow dagush@sol.info.unlp.edu.ar # Sumant Narayan Pattanaik; IRISA; Rennes; France alias pattanaik sumant@graphics.cornell.edu # Charles Patterson; Georgia Tech # I'm a Ph.D. at Georgia Tech and I work on radiosity clustering. # My formal advisor is Dr. Holly Rushmeier. alias patterson charliep@cc.gatech.edu # Mathias Paulin; Institut de Recherche en Informatique de Toulouse; # Universite Paul Sabatier; 31062 Toulouse; France # interests: parallel radiosity and ray tracing algorithms (Transputers, PVM) # shadow accuracy, transfer simulations in dense foliage alias paulin paulin@irit.fr # Hans K. Pedersen; Stanford University alias pedersen hkp@aperture.stanford.edu # Frederic Perez Cazorla; University of Girona alias perez frederic@ima.udg.es # Bernard Peroche; Ecole des Mines de Saint Etienne # domains of interest : ray tracing, color reproduction, BRDF models alias peroche peroche@emse.fr # Ingmar Peter; University of Dortmund # I am student of computer science at the University of Dortmund and currently # writing my master theses, an object-oriented Monte-Carlo Ray-Tracer. alias ipeter peter@ls7.informatik.uni-dortmund.de # Sylvain Petitjean; ISA project, CRIN, Nancy (France) alias petitjean Sylvain.Petitjean@loria.fr # Fabrizio Pezzola; eyeTech Graphix; I am a computer engineering student and # I'm writing a Ray-tracer which use global illumination algorithms. alias pezzola mc4242@mclink.it # Matt Pharr alias pharr mmp@lux.Stanford.EDU # Georg Pietrek; Universitaet Dortmund. # radiosity, combination radiosity/ray tracing, OO design for rendering programs alias pietrek pietrek@ls7.informatik.uni-dortmund.de # Pierre Poulin; Dept. IRO, Universite de Montreal, # C.P. 6128, succ. Centre-Ville, Montreal, Quebec, Canada H3C 3J7 # interests: illumination, rendering, realism alias poulin poulin@iro.umontreal.ca # Bob Powell ; Rhythm and Hues. http://www.rhythm.com/~bpowell/index.html alias powell bpowell@rhythm.com # Jan Prikryl; T.U. Vienna, Institute of Computer Graphics and Visualisation alias prikryl prikryl@cg.tuwien.ac.at # Claude Puech; iMAGIS/IMAG, BP 53, F-38041 Grenoble Cedex 9. France alias puech Claude.Puech@imag.fr # Xavier Pueyo; Dept. Llenguatges i Sistemes Informatics; # Universitat Politecnica de Catalunya; Av. Diagonal, 647 planta 8; # 08028-Barcelona; Spain; # interests: diffuse environments alias pueyo xavier@ima.udg.es # Werner Purgathofer; Institute of Computer Graphics; Techn. Univ. Vienna; # Karlsplatz 13 / 186; A-1040 Wien / Austria # interests: radiosity, ray tracing, color, virtual reality, # dithering and quantization alias purgathofer wp@cg.tuwien.ac.at # Szymon Rusinkiewicz ; stanford # I am currently working in BRDF measurement and representation, and am also # interested in the relation between spatially varying BRDFs and light fields. alias rusinkiewicz smr@cs.stanford.edu # Ari Rappoport alias rappoport arir@cs.huji.ac.il # Jordi Regincos alias regincos jordir@upisun4.uab.es # Panu Rekola; Computer Science Dept, Helsinki U. of Tech.; Finland alias rekola pre@cs.hut.fi # Luc Renambot; IRISA # I began a PhD at IRISA in Rennes about the parallelization # of global illumination and radiosity methods. alias renambot renambot@irisa.fr # Erik Robson: interested in Global illumination's advantages in architectural # situations, as a sculptor/writer/photographer turned digital artist alias robson fiction@pressroom.com # Barry Carlton Ruff alias ruff bruff@wsicorp.com # Holly Rushmeier, Computing and Applied Math Lab; # National Institute for Standards and Technology; Gaithersburg, Maryland alias rushmeier holly@watson.ibm.com # David Salesin; U. of Washington alias salesin salesin@cs.washington.edu # Stefan Schaefer; University of Bonn alias schaefer schaefer@graphics.cs.uni-bonn.de # Christophe Schlick; LaBRI; U. of Bordeaux; 351 Cours de la Liberation # 33400 Talence; France # interests: ray tracing, radiosity, antialiasing, general reflectance functions alias schlick schlick@labri.u-bordeaux.fr # Karl Johann Schmidt; Mental Images alias kjschmidt kjs@mental.de # Olaf Schmidt; University of Paderborn # PARAGRAPH-Project, parallel simulation of global illumination alias oschmidt merlin@uni-paderborn.de # Frank Schoeffel; Fraunhofer IGD in Darmstadt, Germany alias schoeffel schoeffe@igd.fhg.de # Roland Schregle; ??? alias schregle schregle@uran.informatik.uni-bonn.de # My interest in global illumination pertains to the photon map. I'm currently # implementing it as part of my master's degree in the computer graphics dept. # at Bonn university. # Michael Schroeder; University of Erlangen # Hierarchical Radiosity, Monte-Carlo methods alias mschroeder Michael.Schroeder@informatik.uni-erlangen.de # Peter Schroeder alias pschroeder ps@cs.caltech.edu # Roberto Scopigno; CNUCE; Consiglio Nazionale delle Richerche; # Via S.Maria, 36; 56100 Pisa; Italy # interests: volume rendering, user interfaces, parallel processing, geography alias scopigno R.Scopigno@cnuce.cnr.it # Peter Segal; # development of commercial applications of global illumination alias psegal Peter.Segal@Bentley.Com # Francisco Seron; Dpto. Ingenieria Electrica e Informatica; # Centro Politecnico Superior de Ingenieros; Universidad de Zaragoza; # C/ Maria Luna s/n; E-50015 Zaragoza; Spain alias seron pseron@mcps.unizar.es # Pete Shirley, Indiana U., on leave at Cornell as of 7/94 alias shirley shirley@cs.utah.edu # Francois Sillion; IMAG; Grenoble; France alias sillion Francois.Sillion@imag.fr # Philipp Slusallek; Universitaet Erlangen; # IMMD IX - Graphische Datenverarbeitung; Am Weichselgarten 9; # W-8520 Erlangen, Germany # interests: CAD, surfaces, doing PhD on physical basis of glob. illum. alias slusallek slusallek@informatik.uni-erlangen.de # Brian Smits; University of Utah alias smits bes@cs.utah.edu # Cyril Soler; iMAGIS, Grenoble, France alias csoler Cyril.Soler@imag.fr # Rick Speer alias speer speer@crl.com # Stephen Spencer alias spencer spencer@cgrg.ohio-state.edu # Marc Stamminger; University of Erlangen # Wavelet Radiosity/Radiance, # in future: Clustering, Parallelization of Radiosity/Radiance algorithms alias stamminger Marc.Stamminger@informatik.uni-erlangen.de # Jorge Stolfi alias stolfi stolfi@dcc.unicamp.br # Eric Stollnitz alias stollnitz stoll@amath.washington.edu # Wolfgang Stuerzlinger, Department of Graphics and Parallel Processing, # Johannes Kepler University, Linz, Austria alias stuerzlinger wrzl@gup.uni-linz.ac.at # K. R. Subramanian; AT&T Bell Labs; Murray Hill, NJ alias ksubramanian krs@allegra.att.com # Kelvin Sung; Alias Research Inc. #110 Richmond Street East # Toronto, Canada, M5C 1P1 # interests: fast ray tracing, modular global illumination software alias sung ksung@aw.sgi.com # Frank Suykens; Computer Graphics Research Group, K.U.Leuven alias suykens Frank.Suykens@cs.kuleuven.ac.be # Filippo Tampieri; Lightscape Technologies, Inc; San Jose, CA alias tampieri fxt@discreet.com # Rasmus Tamstorf; Technical University of Denmark # Monte Carlo based rendering, image processing and computer vision. alias tamstorf tamstorf@fa.disney.com # Seth Teller; MIT alias teller seth@lcs.mit.edu # Pierre Tellier # LSIIT (Laboratoire des Sciences de l'Image, d'Informatique et de # Teledetection); Departement d'Informatique de l'Universite Louis Pasteur; # 7, rue R. Descartes; 67084 Strasbourg; France alias tellier tellier@dpt-info.u-strasbg.fr # J Tidmus; University of the West of England in Bristol alias tidmus jpt@btc.uwe.ac.uk # Robert Tobler. T.U. Vienna, Institute of Computer Graphics and Visualisation alias tobler rft@cg.tuwien.ac.at # Jack Tumblin, Georgia Tech alias tumblin ccsupjt@cc.gatech.edu # Sam Uselton; CSC, NASA Ames, Mountain View, CA alias uselton uselton@nas.nasa.gov # Robert van Liere; Department of Interactive Systems; # Center for Mathematics and Computer Science (CWI); # Kruislaan 413, 1098 SJ Amsterdam, The Netherlands # interests: generalizing radiosity method, parallel methods for radiosity alias vanliere robertl@cwi.nl # Cornelius Skip Van Wyk, Jr; ?? alias vanwyk vanwyk@unm.edu # Eric Veach; Stanford U. # interests: hierarchical global illumination, clustering objects, # global illumination methods for "black box" scene representations alias veach ericv@cs.stanford.edu # Francisco Villatoro; Universidad de Malaga (SPAIN) alias villatoro villa@lcc.uma.es # Gianluca Vezzadini; Alias | Wavefront (Paris, France) # My main interests are in lighting design; I am also very interested in any # debate concerning standardization: of terminology, of file format for data #exchange, etc. alias vezzadini gvezzadini@aw.sgi.com # Bretton Wade; alias bwade bwade@sgi.com # Changyaw Wang; Alias Wavefront # interests: rendering and modeling of complex outdoor environments alias cwang wang@aw.sgi.com # Greg Ward Larson; SGI alias ward gwlarson@positron.CS.Berkeley.EDU # Stephen H. Westin; Cornell Program of Computer Graphics alias westin westin@graphics.cornell.edu # Daniel E. Wexler; R&D Staff; Pacific Data Images alias wexler2 wexler@pdi.com # Alexander Wilkie; T.U. Vienna alias wilkie wilkie@cg.tuwien.ac.at # Peter L. Williams; Vassar College; NASA Ames Research Center alias plwilliams williams@cs.vassar.edu # Andrew J. Willmott; CMU alias willmott Andrew.Willmott@cs.cmu.edu # Jim Winget, Silicon Graphics alias winget jmw@sgi.com # Stephen Wittkopf; Dept of Architecture, Technical University Darmstadt,Germany alias wittkopf wittkopf@hp01.cad.architektur.th-darmstadt.de # Adam Worrall, University of Bristol Graphics Group # Computer Science Department, The University, Bristol, UK alias worrall Adam.Worrall@bristol.ac.uk # Chien Kok Yang; UC Berkeley # My research interests are realistic image synthesis and modeling alias yang ckyang@bach.eecs.berkeley.edu # J. Zanizetti; Ecole des Mines de Saint-Etienne, France. alias zanizetti jzaninet@emse.fr # Dave Zareski ; # development of commercial applications of global illuminatio alias zareski David.Zareski@Bentley.Com # Hansong Zhang; University of North Carolina at Chapel Hill. # My interest include radiosity, interactive 3D graphics, simplification.. alias hzhang zhangh@cs.unc.edu # Sunday Safran Zidonis; I am a student at Columbus State Community College # and am pursuing my second degree in Technical Communications. alias zidonis sundayz@ix.netcom.com # Al Zimmerman; # I am interested in acceleration of global illumination alias azimmerman alz@LanMinds.com # Kurt Zimmerman alias zimmerman kuzimmer@cs.indiana.edu # Andrew Zisserman; Robotics Research Group; Oxford University; UK # interests: computer vision, radiosity alias zisserman az@robots.oxford.ac.uk # Zumtobel Licht GmbH; Schweizerstr. 30; A-6850 Dornbirn; Austria # interests: lighting design visualization, radiosity # (an alias for global illumination folks at the Zumtobel company) alias zumtobel glbi@cophos.co.at # alias globillum_explicit \ agrawala alagha mallison almagro amanatides andreas arnu arvo ashdown babu\ bakshi bala baranoski bastos baum bekaert besuievsky bohn boivin cborel\ bouatouch buckalew bustillo camahort campbell canoolivares carrard\ casasayas achalmers chelle chen nchristensen pchristensen chung mcohen\ collins costa cornell_students cunha curless jdave deniel dilaura doi\ donaldson dorsey drettakis dumont fdurand dutre elias fellner ferwerda\ fiume forsyth fournier fussell garcia garmann gatenby geigel gershbein\ gibson gifford glassner goel grabenstein grant greenberg gritz guibas\ haines hanrahan heal heckbert hedley heidrich hollasch holzschuch helenhu\ hubbard ivanov jelle jensen jessel gjones hunt jolivet kaneda karner keller\ kesteloot kilanowski kirk kok kolb kouhia kresse kumar lafortune lalonde\ lang langer leaver legakis levoy blewis plewis lipman lippert lischinski\ loria loscos mccabe mcnamara maierhofer maisel manocha mardaljevic marini\ imartin max meneveaux metge dmitchell moller moubaraki gmueller musgrave\ myszkowski neyret nguyen nimeroff nishita paquette patmore patow pattanaik\ patterson paulin pedersen perez peroche ipeter petitjean pezzola pharr\ pietrek poulin powell prikryl puech pueyo purgathofer rusinkiewicz\ rappoport regincos rekola renambot robson ruff rushmeier salesin schaefer\ schlick kjschmidt oschmidt schoeffel schregle mschroeder pschroeder\ scopigno psegal seron shirley sillion slusallek smits csoler speer spencer\ stamminger stolfi stollnitz stuerzlinger ksubramanian sung suykens tampieri\ tamstorf teller tellier tidmus tobler tumblin uselton vanliere vanwyk veach\ villatoro vezzadini bwade cwang ward westin wexler2 wilkie plwilliams\ willmott winget wittkopf worrall yang zanizetti zareski hzhang zidonis\ azimmerman zimmerman zisserman zumtobel ### Current number of globillum members: 221 ### END OF GLOBAL ILLUMINATION MAILING LIST +------------------+------------------------------------------------------+ | Francois SILLION | iMAGIS - GRAVIR/IMAG, B.P. 53, 38041 Grenoble Cedex 9| | ' | France. Tel:+33 4 76 51 43 54 - Fax:+33 4 76 63 55 80| +------------------+--------+---------------------------------------------+ | Francois.Sillion@imag.fr | http://www-imagis.imag.fr/~Francois.Sillion | +---------------------------+---------------------------------------------+ From owner-globillum@imag.fr Thu Jul 2 14:31:43 1998 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id OAA15652 for ; Thu, 2 Jul 1998 14:31:42 -0700 (PDT) Received: (from daemon@localhost) by imag.imag.fr (8.8.5/8.8.5) id WAA26633 for globillum-imag-outgoing; Thu, 2 Jul 1998 22:50:48 +0200 (MET DST) Message-ID: <004201bda5fa$e4f7e420$2d2aa8c0@ian-ashdown> From: "Ian Ashdown" To: Subject: New paper of interest Date: Thu, 2 Jul 1998 13:49:22 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003F_01BDA5C0.38990C20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: RO This is a multi-part message in MIME format. ------=_NextPart_000_003F_01BDA5C0.38990C20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This mailing list has been awfully quiet of late ... Some of you may know Kendall Jackson as the author of "The Numerical = Solution of Integral Equations of the Second Kind" (Cambridge University = Press - http://www.cup.org/Titles/58/0521583918.html) or as editor of = the Journal of Integral Equations and Applications = (http://www.math.uiowa.edu/~atkinson/jieapage.html). Ken has coauthored several very interesting papers on the radiosity = equation lately. His most recent paper (26 pages!), "The Planar = Radiosity Equation and its Numerical Solution," is now available as = rdsty-planar.ps.Z and rdsty-planar.pdf.Z from = http://www.math.uiowa.edu/ftp/atkinson/. I have just begun reading this challenging paper, and so I cannot offer = any comments on it. However, it appears to be an important contribution = to global illumination research. Given that it will not be published in = the usual roundup of computer graphics journals, I thought it best to = bring the paper to the attention of this group. Ian Ashdown, P. Eng., LC Head of Research Ledalite Architectural Products http://www.ledalite.com ------=_NextPart_000_003F_01BDA5C0.38990C20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This mailing list has been awfully = quiet of late=20 ...
 
Some of you may know Kendall Jackson = as the=20 author of "The Numerical Solution of Integral Equations of the = Second=20 Kind" (Cambridge University Press - http://www.cup.org/= Titles/58/0521583918.html)=20 or as editor of the Journal of Integral Equations and Applications (http://www.mat= h.uiowa.edu/~atkinson/jieapage.html).
 
Ken has coauthored several very = interesting=20 papers on the radiosity equation lately. His most recent paper (26 = pages!),=20 "The Planar Radiosity Equation and its Numerical Solution," is = now=20 available as rdsty-planar.ps.Z and rdsty-planar.pdf.Z from http://www.math.uiowa.ed= u/ftp/atkinson/.
 
I have just begun reading this challenging paper, = and so I=20 cannot offer any comments on it. However, it appears to be an important=20 contribution to global illumination research. Given that it will not be=20 published in the usual roundup of computer graphics journals, I thought = it best=20 to bring the paper to the attention of this group.
 
Ian Ashdown, P. Eng., LC
Head of Research
Ledalite Architectural Products
http://www.ledalite.com
=
 
------=_NextPart_000_003F_01BDA5C0.38990C20-- From image-based-rendering-owner@cs.unc.edu Tue Jul 7 19:29:50 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id TAA22303 for ; Tue, 7 Jul 1998 19:29:49 -0700 (PDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id TAA24119 for <@sgi.engr.sgi.com:gwlarson@positron.cs.berkeley.edu>; Tue, 7 Jul 1998 19:30:27 -0700 (PDT) mail_from (image-based-rendering-owner@cs.unc.edu) Received: from radiate.engr.sgi.com (radiate.engr.sgi.com [130.62.245.56]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id TAA71809 for <@cthulhu.engr.sgi.com:gwlarson@positron.cs.berkeley.edu>; Tue, 7 Jul 1998 19:30:19 -0700 (PDT) mail_from (image-based-rendering-owner@cs.unc.edu) Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by radiate.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id TAA15227 for ; Tue, 7 Jul 1998 19:29:44 -0700 Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id TAA98083; Tue, 7 Jul 1998 19:29:19 -0700 (PDT) mail_from (image-based-rendering-owner@cs.unc.edu) Received: from austin.cs.unc.edu (austin.cs.unc.edu [152.2.128.87]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id TAA23665; Tue, 7 Jul 1998 19:29:17 -0700 (PDT) mail_from (image-based-rendering-owner@cs.unc.edu) Received: (from majordom@localhost) by austin.cs.unc.edu (8.8.8/8.8.8) id WAA13645 for image-based-rendering-outgoing; Tue, 7 Jul 1998 22:23:48 -0400 (EDT) X-Authentication-Warning: austin.cs.unc.edu: majordom set sender to owner-image-based-rendering@cs.unc.edu using -f Received: from jack.direct.ca (jack.direct.ca [199.60.229.4]) by austin.cs.unc.edu (8.8.8/8.8.8) with SMTP id WAA13640 for ; Tue, 7 Jul 1998 22:23:44 -0400 (EDT) Received: from van-as-07a10.direct.ca (helios) [204.174.249.106] by jack.direct.ca with smtp (Exim 1.82 #1) id 0ytjtV-0000fW-00; Tue, 7 Jul 1998 19:23:41 -0700 Reply-To: "Ian Ashdown" From: "Ian Ashdown" To: Subject: Image-Based Rendering Bibliography update Date: Tue, 7 Jul 1998 19:23:46 -0700 Message-ID: <01bdaa17$6f58c420$6af9aecc@helios> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-image-based-rendering@cs.unc.edu Precedence: bulk Status: R ANNOUNCE: 98/07/01 Release of IBR98.BIB --------------------------------------- IBR98 is a comprehensive bibliography of image-based rendering and near-field photometry papers, theses, articles, and books. It currently includes 146 references -- 40 new additions since the 98/02/01 release. This bibliography is available in BibTex format as IBR98.BIB (with a release date of July 1, 1998) from: http://www.ledalite.com/library-/rrt.htm ftp://ftp.ledalite.com/pub/ibr98.bib As always, it is time-consuming and sometimes difficult to track down conference papers and theses on image-based rendering. If you know of a relevant reference that is not included in these bibliographies, please let us know so that we can include it in the next release. Partial financial support for the maintenance of this bibliography has been provided by the ACM SIGGRAPH Special Projects. Ian Ashdown, P. Eng., LC | READ THE BOOK! Vice President, R & D | Radiosity: A Programmer's Perspective byHeart Consultants Limited | John Wiley & Sons 1994 West Vancouver, BC (Canada) | http://mypage.direct.ca/b/byheart From owner-globillum@imag.fr Tue Jul 7 19:40:30 1998 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id TAA22460 for ; Tue, 7 Jul 1998 19:40:28 -0700 (PDT) Received: (from daemon@localhost) by imag.imag.fr (8.8.5/8.8.5) id EAA10798 for globillum-imag-outgoing; Wed, 8 Jul 1998 04:22:38 +0200 (MET DST) Reply-To: "Ian Ashdown" From: "Ian Ashdown" To: Subject: Global Illumination Bibliography update Date: Tue, 7 Jul 1998 19:21:59 -0700 Message-ID: <01bdaa17$2fcff710$6af9aecc@helios> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R ANNOUNCE: 98/07/01 Release of RADBIB98.BIB ------------------------------------------ RADBIB98 is a comprehensive bibliography of radiosity and related global illumination papers, theses, articles, and books. It currently includes 1,399 references -- 59 new additions since the 98/04/15 release. This bibliography is available in BibTex format as RADBIB98.BIB (with a release date of July 1, 1998) from: http://www.ledalite.com/library-/rrt.htm ftp://ftp.ledalite.com/pub/radbib98.bib Also available from this site is an abridged version of RADBIB98.BIB called GITHESIS.BIB. This bibliography includes 161 references to radiosity and global illumination theses -- 7 new additions since the 98/02/10 release. As always, it is time-consuming and sometimes difficult to track down conference papers and theses on radiosity and global illumination. If you know of a relevant reference that is not included in these bibliographies, please let us know so that we can include it in the next release. Partial financial support for the maintenance of these bibliographies has been provided by the ACM SIGGRAPH Special Projects. Ian Ashdown, P. Eng., LC | READ THE BOOK! Vice President, R & D | Radiosity: A Programmer's Perspective byHeart Consultants Limited | John Wiley & Sons 1994 West Vancouver, BC (Canada) | http://mypage.direct.ca/b/byheart From owner-globillum@imag.fr Wed Jul 8 08:53:33 1998 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id IAA22957 for ; Wed, 8 Jul 1998 08:53:32 -0700 (PDT) Received: (from daemon@localhost) by imag.imag.fr (8.8.5/8.8.5) id RAA15300 for globillum-imag-outgoing; Wed, 8 Jul 1998 17:25:32 +0200 (MET DST) Mime-Version: 1.0 Date: Wed, 8 Jul 1998 11:19:02 -0700 Message-ID: <0061B799.4149@autodesk.com> From: eric.haines@autodesk.com (Eric Haines) Subject: Ray tracing roundtable & bibliography To: Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R Ian's note reminded me of two things worth mentioning here. First, the Nth annual Ray Tracing Roundtable will be meeting at SIGGRAPH on Thursday, July 23rd, from 6:15 to 7:45 pm at the Peabody Hotel (across the street from the convention center) in Bayhill Rooms I & II. At this event we quickly introduce ourselves, then break up to talk with each other about what we've been doing in the field. It fits in nicely in the dead time between papers and the reception. Second, I've updated the free ray tracing bibliography at http://www.acm.org/tog/resources/bib/, and added a link to search the bibliography online (as part of the collection of computer science bibliographies, a wonderful free service). Not too many new references, but a few - let me know if I've missed your work. I've also made Tom Wilson's collection of ray tracing article abstracts available at this site. Eric Haines erich@acm.org http://www.acm.org/tog/editors/erich/ From owner-globillum@imag.fr Thu Jul 16 15:12:53 1998 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id PAA03488 for ; Thu, 16 Jul 1998 15:12:52 -0700 (PDT) Received: (from daemon@localhost) by imag.imag.fr (8.8.5/8.8.5) id XAA14386 for globillum-imag-outgoing; Thu, 16 Jul 1998 23:44:07 +0200 (MET DST) From: Peter Shirley Message-Id: <199807162143.PAA19239@lal.cs.utah.edu> Subject: links and atmospheric persp. To: globillum@imag.fr Date: Thu, 16 Jul 1998 15:43:28 -0600 (MDT) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R Hi Globillumers. Two things: 1. Anybody know any good computer graphics references which have implemented atmospheric perspective in a physically-based way? 2. I am setting up a page of links on global illumination-- http://www.cs.utah.edu/~shirley/gi/ it is barely started. Additions appreciated. See many of you soon. Pete From shirley@cs.utah.edu Thu Jul 16 17:54:57 1998 Received: from wrath.cs.utah.edu (wrath.cs.utah.edu [155.99.198.100]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id RAA03714 for ; Thu, 16 Jul 1998 17:54:56 -0700 (PDT) Received: from phong.cs.utah.edu (phong.cs.utah.edu [155.99.197.68]) by wrath.cs.utah.edu (8.8.8/8.8.8) with ESMTP id SAA16936 for ; Thu, 16 Jul 1998 18:55:28 -0600 (MDT) From: Peter Shirley Received: (from shirley@localhost) by phong.cs.utah.edu (8.8.8/8.8.8) id SAA17888 for gwlarson@positron.CS.Berkeley.EDU; Thu, 16 Jul 1998 18:55:37 -0600 (MDT) Message-Id: <199807170055.SAA17888@phong.cs.utah.edu> Subject: Re: links and atmospheric persp. To: gwlarson (Gregory Ward Larson) Date: Thu, 16 Jul 1998 18:55:37 -0600 (MDT) In-Reply-To: <199807162255.PAA03526@positron.CS.Berkeley.EDU> from "Gregory Ward Larson" at Jul 16, 98 03:55:45 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Status: R I may be using the wrong word-- artists usually call it aerial perspective-- they way distant objects fade and hue-shift due to scattering in air. Pete > > What is "atmospheric perspective?" > > -G > From gwlarson Fri Jul 17 08:25:21 1998 Received: (from gwlarson@localhost) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/970903.SGI.AUTOCF) id IAA04510; Fri, 17 Jul 1998 08:25:21 -0700 (PDT) Date: Fri, 17 Jul 1998 08:25:21 -0700 (PDT) From: gwlarson (Gregory Ward Larson) Message-Id: <199807171525.IAA04510@positron.CS.Berkeley.EDU> To: Peter Shirley Subject: Re: links and atmospheric persp. Status: R Hi Pete, You can do what you want with a pretty simple formula, actually. I combine the ambient value setting in Radiance with an atmospheric extinction coefficient, kappa (in 1/distance), and a scattering albedo, Omega (unitless -- scattering coefficient over absorption plus scattering). The formula for radiance is then: L(s) = [L(0) - Omega*ambient]*exp(-kappa*s) + Omega*ambient where: L = returned distance s = ray travel distance This is formula 14.6 is "Rendering with Radiance." All values are chromatic except distance. -Greg P.S. I think I took this formula originally from Holly'course notes in Paul Heckbert's global illumination course a few Siggraphs ago. From shirley@cs.utah.edu Fri Jul 17 08:33:43 1998 Received: from wrath.cs.utah.edu (wrath.cs.utah.edu [155.99.198.100]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id IAA04564 for ; Fri, 17 Jul 1998 08:33:42 -0700 (PDT) Received: from phong.cs.utah.edu (phong.cs.utah.edu [155.99.197.68]) by wrath.cs.utah.edu (8.8.8/8.8.8) with ESMTP id JAA26296 for ; Fri, 17 Jul 1998 09:34:18 -0600 (MDT) From: Peter Shirley Received: (from shirley@localhost) by phong.cs.utah.edu (8.8.8/8.8.8) id JAA19370 for gwlarson@positron.CS.Berkeley.EDU; Fri, 17 Jul 1998 09:34:26 -0600 (MDT) Message-Id: <199807171534.JAA19370@phong.cs.utah.edu> Subject: Re: links and atmospheric persp. To: gwlarson (Gregory Ward Larson) Date: Fri, 17 Jul 1998 09:34:26 -0600 (MDT) In-Reply-To: <199807171525.IAA04510@positron.CS.Berkeley.EDU> from "Gregory Ward Larson" at Jul 17, 98 08:25:21 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Status: R Thanks Greg. We are using something similar that as our first approximation right now. One thing we are trying to figure out is where the "seet-spot" is on accuracy-- we have a very non-uniform sky luminance so we expect the "ambient" to vary with direction. This grew out of us trying to make a CIE-like sky approximation in terms of spectral radiance (not just luminance). It amazes me that almost nothing has been published in the graphics literature on this.... Pete From shirley@cs.utah.edu Fri Jul 17 08:51:33 1998 Received: from wrath.cs.utah.edu (wrath.cs.utah.edu [155.99.198.100]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id IAA04616 for ; Fri, 17 Jul 1998 08:51:29 -0700 (PDT) Received: from phong.cs.utah.edu (phong.cs.utah.edu [155.99.197.68]) by wrath.cs.utah.edu (8.8.8/8.8.8) with ESMTP id JAA26682 for ; Fri, 17 Jul 1998 09:52:04 -0600 (MDT) From: Peter Shirley Received: (from shirley@localhost) by phong.cs.utah.edu (8.8.8/8.8.8) id JAA19405 for gwlarson@positron.CS.Berkeley.EDU; Fri, 17 Jul 1998 09:52:15 -0600 (MDT) Message-Id: <199807171552.JAA19405@phong.cs.utah.edu> Subject: Re: links and atmospheric persp. To: gwlarson (Gregory Ward Larson) Date: Fri, 17 Jul 1998 09:52:15 -0600 (MDT) In-Reply-To: <199807171538.IAA04596@positron.CS.Berkeley.EDU> from "Gregory Ward Larson" at Jul 17, 98 08:38:24 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Status: R Yeah-- we have gone over those heavily-- we used some of his stuff to model scattering. There seem to be two approaches: 1. Full-bore (SLOW) modeling 2. zeroth-order approximation (like the formula you sent) We are trying to develop something in the middle-- what is unclear is whether that would actually be an improvement over (2)-- an empirical question I think so we have to try it. Pete > > Nishita has a paper or two on atmospheric modeling. I don't have my > rendering workshop proceedings handy, or I'd give them to you. I do > plan to bring it to Siggraph, though -- maybe we can check it there. > > -Greg > From owner-globillum@imag.fr Mon Jul 27 15:27:45 1998 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id PAA11418 for ; Mon, 27 Jul 1998 15:27:44 -0700 (PDT) Received: (from daemon@localhost) by imag.imag.fr (8.8.5/8.8.5) id AAA25826 for globillum-imag-outgoing; Tue, 28 Jul 1998 00:07:03 +0200 (MET DST) Mime-Version: 1.0 Date: Mon, 27 Jul 1998 18:02:07 -0700 Message-ID: <00667C4C.4149@autodesk.com> From: eric.haines@autodesk.com (Eric Haines) Subject: ray tracing bibliography updated To: globillum Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R The free ray tracing bibliography at: http://www.acm.org/pubs/tog/resources/bib/ has been updated with recent papers in SIGGRAPH '98 proceedings and course notes. Eric From owner-globillum@imag.fr Fri Aug 21 11:54:59 1998 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA52951 for ; Fri, 21 Aug 1998 11:54:57 -0700 (PDT) Received: (from daemon@localhost) by imag.imag.fr (8.8.5/8.8.5) id UAA01870 for globillum-imag-outgoing; Fri, 21 Aug 1998 20:22:30 +0200 (MET DST) From: Philippe Bekaert Message-Id: <199808211821.UAA04071@flater.cs.kuleuven.ac.be> Subject: RenderPark: A Photorealistic Rendering Tool To: globillum@imag.fr Date: Fri, 21 Aug 1998 20:21:51 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R Dear Globillumers, RenderPark is the global illumination test-bed system we use at the K.U.Leuven. It contains several interesting global illumination algorithms such as bidirectional path tracing and hierarchical Monte Carlo radiosity. Some of these algorithms have been developed in our research group. Others have been implemented in order to compare our own algorithms with. RenderPark will be especially useful if you are looking for a reference implementation of algorithms which you are considering to use. It will also be very valuable if you are a rendering researcher looking for a free, but proven, software environment to implement your new research ideas. (Yes ... contributions are welcome!) And it is evolving towards a useful rendering software package for others as well. We invite you to have a look at the new release which can be obtained from URL: http://www.cs.kuleuven.ac.be/~graphics/RENDERPARK/ Some excerpts from the README file are included below. With best regards, Philippe Bekaert & Frank Suykens-de Laet. ----------------------------------------------------------------------- What is RenderPark?? RenderPark is a photo-realistic rendering tool being developed at the Computer Graphics Research Group of the Katholieke Universiteit Leuven, in Belgium. The goal is to offer a solid implementation of many existing photo-realistic rendering algorithms in order to compare them on a fair basis, evaluate benefits and shortcomings, find solutions for the latter and to develop new algorithms that are more robust and efficient than the algorithms that are available today. RenderPark will offer you several state-of-the-art rendering algorithms that are not yet present in other rendering packages, not even in expensive ones. Although RenderPark is in the first place a test-bed for rendering algorithms, it is evolving towards a full-featured physics-based global illumination rendering system. The development of RenderPark started in the fall of 1993 and is supported by the Belgian National Science Foundation (FWO-Vl), the Flemish Institute for the Promotion of Scientific-Technological Research in Industry (IWT) and an equipment grant by Hewlett-Packard. RenderPark is realised within the context of various international collaboration projects as well. Rendering algorithms implemented: Object-space radiance algorithms: - Galerkin radiosity (both gathering and shooting) with (or without) hierarchical refinement, higher order approximations, clustering, view-importance, ... - Hierarchical Well Distributed Ray Set Radiosity (the most easy-to-use and often also the fastest radiosity algorithm) - (Quasi-)Monte Carlo random walk radiosity algorithms in three flavours: Pattanaik's particle tracing, Keller's Quasi Monte Carlo radiosity algorithm and Sbert's global multipath algorithm. - stochastic ray radiosity - density estimation (contributed by Olivier Ceulemans UCL/KUL) Pixel-driven radiance algorithms: - stochastic ray tracing (usable as a second pass after an object-space radiance algorithm) - bidirectional path tracing (Lafortune, Veach) Features: - reads models in MGF file format - images can be saved in ppm format, for which numerous converters exist - illuminated models after radiosity can be saved in VRML'97 format - X-Windows/Motif based user interface - interactive navigation using graphics hardware with support for OpenGL, IrisGL and starbase - batch rendering with control through command line arguments or Inter Process Communication - rendering into an external canvas window makes RenderPark behave as a "plug-in" in your applications. Supported platforms: - RenderPark is being developed on the following UNIX platforms: SGI/Iris 6.4 (GNU make and MipsPro 7.2 C/C++ compiler). SUN/Solaris (GNU gcc/SUN's cc + GNU make) Linux (GNU gcc or egcs and GNU make) - GUI: X-window system + Motif toolkit - 3D-graphics: OpenGL, IrisGL, starbase RenderPark is known to compile and run fine on a couple of other (UNIX) platforms as well, including HP-UX, DEC Alpha, FreeBSD, ... -- /~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\ \ Philippe Bekaert | If anything can go wrong, it will, but / / Computer Graphics Research Group | ... we're prepared for it (Switzerland) \ \ Department of Computer Science | ... we don't care (Greece) / / K.U.Leuven - Belgium | ... what the heck, it's been going \ \ | wrong for centuries already (Portugal) / / http://www.cs.kuleuven.ac.be/ | ... it's the fault of the Walloons \ \ ~philippe/ | (Flanders) / /__________________________________| ... we deserve it (Wallonie) \ \ | ... as long as there's vodka we don't / / Not everything that is written | care (Russia) \ \ here is my employers opinion, | ... how much money do I loose? / / sometimes not even mine. | (The Netherlands) \ \__________________________________|_________________________________________/ From gwlarson Fri Aug 21 13:33:36 1998 Received: (from gwlarson@localhost) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/970903.SGI.AUTOCF) id NAA53249; Fri, 21 Aug 1998 13:33:35 -0700 (PDT) Date: Fri, 21 Aug 1998 13:33:35 -0700 (PDT) From: gwlarson (Gregory Ward Larson) Message-Id: <199808212033.NAA53249@positron.CS.Berkeley.EDU> To: Philippe Bekaert Subject: Re: RenderPark: A Photorealistic Rendering Tool Status: R Hey Philippe -- This is great! I'm glad you guys are releasing this to the world. One question, do you intend to add TIFF i/o to your package at some point? I'd like you to look at the high dynamic-range format I added to TIFF recently, which is ideal for rendering and re-rendering applications. See the web site at: http://www.sgi.com/Technology/pixformat/ for details. I'd be happy to talk with you more about it if you're interested. Good work! -Greg From Philippe.Bekaert@cs.kuleuven.ac.be Sat Aug 22 03:33:57 1998 Received: from styx.cs.kuleuven.ac.be (styx.cs.kuleuven.ac.be [134.58.40.3]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id DAA52027 for ; Sat, 22 Aug 1998 03:33:45 -0700 (PDT) Received: from flater.cs.kuleuven.ac.be (philippe@flater.cs.kuleuven.ac.be [134.58.45.35]) by styx.cs.kuleuven.ac.be (8.9.0/8.9.0) with ESMTP id MAA14403 for ; Sat, 22 Aug 1998 12:34:04 +0200 (MET DST) Received: (from philippe@localhost) by flater.cs.kuleuven.ac.be (8.9.0/8.9.0) id MAA12015; Sat, 22 Aug 1998 12:34:02 +0200 (MET DST) From: Philippe Bekaert Message-Id: <199808221034.MAA12015@flater.cs.kuleuven.ac.be> Subject: Re: RenderPark: A Photorealistic Rendering Tool In-Reply-To: <199808212033.NAA53249@positron.CS.Berkeley.EDU> from Gregory Ward Larson at "Aug 21, 98 01:33:35 pm" To: gwlarson (Gregory Ward Larson) Date: Sat, 22 Aug 1998 12:34:02 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R Hi Greg, > One question, do you intend to add TIFF i/o to your package at some point? > I'd like you to look at the high dynamic-range format I added to TIFF > recently, which is ideal for rendering and re-rendering applications. It's something I have been thinking of already for over one year, since you sent a mail that you were working on high-dynamic range stuff in TIFF. I have the library here, and read the docs etc... but never arrived at effectively implementing something due to other work. I'll surely contact you when I start working on it! Thanks! Philippe. -- /~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\ \ Philippe Bekaert | If anything can go wrong, it will, but / / Computer Graphics Research Group | ... we're prepared for it (Switzerland) \ \ Department of Computer Science | ... we don't care (Greece) / / K.U.Leuven - Belgium | ... what the heck, it's been going \ \ | wrong for centuries already (Portugal) / / http://www.cs.kuleuven.ac.be/ | ... it's the fault of the Walloons \ \ ~philippe/ | (Flanders) / /__________________________________| ... we deserve it (Wallonie) \ \ | ... as long as there's vodka we don't / / Not everything that is written | care (Russia) \ \ here is my employers opinion, | ... how much money do I loose? / / sometimes not even mine. | (The Netherlands) \ \__________________________________|_________________________________________/ From owner-globillum@imag.fr Wed Aug 26 17:16:44 1998 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id RAA61342 for ; Wed, 26 Aug 1998 17:16:43 -0700 (PDT) Received: (from daemon@localhost) by imag.imag.fr (8.8.5/8.8.5) id BAA01427 for globillum-imag-outgoing; Thu, 27 Aug 1998 01:43:36 +0200 (MET DST) Date: Wed, 26 Aug 1998 16:42:22 -0700 (PDT) From: gwlarson (Gregory Ward Larson) Message-Id: <199808262342.QAA61863@positron.CS.Berkeley.EDU> To: globillum@imag.fr Subject: dissertation on global illumination available Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R [Forwarded from the Radiance discussion group mailing list. -G] To: raydisc@floyd.lbl.GOV Date: Thu, 27 Aug 1998 00:07:27 +0200 (MESZ) Hi, Fraunhofer ISE has funding for a PhD candidate to develop a thesis on the modelling of light transport using ray tracing. If you are a student in computer graphics or physics, you might want to check http://www.ise.fhg.de/radiance/diss1.html for details. regards Peter -- Peter Apian-Bennewitz apian@ise.fhg.de +49-761-4588-[123|302] Fraunhofer Institute for Solar Energy Systems, D-79100 Freiburg http://www.ise.fhg.de/~apian From Philippe.Bekaert@cs.kuleuven.ac.be Fri Aug 28 11:40:59 1998 Received: from styx.cs.kuleuven.ac.be (styx.cs.kuleuven.ac.be [134.58.40.3]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA61402 for ; Fri, 28 Aug 1998 11:40:55 -0700 (PDT) Received: from flater.cs.kuleuven.ac.be (philippe@flater.cs.kuleuven.ac.be [134.58.45.35]) by styx.cs.kuleuven.ac.be (8.9.0/8.9.0) with ESMTP id UAA05077 for ; Fri, 28 Aug 1998 20:40:53 +0200 (MET DST) Received: (from philippe@localhost) by flater.cs.kuleuven.ac.be (8.9.0/8.9.0) id UAA01247; Fri, 28 Aug 1998 20:40:46 +0200 (MET DST) From: Philippe Bekaert Message-Id: <199808281840.UAA01247@flater.cs.kuleuven.ac.be> Subject: Re: RenderPark: A Photorealistic Rendering Tool In-Reply-To: <199808212033.NAA53249@positron.CS.Berkeley.EDU> from Gregory Ward Larson at "Aug 21, 98 01:33:35 pm" To: gwlarson (Gregory Ward Larson) Date: Fri, 28 Aug 1998 20:40:46 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R Hey Greg > One question, do you intend to add TIFF i/o to your package at some point? > I'd like you to look at the high dynamic-range format I added to TIFF > recently, which is ideal for rendering and re-rendering applications. > See the web site at: > > http://www.sgi.com/Technology/pixformat/ > > for details. I'd be happy to talk with you more about it if you're > interested. I happen to need it right now, so I gave it a try. It's in the todays RenderPark snapshot you can obtain from URL http://www.cs.kuleuven.ac.be/~graphics/RENDERPARK/ Implementing LogLuv TIFF support went fairly smooth. It took me in total about 10 hours of work (including learning again how to use the TIFF lib). You might be interested in the RenderPark/IMAGE directory. It contains a C++ library for writing images in TIFF (both "normal" and high dynamic range, as well as PPM format). It's pretty clean. Especially the tiff.C file might be funny for you to see. Checking whether RenderPark gives the same radiance values (more or less) as radiance is soemthing I'll do next week. It probably doesn't at this time. Write me your opinion if you find the time to give it a try. Best regards, Philippe. -- /~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\ \ Philippe Bekaert | If anything can go wrong, it will, but / / Computer Graphics Research Group | ... we're prepared for it (Switzerland) \ \ Department of Computer Science | ... we don't care (Greece) / / K.U.Leuven - Belgium | ... what the heck, it's been going \ \ | wrong for centuries already (Portugal) / / http://www.cs.kuleuven.ac.be/ | ... it's the fault of the Walloons \ \ ~philippe/ | (Flanders) / /__________________________________| ... we deserve it (Wallonie) \ \ | ... as long as there's vodka we don't / / Not everything that is written | care (Russia) \ \ here is my employers opinion, | ... how much money do I loose? / / sometimes not even mine. | (The Netherlands) \ \__________________________________|_________________________________________/ From gwlarson Fri Aug 28 11:48:38 1998 Received: (from gwlarson@localhost) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/970903.SGI.AUTOCF) id LAA61042; Fri, 28 Aug 1998 11:48:38 -0700 (PDT) Date: Fri, 28 Aug 1998 11:48:38 -0700 (PDT) From: gwlarson (Gregory Ward Larson) Message-Id: <199808281848.LAA61042@positron.CS.Berkeley.EDU> To: Philippe Bekaert Subject: Re: RenderPark: A Photorealistic Rendering Tool Status: R Hi Philippe, That's pretty quick work! I don't know about you, but I found use of the TIFF library to be fairly confusing with all those variables and things. I'm impressed that you were able to get it going so quickly! I am downloading it to take a look at your libtiff calls, but I kind of doubt I'll manage to compile the whole thing.... Thanks! -Greg From owner-globillum@imag.fr Fri Aug 28 11:55:56 1998 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA61629 for ; Fri, 28 Aug 1998 11:55:55 -0700 (PDT) Received: (from daemon@localhost) by imag.imag.fr (8.8.5/8.8.5) id UAA01930 for globillum-imag-outgoing; Fri, 28 Aug 1998 20:28:28 +0200 (MET DST) Message-ID: From: "Michael Cohen (Research)" To: globillum@imag.fr Subject: Radiosity and Realistic Image Synthesis Date: Fri, 28 Aug 1998 11:27:47 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R FYI: I've been told that AP Professional that is teaming up with Morgan/Kaufmann will print another batch of "Radiosity and Realistic Image Synthesis" by myself and John Wallace to bring it back from the "out of print" cemetary. I don't know exactly when it will be available again. - Michael From Philippe.Bekaert@cs.kuleuven.ac.be Sat Aug 29 03:33:58 1998 Received: from styx.cs.kuleuven.ac.be (styx.cs.kuleuven.ac.be [134.58.40.3]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id DAA01759 for ; Sat, 29 Aug 1998 03:33:56 -0700 (PDT) Received: from flater.cs.kuleuven.ac.be (philippe@flater.cs.kuleuven.ac.be [134.58.45.35]) by styx.cs.kuleuven.ac.be (8.9.0/8.9.0) with ESMTP id MAA02666 for ; Sat, 29 Aug 1998 12:34:21 +0200 (MET DST) Received: (from philippe@localhost) by flater.cs.kuleuven.ac.be (8.9.0/8.9.0) id MAA09402; Sat, 29 Aug 1998 12:34:19 +0200 (MET DST) From: Philippe Bekaert Message-Id: <199808291034.MAA09402@flater.cs.kuleuven.ac.be> Subject: high dynamic rangle image output in RenderPark In-Reply-To: <199808281848.LAA61042@positron.CS.Berkeley.EDU> from Gregory Ward Larson at "Aug 28, 98 11:48:38 am" To: gwlarson (Gregory Ward Larson) Date: Sat, 29 Aug 1998 12:34:19 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Hi Greg, > That's pretty quick work! I don't know about you, but I found use of the > TIFF library to be fairly confusing with all those variables and things. > I'm impressed that you were able to get it going so quickly! It's surely harder than ppm or radiance pic format, but some examples help a lot. I studied ppm2tiff and ra_tiff (Thanks for making it available!). Writing a good TIFF reader handling all possible encodings properly is harder than writing a TIFF writer for one specific encoding I think. It seems to work fine on both our Octane and my Linux PC at home. > I am downloading it to take a look at your libtiff calls, but I kind of > doubt I'll manage to compile the whole thing.... Please tell me what problems you have compiling RenderPark (with some info about the platform you use as well if you care). I can try to make an executable for you too if you like. Best regards, Philippe. -- /~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\ \ Philippe Bekaert | If anything can go wrong, it will, but / / Computer Graphics Research Group | ... we're prepared for it (Switzerland) \ \ Department of Computer Science | ... we don't care (Greece) / / K.U.Leuven - Belgium | ... what the heck, it's been going \ \ | wrong for centuries already (Portugal) / / http://www.cs.kuleuven.ac.be/ | ... it's the fault of the Walloons \ \ ~philippe/ | (Flanders) / /__________________________________| ... we deserve it (Wallonie) \ \ | ... as long as there's vodka we don't / / Not everything that is written | care (Russia) \ \ here is my employers opinion, | ... how much money do I loose? / / sometimes not even mine. | (The Netherlands) \ \__________________________________|_________________________________________/ From owner-globillum@imag.fr Fri Sep 11 11:10:23 1998 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA21140 for ; Fri, 11 Sep 1998 11:10:22 -0700 (PDT) Received: (from daemon@localhost) by imag.imag.fr (8.8.5/8.8.5) id TAA05782 for globillum-imag-outgoing; Fri, 11 Sep 1998 19:34:53 +0200 (MET DST) Mime-Version: 1.0 Date: Fri, 11 Sep 1998 13:29:15 -0700 Message-ID: <0074A561.4149@autodesk.com> From: eric.haines@autodesk.com (Eric Haines) Subject: article in new issue of "journal of graphics tools" To: globillum Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R Globillumers, "A Low Distortion Map Between Disk and Square", by Peter Shirley and Kenneth Chu, has just been published in the _journal of graphics tools_, v.2 n.3, p.45-52. See http://www.acm.org/jgt/papers/ShirleyChiu97/ for the abstract and code for the technique. It should be noted that this technique is extended in the paper to mapping between a hemisphere and square. It has obvious application within the field of global illumination. Eric From owner-globillum@imag.fr Wed Sep 16 09:35:49 1998 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id JAA30065 for ; Wed, 16 Sep 1998 09:35:47 -0700 (PDT) Received: (from daemon@localhost) by imag.imag.fr (8.8.5/8.8.5) id SAA08256 for globillum-imag-outgoing; Wed, 16 Sep 1998 18:06:37 +0200 (MET DST) From: hertjwr@us.ibm.com X-Lotus-FromDomain: IBMUS To: globillum@imag.fr Message-ID: <85256681.005823FA.00@us.ibm.com> Date: Wed, 16 Sep 1998 12:05:41 -0400 Subject: 1999 NHTC - K20 Call for Paper-7 sessions Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R Those of you working on radiosity methods that apply across disciplinary boundaries (i.e. applicable to illumination and heat transfer) might be interested in the following calls for papers (Aug. 15-17 is immediately **after** SIG 99) -- Holly ---------------------- Forwarded by Holly Rushmeier/Watson/IBM on 16/09/98 12:02 --------------------------- Ashley Emery 16/09/98 11:12 To: Ashley Emery cc: (bcc: Holly Rushmeier/Watson/IBM) Subject: 1999 NHTC - K20 Call for Paper-7 sessions Call for Papers 33rd National Heat Transfer Conference Hyatt Regency Hotel Albuquerque, New Mexico August 15-17, 1999 The ASME-Heat Transfer Division's K-20 Committee on Computational Heat Transfer is soliciting papers for several sessions at the 1999 National Heat Transfer Conference. Sessions titles, pertinent topics, and abstract submittal information are listed below. 1. Error Estimates for Computational Heat Transfer Software. Papers on error estimators for computational heat transfer numerical methods are sought. Estimators for finite difference, finite volume, finite element and other discretization methods are of interest. Both methods for a priori and a posteriori error estimators are sought. In addition, approaches to multiple conservation laws are solicited. Applications to heat conduction, convection and/or radiation heat transfer are sought, as well as other computational heat transfer analysis. Dr. Robert J. Cochran Org. 9113 - Thermal Sciences Dept. Sandia National Laboratories P.O. Box 5800, Mail Stop 0835 Albuquerque, NM 87185-0835 Ph: (505) 844-6133 Fax: (505) 844-4523 Email: rjcochr@sandia.gov Dr. Foluso Ladeinde Dept. of Mech. Engineering SUNY Stony Brook Stony Brook, NY 11794-2300 Phone: (516) 632-9293 Fax: (516) 632-8771 Ladeine@mech.eng.sunysb.edu 2. Boundary and Finite Element Methods in Heat Transfer. The session is intended to cover the latest developments and applications of the boundary or finite element method in all modes of heat transfer. Dr. Ashley Emery, Program Director Thermal Transport & Thermal Processing Chemical Transport System Division National Science Foundation Arlington, VA Phone: 703-306-1371 FAX: 703-306-0319 Email: aemery@nsf.gov Dr. Darrell W. Pepper, Professor and Chairman Dept. of Mechanical Engineering University of Nevada, Las Vegas 4505 S Maryland Parkway Las Vegas, NV 89154-4027 Phone: 702-895-1056 FAX: 702-895-3936 Email: pepperu@nye.nscee.edu 3. Numerical Implementation of Radiation Heat Transfer. Papers related to recent developments in the numerical implementation of radiation heat transfer methods are sought. Implementation is of interest for finite difference, finite volume, finite element or other discretization methods. Manuscripts describing numerical methods for both participating media and surface-surface radiation exchange are solicited. Topics may include coupled, multi-physics and single physics implementations as well as nongray effects, anisotropic and isotropic scattering and surface reflection and parallel processing. Dr. Shawn P. Burns Sandia National Laboratories MS 0836 P.O. Box 5800 Albuquerque, NM 87185-0836 Ph.: 505-844-6200 FAX: 505-844-8251 Email: spburns@engsci.sandia.gov Woody Fiveland Babcock and Wilcox Research and Development 1562 Beeson St. Alliance, OH 44601 Phone: 216/829-7565 FAX: 216/823-0639 Email: woody.a.fiveland@rdd.mcdermott.com 4. Applications in Computational Heat Transfer. Papers describing recent applications of computational heat transfer software for research, industrial applications, system design, or process/system optimization are requested. Any numerical technique or physical phenomenon will be accepted for this session. Papers from industry and academia are encouraged. Dr. Randy Clarksean P.O. Box 51 17 East Gilman Street New York Mills, MN 56567 Ph: 218-385-3750, fax: 218-385-3751 Email: clark@uslink.net 5. Numerical Methods for Porous Media. Papers dealing with transport phenomenon in porous media are invited. Numerical methods for heat and mass transfer problems, applied to natural and forced convection in a porous medium is the focus. The physical system studied can be any system that can be approximated as a porous medium (e.g., sand and crushed rocks saturated with water, fiber, granular insulation, cores of nuclear reactors, etc.). Dr. Jamil A. Khan Department of Mechanical Engineering University of South Carolina 300 S. Main Street Columbia, SC 29208 803-777-1578 (phone); 803-777-0106 (fax) email: jamil.khan@sc.edu plus TBD co-chairs from other committees 6. Adaptive Gridding of Phase Change Problems. Technical papers using numerical schemes with adaptive grids to solve phase change problems are invited. In general, the numerical schemes should be capable of tracking interface fronts along with temperature and/or fluid flow during the phase change processes. Problems studied may include, but are not limited to, melting/solidification of water, pure metal, alloys (casting, welding), infiltration processing of metal matrix composites, etc. Dr. Jamil A. Khan (K20) Department of Mechanical Engineering University of South Carolina 300 S. Main Street Columbia, SC 29208 803-777-1578 (phone); 803-777-0106 (fax) email: jamil.khan@sc.edu Prof. Samuel Paolucci (K8) Aerospace and Mechanical Engineering University of Notre Dame Notre Dame, IN 46556-5637 Phone: (219)631-8110 fax: (219)631-8341 email: paolucci@chaos.ame.nd.edu 7. Advances in Computational Heat Transfer. The focus of the session is on the development, testing and/or application of improved algorithms and predictive procedures. Examples of topics that are of interest include: improved differencing schemes, more efficient solution schemes including multi-grid and solution-adaptive methods, improved turbulence models and subgrid stress models, improved grid generation schemes, and improvements in the prediction of multi-component or reacting flows. Dr. S. Acharya Dept. of Mechanical Engr. Louisiana State University Baton Rouge, LA 70803 Ph: (504)388-5809 fax: (504)388-5924 email: meacha@lsuvax.sncc.lsu.edu Dr. Rod W. Douglass, MS F645 Computational Methods Group - XCM Applied Theoretical and Comp. Physics Div. Los Alamos National Laboratory Los Alamos, NM 87545 Ph: (505) 665-0570 FAX: (505) 665-4479 email: rwd@lanl.gov Prospective authors are encouraged to submit three copies of an abstract of 300-500 words by September 30, 1998 to Dr. Marino di Marzo as shown below. Authors should reference the session title and K-20 to insure that it is properly placed at the conference. Authors may also want to submit a copy of their abstract to the session chair for their planning purposes - but note that an abstract must be submitted to Dr. Marzo for it to be considered for the conference. Dr. Marino di Marzo Mechanical Engineering Department University of Maryland - College Park, MD 20742 phone: 301-405-5257 ; fax 301-314-9477 email: marino@eng.umd.edu Other dates of importance. Author notification of abstract acceptance November 1, 1998 Receipt of 5 copies of full manuscript December 15, 1998 Notification of manuscript acceptance February 22, 1999 Revised/Final manuscript due March 22, 1999 From owner-globillum@imag.fr Mon Sep 21 03:32:52 1998 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id DAA06904 for ; Mon, 21 Sep 1998 03:32:51 -0700 (PDT) Received: (from daemon@localhost) by imag.imag.fr (8.8.5/8.8.5) id MAA17382 for globillum-imag-outgoing; Mon, 21 Sep 1998 12:02:30 +0200 (MET DST) Message-ID: <8815647C7041D111A3010060B06BE1C039C202@elvis.lightwork> From: Neil Gatenby To: globillum@imag.fr Subject: near field stuff Date: Mon, 21 Sep 1998 11:01:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: RO Following on from a recent chit-chat that began at the (Wien/Vienna) Eurographics Workshop on Rendering, some of you may find the following site of interest. (relates to "canned light sources"/"near field photometric data") http://www.radimg.com/products_radiantsources.htm Neil From owner-globillum@imag.fr Tue Oct 6 10:51:37 1998 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA27992 for ; Tue, 6 Oct 1998 10:51:35 -0700 (PDT) Received: (from daemon@localhost) by imag.imag.fr (8.8.5/8.8.5) id SAA17367 for globillum-imag-outgoing; Tue, 6 Oct 1998 18:38:51 +0200 (MET DST) Date: Tue, 6 Oct 1998 09:37:57 -0700 (PDT) From: Alain Fournier Message-Id: <199810061637.JAA20592@pedigree.cs.ubc.ca> To: byheart@Direct.CA, globillum@imag.fr Subject: Re: More global illumination patents Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R As Ian says "one which, if I read it correctly, apparently patents the WHILE loop". That is great, if that means the REPEAT UNTIL loop remains available to patent. From owner-globillum@imag.fr Tue Oct 6 10:53:38 1998 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA28019 for ; Tue, 6 Oct 1998 10:53:37 -0700 (PDT) Received: (from daemon@localhost) by imag.imag.fr (8.8.5/8.8.5) id QAA06883 for globillum-imag-outgoing; Tue, 6 Oct 1998 16:35:07 +0200 (MET DST) From: Peter Shirley Message-Id: <199810061434.IAA02720@phong.cs.utah.edu> Subject: Clearcoat? To: globillum@imag.fr Date: Tue, 6 Oct 1998 08:34:16 -0600 (MDT) X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R Anyone have the scoop on what this technology is: http://www.sgi.com/newsroom/press_releases/1998/september/clearcoat.html ?? As far as I can guess it is just environment mapping with variable reflectance. But it is hard to tell if there is more (the above release is all marketing content-free verbiage). I couldn't find a whitepaper at the SGI web site either. Thanks Pete Shirley From gwlarson Tue Oct 6 11:00:05 1998 Received: (from gwlarson@localhost) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/970903.SGI.AUTOCF) id LAA27973; Tue, 6 Oct 1998 11:00:05 -0700 (PDT) Date: Tue, 6 Oct 1998 11:00:05 -0700 (PDT) From: gwlarson (Gregory Ward Larson) Message-Id: <199810061800.LAA27973@positron.CS.Berkeley.EDU> To: Peter Shirley Subject: Re: Clearcoat? Status: R Write to Brian Cabral to ask him about it. He told me a bit, but I don't want to give away anything he isn't ready to share, besides being afraid I might screw up the details. You're on track with your conclusions, I think. It's just a clever hack for the most part. (Brian's e-mail is cabral@engr.sgi.com. -Greg From owner-globillum@imag.fr Tue Oct 6 11:01:21 1998 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA27359 for ; Tue, 6 Oct 1998 11:01:20 -0700 (PDT) Received: (from daemon@localhost) by imag.imag.fr (8.8.5/8.8.5) id PAA03740 for globillum-imag-outgoing; Tue, 6 Oct 1998 15:53:08 +0200 (MET DST) Reply-To: "Ian Ashdown" From: "Ian Ashdown" To: Subject: More global illumination patents Date: Tue, 6 Oct 1998 06:52:21 -0700 Message-ID: <01bdf130$8a83ce60$bf8442d8@helios> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R Two more global illumination patents to consider: US Patent 5,734,385, Drawing Method and Apparatus Using Radiosity Algorithm Issue Date: March 31, 1998 US Patent 5,742,292, System and Method for Realistically Displaying Images Indicating the Effects of Lighting on an Object in Three Dimensional Space Issue Date: April 21, 1998 and one which, if I read it correctly, apparently patents the WHILE loop construct: US Patent 5,561,752, Multipass Graphics Rendering Method and Apparatus with Re-Traverse Flag Issue Date: October 1, 1996 Assignee: Apple Computer, Inc. Ian Ashdown, P. Eng., LC | READ THE BOOK! (300 copies remaining) Vice President, R & D | Radiosity: A Programmer's Perspective byHeart Consultants Limited | John Wiley & Sons 1994 West Vancouver, BC (Canada) | http://mypage.direct.ca/b/byheart From owner-globillum@imag.fr Tue Oct 6 11:10:56 1998 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA28013 for ; Tue, 6 Oct 1998 11:10:55 -0700 (PDT) Received: (from daemon@localhost) by imag.imag.fr (8.8.5/8.8.5) id TAA21136 for globillum-imag-outgoing; Tue, 6 Oct 1998 19:48:18 +0200 (MET DST) Message-ID: From: Don Mitchell To: Ian Ashdown , globillum@imag.fr Subject: RE: More global illumination patents Date: Tue, 6 Oct 1998 10:47:39 -0700 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R Patents have cooties. If you're writing and selling graphics software, talk to your attorney and he will explain what that means and why you should not look at these documents. :-) > -----Original Message----- > From: Ian Ashdown [SMTP:byheart@direct.ca] > Sent: Tuesday, October 06, 1998 6:52 AM > To: globillum@imag.fr > Subject: More global illumination patents > > Two more global illumination patents to consider: > > US Patent 5,734,385, Drawing Method and Apparatus Using Radiosity > Algorithm > Issue Date: March 31, 1998 > > US Patent 5,742,292, System and Method for Realistically Displaying Images > Indicating the Effects of Lighting on an Object in Three Dimensional Space > Issue Date: April 21, 1998 > > and one which, if I read it correctly, apparently patents the WHILE loop > construct: > > US Patent 5,561,752, Multipass Graphics Rendering Method and Apparatus > with > Re-Traverse Flag > Issue Date: October 1, 1996 > Assignee: Apple Computer, Inc. > > Ian Ashdown, P. Eng., LC | READ THE BOOK! (300 copies remaining) > Vice President, R & D | Radiosity: A Programmer's Perspective > byHeart Consultants Limited | John Wiley & Sons 1994 > West Vancouver, BC (Canada) | http://mypage.direct.ca/b/byheart > From shirley@cs.utah.edu Tue Oct 6 12:26:10 1998 Received: from wrath.cs.utah.edu (wrath.cs.utah.edu [155.99.198.100]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id MAA27899 for ; Tue, 6 Oct 1998 12:26:05 -0700 (PDT) Received: from phong.cs.utah.edu (phong.cs.utah.edu [155.99.197.68]) by wrath.cs.utah.edu (8.8.8/8.8.8) with ESMTP id NAA20346 for ; Tue, 6 Oct 1998 13:26:25 -0600 (MDT) From: Peter Shirley Received: (from shirley@localhost) by phong.cs.utah.edu (8.8.8/8.8.8) id NAA03151 for gwlarson@positron.CS.Berkeley.EDU; Tue, 6 Oct 1998 13:26:13 -0600 (MDT) Message-Id: <199810061926.NAA03151@phong.cs.utah.edu> Subject: Re: Clearcoat? To: gwlarson (Gregory Ward Larson) Date: Tue, 6 Oct 1998 13:26:13 -0600 (MDT) In-Reply-To: <199810061800.LAA27973@positron.CS.Berkeley.EDU> from "Gregory Ward Larson" at Oct 6, 98 11:00:05 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Status: R Cool. Thanks Greg. I will talk to him. > > Write to Brian Cabral to ask him about it. He told me a bit, but I don't > want to give away anything he isn't ready to share, besides being afraid > I might screw up the details. You're on track with your conclusions, I > think. It's just a clever hack for the most part. > > (Brian's e-mail is cabral@engr.sgi.com. > -Greg > From owner-globillum@imag.fr Wed Oct 7 00:16:16 1998 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id AAA28284 for ; Wed, 7 Oct 1998 00:16:15 -0700 (PDT) Received: (from daemon@localhost) by imag.imag.fr (8.8.5/8.8.5) id IAA05536 for globillum-imag-outgoing; Wed, 7 Oct 1998 08:46:50 +0200 (MET DST) From: Francois Sillion Message-Id: <199810070646.IAA09595@safran> Subject: Re: Clearcoat? To: globillum@imag.fr (Global Illumination List) Date: Wed, 7 Oct 1998 08:46:13 +0200 (MDT) Cc: reiners@igd.fhg.de Reply-To: Francois.Sillion@imag.fr X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R I am forwarding this message since it is clearly of interest to all of us. The original message bounced because of the problem I explained earlier, namely that our list server only accepts contributions from the listed e-mail addresses... Again, if the adress listed in globillum is not the one you send e-mail from, please send me the new one. --Francois. owner-globillum@imag.imag.fr wrote: > From owner-globillum@imag.fr Tue Oct 6 20:47:42 1998 > Date: Tue, 6 Oct 1998 20:47:41 +0200 (MET DST) > Message-Id: <199810061847.UAA24587@imag.imag.fr> > To: owner-globillum@imag.imag.fr > From: owner-globillum@imag.imag.fr > Subject: BOUNCE globillum@imag.imag.fr: Non-member submission from [reiners@igd.fhg.de] > > > > Hi folks, > > if you want to see it and you're an SGI developer, try > > https://toolbox.sgi.com/toolbox/src/demos/Onyx2/ > > they have a demo to download for Irix 6.4. It doesn't say a lot about > the technology, it only says that it's a single pass reflection map > technique to handle surfaces whose reflecitivty varies with incident > angle. Andreas Fischer of Daimler Benz sent me a mail saying that the > Fresnel Index and the intensity of the map are included in the > calculation. The demo is general enough so that you can load your own > models and the above webpage has some documentation on the parameters. > Maybe somebody more knowledgeable can take a look at it and guess how > it does what it does. > > My feeling is that it's just a name for calculating envmaps for the > material characteristics you want, but maybe I get some more info > later. > > Hope it helps > > Dirk > > -- > -- > -- Dirk Reiners reiners@igd.fhg.de > -- IGD - A4 http://www.igd.fhg.de/~reiners > -- Rundeturmstrasse 6 > -- D-64283 Darmstadt All standard disclaimers apply. > -- Truth is stranger than fiction because fiction has to make sense. > +------------------+------------------------------------------------------+ | Francois SILLION | iMAGIS - GRAVIR/IMAG, B.P. 53, 38041 Grenoble Cedex 9| | ' | France. Tel:+33 4 76 51 43 54 - Fax:+33 4 76 63 55 80| +------------------+--------+---------------------------------------------+ | Francois.Sillion@imag.fr | http://www-imagis.imag.fr/~Francois.Sillion | +---------------------------+---------------------------------------------+ From owner-globillum@imag.fr Wed Oct 7 00:16:17 1998 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id AAA28782 for ; Wed, 7 Oct 1998 00:16:15 -0700 (PDT) Received: (from daemon@localhost) by imag.imag.fr (8.8.5/8.8.5) id IAA05735 for globillum-imag-outgoing; Wed, 7 Oct 1998 08:48:33 +0200 (MET DST) From: Francois Sillion Message-Id: <199810070647.IAA09618@safran> Subject: Re: Clearcoat? To: globillum@imag.fr (Global Illumination List) Date: Wed, 7 Oct 1998 08:47:54 +0200 (MDT) Cc: westin@graphics.cornell.edu (Stephen H. Westin) Reply-To: Francois.Sillion@imag.fr X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R Same deal... owner-globillum@imag.imag.fr wrote: > From owner-globillum@imag.fr Tue Oct 6 22:38:30 1998 > Date: Tue, 6 Oct 1998 22:38:29 +0200 (MET DST) > Message-Id: <199810062038.WAA04796@imag.imag.fr> > To: owner-globillum@imag.imag.fr > From: owner-globillum@imag.imag.fr > Subject: BOUNCE globillum@imag.imag.fr: Non-member submission from ["Stephen H. Westin" ] > > Subject: Re: Clearcoat? > Reply-To: westin@graphics.cornell.edu > > > > Anyone have the scoop on what this technology is: > > > > http://www.sgi.com/newsroom/press_releases/1998/september/clearcoat.html > > > As far as I can guess it is just environment mapping with variable reflectance. > > But it is hard to tell if there is more (the above release is all > > marketing content-free verbiage). I couldn't find a whitepaper at the > > SGI web site either. > > A couple of speculations: > > - Separating the lighting calculation from the reflection map. > I believe OpenGL actually multiplies the reflection map by > the result of the lighting calculation, which is a bit silly. > > - Cube-based environment maps. Hitherto, the spherical map used > in OpenGL is camera-centric: you could rotate the car, but > not walk around it. A paper some years ago from SGI showed > how to do this not too painfully with existing hardware. > > Anyway, it's quite possible that they are just fixing something that's > broken :). > > Another possibility is that they are doing Fresnel reflectance (or > some approximation) at a low level. But if everything has to be baked > into a precomputed map (e.g. lighting), why not include Fresnel in > that? > > My spies at Ford haven't responded yet... > +------------------+------------------------------------------------------+ | Francois SILLION | iMAGIS - GRAVIR/IMAG, B.P. 53, 38041 Grenoble Cedex 9| | ' | France. Tel:+33 4 76 51 43 54 - Fax:+33 4 76 63 55 80| +------------------+--------+---------------------------------------------+ | Francois.Sillion@imag.fr | http://www-imagis.imag.fr/~Francois.Sillion | +---------------------------+---------------------------------------------+ From owner-globillum@imag.fr Sat Oct 17 21:57:30 1998 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id VAA47828 for ; Sat, 17 Oct 1998 21:57:29 -0700 (PDT) Received: (from daemon@localhost) by imag.imag.fr (8.8.5/8.8.5) id GAA24098 for globillum-imag-outgoing; Sun, 18 Oct 1998 06:40:48 +0200 (MET DST) Message-ID: <362970BD.35C96BDE@eml.hiroshima-u.ac.jp> Date: Sun, 18 Oct 1998 13:38:21 +0900 From: Tomoyuki Nishita Reply-To: nis@is.s.u-tokyo.ac.jp X-Mailer: Mozilla 4.03 [ja] (Win95; I) MIME-Version: 1.0 To: globillum@imag.fr Subject: moved to Tokyo Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R Hi Globillumers,e; I moved from Fukuyama University to the University of Tokyo in this month. My new address is as follows; Dept. of Information Science, Faculty of Science University of Tokyo 7-3-1 Hongo, Bunkyo-ku, Tokyo 113-0033, Japan Tel: +81-3-3812-2111 ext. 4106 Fax: +81-3-3818-1073 http://www.is.s.u-tokyo.ac.jp/~nis/ e-mail: nis@is.s.u-tokyo.ac.jp From owner-globillum@imag.fr Sat Oct 17 15:08:16 1998 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id PAA46868 for ; Sat, 17 Oct 1998 15:08:15 -0700 (PDT) Received: (from daemon@localhost) by imag.imag.fr (8.8.5/8.8.5) id XAA10717 for globillum-imag-outgoing; Sat, 17 Oct 1998 23:48:58 +0200 (MET DST) Reply-To: "Ian Ashdown" From: "Ian Ashdown" To: Subject: Stochastic global illumination and RADBIB98 Date: Sat, 17 Oct 1998 14:47:32 -0700 Message-ID: <01bdfa17$bea46ac0$0100007f@helios> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: RO I normally refrain from commenting on the papers that I add to the RADBIB98 global illumination bibliography, but in this case I will make an exception. Dr. Laszlo Szirmay-Kalos of the Department of Control Engineering and Information Technology, Technical University of Budapest (szirmay@fsz.bme.hu) and various co-authors have been prolific in the number of high-quality papers and technical reports they have written on global illumination over the past few years. I have listed these publications in RADBIB98 (see below), but I want to draw your attention to one in particular: "Stochastic Methods in Global Illumination - State of the Art Report" (Technical Report TR-186-2-98-23). This 29-page report (in English) presents "a state-of-the-art report of those global illumination algorithms which involve Monte Carlo or quasi-Monte Carlo algorithms." If you are a grad student involved in this area, this is likely a must-read paper. It offers an excellent overview and 84 references to follow up on. To download this paper or the many others that Dr. Szimay-Kalos and co-authors have written, go to http://www.fsz.bme.hu/~szirmay/puba.html. Speaking of RADBIB98, it and GITHESIS are still very much alive. Unfortunately, the Webmeister of their host Web site (www.ledalite.com) has been inundated with work and has so far been unable to upload the September 30th releases for me. RADBIB98 now has 1,440 entries (34 additions since its July 15th release) and GITHESIS (a subset of RADBIB98 featuring MSc and PhD theses) has 168 entries (7 additions), with more to come. I do not know when Ledalite will be able to upload the latest versions. If it doesn't happen by the end of the month, I may set up a new Web site for global illumination research and host them myself. In the meantime, if you would like copies, please send me an e-mail request at iashdown@cs.ubc.ca. (Yes, I am now a full-time computer science graduate student.) - Ian Ashdown From owner-globillum@imag.fr Thu Nov 5 19:52:47 1998 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id TAA08450 for ; Thu, 5 Nov 1998 19:52:45 -0800 (PST) Received: (from daemon@localhost) by imag.imag.fr (8.8.5/8.8.5) id EAA02582 for globillum-imag-outgoing; Fri, 6 Nov 1998 04:30:57 +0100 (MET) Reply-To: "Ian Ashdown" From: "Ian Ashdown" To: Subject: ANNOUNCE: 98/11/15 Release of RADBIB98.BIB and GITHESIS.BIB Date: Thu, 5 Nov 1998 19:29:50 -0800 Message-ID: <01be0935$b62f6a70$4f8742d8@helios> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R ANNOUNCE: 98/11/15 Release of RADBIB98.BIB and GITHESIS.BIB ----------------------------------------------------------- RADBIB98 is a comprehensive bibliography of radiosity and related global illumination papers, theses, articles, and books. It currently includes 1,466 references -- 60 new additions since the 98/07/15 release. This bibliography is available in BibTex format as RADBIB98.BIB (with a release date of November 15, 1998) from: http://www.ledalite.com/library-/rrt.htm ftp://ftp.ledalite.com/pub/radbib98.bib Also available from this site is an abridged version of RADBIB98.BIB called GITHESIS.BIB. This bibliography includes 171 references to radiosity and global illumination theses -- 10 new additions since the 98/07/15 release. As always, it is time-consuming and sometimes difficult to track down conference papers and theses on radiosity and global illumination. If you know of a relevant reference that is not included in these bibliographies, please let us know so that we can include it in the next release. Partial financial support for the maintenance of these bibliographies has been provided by the ACM SIGGRAPH Special Projects. Ian Ashdown Head of Research Ledalite Architrctural Products Inc. http://www.ledalite.com From owner-globillum@imag.fr Wed Nov 18 10:19:34 1998 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA13599 for ; Wed, 18 Nov 1998 10:19:31 -0800 (PST) Received: (from daemon@localhost) by imag.imag.fr (8.8.5/8.8.5) id SAA03688 for globillum-imag-outgoing; Wed, 18 Nov 1998 18:41:17 +0100 (MET) Message-Id: <9811181740.AA03053@merckx.graphics.cornell.edu> Date: Wed, 18 Nov 1998 12:40:39 -0500 From: "Stephen H. Westin" To: globillum@imag.fr Subject: Translation of Kubelka-Munk Paper Reply-To: westin@graphics.cornell.edu Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: RO I have translated the 1931 paper, "Ein Beitrag zur Optik der Farbanstriche", by Paul Kubelka and Franz Munk, into English. This is the fundamental paper on reflectance of pigment-bearing layers. I would appreciate any corrections or improvements to my amateur translation. The translation is available in gzipped PostScript at . -Stephen H. Westin Any information or opinions in this message are mine: they do not represent the position of Cornell University or any of its sponsors. From owner-globillum@imag.fr Wed Jan 13 10:33:38 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA02854 for ; Wed, 13 Jan 1999 10:33:37 -0800 (PST) Received: (from daemon@localhost) by imag.imag.fr (8.8.5/8.8.5) id SAA17944 for globillum-imag-outgoing; Wed, 13 Jan 1999 18:52:50 +0100 (MET) From: Adrian James Chung To: globillum@imag.fr Subject: Thesis downloadable Message-Id: Date: Wed, 13 Jan 1999 17:52:13 +0000 Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: RO Dear researcher, I've finally completed my Ph.D. duties and have placed the resulting thesis online: http://www.doc.ic.ac.uk/~ajc/Papers/thesis.ps.bz2 (2.0 MB) While this body of work does not concentrate purely on Global Illumination some interesting ideas are proposed, implemented and studied that may be of interest to researchers in this field: 1. Ray space partitions for ray casting acceleration 2. Detecting total occlusion of ray shafts in non-polygonal environments 3. Constructing smooth shading functions over arbitrary topologies 4. Robust classification of shadow regions -- umbra, penumbra and full illumination. Bye. Adrian. From owner-globillum@imag.fr Fri Jan 15 02:12:15 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id CAA06804 for ; Fri, 15 Jan 1999 02:12:11 -0800 (PST) Received: (from daemon@localhost) by imag.imag.fr (8.8.5/8.8.5) id IAA06951 for globillum-imag-outgoing; Fri, 15 Jan 1999 08:58:33 +0100 (MET) Reply-To: From: "Ian Ashdown" To: Subject: RADBIB99 and GITHESIS - new releases Date: Fri, 15 Jan 1999 00:00:58 -0800 Message-ID: <000001be405d$33db5160$2b8742d8@byheart> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R ANNOUNCE: 99/01/01 Release of RADBIB99.BIB ------------------------------------------ RADBIB99 is a comprehensive bibliography of radiosity and related global illumination papers, theses, articles, and books. It currently includes 1,550 references -- 84 new additions since the 98/11/15 release. This bibliography is available in BibTex format as RADBIB99.BIB (with a release date of January 1, 1999) from: http://www.ledalite.com/library-/rrt.htm ftp://ftp.ledalite.com/pub/radbib99.bib Also available from this site is an abridged version of RADBIB99.BIB called GITHESIS.BIB. This bibliography includes 186 references to radiosity and global illumination theses -- 15 new additions since the 98/11/15 release. As always, it is time-consuming and sometimes difficult to track down conference papers and theses on radiosity and global illumination. If you know of a relevant reference that is not included in these bibliographies, please let us know so that we can include it in the next release. Partial financial support for the maintenance of these bibliographies has been provided by the ACM SIGGRAPH Special Projects. Ian Ashdown, P. Eng, LC READ THE BOOK! Vice President Radiosity: A Programmer's Perspective byHeart Consultants Limited John Wiley & Sons 1994 http://persweb.direct.ca/byheart/Ashdown.html From owner-globillum@imag.fr Wed Feb 3 07:26:38 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id HAA03850 for ; Wed, 3 Feb 1999 07:26:36 -0800 (PST) Received: (from daemon@localhost) by imag.imag.fr (8.8.5/8.8.5) id NAA15626 for globillum-imag-outgoing; Wed, 3 Feb 1999 13:41:39 +0100 (MET) Message-ID: <36B84283.3E8AE59F@goliat.ugr.es> Date: Wed, 03 Feb 1999 12:35:15 +0000 From: "Carlos Ureña Almagro" Reply-To: almagro@goliat.ugr.es Organization: Depto. LSI - ETSI Informatica - Univ. Granada X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.32 i586) MIME-Version: 1.0 To: globillum@imag.fr Subject: EG Rendering Workshop: Students grants. Registration. Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R (sorry for any duplicates) This is to announce that registration for the 10th Eurographics Rendering Workshop is now possible, through the on-line registration form at Workshop Web pages: http://alhambra.ugr.es/egrw99 Workshop will take place at June 21-23, 1999, in Granada, Spain. We offer a reduced inscription price for 20 students at most. If you are interested, please write to organizers. Requests will be processed in the order they are received. Thank you very much in advance, Carlos Ureña. From owner-globillum@imag.fr Tue Feb 16 06:48:47 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id GAA27301 for ; Tue, 16 Feb 1999 06:48:43 -0800 (PST) Received: (from daemon@localhost) by imag.imag.fr (8.8.5/8.8.5) id PAA10445 for globillum-imag-outgoing; Tue, 16 Feb 1999 15:22:02 +0100 (MET) Message-ID: <003801be59b8$1c58f8c0$7e8442d8@byheart> From: "Ian Ashdown" To: Subject: Fw: fast hemispherical scatterometer - commercial partner wanted Date: Tue, 16 Feb 1999 06:24:48 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R Interesting item from sci.optics -- anyone have any details on this (presumably European) patent? (If the device really is patented rather than patent pending, the details should be in the public domain.) - Ian Ashdown -----Original Message----- From: Sipke Wadman Newsgroups: sci.optics Date: February 16, 1999 2:35 AM Subject: fast hemispherical scatterometer - commercial partner wanted >Title: Fast hemispherical scatterometer - commercial partner wanted > >We have a new, patented scatterometer capable of measuring a full >hemispherical scatterogram of a surface for light from +90 to -90 degrees >(reflected and transmitted) incidence in seconds. Probed surface approx. 1 - >10 mm, multiple wavelength. Its purpose is fast quantitative >characterisation of textures, visual appearance etc. for use as a quality >monitoring tool for industrial production processes and as an input for >computer graphics. The scatterometer is under further development and will >be equipped with appropriate software for data processing. > >Building scatterometers is not our core business and we seek co-operation >with a commercial instrumentation manufacturer to design, build and sell a >commercial version under licence, so we (and others) can simply buy it on >the market. > >Potential partners are invited to respond by E-mail (s.wadman@philips.com) >or by fax (+31 40 2737012); technical details will be given under prior >legal non-disclosure agreement. > >Sipke Wadman, >Centre for Manufacturing Technology of Royal Philips Electronics, >Netherlands From image-based-rendering-owner@cs.unc.edu Tue Dec 15 18:15:45 1998 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id SAA30448 for ; Tue, 15 Dec 1998 18:15:43 -0800 (PST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id SAA04009 for <@sgi.engr.sgi.com:gwlarson@positron.cs.berkeley.edu>; Tue, 15 Dec 1998 18:16:13 -0800 (PST) mail_from (image-based-rendering-owner@cs.unc.edu) Received: from radiate.engr.sgi.com (radiate.engr.sgi.com [130.62.245.56]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via SMTP id PAA66316 for <@cthulhu.engr.sgi.com:gwlarson@positron.cs.berkeley.edu>; Tue, 15 Dec 1998 15:53:19 -0800 (PST) mail_from (image-based-rendering-owner@cs.unc.edu) Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by radiate.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id PAA05254 for ; Tue, 15 Dec 1998 15:52:38 -0800 Received: from sgi.sgi.com (sgi.engr.sgi.com [192.26.80.37]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id PAA08892; Tue, 15 Dec 1998 15:52:37 -0800 (PST) mail_from (image-based-rendering-owner@cs.unc.edu) Received: from austin.cs.unc.edu (austin.cs.unc.edu [152.2.128.87]) by sgi.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA02840; Tue, 15 Dec 1998 15:52:35 -0800 (PST) mail_from (image-based-rendering-owner@cs.unc.edu) Received: (from majordom@localhost) by austin.cs.unc.edu (8.8.8/8.8.8) id SAA00848 for image-based-rendering-outgoing; Tue, 15 Dec 1998 18:36:57 -0500 (EST) X-Authentication-Warning: austin.cs.unc.edu: majordom set sender to owner-image-based-rendering@cs.unc.edu using -f Received: from dirc.bris.ac.uk (dirc.bris.ac.uk [137.222.10.51]) by austin.cs.unc.edu (8.8.8/8.8.8) with SMTP id SAA00840 for ; Tue, 15 Dec 1998 18:36:50 -0500 (EST) Received: from cs.bris.ac.uk (actually host luna.cs.bris.ac.uk) by dirc.bris.ac.uk with SMTP-PRIV (PP) with ESMTP; Tue, 15 Dec 1998 23:36:34 +0000 Received: from voodoo.cs.bris.ac.uk (voodoo.cs.bris.ac.uk [137.222.102.33]) by cs.bris.ac.uk (8.8.7/8.8.5) with ESMTP id XAA06883 for ; Tue, 15 Dec 1998 23:31:51 GMT Received: from localhost by voodoo.cs.bris.ac.uk (8.8.7) id XAA02174; Tue, 15 Dec 1998 23:31:45 GMT Date: Tue, 15 Dec 1998 23:31:45 +0000 (GMT) From: HPCG Editor X-Sender: hpcg@voodoo To: hpcg-list@cs.bris.ac.uk Subject: Announcement of New Journal / Call for papers Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-image-based-rendering@cs.unc.edu Precedence: bulk Status: RO Dear Colleague, You are invited to submit your research to the new Journal, described below. We are now accepting submissions of papers for the issues that will appear in 1999. If you require any advice or further information please contact one of the Editors in Chief. Yours sincerely, Derek Paddon ************************************************************************** Announcement of New Journal and Call for Papers for Volume 1, 1999 ************************************************************************** International Journal of High Performance Computer Graphics, Multimedia and Visualisation http://www.bath.ac.uk/~maxhpcg/ This Journal is a high quality fully refereed Journal that brings together papers under one heading that relate to efficiency, performance or quality in Computer Graphics, Multimedia and Visualisation. The efficiency, performance and quality issues will include any results that can be regarded as extending the work to a level that merits reporting to the research and practitioner community. Algorithms, systems and applications are equally important, therefore papers may be accepted that report on new algorithmic methods, acceleration techniques, higher quality results, distributed and parallel algorithms and systems, innovative architectures or algorithms, progression towards or actual real-time solutions, modelling, handling large data sets, etc. The Journal's scope in efficiency, performance and quality issues include, but is not restricted to, the following topics in computer graphics, multimedia and visualisation: * Algorithms - efficiency or performance issues. * Quality issues - accuracy and perception. * Tools and techniques for improving quality or efficiency. * Distributed and parallel algorithms or systems. * Fundamentals of higher performance computing. * Systems for high performance. * Architectures and technologies for high performance computing. * Algorithms that accelerate performance. * High performance or efficient applications. * Performance modelling, analysis and measurement. * Theoretical analysis of algorithms. * Model building. * Handling large data sets. * Virtual environments. * Distributed virtual environments. * Augmented environments. * Human factors in efficient systems. * Real-time dynamic environments. * Computer animation - modelling and interaction. * Time varying data. * Volume and information visualisation. * Video and media processing. * Images and sound in multimedia. * Motion capture, motion control. * Real-time interaction. * High performance photo-realism in computer graphics. * Algorithmic impact on high performance architectures. * Architectural impact on high performance algorithms. * Industrial and commercial applications and products. * Future technologies - analyses and perspectives. Other topics will be considered by the editors for publication if the work is in keeping with the general aims and objectives of the Journal. Joint Editors-in-Chief Derek Paddon and Claire Willis Editorial Board: Ken-ichi Anjyo - Japan Kadi Bouatouch - France Tom Crockett - USA Don Fussell - USA Pat Hanrahan - USA Chuck Hansen - USA Alan Heirich - USA Horst Holstein - UK Roger Hubbold - UK Paul Mackerras - Australia Ulrich Neumann - USA Bulent Ozguc - Turkey Derek Paddon - UK Sumanta Pattanaik - India/USA Antonio Sousa Pereira - Portugal Jan Prins - USA Thierry Priol - France Werner Purgathofer - Austria Georgios Sakas Germany Sam Uselton - USA Scott Whitman - USA Claire Willis - UK Craig Wittenbrink - USA Format of the Journal The initial circulation would be 4 issues per year of approximately 100 pages per issue. The use of coloured illustrations will be encouraged where it adds to the value of the papers. The length of papers is open, therefore each issue is expected to contain major papers as well as work of a shorter length. Technical notes are encouraged with a special section being devoted to these items. Authors can report major discoveries or innovation as a short technical note in advance of the ideas being fully implemented. These notes will receive very rapid refereeing in order to bring the work to the notice of the community and also to mark the achievement of the authors. As well as publishing previously unseen original work, the journal provides a focus for selected high quality conference papers that are currently appearing in special interest conferences related to high performance issues. These papers will always be re-refereed and as a result can be expected to be extended or reworked in some way. Full details on submission procedures for papers and other information related to the Journal can be found at the following www site: http://www.bath.ac.uk/~maxhpcg/ The Editors-in-Chief can be contacted by email as follows: Derek Paddon hpcg@cs.bris.ac.uk / derek@cs.bris.ac.uk Claire Willis H.P.C.Journal@bath.ac.uk / cpw@maths.bath.ac.uk From bretton_wade@acm.org Tue Mar 2 20:41:25 1999 Received: from mail-gw6.pacbell.net (mail-gw6.pacbell.net [206.13.28.41]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id UAA09209 for ; Tue, 2 Mar 1999 20:41:23 -0800 (PST) Received: from dragon (adsl-206-170-148-204.dsl.pacbell.net [206.170.148.204]) by mail-gw6.pacbell.net (8.8.8/8.7.1+antispam) with SMTP id UAA29484; Tue, 2 Mar 1999 20:40:30 -0800 (PST) From: "Bretton Wade" To: "Stephen Westin" , "Sing Choong Foo" , "Richard Lobb" , "Philip Hubbard" , "Peter Shirley" , "Jed Lengyel" , "Gregory Ward Larson" , "Eric Haines" , "Dennis B. Jones" <75460.171@compuserve.com>, "David Zareski" , "Daniel Woods" , "Chris Schoeneman" , "Brian Smits" Subject: Ray tracing in hardware... Date: Tue, 2 Mar 1999 20:41:18 -0800 Message-ID: <002a01be6530$14508750$cc94aace@dragon.pacbell.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Status: R Hi folks, Sorry for spamming all of you. I ran across this company, and I was wondering if any of you know anything about it. http://www.art-render.com One of the founding members (CTO) is a fellow by the name of Adrian Wrigley. His background is physics and electronic engineering, and he was a member of the Rainbow group at Cambridge working on HDTV. It looks to be about a 20 person company. -- Bretton Wade From owner-globillum@imag.imag.fr Fri Mar 5 21:02:48 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id VAA16583 for ; Fri, 5 Mar 1999 21:02:47 -0800 (PST) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id FAA08951 for globillum-imag-outgoing; Sat, 6 Mar 1999 05:37:47 +0100 (MET) X-Authentication-Warning: imag.imag.fr: majordom set sender to owner-globillum@imag.imag.fr using -f Message-ID: <006401be678b$ab66aae0$608642d8@byheart> From: "Ian Ashdown" To: Subject: ANNOUNCE: Updated RADBIB99 and GITHESIS Date: Fri, 5 Mar 1999 20:41:55 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0061_01BE6748.9BA153A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R This is a multi-part message in MIME format. ------=_NextPart_000_0061_01BE6748.9BA153A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ANNOUNCE: 99/03/01 Release of RADBIB99.BIB ------------------------------------------ RADBIB99 is a comprehensive bibliography of radiosity and related global illumination papers, theses, articles, and books. It currently includes 1,558 references -- 8 new additions since the 99/01/01 release. This bibliography is available in BibTex format as RADBIB99.BIB (with a release date of March 1, 1999) from: http://persweb.direct.ca/byheart/Ashdown.html Also available from this site is an abridged version of RADBIB99.BIB called GITHESIS.BIB. This bibliography includes 190 references to radiosity and global illumination theses -- 4 new additions since the 99/01/01 release. Partial financial support for the maintenance of these bibliographies has been provided by the ACM SIGGRAPH Special Projects. - Ian Ashdown ------=_NextPart_000_0061_01BE6748.9BA153A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
ANNOUNCE: = 99/03/01=20 Release of=20 RADBIB99.BIB
------------------------------------------
RADBIB99 = is a=20 comprehensive bibliography of radiosity and
related global = illumination=20 papers, theses, articles, and
books. It currently includes 1,558 = references=20 -- 8 new
additions since the 99/01/01 = release.
 
This = bibliography is=20 available in BibTex format as
RADBIB99.BIB (with a release date of = March 1,=20 1999) from:
 
 
Also = available from=20 this site is an abridged version of
RADBIB99.BIB called GITHESIS.BIB. = This=20 bibliography
includes 190 references to radiosity and=20 global
illumination theses --=20 4 new additions since the 99/01/01
release.
 
Partial = financial=20 support for the maintenance of these
bibliographies has been provided = by the=20 ACM SIGGRAPH
Special Projects.
- Ian=20 Ashdown
 
------=_NextPart_000_0061_01BE6748.9BA153A0-- From owner-globillum@imag.imag.fr Fri Apr 16 14:32:45 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id OAA99240 for ; Fri, 16 Apr 1999 14:32:44 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id XAA03834 for globillum-imag-outgoing; Fri, 16 Apr 1999 23:04:03 +0200 (MET DST) Date: Fri, 16 Apr 1999 17:03:56 -0400 (EDT) From: Jack Tumblin Reply-To: Jack Tumblin To: "Global Illum. Mail List" Subject: Hi Contrasts, implants, ... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: RO This may be drifting off the subject, but scary-sounding implants are getting serious attention to help replace dead photoreceptors in the retinas of macular degeneration patients. Take a look at: [ http://www.ims-chips.de/products.html ] and click on '3.BMBF Project "Subretinal Microphotodiodes" This same group has had good, working high-dynamic range camera (uses logarithmic responding pixels, 120dB range = 1:10^6 contrast range) for several years now that may be useful for verifying global illumination solutions: [ http://www.ims-chips.de/products.html ] and click on 1. Vision Chips & Digital Cameras Regards, -Jack Tumblin (ccsupjt@cc.gatech.edu) Gradual Student, College of Computing Use all letters: "Jackdaws love my big sphinx of quartz!"-`Says You', NPR From owner-globillum@imag.imag.fr Fri Apr 16 14:33:06 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id OAA99159 for ; Fri, 16 Apr 1999 14:33:05 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id XAA03714 for globillum-imag-outgoing; Fri, 16 Apr 1999 23:00:27 +0200 (MET DST) Date: Fri, 16 Apr 1999 14:00:06 -0700 (PDT) From: gwlarson (Gregory Ward Larson) Message-Id: <199904162100.OAA95767@positron.CS.Berkeley.EDU> To: lg@pixar.com Subject: Re: Interesting display technology Cc: globillum@imag.fr References: <199904162007.QAA20278@bach.Graphics.Cornell.EDU> Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: RO This is very interesting. I would prefer this myself to a brain implant, though I don't want the modulator to lose power before the laser, although the following paper claims it's perfectly safe: Viirre, E., Johnston, R., Pryor, H. and Nagata, S. (1997). Laser Safety Analysis of a Retinal Scanning Display System. Journal of Laser Applications, 9(4), 253-260. (http://www.hitl.washington.edu/publications/r-97-31/) I was wondering how they would manage to track eye movements, and I guess they're still working on the problem, or at least they were still thinking about it in 1995: Tidwell, M., Johnston, R.S., Melville, D. and Furness, T.A. (1995). The Virtual Retinal Display - A Retinal Scanning Imaging System. In Proceedings of Virtual Reality World '95, pp. 325-333. (http://www.hitl.washington.edu/publications/p-95-1/) Quote: 4.6.2 Exit Pupil The exit pupil in the current prototypes is still quite small. The exit pupil for Prototype #2, for example, is approximately 1.5 millimeters. Thus, the eye must be aligned with the exit pupil to view the image. This will not present an issue in a hand held unit but is not optimal for a head mounted unit. Methods of enlarging the exit pupil are therefore being developed. I noticed that many of their proposed applications had to do with "low vision," i.e., people with poor eyesight. This also corresponds to the time when implants start to make some kind of sense, though not to me, personally. -Greg ______________________________________________________________________________ Gregory Ward Larson (the computer artist formerly known as Greg Ward) Silicon Graphics, Inc. Computer Science Department 2011 N. Shoreline Blvd., 40U-553 537 Soda Hall, UC Berkeley Mountain View, CA 94043-1389 Berkeley, CA 94720-1776 (650) 933-4878, 932-4878 fax (510) 642-3631, -5775 fax gregl@sgi.com http://positron.cs.berkeley.edu/gwlarson ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-globillum@imag.imag.fr Mon Apr 19 00:50:05 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id AAA90419 for ; Mon, 19 Apr 1999 00:50:04 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id JAA26816 for globillum-imag-outgoing; Mon, 19 Apr 1999 09:25:35 +0200 (MET DST) Message-ID: <371ADA6D.21DCBDC4@imag.fr> Date: Mon, 19 Apr 1999 09:25:33 +0200 From: Francois Sillion Organization: iMAGIS - GRAVIR/IMAG INRIA X-Mailer: Mozilla 4.5C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: globillum@imag.fr Subject: More on display technologies References: <199904162007.QAA20278@bach.Graphics.Cornell.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: RO Dear Globillum members, Please let me remind you that our anti-spam filters will only allow your contributions from the e-mail address listed on our server. Several messages bounced back in the last few days, so I am including them below. I realise this is not the most convenient system, but that's how it works... please try to remember to post from your designated account/email address. ----------------------------------------------------------------------------- Daniel Kartch wrote: Am I the only person leery of the idea of intentionally shining a laser diode into my eye. I can just imagine some virus infecting the device driver files and before I can yank the thing off I've got "Kilroy was here" permanently burned into my retina. ----------------------------------------------------------------------------- Marc Levoy wrote: I recall trying a similar retinal display system years ago, head-mounted, manufactured by Reflection Technologies. One problem with it was that visual saccades and blinking caused disturbing tearing of the perceived image. -Marc Levoy +------------------+--------------------------------------------------------+ | Francois SILLION | iMAGIS-GRAVIR/IMAG/INRIA, BP 53, 38041 Grenoble Cedex 9| | ' | France. Tel: +33 4 76 51 43 54 - Fax: +33 4 76 63 55 80| +------------------+--------+-----------------------------------------------+ | Francois.Sillion@imag.fr | http://www-imagis.imag.fr/~Francois.Sillion | +---------------------------+-----------------------------------------------+ From owner-globillum@imag.imag.fr Fri Apr 16 20:53:06 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id UAA99454 for ; Fri, 16 Apr 1999 20:53:05 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id FAA16933 for globillum-imag-outgoing; Sat, 17 Apr 1999 05:26:23 +0200 (MET DST) Message-ID: <009101be8881$ffeeee80$1f8742d8@helios> Reply-To: "Ian Ashdown" From: "Ian Ashdown" To: Subject: High dynamic range cameras Date: Fri, 16 Apr 1999 20:25:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: RO Jack Tumblin wrote: > >This same group has had good, working high-dynamic range camera (uses >logarithmic responding pixels, 120dB range = 1:10^6 contrast range) for >several years now that may be useful for verifying global illumination >solutions: > >[ http://www.ims-chips.de/products.html ] and click on > 1. Vision Chips & Digital Cameras > I haven't looked at this Web site, but you can purchase high dynamic range cameras in the US at very reasonable prices. I don't have their catalog handy, but I believe that the C-Cam digital cameras from The Imaging Source (see http://www.theimagingsource.com/catalog/index.htm) cost on the order of $500 or so. The good news is that they have a 120 dB dynamic range; the bad news is that they have an 8-bit output. I'll leave it as an exercise to figure out the dynamic range of each step. (Actually, it isn't as bad as this. You can program the camera to digitize within a four-decade window in the dynamic range, or you can use an external 10-bit digitizer.) The C-Cam cameras are very useful for imaging inherently high dynamic range scenes such as bare lamps (at the expense of everything else in the field of view, of course), but they are a looong way from offering serious competition to our biological imaging systems. - Ian Ashdown From owner-globillum@imag.imag.fr Mon Apr 19 10:19:30 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id KAA98314 for ; Mon, 19 Apr 1999 10:19:29 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id SAA15703 for globillum-imag-outgoing; Mon, 19 Apr 1999 18:56:26 +0200 (MET DST) Date: Mon, 19 Apr 1999 09:55:59 -0700 (PDT) From: Alain Fournier Message-Id: <199904191655.JAA17587@pedigree.cs.ubc.ca> To: Francois.Sillion@imag.fr, globillum@imag.fr Subject: Re: More on display technologies Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R Marc Levoy's point about saccade and blinking is interesting. Even though I've heard before of the HIT lab device (some of the Imager people here I think had a demo of it on the visit to Seattle a couple of years ago) I did not think about this (serious) kind of potential problems (I'd rather wear glasses than contacts, so you can imagine how I feel about shining light under computer control directly on my retina). From owner-globillum@imag.imag.fr Mon Apr 19 11:55:22 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id LAA03444 for ; Mon, 19 Apr 1999 11:55:21 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id UAA20174 for globillum-imag-outgoing; Mon, 19 Apr 1999 20:18:22 +0200 (MET DST) Message-ID: <4FD6422BE942D111908D00805F3158DF13ABC213@RED-MSG-52> From: Steve Hollasch To: globillum@imag.fr Subject: RE: Virtual Retinal Display (was: More on display technologies) Date: Mon, 19 Apr 1999 11:17:40 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R Hello; I chair the SIGGRAPH Seattle chapter, and hosted a talk on the Virtual Retinal Display two years ago at the University of Washington. I thought I'd share some of my experiences with the VRD since it's come up here. First off, a picture of the color VRD prototype (with Dr. Furness viewing) can be found at the hit lab home page: . The corresponding color image is on the CRT in the background. Several viewers have expressed a reticence about having a computer-controlled laser projected directly onto your retina. Let me assure you, the burning sensation is minimal, and the image fades within a week or so. =^) Truthfully, the laser (or diode) is extremely low power. Dr. Furness stated that leaving the beam targeted to a single region on the retina for eight hours straight would still be well (*well*) within industry guidelines for illumination intensity. This is probably the most common concern (and one of the first questions) about this device, probably because we're so used to high-energy lasers. In fact, the energy needed to excite our rods or cones is extremely low. From the rod's or cone's point of view, it really doesn't matter if the photons are coming from a coherent beam or as part of a larger bundle of light rays focused on the retina (say, from a CRT light source focused via the eye's natural lens). Beyond that, what is particularly interesting about this device is that the focal point of the projected image is *inside the eye's lens*. In normal vision, the focal point is inside the eyeball, and the entire lens is used to focus the resulting image. With the VRD, the light rays pivot about the lens-centered focal point, using very little of the lens refractive properties, and effectively bypassing the normal optical system. The result of this is that the image is well-focused regardless of the viewer's optical vision, and corrective eyewear (the image above notwithstanding) is unnecessary. And better than that. Dr. Furness related a time that he was giving a demonstration and a fellow viewed the device with one eye, and then for grins with the other eye. In a very quiet voice he asked what was going on, since he saw a crystal-clear image in the eye in which he was legally blind. Specifically, his eye was injured in an auto accident, and corneal scarring had eventually rendered that eye useless. Nevertheless, there was a tiny unscarred region of the cornea through which the VRD beams could pass, and then bloom out to the full image directly on his retina. What I find particularly compelling about this technology is that it does for displays what Graffiti (and variants) did for user input. Imagine having an effective large high-resolution display included in your Palm Pilot or cell-phone, for example. =^) All in all, I was quite impressed with the prototypes I played with. From owner-globillum@imag.imag.fr Tue May 25 07:34:17 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id HAA69565 for ; Tue, 25 May 1999 07:34:15 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id PAA12117 for globillum-imag-outgoing; Tue, 25 May 1999 15:22:50 +0200 (MET DST) From: hertjwr@us.ibm.com X-Lotus-FromDomain: IBMUS To: Hector Yee cc: globillum@imag.fr Message-ID: <8525677C.00497452.00@D51MTA03.pok.ibm.com> Date: Tue, 25 May 1999 09:22:18 -0400 Subject: Re: SIGGRAPH Security Warning Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: RO I checked with Warren Waggenspack, the SIGGRAPH 99 chair. He said that there was briefly a problem, but it has been fixed. I haven't tried it so I can't give you a first hand report. Since I am cluttering your mailboxes, I wanted to point out some TOG articles you may be interested in: Oct. 98 (this was sent out some time ago): "Jagged Edges: When Is Filtering Necessary?" by Avi. C. Naiman The paper deals with edges in b/w images, however as the last sentence of the abstract says "This work also provides a template for how the results of psychophysical experiments can be applied in computer graphics to address image-quality questions." Jan 99 (should be out very soon -- we are working hard to catch up): "Two Methods for Display of High Contrast Images", Jack Tumblin, Jessica Hodgins and Brian Guenter "Reflectance and Texture of Real-World Surfaces", Kristin Dana, Shree Nayar, Bram van Ginneken, and Jan Koenderink and already sent to ACM for typesetting for future issues: "Model And Representation: The Effect of Visual Feedback on Human Performance in a Color Picker Interface", Sarah Douglas and Arthur E. Kirkpatrick " Fast and Accurate Hierarchical Radiosity Using Global Visibility", Fredo Durand, George Drettakis, and Claude Puech "Anisotropic Diffusion for Monte Carlo Noise Reduction", Michael McCool -- Holly __________________________ Holly Rushmeier , holly@watson.ibm.com, (914)784-7252 IBM TJ Watson Research Center, 30 Saw Mill River Road, Hawthorne, NY 10532, USA To: globillum@imag.fr cc: (bcc: Holly Rushmeier/Watson/IBM) Subject: SIGGRAPH Security Warning Hi guys, If you're registering for SIGGRAPH online and paying via credit card, just be careful ... I got a confirmation reply via e-mail with my credit card unencrypted, in plain text, nicely formatted right in the middle of the e-mail. So much for 128-bit RSA encryption, when the return path is in plaintext. I think calling up will be a better idea. Did anyone have a similar problem or is it just me? ---------- Hector Yee Program of Computer Graphics Cornell University 607-255-6705 http://www.graphics.cornell.edu/~hector From owner-globillum@imag.imag.fr Thu Jun 24 10:45:20 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id KAA10245 for ; Thu, 24 Jun 1999 10:45:06 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id QAA21847 for globillum-imag-outgoing; Thu, 24 Jun 1999 16:58:40 +0200 (MET DST) Date: Thu, 24 Jun 1999 10:58:32 -0400 (EDT) Message-Id: <199906241458.KAA14110@bach.Graphics.Cornell.EDU> From: "Stephen H. Westin" To: globillum@imag.fr Subject: Paper on line: image-based BRDF acquisition Reply-to: westin@Graphics.Cornell.EDU Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R The paper Image-Based BRDF Acquisition Including Human Skin, by Steve Marschner, myself, Eric Lafortune, Ken Torrance, and Don Greenberg, presented this week at the 10th Eurographics Workshop on Rendering, is now available online at . It describes how we measured the BRDF of various surfaces, including living human skin, using only a digital camera, an electronic flash, and a Cyberware scanner. The measurements have been verified against measurements on our gonioreflectometer; in the best case, they appear to be accurate to within the limits of the gonioreflectometer. Stephen H. Westin Research Project Leader Program of Computer Graphics Cornell University westin@graphics.cornell.edu 607 255 9080 (VOX) 607 255 0806 (FAX) From owner-globillum@imag.imag.fr Thu Jun 24 13:04:21 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id NAA10025 for ; Thu, 24 Jun 1999 13:04:20 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id VAA08991 for globillum-imag-outgoing; Thu, 24 Jun 1999 21:41:23 +0200 (MET DST) Date: Thu, 24 Jun 1999 15:41:14 -0400 (EDT) Message-Id: <199906241941.PAA15683@bach.Graphics.Cornell.EDU> From: "Stephen H. Westin" To: globillum@imag.fr Subject: Slides from April Ithaca workshop on line Reply-to: westin@graphics.cornell.edu Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: RO Through the good graces of our speakers, we are able to make the slides (and some animations and VRML files) from the recent Workshop on Rendering, Perception, and Measurement available on the Web. point your browser to A few photos from the workshop are available here; more are on line at Greg Larson's Web site: Stephen H. Westin Research Project Leader Program of Computer Graphics Cornell University westin@graphics.cornell.edu 607 255 9080 (VOX) 607 255 0806 (FAX) From owner-globillum@imag.imag.fr Thu Jun 24 13:04:21 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id NAA10025 for ; Thu, 24 Jun 1999 13:04:20 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id VAA08991 for globillum-imag-outgoing; Thu, 24 Jun 1999 21:41:23 +0200 (MET DST) Date: Thu, 24 Jun 1999 15:41:14 -0400 (EDT) Message-Id: <199906241941.PAA15683@bach.Graphics.Cornell.EDU> From: "Stephen H. Westin" To: globillum@imag.fr Subject: Slides from April Ithaca workshop on line Reply-to: westin@graphics.cornell.edu Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: RO Through the good graces of our speakers, we are able to make the slides (and some animations and VRML files) from the recent Workshop on Rendering, Perception, and Measurement available on the Web. point your browser to A few photos from the workshop are available here; more are on line at Greg Larson's Web site: Stephen H. Westin Research Project Leader Program of Computer Graphics Cornell University westin@graphics.cornell.edu 607 255 9080 (VOX) 607 255 0806 (FAX) From owner-globillum@imag.imag.fr Mon Jul 19 12:09:28 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id MAA13156 for ; Mon, 19 Jul 1999 12:09:27 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id UAA05872 for globillum-imag-outgoing; Mon, 19 Jul 1999 20:09:06 +0200 (MET DST) Message-Id: <199907191809.OAA12648@bach.Graphics.Cornell.EDU> From: "Stephen H. Westin" Date: Mon, 19 Jul 1999 13:54:11 -0400 (EDT) To: globillum@imag.fr Subject: Paper online has moved: technical reports added Reply-to: westin@graphics.cornell.edu Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R For those who may be interested in the following paper Stephen R. Marschner, Stephen H. Westin, Eric P. F. Lafortune, Kenneth E. Torrance, and Donald P. Greenberg. Image-based brdf measurement including human skin. In Eurographics Workshop on Rendering, 1999. we now have a permanent URL: Also online are two more detailed technical reports on the research: see . Stephen H. Westin Research Project Leader Program of Computer Graphics Cornell University westin@graphics.cornell.edu 607 255 9080 (VOX) 607 255 0806 (FAX) From owner-globillum@imag.imag.fr Tue Jul 27 12:24:08 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id MAA05859 for ; Tue, 27 Jul 1999 12:24:07 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id UAA02448 for globillum-imag-outgoing; Tue, 27 Jul 1999 20:32:45 +0200 (MET DST) From: hertjwr@us.ibm.com X-Lotus-FromDomain: IBMUS To: globillum@imag.fr Message-ID: <852567BB.0065D68D.00@D51MTA03.pok.ibm.com> Date: Tue, 27 Jul 1999 14:32:30 -0400 Subject: SIGGRAPH BOF? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R Hi all-- Unless I missed something, we didn't have a globillum BOF last year. Shall we get together this year? I didn't get to go to the Rendering workshop this year, so if people would be willing to say a bit about what they presented and/or heard about there I would really be interested, and I am sure there are other people who wanted to go but couldn't get to Spain. Also, from this years SIGGRAPH papers there seems to be a lot about input data capture and perceptual mappings, are we almost finished with figuring out how to do the calculations in between? How would Thursday lunch time be? I am getting to LA Saturday, and I could try to sign up for the time right away. After Ken's message I am looking forward to SIGGRAPH -- its been a while since I have heard things like scan-line rendering likened to bleeding the sick. On a more mundane topic, is anybody staying at the Hotel Figueroa, or have you stayed there before? (just send me mail at holly@watson.ibm.com, I doubt that everyone wants to hear about pros/cons of SIGGRAPH hotels.) -- Holly __________________________ Holly Rushmeier , holly@watson.ibm.com, (914)784-7252 IBM TJ Watson Research Center, 30 Saw Mill River Road, Hawthorne, NY 10532, USA From owner-globillum@imag.imag.fr Tue Jul 27 13:01:04 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id NAA05917 for ; Tue, 27 Jul 1999 13:01:03 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id VAA04831 for globillum-imag-outgoing; Tue, 27 Jul 1999 21:30:27 +0200 (MET DST) Message-ID: <379E08CC.67CB3F71@llnl.gov> Date: Tue, 27 Jul 1999 12:30:20 -0700 From: "Nelson L. Max" X-Mailer: Mozilla 4.51C-SGI [en] (X11; I; IRIX64 6.5 IP30) X-Accept-Language: en MIME-Version: 1.0 To: globillum@imag.fr Subject: EGWR99 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R Holly Rushmeier wanted to know what went on at EGWR99. Here is my trip report, biased toward what I needed to tell LLNL and the DOE. The purpose of the trip was to attend the 10th Eurographics Workshop on Rendering, which took place on June 21 to 23, at the Congress Hall in Granada, Spain. This annual workshop has become the main forum for new research results in rendering (second only to the Siggraph conference, which has space for only a few papers on this topic). Although it is traditionally held in Europe, participants come from all over the world. As in past years, many of the papers concerned local and global illumination. For local illumination, these included papers on mathematically modelling, measuring, representing and approximating local reflection functions (for example, of paint, human skin, wet materials, and surfaces covered by thin films). For global illumination these included stochastic methods, computing soft shadows and approximating their discontinuities, face clustering, interreflection in thick surface geometries, accelerated matrix solution techniques, and efficiently updating global illumination for scenes with moving objects. A new area that is rapidly becoming important is image-based rendering, and papers on this subject included model acquisition and display, visibility ordering for reprojected triangles, use of images in measuring local reflection functions, and uses of hardware in image based rendering. My presented paper in this field "Hierarchical Image-Based Rendering using Texture Mapping Hardware" combined my hierarchical modelling, presented in this workshop in 1996, the hardware-based reprojection techniques I learned from Gernot Schaufler's talk at last year's workshop, and the hardware shading techniques I learned from Rudiger Westermann when I visited him at Erlangen last year. (This proves the utility of my DOE supported trip to Europe last summer.) The paper that I was co-author on was "Shadow Penumbras for Complex Objects by Depth Dependent Filtering of Multi-Layer Images", presented by my Ph.D. student Brett Keating, and the shadow algorithm described is also applicable to image-based models. There were also talks on optimized lighting design, filtering motion sequences using human spatio-temporal perception effects (and in related different paper, producing motion sequences by reprojecting cached surface points from previous frames), adding snow and trees to terrain images, and compressing precomputed intersurface visibility data. The vacation days in Spain were spent looking at churches and palaces, including the Alhambra, and the vacation days in Russia were spent touring with Slavyanka, a male slavic chorus, giving three formal concerts, and singing informally in churches, monasteries, and at the Hermitage museum in St. Petersburg. -- email: max2@llnl.gov Nelson Max, Mail Stop L-560 http://www.llnl.gov/graphics Lawrence Livermore National Laboratory phone (925) 422-4074 7000 East Avenue fax (925) 422-6287 Livermore, CA 94550, USA From owner-globillum@imag.imag.fr Tue Jul 27 14:12:39 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id OAA06109 for ; Tue, 27 Jul 1999 14:12:38 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id WAA08115 for globillum-imag-outgoing; Tue, 27 Jul 1999 22:43:26 +0200 (MET DST) From: eric.haines@autodesk.com Message-ID: <19879C753611D3119DAB0008C7A4C0C101227B3A@hqmsgsrf04.autodesk.com> To: globillum@imag.fr Subject: FW: Ray Tracing Roundtable Date: Tue, 27 Jul 1999 13:43:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R [another person who wanted to have his note forwarded to globillum. Since I'm forwarding it, I've responded at the end. -EAH] -----Original Message----- From: Fabrice Neyret [mailto:Fabrice.Neyret@imag.fr] Sent: Tuesday, July 27, 1999 3:27 PM To: eric.haines@autodesk.com Cc: Fabrice.Neyret@imag.fr Subject: Re: Ray Tracing Roundtable There is a big issue about image quality (and not only data quantity). For instance, there is a big deal concerning aliasing. I don't believe ray-tracing can win soon, because of its very bad properties on this topic. Just have a look on the non-realtime side: does video-production companies massively use raytracing ? the answer is no, and it is very far from being ( indeed, it is a minority ). Instead, high quality renderers used in video production are using algorithms that are members of the projective rendering familly, with much extensions that allows nice quality (antialiasing, reflects, shaders, procedural textures, etc). Typically, this is the A-buffer algorithm and various variations about it (possibly mixed with other algorithms, at pixels needing special features). Thus, I feel reasonable to guess than the same path can be followed for hardware graphic accelerators: More than one color+z per pixel, per-pixel computations, coverage masks are features already or soon available on SGIs. Basic limitations such as the number of textures tend to vanish on Playstation2. Less limitations and per-pixel shaders may help decreasing the number of passes. >From this, one may reach soon an A-buffer configuration, per-pixel shaders and so on. A-buffer allows easy anti-aliasing computation, clear separation of geometry and shading (allowing material editing ala IPR), and the obstacle about turning it into hardware 10 years ago was mainly memory... I guess all these are properties that makes the method electable ! Fabrice NEYRET -------------------------------------------- equipe iMAGIS ( GRAVIR (CNRS,INPG,UJF) & INRIA ) http://www-imagis.imag.fr/Membres/Fabrice.Neyret/index.html fax: +33 (0)4 76 63 55 80 secretariat: +33 (0)4 76 51 46 90 -------------------------------------------- Eric here: I'd like to respond by agreeing a fair bit. Beyond Blue Sky Studios (who did win an Academy Award last year for "Bunny", http://www.blueskystudios.com/), most production software uses A-buffers or use RenderMan, i.e. micropolygons, with ray tracing an occasional "nothing else will do (or at least not easily)" effect. A-buffering gives a lot of samples per pixel cheaply, and so often looks better than adaptive subdivision ray tracing (it catches the spokes of a wheel more consistently, for example). Is this approach the future, or does the simplicity of ray tracing have the same effect as the simplicity of the Z-buffer vs. the 10 hidden-surface algorithms compared by Sutherland et al. 25 years ago? The Z-buffer won out as of today because it had fixed memory costs, memory got cheaper, and "dumbest wins" when programming hardware chips since it saves on dedicated transistors. That said, Winner et al. in SIGGRAPH '97 talk about how A-buffers can reuse much of the Z-buffer pipeline, so are low cost to add to existing designs. Or is the future dictated more by memory size than processor speed, i.e. A Bug's Life scenes have a gigabyte of geometry (not including textures), and a RenderMan architecture allows dealing with it a small chunk at a time vs. the whole caboodle at once as needed in global solutions [but then there's Matt Pharr's ray tracing approach...]. BTW, to wow your friends and confound your enemies, try out some of the real-time ray tracing demos at http://www.acm.org/tog/resources/RTNews/demos/overview.htm That a 4K program like chrome.zip can do anything at all I consider miraculous. From owner-globillum@imag.imag.fr Tue Jul 27 15:41:22 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id PAA06123 for ; Tue, 27 Jul 1999 15:41:21 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id AAA12481 for globillum-imag-outgoing; Wed, 28 Jul 1999 00:18:05 +0200 (MET DST) Message-ID: From: Francois Sillion To: "'globillum@imag.fr'" Subject: Ray tracing roundtable. BOUNCE globillum@imag.imag.fr: Non-me mber submission from [Dan Wexler ] Date: Tue, 27 Jul 1999 15:15:13 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R Here's another contribution (from Dan Wexler) to the thread. Let me remind everyone that our anti-spam filter will only accept contributions from the actuale-mail address registered in the list. If you want to change your e-mail address, drop me a note! +-----------------+--------------------------------------------------------+ |Francois SILLION | iMAGIS-GRAVIR/IMAG/INRIA, BP 53, 38041 Grenoble Cedex 9| |Senior Researcher| France. Tel: +33 4 76 51 43 54 - Fax: +33 4 76 63 55 80| +-----------------+--------------------------------------------------------| |Microsoft Research 31/1145, 1 Microsoft Way Redmond WA 9898052-6399 USA | |Tel: (425) 703 8412, Fax: (425) 936 7329. < mailto:sillion@microsoft.com> | +--------------------------+-----------------------------------------------+ |Francois.Sillion@imag.fr | http://www-imagis.imag.fr/~Francois.Sillion | +--------------------------+-----------------------------------------------+ > -----Original Message----- > Date: Tue, 27 Jul 1999 14:57:13 -0700 > From: Dan Wexler > To: globillum@imag.fr > Subject: Re: FW: Ray Tracing Roundtable > > > Instead, high quality renderers used in video production are using > > algorithms that are members of the projective rendering familly, > > with much extensions that allows nice quality > (antialiasing, reflects, > > shaders, procedural textures, etc). > > Typically, this is the A-buffer algorithm and various > variations about it > > (possibly mixed with other algorithms, at pixels needing > special features). > > Really? Here at PDI we use a variant of the A-buffer algorithm, > but I don't believe this is the norm. I don't think I'd qualify > PRMan as an abuffer algorithm, nor is Mental Ray, nor the > renderer used at Rhythm and Hues (from what I've gathered at least) > nor the scanline renderers found in many of the commercial packages. > > I don't think we're going to stick with the abuffer method either > for too much longer. The abuffer algorithm does not have very > good antialiasing qualities. The abuffer representation of a > subpixel fragment just isn't accurate enough for really high quality > antialiasing. It tries to represent a area (as opposed to a point > sample) and does so rather poorly, IMHO. > > Another major issue is handling motion blur and depth of field. > These don't work too well in a traditional abuffer renderer. > > Then Eric added: > > > A-buffering gives a lot of samples per pixel > > cheaply, and so often looks better than adaptive > subdivision ray tracing (it > > catches the spokes of a wheel more consistently, for example). > > Multiple samples per pixel? Really? I spent a bunch of time > modifying our abuffer to actually shade multiple samples for > a single abuffer fragment, and I could never really get it to > work correctly. Consider the problem of representing the range > of surface normals over a given abuffer fragment. It is not > an easy task to modify your scan converter to generate these data. > I suppose you could just shade each of the subpixels in the > abuffer mask using the interpolated scanline values, but I don't > think that is the norm, and it assumes that you generate an abuffer > mask using a sort of zbuffer scan conversion. Also, in that case > it would still probably be using a regular sampling pattern. > > Sure, you get coverage information that represents portions of > the pixel, but it tends to be regularly sampled. Again, modifying > the abuffer algorithm to handle some form of stochastic sampling > is non-trivial. > > Regarding memory usage, the average shot on Antz had upwards of > 1-2 GB of data in the form of geometry, textures, and scene > description -- and much of the geometry was generated procedurally. > We had an *average* of 12 polygons per pixel and we sampled > well over 100 points in shadow maps for each shaded sample. > We also must render all our frames in under 8 hours. > > > > Wex > From owner-globillum@imag.imag.fr Tue Jul 27 17:12:57 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id RAA06300 for ; Tue, 27 Jul 1999 17:12:56 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id BAA16290 for globillum-imag-outgoing; Wed, 28 Jul 1999 01:58:54 +0200 (MET DST) Date: Tue, 27 Jul 1999 19:58:49 -0400 From: Hansong Zhang To: globillum@imag.fr Subject: [Fwd: Ray tracing in everyone's future?] Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R A comment from Michael Jones... -------- Original Message -------- Subject: Ray tracing in everyone's future? Date: Tue, 27 Jul 1999 15:28:40 -0700 From: "Michael T. Jones" To: hansong@intrinsic.com Hansong, I have a comment on Eric's comment. Pass it along to him if you wish... When Eric writes "...The Z-buffer won out as of today because it had fixed memory costs, memory got cheaper, and "dumbest wins" when programming hardware chips since it saves on dedicated transistors." I would restate this--essentially challenging it. What wins is the nice combination of "true" parallelism without cross-communication, or at least with tremendously reduced cross-communication bandwidth compared to action at the parallel stage. Machines like the SGI G, GT, VGX, RE, and IR have this characteristic: LOW: one polygon in, HIGH fanned-out to hundreds of non-cross-connected mini-framebuffer / rasterization engines (multiple of these on a chip), and then LOW fan-in to a single coherent raster-order byte stream for video display. Such structures are well suited to the current interconnect technology. Packaging technology reinforces this too, since the number of gates grows much faster than the number of pins, and the frequency of those gates grows much faster than the frequency of those pins. As a result, the "next gen killer architecture" for the next while will be designed as the answer to "how can I best exploit locality?" With interesting answers like "in this core, in this cache, in this chip, on this board, etc." This is where the "it will all be ray-tracing" line of thinking hits the brick wall of VLSI truth. If you can think of a structured way to ray cast, then may be it's ok. If not, then no. It's easier to render something coherent five times than to jump around once and I expect it to stay that way until busses become somewhat like crossbars (i.e., multifrequency fiber with an open channel per link-pair). Michael Jones ---------- Michael T. Jones - mtj@intrinsic.com From owner-globillum@imag.imag.fr Wed Jul 28 02:02:58 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id CAA06774 for ; Wed, 28 Jul 1999 02:02:57 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id KAA07801 for globillum-imag-outgoing; Wed, 28 Jul 1999 10:43:26 +0200 (MET DST) Message-ID: <379EDFEC.85878A85@goliat.ugr.es> Date: Wed, 28 Jul 1999 10:48:12 +0000 From: Carlos =?iso-8859-1?Q?Ure=F1a?= Almagro Organization: Universidad de Granada / Spain X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.36 i686) X-Accept-Language: es-ES, es, en-GB, en-US, en MIME-Version: 1.0 To: globillum@imag.fr Subject: Re: SIGGRAPH BOF? References: <852567BB.0065D68D.00@D51MTA03.pok.ibm.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by imag.imag.fr id KAA07798 Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R hertjwr@us.ibm.com wrote: > > I didn't get to go to the Rendering workshop this year, > so if people would be willing to say a bit about what they presented and/or heard > about there I would really be interested, and I am sure there are other people who > wanted to go but couldn't get to Spain. Hello all, We have online the workshop programme, including the abstracts for all the papers. There are two mirrors, one at UC Berkeley: http://positron.cs.berkeley.edu/egrw99 the other one is here in Granada (probably faster for europeans) http://alhambra.ugr.es/egrw99 besides the programme, we have uploaded in our server the group photographs Robert Tobler made at Conference Hall, joined by Dani Lischinski, whom also wrote the workshop report (now available both at EG Web pages and here). In the case that any author of a paper presented in Granada has a Web page with more information about it, I would like to ask him to send me the URL (if possible) so we can point to that page from the abstract page. Thank you very much in advance. Carlos Urena (EGRW99 organizing committee chair) -- _____________________________________________________________________ Carlos Ureña Almagro tlf: (+34) 958 243178 fax: (+34) 958 243179 Dpt. L.S.I. - E.T.S. Ingenieria Informatica - Universidad de Granada Av./ Andalucia, 38. 18071 Granada. Spain. http://giig.ugr.es/~curena From owner-globillum@imag.imag.fr Wed Jul 28 08:35:47 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id IAA02057 for ; Wed, 28 Jul 1999 08:35:47 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id OAA23175 for globillum-imag-outgoing; Wed, 28 Jul 1999 14:53:19 +0200 (MET DST) From: hertjwr@us.ibm.com X-Lotus-FromDomain: IBMUS To: globillum@imag.fr Message-ID: <852567BC.0046C23B.00@D51MTA03.pok.ibm.com> Date: Wed, 28 Jul 1999 08:53:03 -0400 Subject: Re: [Fwd: Ray tracing in everyone's future?] Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R I realize that I always make the same points, but I can't help bringing this up again. As far as ray tracing for real time rendering, doesn't it matter what the goal of the rendering is? Exploiting geometric coherence as Michael describes wins if you can settle for a non-global lighting solution (which is the right thing to do for a lot of applications) , or if you can cope with a temporally fixed lighting solution that carries around a lot of directional information. If you want to have on-the-fly accurate lighting, ray tracing wins I think over other schemes to make use of zbuffers for secondary lighting etc. The rendering used for motion picture production is a really different problem from a person interacting with building design on their computer. As difficult as the motion picture problem is, they can define the lighting rules they want, and they don't have to cope with changes on the fly. On the other hand, they can't allow random artifacts to crop up -- the method they used has to be robust. On the other hand if I were to be designing something, I want to be able to move things around whenever I want to, and if there is an occasion glitch or aliasing it isn't going to bother me that much. __________________________ Holly Rushmeier , holly@watson.ibm.com, (914)784-7252 IBM TJ Watson Research Center, 30 Saw Mill River Road, Hawthorne, NY 10532, USA From owner-globillum@imag.imag.fr Fri Jul 30 08:16:44 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id IAA09780 for ; Fri, 30 Jul 1999 08:16:42 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id QAA25770 for globillum-imag-outgoing; Fri, 30 Jul 1999 16:23:34 +0200 (MET DST) Message-Id: <199907301423.QAA25763@imag.imag.fr> Subject: Re: Ray tracing roundtable. To: globillum@imag.fr Date: Fri, 30 Jul 1999 10:23:08 -0400 (EDT) From: Andrew Willmott Reply-To: ajw+@cs.cmu.edu X-Mailer: ELM [version 2.4 PL25-40] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R Dan Wexler wrote: > > Really? Here at PDI we use a variant of the A-buffer algorithm, > > but I don't believe this is the norm. I don't think I'd qualify > > PRMan as an abuffer algorithm, nor is Mental Ray, nor the > > renderer used at Rhythm and Hues (from what I've gathered at least) > > nor the scanline renderers found in many of the commercial packages. I had some experience with hacking on the R&H renderer some years ago. It was a reasonably standard scanline renderer. If I recall correctly, in the default mode 3x3 subsampling was used for antialiasing, but by default only one shading sample was used for each polygon that fell within a pixel. (Though that polygon might cover a number of subsamples.) The assumption being that typically shading varied more slowly than geometry. (Shading every subsample could be forced when this wasn't the case.) I've always thought that the big win for REYES-type architectures is that motion blur was pretty much for free. With the traditional scanline renderers you have to render a number of slices and composite, so your rendering cost goes up as motion blur increases. With REYES, you're just perturbing a fixed number of fragments differently, so the cost stays pretty much the same. As a trivial data point, I was running some timing tests on a new PC we got in the graphics lab yesterday, on a 100,000 triangle whale model, in a 400x400 pixel window; definitely more than one polygon per pixel. On an SGI O2 the update rate for hardware rendering, one light source, was 0.59s per frame. On the new PC box, with a 450Mhz PIII, I was getting 0.50s per frame rendered with a nested grid raytracer for the same settings. Of course, for animation, handling things like texture map sizzle, shading, shadows, motion blur, and the sheer size of those scenes in a robust manner is often more important than getting the last ounce of speed out of your renderer. Andrew From owner-globillum@imag.imag.fr Fri Jul 30 12:34:32 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id MAA10397 for ; Fri, 30 Jul 1999 12:34:31 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id UAA09080 for globillum-imag-outgoing; Fri, 30 Jul 1999 20:44:30 +0200 (MET DST) From: eric.haines@autodesk.com Message-ID: <19879C753611D3119DAB0008C7A4C0C101414467@hqmsgsrf04.autodesk.com> To: globillum@imag.fr Subject: RE: Ray tracing roundtable Date: Fri, 30 Jul 1999 11:44:22 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R Dan Wexler wrote: > I don't think we're going to stick with the abuffer method either > for too much longer. The abuffer algorithm does not have very > good antialiasing qualities. The abuffer representation of a > subpixel fragment just isn't accurate enough for really high quality > antialiasing. It tries to represent a area (as opposed to a point > sample) and does so rather poorly, IMHO. I agree, it's poor for some cases. Near horizontal or vertical edges, for example, will tend to have only five levels of antialiasing with a 4x4 A-buffer, i.e. edge covers nothing, edge covers 1/4th, edge covers 2/4ths, edge covers 3/4ths, edge covers whole thing. It's pretty visible. Stochastic sampling or other non-uniform sampling schemes are really the way to go. But you have to walk before you run, so I suspect multisampling will (will? already is, on high-end SGIs) be the next step. One thing that would help multisampling further is actually doing half-decent filtering on it, not treating a pixel like a little square. Harder in hardware, since a sample then affects a few pixels. Eric From owner-globillum@imag.imag.fr Mon Aug 2 19:40:30 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id TAA03302 for ; Mon, 2 Aug 1999 19:40:29 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id DAA11200 for globillum-imag-outgoing; Tue, 3 Aug 1999 03:54:40 +0200 (MET DST) Date: Mon, 2 Aug 1999 21:54:34 -0400 (EDT) Message-Id: <199908030154.VAA02130@bach.Graphics.Cornell.EDU> From: "Stephen H. Westin" To: bretton_wade@acm.org CC: globillum@imag.fr In-reply-to: Subject: Re: SIGGRAPH BOF? Reply-to: westin@graphics.cornell.edu References: Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R > I'll go this one further... Since there won't be any proceedings from the > informal workshop at Cornell (May?), it would be nice to hear some of what > went on there, and not just the globillum stuff. Well, SIGGRAPH has asked for something of the sort, seeing as they helped fund the workshop. So something will appear in Computer Graphics. But not soon; it probably won't be written before SIGGRAPH. I don't know any reason that summary shouldn't show up here in draft form, though. Stephen H. Westin Research Project Leader Program of Computer Graphics Cornell University westin@graphics.cornell.edu 607 255 9080 (VOX) 607 255 0806 (FAX) From owner-globillum@imag.imag.fr Tue Aug 3 18:51:44 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id SAA04984 for ; Tue, 3 Aug 1999 18:51:43 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id DAA13655 for globillum-imag-outgoing; Wed, 4 Aug 1999 03:24:43 +0200 (MET DST) Message-ID: <003901bede18$1b22cf00$989c42d8@byheart> Reply-To: "Ian Ashdown" From: "Ian Ashdown" To: Subject: ANNOUNCE: 99/08/01 Release of RADBIB99.BIB Date: Tue, 3 Aug 1999 18:24:30 -0700 Organization: byHeartConsultants Limited MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0036_01BEDDDD.6D38C320" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R This is a multi-part message in MIME format. ------=_NextPart_000_0036_01BEDDDD.6D38C320 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ANNOUNCE: 99/08/01 Release of RADBIB99.BIB ------------------------------------------ RADBIB99 is a comprehensive bibliography of radiosity and related global illumination papers, theses, articles, and books. It currently includes 1,621 references -- 17 new additions since the 99/07/15 release. This bibliography is available in BibTex format as RADBIB99.BIB (with a release date of August 1, 1999) from: http://www.helios32.com/resources.htm Also available from this site is an abridged version of RADBIB99.BIB called GITHESIS.BIB. This bibliography includes 195 references to radiosity and global illumination theses -- one new addition since the 99/07/15 release. Financial support for the maintenance of these bibliographies has been provided by ACM SIGGRAPH Special Projects and byHeart Consultants Limited. -- Ian Ashdown, P. Eng., LC Vice President byHeart Consultants Limited http://www.helios32.com ------=_NextPart_000_0036_01BEDDDD.6D38C320 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ANNOUNCE: = 99/08/01 Release of=20 RADBIB99.BIB
------------------------------------------
RADBIB99 = is a=20 comprehensive bibliography of radiosity and
related global = illumination=20 papers, theses, articles, and
books. It currently includes 1,621 = references=20 -- 17 new
additions since the 99/07/15 release.

This = bibliography is=20 available in BibTex format as
RADBIB99.BIB (with a release date of = August 1,=20 1999) from:

  http://www.helios32.com/re= sources.htm

Also=20 available from this site is an abridged version of
RADBIB99.BIB = called=20 GITHESIS.BIB. This bibliography
includes 195 references to radiosity = and=20 global illumination
theses -- one new addition since the 99/07/15=20 release.

Financial support for the maintenance of = these
bibliographies=20 has been provided by ACM SIGGRAPH Special
Projects and byHeart = Consultants=20 Limited.
--
Ian Ashdown, P. Eng., LC
Vice President
byHeart=20 Consultants Limited
http://www.helios32.com
 ------=_NextPart_000_0036_01BEDDDD.6D38C320-- From owner-globillum@imag.imag.fr Mon Aug 16 09:24:09 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id JAA12755 for ; Mon, 16 Aug 1999 09:24:08 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id RAA16725 for globillum-imag-outgoing; Mon, 16 Aug 1999 17:39:26 +0200 (MET DST) Message-Id: <199908161539.RAA08523@safran.imag.fr> X-Authentication-Warning: safran.imag.fr: fneyret@localhost didn't use HELO protocol XCOrganization: iMAGIS - GRAVIR/IMAG Reply-to: Fabrice.Neyret@imag.fr To: globillum@imag.fr cc: Fabrice.Neyret@imag.fr Subject: old good ones Date: Mon, 16 Aug 1999 17:39:23 +0200 From: Fabrice Neyret Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: RO I really would like to found and buy very old Siggraph proceedings, my favorite epoch being 1983-1989. Siggraph and ACM have nothing that old ( I was so happy, 2 years ago, to get the last 1989, with a dammaged back cover ! ) ( hey, where our memory is going ? ) -> do you know any way (group, news-group, store) to get them ? ( Excepted by parsing every Library College Annual Big Sell, where some very lucky people I know could find somes at 2$ each :^) ) Fabrice NEYRET -------------------------------------------- equipe iMAGIS ( GRAVIR (CNRS,INPG,UJF) & INRIA ) http://www-imagis.imag.fr/Membres/Fabrice.Neyret/index.html fax: +33 (0)4 76 63 55 80 secretariat: +33 (0)4 76 51 46 90 -------------------------------------------- From owner-globillum@imag.imag.fr Mon Aug 16 22:38:07 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id WAA13925 for ; Mon, 16 Aug 1999 22:38:07 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id HAA08841 for globillum-imag-outgoing; Tue, 17 Aug 1999 07:00:00 +0200 (MET DST) From: "Bretton Wade" To: "Globillum" Subject: Web pages, and conversations Date: Mon, 16 Aug 1999 21:58:54 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.4200 Importance: Normal Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R Hi folks, I enjoyed seeing, and in some cases meeting you all at SIGGRAPH. Some interesting points of discussion came up at different times. The one that I'm intrigued by was touched on somewhat at the BOF, but also at the ray-tracing roundtable, and that is the role of global illumination in the entertainment industry, or the lack thereof. I realize that this could be a divisive topic, so I'll take the low road and be provocative. Listening to the second (third?) annual panel on "(global illumination in production)" echoed several sentiments I heard from people at PDI and Pixar: 1. Global illumination is too expensive in terms of compute time, 2. Artists can get as good or better with the tools they have, and 3. Even if they had instant global illumination algorithms at hand, artists don't want the effect of realism. In fact, they want everything but realism. Blue Sky engineers confirmed what I inferred from the panel, that the use of globillum techniques, even for a lame scene in which most of the reflected energy would bounce into space, comes up almost even with the artists manually placing extra lights to achieve the desired results, at least in terms of time. The artist's time costs more, though. I'll make the additional observation that SIGGRAPH this year had a lot of algorithms presented that were strictly approximations useful to the entertainment industry. This is a fair deviation from past years, but I think it reflects one of the major consumers of the technology usually presented at SIGGRAPH. So what this comes down to is the question, "what computational tools for illumination would artists use, that the research community could actually delve into?" That could perhaps be worded more precisely, but I think it gets at the heart of the matter I'm thinking about, which is that the global illumination community hasn't really been developing what it's primary customer wants. If "we" were a company, we'd be going out of business. Now I realize that there are lots of important applications of true photorealistic image development, and physically accurate simulation. Perhaps it is just a side effect of the glamour of the entertainment industry overshadowing other professions, but I perceive that the bulk of our community not in academia is in entertainment (games, movies, television). One suggestion that Dani mentioned was an extended "Painting with Light", referring to the technique presented by Chris Schoeneman, et al. in 1993, for using least squares minimization to determine the needed intensity and color for a set of fixed position light sources. The next step in that direction sounds intimidating, placing light sources to accomodate a desired result. Bruce Walter et al. touched on this again in 1997 using ordinary Phong sources to capture highlights on specular surfaces in a hardware rendered walkthrough, again using least squares minimization. I'm sure there are other examples, but how much harder is the real problem? So, what thoughts does anybody have? On another note, could somebody *please* send me the URL for the globillum archive web page? -- Bretton Wade http://redirect.to/bretton_wade From owner-globillum@imag.imag.fr Thu Aug 19 11:28:24 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id LAA17711 for ; Thu, 19 Aug 1999 11:28:23 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id TAA21573 for globillum-imag-outgoing; Thu, 19 Aug 1999 19:40:28 +0200 (MET DST) Message-ID: <37BC4184.66D5C2F2@llnl.gov> Date: Thu, 19 Aug 1999 10:40:20 -0700 From: "Nelson L. Max" X-Mailer: Mozilla 4.51C-SGI [en] (X11; I; IRIX64 6.5 IP30) X-Accept-Language: en MIME-Version: 1.0 To: globillum@imag.fr Subject: compendium.ps Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R I just tried to print compendium.ps (with 21 single column pages of Global Illumination formulas) that I downloaded as a file from the site mentioned in the last broadcast. (I deleted the message and no longer remember the author.) The %!PS-Adobe-3.0 line was preceed in the file by 3 extraneous lines, so our printer used up a ream of paper printing the file as a text file, before a colleague here stopped it. I recommend that you don't repeat my mistake, and delete those three lines from the file before attempting to print it. -- email: max2@llnl.gov Nelson Max, Mail Stop L-560 http://www.llnl.gov/graphics Lawrence Livermore National Laboratory phone (925) 422-4074 7000 East Avenue fax (925) 422-6287 Livermore, CA 94550, USA From owner-globillum@imag.imag.fr Thu Aug 19 12:08:52 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id MAA17771 for ; Thu, 19 Aug 1999 12:08:51 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id UAA23162 for globillum-imag-outgoing; Thu, 19 Aug 1999 20:21:14 +0200 (MET DST) X-Gnus-Agent-Meta-Information: mail nil Original-Sender: mmp@nurbs.stanford.edu To: "'globillum@imag.fr'" Subject: Re: good old ones (from P. Dutre and M. Blais) References: X-Face: C!.oGaE]n@p)VF9Ss3]f'|<)kRrtpG)^^b^X-3_zhUHp\jBj29jaoTItqWR>mHa+v-{/!jx7OA@!cV0>Fm-b:zEL<`oOXG[BFQ\ Date: 19 Aug 1999 10:26:11 -0700 In-Reply-To: Francois Sillion's message of "Thu, 19 Aug 1999 09:24:57 -0700" Message-ID: User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/20.4 (Emerald) Content-Type: text/plain; charset=us-ascii X-Face: C!.oGaE]n@p)VF9Ss3]f'|<)kRrtpG)^^b^X-3_zhUHp\jBj29jaoTItqWR>mHa+v-{/!jx7OA@!cV0>Fm-b:zEL<`oOXG[BFQ\ writes: > > From: Martin Blais > > Organization: Discreet Logic > > Subject: Re: old good ones > > > > More seriously, wouldn't it be really nice if ACM / SIGGRAPH > > scan/converted the old proceedings into pdf files and sold CD reprints > > of these old proceedings? This question comes up on the comp.graphics newsgroups periodically. At some point, Stephen Spencer posted a reply to the effect that SIGGRAPH is aware of the issue and that remedies along the lines of CD reprints are in the works. -matt -- Matt Pharr mmp@graphics.stanford.edu From owner-globillum@imag.imag.fr Thu Aug 19 14:52:23 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id OAA17857 for ; Thu, 19 Aug 1999 14:52:22 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id XAA28354 for globillum-imag-outgoing; Thu, 19 Aug 1999 23:19:42 +0200 (MET DST) From: eric.haines@autodesk.com Message-ID: <19879C753611D3119DAB0008C7A4C0C1019507DD@hqmsgsrf04.autodesk.com> To: globillum@imag.fr Subject: RE: good old ones (from P. Dutre and M. Blais) Date: Thu, 19 Aug 1999 14:19:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R > Fabrice Neyret wrote: > > > > I really would like to found and buy very old Siggraph proceedings, > > my favorite epoch being 1983-1989. Matt Pharr's comment is right, the ACM is eventually going to have everything ever published by them from 1947 on, journals & proceedings & etc, scanned in and available in the ACM Digital Library (http://www.acm.org/dl). From what I can tell, it's mostly just a matter of funding and time to scan and archive all the material. Right now the Digital Library dates back to about 1991-92 for everything, but even that's pretty useful - there are some hard-to-get proceedings out there that have solid information. If you use it, a nice deal at $87/year. Other resources on the web (though not of much help for pre 1992 papers, though...): http://www2.iro.umontreal.ca/~ratib/code/ (go to Applications/Computer Graphics/Publications) - a great resource, but only a few links to pre 1992 SIGGRAPH papers. http://w3imagis.imag.fr/Membres/Fredo.Durand/Book/publi.html - Siggraph 99 and other papers on the web, links to other wonderful resources. An actual repository exists at http://grafix3d.tzo.com/main/index.html (click on "quick list" at the bottom of the column), but this site is somewhat underpowered and a little clunky to access - nonetheless, it's quite a large graphics paper repository. Eric From owner-globillum@imag.imag.fr Thu Aug 26 08:10:08 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id IAA26659 for ; Thu, 26 Aug 1999 08:10:07 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id PAA23036 for globillum-imag-outgoing; Thu, 26 Aug 1999 15:25:44 +0200 (MET DST) Message-ID: <37C54061.3896D715@gmd.de> Date: Thu, 26 Aug 1999 15:25:54 +0200 From: Christian Bohn X-Mailer: Mozilla 4.51 [en] (X11; U; IRIX 6.3 IP32) X-Accept-Language: en MIME-Version: 1.0 To: globillum@imag.fr Subject: new rendering group at GMD / job offer / CORRECTION Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R It is http://imk.gmd.de/reta Sorry Christian -- Christian Bohn, Institute for Media Communication, GMD +49-2241-142230, http://viswiz.gmd.de/bohn, bohn@gmd.de From owner-globillum@imag.imag.fr Thu Aug 26 08:24:01 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id IAA25804 for ; Thu, 26 Aug 1999 08:24:00 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id PAA22419 for globillum-imag-outgoing; Thu, 26 Aug 1999 15:17:59 +0200 (MET DST) Message-ID: <37C53E89.5DAE696B@gmd.de> Date: Thu, 26 Aug 1999 15:18:02 +0200 From: Christian Bohn X-Mailer: Mozilla 4.51 [en] (X11; U; IRIX 6.3 IP32) X-Accept-Language: en MIME-Version: 1.0 To: globillum@imag.fr Subject: new rendering group at GMD / job offer Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R In July '99, GMD founded the 'research island' "Rendering Techniques and Application". Now, we are looking for people who want to take part in the early phase of defining research directions and the character of the group. Task of the island is doing fundamental research in rendering techniques and connected fields with focus on interactivity and on using rendering hardware. The size of the group is aimed at 5-7 people at the beginning of 2000. Positions offered are postdoctoral (full position), postgraduate (half-time), students, and trainees. For questions or more information contact me or have a look at http://viswiz.gmd.de/reta/ Thanks, feel free to distribute this offer. Christian Bohn -- Christian Bohn, Institute for Media Communication, GMD +49-2241-142230, http://viswiz.gmd.de/bohn, bohn@gmd.de From owner-globillum@imag.imag.fr Sat Aug 28 23:31:57 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id XAA30031 for ; Sat, 28 Aug 1999 23:31:41 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id HAA06086 for globillum-imag-outgoing; Sun, 29 Aug 1999 07:19:13 +0200 (MET DST) From: Peter Shirley Message-Id: <199908290518.XAA19578@lal.cs.utah.edu> Subject: BRDF links? To: globillum@imag.fr Date: Sat, 28 Aug 1999 23:18:33 -0600 (MDT) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R Hi-- I am teaching a seminar on BRDFs this term: http://www2.cs.utah.edu/~shirley/classes/brdf/ If you have any other links please send them to me. Also, I used to have a list of journals etc on my page. If you used this they have moved to: http://www2.cs.utah.edu/vissim/resources/ Thanks Pete From owner-globillum@imag.imag.fr Tue Aug 31 11:14:27 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id LAA33466 for ; Tue, 31 Aug 1999 11:14:26 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id TAA25923 for globillum-imag-outgoing; Tue, 31 Aug 1999 19:44:13 +0200 (MET DST) Date: Tue, 31 Aug 1999 13:44:05 -0400 From: "Stephen N. Spencer" To: globillum@imag.fr Subject: Re: good old ones (from P. Dutre and M. Blais) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R > More seriously, wouldn't it be really nice if ACM / SIGGRAPH > scan/converted the old proceedings into pdf files and sold CD reprints of > these old proceedings? Funny you should say that -- it's exactly what we're doing right now, with the help of Xerox Business Services. Hopefully they'll be available by year's end. > Also, maybe they are already available thru the ACM Digital Library? They'll be available through the ACM Digital Library, too, though probably not as quickly as they'll be available on CD. Stephen N. Spencer 614.292.1067 (v) Graphics Research Specialist spencer@siggraph.org 614.292.7776 (f) ACCAD - The Ohio State University spencer@cgrg.ohio-state.edu 614.520.5799 (p) SIGGRAPH Director for Publications spencer@acm.org "After ecstasy, laundry." -- Zen writing "The truth is that progress is usually small and sneaky." -- Anne Lamott From owner-globillum@imag.imag.fr Thu Sep 2 09:58:31 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id JAA36172 for ; Thu, 2 Sep 1999 09:58:29 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id SAA26629 for globillum-imag-outgoing; Thu, 2 Sep 1999 18:32:36 +0200 (MET DST) Date: Thu, 2 Sep 1999 12:32:23 -0400 (EDT) Message-Id: <199909021632.MAA06058@bach.Graphics.Cornell.EDU> From: "Stephen H. Westin" To: globillum@imag.fr In-reply-to: <852567E0.00561BB7.00@D51MTA03.pok.ibm.com> (hertjwr@us.ibm.com) Subject: Re: BRDF links? Reply-to: westin@graphics.cornell.edu References: <852567E0.00561BB7.00@D51MTA03.pok.ibm.com> Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R Holly wrote: > My uncle asked me about an interesting problem involving BRDF. He > had read once that we get 1/9 the light from a half moon than we get > from a full moon. If you work it out for a Lambertian surface, we > would get 1/pi the light. I couldn't come up with 1/9 right of the > bat, but I think it has to do with the moon being retroreflective. > Siegel and Howell points out since a full moon looks equally bright > all the way across, the peak of retroreflectance must increase with > view angle to compensate for the reduced projected area. If the 1/9 > figure is correct, I think you can also estimate the width of the > lobe around the direction of retroreflection ( or you could use the > data from Siegel and Howell to approximate the BRDF and check if 1/9 > is about right.) Actually, this is quite well studied in planetary science. A model originated by Hapke and enhanced over the last two or three decades is generally used; it includes a term for the "opposition surge", which is their term for retroreflection. I think there is still debate about the actual physical mechanism involved, and how best to model it. The enhanced Hapke model looks pretty ugly to me, but then what do I know about planetary science? Anyway, it's interesting to talk to these folks, as they have the opposite problem to rendering: they know something about the radiance, and want to deduce composition, surface structure, and even geometry from their images. The Moon has been studied particularly well, as it's the only extraterrestrial body from which we have actual samples. The hope is that a model that deduces the correct characteristics for the Moon will probably give you the right answer on Mars or an asteroid. -Stephen H. Westin Any information or opinions in this message are mine: they do not represent the position of Cornell University or any of its sponsors. From owner-globillum@imag.imag.fr Thu Sep 2 15:05:57 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id PAA36333 for ; Thu, 2 Sep 1999 15:05:56 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id XAA07105 for globillum-imag-outgoing; Thu, 2 Sep 1999 23:42:46 +0200 (MET DST) Date: Thu, 2 Sep 1999 14:21:11 -0700 (PDT) From: Alain Fournier Message-Id: <199909022121.OAA06588@pedigree.cs.ubc.ca> To: hertjwr@us.ibm.com, shirley@cs.utah.edu Subject: Re: BRDF links? Cc: globillum@imag.fr Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R I remember that a simple formula to "explain" the uniform brightness of the full moon is that it raflects as cos(theta)^0.5, where theta of course is the angle between surface normal and light source (sun) direction, which is the same as the viewing direction when the moon is full. I would have to figure out if it gives the 1/9 ratio for the half moon. I also have to find the relevant references (Bob Woodham in our department has been involved with that very subject in the not too distant past). From owner-globillum@imag.imag.fr Mon Sep 6 08:22:06 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id IAA40624 for ; Mon, 6 Sep 1999 08:22:04 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id PAA08007 for globillum-imag-outgoing; Mon, 6 Sep 1999 15:29:46 +0200 (MET DST) From: eric.haines@autodesk.com Message-ID: <19879C753611D3119DAB0008C7A4C0C101C446F0@hqmsgsrf04.autodesk.com> To: globillum@imag.fr Subject: New ray tracing bibliography Date: Fri, 3 Sep 1999 08:13:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: RO The free ray tracing bibliography has been updated, it's at http://www.acm.org/pubs/tog/resources/bib/ While it's continuing to get hazy as to what a ray tracing paper is (e.g. do Monte Carlo sampling papers count? No, I try to list papers specifically about how to do ray tracing, not about using ray tracing as a tool), I still think it's worth maintaining. As usual, let me know of any missing papers, Eric From owner-globillum@imag.imag.fr Mon Sep 6 09:41:57 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id JAA40922 for ; Mon, 6 Sep 1999 09:41:55 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id SAA12020 for globillum-imag-outgoing; Mon, 6 Sep 1999 18:07:49 +0200 (MET DST) Message-ID: <001501bef881$b4b0ae20$9f9c42d8@byheart> Reply-To: "Ian Ashdown" From: "Ian Ashdown" To: References: <19879C753611D3119DAB0008C7A4C0C101C446F0@hqmsgsrf04.autodesk.com> Subject: Re: New ray tracing bibliography Date: Mon, 6 Sep 1999 09:05:56 -0700 Organization: byHeartConsultants Limited MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: RO > The free ray tracing bibliography has been updated, it's at > http://www.acm.org/pubs/tog/resources/bib/ While it's continuing to get hazy > as to what a ray tracing paper is (e.g. do Monte Carlo sampling papers > count? No, I try to list papers specifically about how to do ray tracing, > not about using ray tracing as a tool), I still think it's worth > maintaining. > Given that the RADBIB global illumination bibliography gets over 100 hits a month from my Web site alone, I would say that Eric's maintaining his ray tracing bibliography is well worth the effort. If nothing else, consider the poor grad student who has to jump from Foley et al.'s Computer Graphics to researching a quarter-century of obscure publications. Keep up the good work, Eric -- it is appreciated! Ian Ashdown, P. Eng., LC Vice President byHeart Consultants Limited http://www.helios32.com From owner-globillum@imag.imag.fr Mon Sep 13 14:09:04 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id OAA51327 for ; Mon, 13 Sep 1999 14:09:03 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id WAA13543 for globillum-imag-outgoing; Mon, 13 Sep 1999 22:38:52 +0200 (MET DST) From: "A Gallardo" To: "Peter Shirley" , Subject: RE: BRDF links? Date: Mon, 13 Sep 1999 16:30:20 -0400 Message-ID: <000801befe26$cc3106d0$e3d81a26@dellxps> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: <199908290518.XAA19578@lal.cs.utah.edu> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Importance: Normal Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R Hi, Sorry for the delayed post. I am just catching up on my e-mail. Here are a few liks I have found. http://www.cgl.uwaterloo.ca/Projects/rendering/refl.html http://www.cs.columbia.edu/CAVE/curet/ Regards, Arnold Gallardo Visual Content Creator > -----Original Message----- > From: owner-globillum@imag.imag.fr > [mailto:owner-globillum@imag.imag.fr]On Behalf Of Peter Shirley > Sent: Sunday, August 29, 1999 1:19 AM > To: globillum@imag.fr > Subject: BRDF links? > > > > Hi-- I am teaching a seminar on BRDFs this term: > http://www2.cs.utah.edu/~shirley/classes/brdf/ > > If you have any other links please send them to me. > > Also, I used to have a list of journals etc on my page. > If you used this they have moved to: > http://www2.cs.utah.edu/vissim/resources/ > > Thanks > > Pete > From owner-globillum@imag.imag.fr Mon Sep 13 14:48:06 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id OAA51345 for ; Mon, 13 Sep 1999 14:48:05 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id XAA14935 for globillum-imag-outgoing; Mon, 13 Sep 1999 23:16:45 +0200 (MET DST) From: "A Gallardo" To: "Globillum" Subject: RE: Web pages, and conversations Date: Mon, 13 Sep 1999 17:16:26 -0400 Message-ID: <000901befe2d$3d4b48c0$e3d81a26@dellxps> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Importance: Normal Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R Hi, I am just catching up so sorry if this seemed old to you. I am not a global illum researcher per se but rather got into researching because of the radiosity images that I have seen as well as in using a commercially available progressive refinement program. My comments are below. > Listening to the second (third?) annual panel on "(global illumination in > production)" echoed several sentiments I heard from people at PDI > and Pixar: > > 1. Global illumination is too expensive in terms of compute time, > 2. Artists can get as good or better with the tools they have, and > 3. Even if they had instant global illumination algorithms > at hand, artists > don't want > the effect of realism. In fact, they want everything but realism. The third comment is true. Most users after being exposed to a commercial progressive refinement program says it too much work. Too many things to setup and it is easier to achieve by simulating radiosity using local none-shadow casting omnidirectional lights to simulate indirect illumination. It also requires a trememdous amount of processing power and RAM for complex scenes. Most people resent that fact that they have to redo the solutions again if they want to change the geometry. They expect the ease of moving geometry with ttheir scanline or raytracer program, none of them have heard about discontinuity meshing much less dynamic discontinuity meshing. On the other end of the spectrum, beginners using a relatively easy program with minimal parameters are baffled by terms like 'convergeance','iterations' and 'tonemapping'. They generally assume that radiosity is as easy as a raytracer which only requires light placement, color and intensity to work. They expect radiosity to have no 'user intervention issues' at all. Lastly most are not aware of the quadrilateral polygonal geometry requirement which speeds things up and avoid artifacts and they also expect NURBS-based geometry to work well with radiosity. I think that most end users are more likely to adapt to the monte-carlo based radiosity rather than with the deterministic ones. So the issue today is that radiosity even with its gorgeous renderings are no longer persuasive once the end user experience the amount of knowledge needed as well as the amount of intervention needed to produce realistic renderings. It is just so much easier to 'fake' radiosity. It remains to be seen if monte-carlo based radiosity would change the tide. Regards, Arnold Gallardo Visual Content Creator > So, what thoughts does anybody have? > > On another note, could somebody *please* send me the URL for the globillum > archive web page? > > -- > Bretton Wade > http://redirect.to/bretton_wade > From owner-globillum@imag.imag.fr Wed Sep 15 15:02:59 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id PAA55360 for ; Wed, 15 Sep 1999 15:02:57 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id XAA03907 for globillum-imag-outgoing; Wed, 15 Sep 1999 23:03:49 +0200 (MET DST) From: hertjwr@us.ibm.com X-Lotus-FromDomain: IBMUS To: globillum@imag.fr Message-ID: <852567ED.0073A7AE.00@D51MTA03.pok.ibm.com> Date: Wed, 15 Sep 1999 17:03:26 -0400 Subject: job openings Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R Please note that you should contact Gabriel (contact coordinates at the end) with any questions about these openings (rather than using "Reply " to this note) -- Holly Rushmeier ========================================================================= Dear friends, I have two job openings in my department. Job #1 is at the programmer level. It requires a M.Sc. or B.Sc. in computer science, experience with graphics/geometric algorithms, and software development. The successful candidate will help other members of the group develop and implement new ideas, as well as transfer our technology to other IBM divisions, such as the Internet Division. Job #2 is post-doctoral position. The successful candidate will interact with other members of the group to invent and implement new geometric/graphics algorithms/technologies. In the Visual and Geometric Computing group, we are interested in issues related to 3D Graphics in a networked environment, including 3D scanning, surface reconstruction, surface simplification, geometry compression, progressive transmission, and rendering. We are also interested in new image-based representation and rendering schemes. The two most recent projects we have worked on are: 1) the Pieta project, where we reconstructed a 3D model of Michaelangelo's Florentine Pieta, to support art historian Jack Wasserman's study of the statue. 2) the Geometry Compression project, where the technology we developed during the last four years is now part of the MPEG-4 standard. In the 3D scanning front, and based on the experience acquired scanning the Pieta, we are now interested in developing new inexpensive and easy to use 3D scanning systems, including both hardware and software. In the Geometry Compression front, we are now working closely with the IBM Internet Media group to incorporate our MPEG-4 technology to their HotMedia product. We are also developing new schemes/algorithms. If any one of your students/associates is interested in any one of these two positions, please tell her/him to get in touch with me. IBM is an equal opportunity employer. Best regards. -------------------------------------------------------------------------- Gabriel Taubin Manager, Visual and Geometric Computing email: taubin@us.ibm.com IBM T. J. Watson Research Center phone: (914)-784-7095 P.O.Box 704, Yorktown Heights, NY 10598 fax : (914)-784-7667 -------------------------------------------------------------------------- From owner-globillum@imag.imag.fr Thu Sep 16 14:01:54 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id OAA56297 for ; Thu, 16 Sep 1999 14:01:53 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id VAA15088 for globillum-imag-outgoing; Thu, 16 Sep 1999 21:50:32 +0200 (MET DST) From: Paul.Heckbert@HOSTESS.GRAPHICS.CS.CMU.EDU Message-Id: <199909161950.VAA15084@imag.imag.fr> Date: Thu, 16 Sep 99 15:27:43 EDT To: globillum@imag.fr Subject: Re: global illumination in production Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R Arnold Gallardo says: | From: "A Gallardo" | Subject: RE: Web pages, and conversations | Date: Mon, 13 Sep 1999 17:16:26 -0400 | | ... sentiments I heard from people at PDI and Pixar: | > 1. Global illumination is too expensive in terms of compute time, | > 2. Artists can get as good or better with the tools they have, and | > 3. Even if they had instant global illumination algorithms | > at hand, artists don't want the effect of realism. | > In fact, they want everything but realism. This reminds me of attitudes regarding animation techniques from about ten or fifteen years ago. Back then, almost everybody doing animation was using keyframe or procedural methods, and there were only a few academic graphics people and finite element-oriented engineers doing dynamics, and only in specialized situations. The realism of dynamics was attractive, but nobody wanted to give up the control of keyframing systems and turn animation into an initial value problem (users' control limited to initial positions, velocities, masses, and positions), since it would be extremely tedious to get things to move where you wanted. Dynamics is still not easy to use, in general, but with faster hardware, improved algorithms, spacetime techniques, combinations of dynamics for realism and keyframing for control, and better user interfaces, dynamics is much more usable today than it was back then. It's no longer just a "research topic", but is used in production on a regular basis. Global illumination is probably a few years behind dynamics, but it has many of the same high level strengths and weaknesses: * it's good at achieving realism * achieving realism with "manual" techniques is tedious * if you use it whole hog, you give up control * it appears too slow * current methods are too specialized If we keep chipping away at the tough research problems, pay more attention to what users want (control, ease of use, ...) then global illumination will become very commonly used some day soon. -Paul Paul Heckbert, Associate Professor Computer Science Dept., Carnegie Mellon University 5000 Forbes Ave, Pittsburgh PA 15213-3891, USA ph@cs.cmu.edu http://www.cs.cmu.edu/~ph From owner-globillum@imag.imag.fr Fri Sep 17 11:03:53 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id LAA58373 for ; Fri, 17 Sep 1999 11:03:52 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id TAA20966 for globillum-imag-outgoing; Fri, 17 Sep 1999 19:02:58 +0200 (MET DST) Date: Fri, 17 Sep 1999 13:02:53 -0400 (EDT) Message-Id: <199909171702.NAA08236@bach.Graphics.Cornell.EDU> From: "Stephen H. Westin" To: globillum@imag.fr In-reply-to: <37E249F2.DAA98529@gmd.de> (message from Christian Bohn on Fri, 17 Sep 1999 16:02:26 +0200) Subject: Re: CG and wave theory ? Reply-to: westin@graphics.cornell.edu References: <37E249F2.DAA98529@gmd.de> Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R > Date: Fri, 17 Sep 1999 16:02:26 +0200 > From: Christian Bohn > X-Accept-Language: en > Content-Type: text/plain; charset=us-ascii > Sender: owner-globillum@imag.imag.fr > Precedence: bulk > > Hi all, > Does anybody know about recent activities concerning > '3D-CG and wave theory'? > > It seems that actually there's not much interest in that field?! > What I only found is Moravec's paper from siggraph'81, and I am > wondering if anybody else did some work during the past two decades. Well, modeling light as waves at a macro level doesn't really make a lot of sense: you need incredible resolution (Moravec's paper really basically did visualization of radio wave propagation) and it's hard to find a situation where it makes a visible difference. More useful is modeling wave optics where it really does matter: in interaction with surfaces and such. Several papers deal with that: the SIGGRAPH '91 paper from He et al. comes to mind. That solved for wave optics of a class of rough surfaces. Gondek and Meyer did simulations of reflectance, including interference effects within the surface microstructure; that was presented at SIGGRAPH '94, as I recall. And it followed on a Eurographics '90 (I think) paper by Smits and Meyer. Most recently, Jos Stam presented a paper last month at SIGGRAPH on an anisotropic wave-optics model. On the original point, Peter Kochevar did his dissertation here at Cornell in 1989 on a cell-based rendering method designed for massive parallelism. While it wasn't explicitly wave-based, it exhibited some similar characteristics, such as diffraction around corners. From owner-globillum@imag.imag.fr Fri Sep 17 12:19:40 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id MAA58216 for ; Fri, 17 Sep 1999 12:19:39 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id QAA09893 for globillum-imag-outgoing; Fri, 17 Sep 1999 16:02:31 +0200 (MET DST) Message-ID: <37E249F2.DAA98529@gmd.de> Date: Fri, 17 Sep 1999 16:02:26 +0200 From: Christian Bohn X-Mailer: Mozilla 4.51 [en] (X11; U; IRIX 6.3 IP32) X-Accept-Language: en MIME-Version: 1.0 To: globillum@imag.fr Subject: CG and wave theory ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R Hi all, Does anybody know about recent activities concerning '3D-CG and wave theory'? It seems that actually there's not much interest in that field?! What I only found is Moravec's paper from siggraph'81, and I am wondering if anybody else did some work during the past two decades. Thanks for any links, references, etc. Christian -- Christian Bohn, Institute for Media Communication, GMD +49-2241-142230, http://viswiz.gmd.de/bohn, bohn@gmd.de From owner-globillum@imag.imag.fr Fri Sep 17 12:27:16 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id MAA57685 for ; Fri, 17 Sep 1999 12:27:15 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id UAA26357 for globillum-imag-outgoing; Fri, 17 Sep 1999 20:56:34 +0200 (MET DST) From: hertjwr@us.ibm.com X-Lotus-FromDomain: IBMUS To: "Michael Cohen (Research)" cc: "'globillum@imag.fr'" Message-ID: <852567EF.0067FEC5.00@D51MTA03.pok.ibm.com> Date: Fri, 17 Sep 1999 14:56:10 -0400 Subject: RE: CG and wave theory ? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R Maybe you are thinking of: Gershon Elber. ``Low Cost Illumination Computation using an Approximation of Light Wavefronts.'' Computer Graphics, pp 335-342, July 1994, (Siggraph 1994) ? I think the above paper is about a geometric solution to following sets of waves by following a "wavefront" coming from a spherical source. It doesn't treat the wave nature of light. __________________________ Holly Rushmeier , holly@watson.ibm.com, (914)784-7252 IBM TJ Watson Research Center, 30 Saw Mill River Road, Hawthorne, NY 10532, USA From owner-globillum@imag.imag.fr Wed Sep 22 02:28:09 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id CAA65964 for ; Wed, 22 Sep 1999 02:28:07 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id KAA03145 for globillum-imag-outgoing; Wed, 22 Sep 1999 10:25:13 +0200 (MET DST) From: Fredo Durand Message-Id: <199909220825.EAA22969@hue.lcs.mit.edu> Subject: Re: wavefront To: globillum@imag.fr Date: Wed, 22 Sep 1999 04:25:04 -0400 (EDT) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R You can also have a look at: http://www.lems.brown.edu/~leymarie/WaveRender/NotesDec98.html for a research project related to wave propagation I'm sure there are also lots of references in sound simulation Fredo From owner-globillum@imag.imag.fr Wed Sep 22 12:01:39 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id MAA65999 for ; Wed, 22 Sep 1999 12:01:38 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id OAA00701 for globillum-imag-outgoing; Wed, 22 Sep 1999 14:54:57 +0200 (MET DST) From: hertjwr@us.ibm.com X-Lotus-FromDomain: IBMUS To: Fredo Durand cc: globillum@imag.fr Message-ID: <852567F4.0046E87B.00@D51MTA03.pok.ibm.com> Date: Wed, 22 Sep 1999 08:54:27 -0400 Subject: Re: wavefront Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R The approach described in the page Fredo cited seems to me in some ways similar to the Gelber SIGGRAPH 94 paper. They are all using **geometric optics**. The geometrical wavefront being modelled is the surface that is perpendicular to the light rays passing through it. I think Mitchell and Hanrahan's SIGGRAPH 92 was the first to describe these geometric wavefronts and their use in an illumination solution in graphics. Leymarie and Kimia discuss the use of BRDF's in the solution, and BRDF's are the encapsulation of the wave effects of light near a surface when you have to take into account geometric features comparable in size to the wavelength of light. They take an approach for tracking this waves using cellular automata -- which sounds very similar to Peter Kochevar's work that Steve Westin referred to. You can't capture diffraction, interference effects with this voxel approach, unless you have voxels smaller than the wavelength of the radiation. For visible light, this means chopping up the environment pretty finely!! For other types of radiation with substantionally longer wavelengths this is not so bad. Anyway, -- computing geometric wavefronts is not the same as computing effects due to the wave nature of light (i.e. diffraction, interference), but they are both interesting topics -- for the complexity of solving for effects of the wave nature of light we are stuck with dealing with discretizations on the order of (wavelength of light/ our size) or approx.10-7, which makes it much more demanding computationally that some other types of radiation. __________ -- Holly __________________________ Holly Rushmeier , holly@watson.ibm.com, (914)784-7252 IBM TJ Watson Research Center, 30 Saw Mill River Road, Hawthorne, NY 10532, USA Fredo Durand @imag.imag.fr on 09/22/99 04:25:04 AM Sent by: owner-globillum@imag.imag.fr To: globillum@imag.fr cc: Subject: Re: wavefront You can also have a look at: http://www.lems.brown.edu/~leymarie/WaveRender/NotesDec98.html for a research project related to wave propagation I'm sure there are also lots of references in sound simulation Fredo From owner-globillum@imag.imag.fr Wed Sep 22 12:21:19 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id MAA56139 for ; Wed, 22 Sep 1999 12:21:18 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id RAA11265 for globillum-imag-outgoing; Wed, 22 Sep 1999 17:09:21 +0200 (MET DST) Date: Wed, 22 Sep 1999 11:09:14 -0400 (EDT) From: Jack Tumblin To: hertjwr@us.ibm.com cc: Fredo Durand , globillum@imag.fr Subject: Re: wavefront In-Reply-To: <852567F4.0046E87B.00@D51MTA03.pok.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R Gulp, I'm not very familiar with these papers on wave optics in computer graphics, so maybe I should keep my mouth shut here, but sampling volumes at wavelength resolution seems an especially unfortunate choice for modeling wave propagation in the free space between objects. Instead, I'd suggest looking at the Fourier optics formulation for free-space propagation of coherent and monochromatic incoherent light. It is a wave-optics technique that describes light as a continuous-domain complex scalar field: each point (x,y,z) has just amplitude and phase. The math for propagation through free space (or any ordinary uniform medium) from a point source uses a quadratic approximation that looks ALMOST like a Fourier transform, and has proved very accurate for lenses, holography, diffraction and interference through arbitrary apertures, and lots of work in optical computing (military folks used Fourier-optics-based equipment as much as 35-45 years ago for broadband radio surveillance/spying). Would Fourier optics permit us to compute some sort of `complex form factor' to describe the aggregate phase and amplitude relationship between surface patches alone, so that we can forget about the empty volume inbetween? Perhaps a complex integration across source and the receiver patches chosen according to display image resolution? Of course this patch-to-patch integral might be even tougher to solve than Shroder&Hanrahan's precise form factor integral of SIGGRAPH'93, but who knows--it might be simpler. Is it REALLY necessary to have wave-sized patches, even on surfaces, if 1) their results are merged to screen resolution for display, and 2) their free-space interactions are a weighted sum of many sinusoids? I think only the DISTANCES between surface points matter for the wave effects of interest to computer graphics; there's no need to sample those distances to find the phase of a sinusoid spanning it! The classic text for Fourier Optics is: "Introduction to Fourier Optics" J.W.Goodman(1968), and the library website shows 16 other promising looking tutorials & textbooks. It's course material in the optics track in Electrical Engineering here at Tech, (William Rhoades taught / teaches it and later wrote a textbook for the course I took long ago). Regards, -Jack Tumblin (ccsupjt@cc.gatech.edu) Gradual Student, College of Computing (leaving for Cornell Univ. post-doc Sept 23) "Black care rarely sits behind a rider who is fast enough" T. Roosevelt On Wed, 22 Sep 1999 hertjwr@us.ibm.com wrote: > The approach described in the page Fredo cited seems to me in some ways similar > to the Gelber SIGGRAPH 94 paper. They are all using **geometric > optics**. The geometrical ... > > Leymarie and Kimia discuss the use of BRDF's in the solution, > and BRDF's are the encapsulation of the wave effects of light near a surface > when you have to take into account geometric features comparable in size > to the wavelength of light. They take an approach for tracking this > waves using cellular automata -- which sounds very similar to Peter > Kochevar's work that Steve Westin referred to. You can't capture > diffraction, interference effects with this voxel approach, unless you > have voxels smaller than the wavelength of the radiation. For visible > light, this means chopping up the environment pretty finely!! For other > types of radiation with substantionally longer wavelengths this is not > so bad. > >for the complexity of solving for effects of the wave nature of light we are !!!!> stuck with dealing with discretizations on the order of (wavelength !!!!> of light/ our size) or approx.10-7, which makes it much more !!!!> demanding computationally that some other types of radiation. > __________ > Holly Rushmeier , holly@watson.ibm.com, (914)784-7252 > IBM TJ Watson Research Center, 30 Saw Mill River Road, Hawthorne, NY 10532, USA > > > Fredo Durand @imag.imag.fr on 09/22/99 04:25:04 AM > You can also have a look at: > http://www.lems.brown.edu/~leymarie/WaveRender/NotesDec98.html > for a research project related to wave propagation > > I'm sure there are also lots of references in sound simulation > > Fredo From owner-globillum@imag.imag.fr Wed Sep 22 13:22:04 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id NAA66619 for ; Wed, 22 Sep 1999 13:22:03 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id VAA28573 for globillum-imag-outgoing; Wed, 22 Sep 1999 21:45:32 +0200 (MET DST) Message-ID: From: Don Mitchell To: globillum@imag.fr Subject: RE: wavefront Date: Wed, 22 Sep 1999 12:35:12 -0700 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R Shinya's pencil-tracing paper is also based on geometrical optics, described with a somewhat different formalism. Wavefront tracing buys you the ability to get an irradiance value along the ray, so you can almost do backward ray tracing with interpolation instead of density estimation. However, because the wavefront can fold, generating caustics, that interpolation is not simple. There was an elegant paper from Manchester (and I'm blanking on the reference now...) where they did backward wavefront tracing, and used the curvature to control the kernel size in a density estimation. -----Original Message----- From: hertjwr@us.ibm.com [mailto:hertjwr@us.ibm.com] Sent: Wednesday, September 22, 1999 5:54 AM To: Fredo Durand Cc: globillum@imag.fr Subject: Re: wavefront The approach described in the page Fredo cited seems to me in some ways similar to the Gelber SIGGRAPH 94 paper. They are all using **geometric optics**. The geometrical wavefront being modelled is the surface that is perpendicular to the light rays passing through it. I think Mitchell and Hanrahan's SIGGRAPH 92 was the first to describe these geometric wavefronts and their use in an illumination solution in graphics. Leymarie and Kimia discuss the use of BRDF's in the solution, and BRDF's are the encapsulation of the wave effects of light near a surface when you have to take into account geometric features comparable in size to the wavelength of light. They take an approach for tracking this waves using cellular automata -- which sounds very similar to Peter Kochevar's work that Steve Westin referred to. You can't capture diffraction, interference effects with this voxel approach, unless you have voxels smaller than the wavelength of the radiation. For visible light, this means chopping up the environment pretty finely!! For other types of radiation with substantionally longer wavelengths this is not so bad. Anyway, -- computing geometric wavefronts is not the same as computing effects due to the wave nature of light (i.e. diffraction, interference), but they are both interesting topics -- for the complexity of solving for effects of the wave nature of light we are stuck with dealing with discretizations on the order of (wavelength of light/ our size) or approx.10-7, which makes it much more demanding computationally that some other types of radiation. __________ -- Holly __________________________ Holly Rushmeier , holly@watson.ibm.com, (914)784-7252 IBM TJ Watson Research Center, 30 Saw Mill River Road, Hawthorne, NY 10532, USA Fredo Durand @imag.imag.fr on 09/22/99 04:25:04 AM Sent by: owner-globillum@imag.imag.fr To: globillum@imag.fr cc: Subject: Re: wavefront You can also have a look at: http://www.lems.brown.edu/~leymarie/WaveRender/NotesDec98.html for a research project related to wave propagation I'm sure there are also lots of references in sound simulation Fredo From owner-globillum@imag.imag.fr Wed Sep 22 14:02:45 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id OAA66627 for ; Wed, 22 Sep 1999 14:02:44 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id WAA00566 for globillum-imag-outgoing; Wed, 22 Sep 1999 22:30:48 +0200 (MET DST) Message-ID: <000401bf0610$7b801c20$0c0200c0@langzaam.toren.com> From: "tallind" To: , "Fredo Durand" Cc: Subject: Re: wavefront Date: Fri, 24 Sep 1999 00:10:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R Hi, I`m Jolly. I joined the global illumiation newsletter not so long ago. What I want to ask is what program you people think is the best for architectural visualisation. ( and would be able to be used in a production enviroment ) Regards, Jolly From ccsupjt@cc.gatech.edu Thu Sep 23 09:37:14 1999 Received: from burdell.cc.gatech.edu (burdell.cc.gatech.edu [130.207.3.207]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id JAA67015 for ; Thu, 23 Sep 1999 09:37:13 -0700 (PDT) Received: from gaia.cc.gatech.edu (ccsupjt@gaia.cc.gatech.edu [130.207.3.8]) by burdell.cc.gatech.edu (8.9.1/8.9.1) with ESMTP id MAA02684; Thu, 23 Sep 1999 12:40:42 -0400 (EDT) Received: from localhost (ccsupjt@localhost) by gaia.cc.gatech.edu (8.9.1/8.9.1) with SMTP id MAA28925; Thu, 23 Sep 1999 12:40:15 -0400 (EDT) Date: Thu, 23 Sep 1999 12:40:15 -0400 (EDT) From: Jack Tumblin To: Carlos Saona Vazquez , "Wayne L. Wooten" , Ben Watson , "Christopher D. Watkins" , Greg Ward-Larson , Dongmei Wang , John & Alice Tumblin , John Snyder , Stephen Sinclair , Mike Sinclair , Peter Shirley , Marcia Riley , Bonnie Riehl , Charlie Patterson , Sarah Mantegna , Gregory Ward Larson , Victor Klassen , JKH animation lab group , Yves Darly Jean , Ingrid Maria Hybinette , "Larry F. Hodges" , Keven Haynes , Brian Guenter , "Greg Turk's Geometry Reading Group" , Irfan Essa , "Jason B. Ellis" , Barbara Durham , Liz Degoursac/SomeWare , "'Liz DeGoursac" , "de Goursac, Liz" , David Cardoze , Keith Blanton , Robert Basil , Tucker Balch Subject: Gawn'tuh Cornell! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: R Well, it's finally happened--I've finished the dissertation, packed up my apartment and Old Kit Bag and am leaving Georgia Tech tomorrow morning. Monday Morning Sept. 27 I begin a 2-year post-doc fellowship with Don Greenberg at the Program of Computer Graphics at Cornell University in Ithaca NY. If you need to reach me there, my address will be: Jack Tumblin Program of Computer Graphics 580 Rhodes Hall Cornell University Ithaca, NY 14853-1736 office phone: (607) 255-2067 and my e-mail at Ga Tech (ccsupjt@cc.gatech.edu) should still work until the end of the year. I will be coming back to Atlanta in December to march in the graduation parade (Dec 18?) so I'll see some of you then. A pleasant goodbye and good luck to those of you that I can't find before I go! Best Regards, -Jack Tumblin (ccsupjt@cc.gatech.edu) Gradual Student, College of Computing "Black care rarely sits behind a rider who is fast enough" T. Roosevelt From owner-globillum@imag.imag.fr Sun Oct 10 20:25:11 1999 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by positron.CS.Berkeley.EDU (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id UAA93884 for ; Sun, 10 Oct 1999 20:25:10 -0700 (PDT) Received: (from majordom@localhost) by imag.imag.fr (8.9.3/8.8.5) id EAA02374 for globillum-imag-outgoing; Mon, 11 Oct 1999 04:55:18 +0200 (MET DST) Message-ID: <001a01bf1393$9ca766c0$669c42d8@byheart> Reply-To: "Ian Ashdown" From: "Ian Ashdown" To: Subject: ANNOUNCE: 99/10/09 Release of RADBIB99.BIB Date: Sun, 10 Oct 1999 19:52:08 -0700 Organization: byHeartConsultants Limited MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-globillum@imag.imag.fr Precedence: bulk Status: R ANNOUNCE: 99/10/09 Release of RADBIB99.BIB ------------------------------------------ RADBIB99 is a comprehensive bibliography of radiosity and related global illumination papers, theses, articles, and books. It currently includes 1,661 references -- 40 new additions since the 99/08/01 release. This bibliography is available in BibTex format as RADBIB99.BIB (with a release date of October 9, 1999) from: http://www.helios32.com/resources.htm Also available from this site is an abridged version of RADBIB99.BIB called GITHESIS.BIB. This bibliography includes 195 references to radiosity and global illumination theses -- no new additions since the 99/07/15 release. Financial support for the maintenance of these bibliographies has been provided by ACM SIGGRAPH Special Projects and byHeart Consultants Limited. Ian Ashdown, P. Eng., LC Vice President byHeart Consultants Limited http://www.helios32.com