Talk:Radiosity

From Wikipedia, the free encyclopedia

  • There's some bad grammar in the first part of this. The second paragraph in particular needs some work; it's not clear what it is saying. Osmaker 18:59, 20 October 2005 (UTC)
    • I've re-arranged some text. Added a bit here and a bit there. Made it easier to read in mosdt of the areas except the maths sections. Snorbaard 3:04, 24 October 2005 (GMT+2)
    • That looks and reads a lot better; thanks. Osmaker 07:02, 24 October 2005 (UTC)
  • There is a mistake in the discrete radiosity equation. The form-factor inside the sum should be Fij instead of Fji (Francesc Castro, castro@ima.udg.es)
    • Actually, the mistake happened before! The way Fji is defined in this article, the very first formula has to be:B_i\, d A_i = E_i\, d A_i + R_i \int_j B_j F_{ij}\, d A_j,\,\!. The reciprocity also has to be changed to AjFij = AiFji. Finally, in the next 2 formulas, Fij has to be changed to Fji. Wernermarius (talk) 17:05, 17 February 2008 (UTC)
    • An alternative to the above correction is to define Fij as the view factor for the radiation leaving i and hitting patch j. This is more common in CG textbooks. With this correction, no formulas need to be changed. Wernermarius (talk) 17:05, 17 February 2008 (UTC)
      • I went ahead and integrated this correction. Wernermarius (talk) 09:38, 18 February 2008 (UTC)


Contents

[edit] Maxwell..

(afaik) is a truly physically-based renderer, ie it does not employ the kinds of shortcuts that GI renderers use. Is it a good example of a GI renderer? I know of the following: Lucille, POV-Ray, Pane, Parthenon, Perceptuum, Radiance, toxic, Iguana, and those are the free ones...

  • FYI: GI = "global illumination." Global illumination simply means that the shading at each point depends on more than the location and orientation of that point, in other words, the shading depends on other geometry in the scene. Simple shadows are an example of global illumination, as are simple reflections and simple refractions. Maxwell is an example of an unbiased renderer (or so they claim), i.e., it correctly accounts for all types of light paths described by geometric optics. I can't think of a good example of a commercial radiosity renderer in widespread use, probably because most major renderers tend towards photon mapping and irradiance caching these days.

[edit] Global Illumination and Ray Tracing

The article at the very beginning references direct illumination algorithms and refers to ray tracing as an example of one. I however thought ray tracing was also a global illumination algorithm, and if you look at the wikipedia page on global illumination algorithms, it refers to ray tracing as an example of one. --Dterei 09:22, 17 October 2006 (UTC)

  • You are absolutely correct: ray tracing is a global illumination algorithm. I have fixed this error in the page.

I think ray tracing is used to transfere the light around the scene. How else should global illumination get its F[i,j] ? Arnero 17:41, 28 October 2006 (UTC)

  • Well, ray tracing refers to a broad class of algorithms for computing radiance arriving at the image plane "Whitted" ray tracing is what most people think of when they hear ray tracing, though Monte Carlo ray tracing is also ray tracing. Ray casting, i.e., the process of finding the geometric intersection of a ray and the scene geometry, is often used to compute visibility and transport of radiance from one spot to another. However, this isn't the only way to do it: radiosity doesn't have to use ray casting to compute its form factors (often they can be computed analytically).
  • As I understand it, ray tracing is neither a global nor direct illumination algorithm in itself, but it can be used to implement either.
    • Well, technically what you're referring to is ray casting, i.e., finding the intersection of rays with surfaces. Ray tracing really is a class of global illumination algorithms which use ray casting as the fundamental operation for computing the transport part of the equation.
  • "Global Illumination" refers to the class of rendering algorithms which are capable of illuminating an object from light scattered from the entire scene, not just from light sources and reflections/caustics. Direct illumination refers to algorithms which can only illuminate objects directly from light sources and sometimes from reflections/caustics. Whether you use ray tracing, or something else to implement direct or global illumination is up to you.
    • Wrong: reflections and caustics (not to mention simple hard shadows) are global phenomena. A phenomenon is "global" if you need information about any surface point other than the one you're shading in order to perform the shading computation. "Global illumination" algorithms are those which have any kind of global effect. So, ray tracing is a global illumination algorithm.
      • I'm willing to be wrong about this, and what you say could make sense, but you are the first person I have seen who includes shadow casting as part of global illumination. None of the first few pages on a google for "global illumination" seem to include shadow casting. Do you have a reference for this? Many thanks Rocketmagnet 15:38, 8 January 2007 (UTC)
        • Ok, so I was a bit overzealous about the issue of shadows, but certainly it's a consistent definition and one possible interpretation of "global," i.e., the opposite of local. The more common definition is "global" as in the opposite of direct, and is given in the paper "Fast Separation of Direct and Global Components of a Scene using High Frequency Illumination"[1] published in SIGGRAPH 2006: "When a scene is lit by a source of light, the radiance of each point in the scene can be viewed as having two components, namely, direct and global. The direct component is due to the direct illumination of the point by the source. The global component is due to the illumination of the point by other points in the scene." By this definition, a specular reflection is a global phenomenon because you're seeing an object lit by a bounce off another object, not an object directly lit by a light source. Honestly I think the English is wrong -- it should be direct vs. indirect or global vs. local, not global vs. direct, but I'm willing to stick with the convention.

[edit] replacing the ball picture

I have a replacement image that I think illustrates the difference between direct and global illumimation better than the ball image. The image is from my own web site, and was generated using a radiosity renderer I wrote myself, therefore I own the copyright. Eric Pierce, what do you think? If nobody minds, I'll replace the image, and adjust the text accordingly. Rocketmagnet 18:10, 7 January 2007 (UTC)

Yes, I think this is a very good example.

[edit] Different Algorithms

Hi Trevor, Thanks for that, and the other changes. From what you wrote, I think it would be good to have a section, or sections, listing or detailing several algorithms (shooting, texture mapping, etc.) If Agreed, I'll move your bit about shooting, and my bit about texturing into their own sections, which can then be expanded upon in a controlled manner by othe people.Rocketmagnet 09:43, 8 January 2007 (UTC)

  • Sounds good -- by the way, if you're interested in different methods or variations on methods for solving the radiosity equations you might want to check out these papers:
    • R. Troutman, N. Max, "Radiosity Algorithms Using Higher Order Finite Element Methods", SIGGRAPH 1993.
    • P. Hanrahan and D. Salzman and L. Aupperle, "A Rapid Hierarchical Radiosity Algorithm,"[2] SIGGRAPH, 197-206, 1991.
    • B.E. Smits and J.R. Arvo and D.H. Salesin, "An Importance Driven Radiosity Algorithm," SIGGRAPH, 273-282, 1992.
    • D. Lischinski, F. Tampieri and D.P. Greenberg, "A Discontinuity Meshing Algorithm for Accurate Radiosity," IEEE Computer Graphics and Applications, 12, 6, 25-39, 1992.

Trevorgoodchild 07:10, 13 January 2007 (UTC)

  • You know, I think part of the problem is not enough authors put their papers up on the web, and the damn ACM portal costs money! As a consequence, only people in academia can even take a look at some of these neat solutions, and everyone else ends up figuring out their own way to do it... which is not the point of research! :P Trevorgoodchild 17:40, 13 January 2007 (UTC)

[edit] Caption for Radiosity_Progress.jpg

Sorry Trevor, I have reverted the caption for Radiosity_Progress.jpg. From "As additional bounces are calculated in shooting radiosity the scene becomes progressively brighter." back to "As the algorithm iterates, light can be seen to flow into the scene, as multiple bounces are computed."

This is because I believe the original caption to be the more correct one. This image was not rendered using shooting radiosity. It was rendered using texture mapping radiosity. Secondly, the image is not simply getting quantatively brighter. Rather a qualitative change is happening: light flowing through the scene.Rocketmagnet 09:43, 8 January 2007 (UTC)

  • Fair enough. Though I should point out that whether you remesh or use a texture map doesn't fundamentally change the algorithm: either way you're discretizing space in order to get a piecewise constant solution. Using a texture vs. using a mesh is just an implementation detail. Another thing to note (if you're actually writing code using the texture mapping approach) is that evaluating all the elements (texels) naively will lead to slower convergence than doing something like a shooting method where you "shoot" from the element with greatest energy each time. However, I like the idea of the texture mapping approach because it's pedagogical and easy to understand for someone with a little graphics background.Trevorgoodchild 07:19, 13 January 2007 (UTC)
  • yes, I'm a fan of the texturing approach, not because it's "better", simply because I think that it's easy to understand, especially for someone 'with' graphics background. I've had several people write to me, saying that they thought Radiosity was totally beyond them, until they read my article TGLTLSBFFSP:Radiosity. Plus you get hardware acceleration trivially, and using OpenGL means most of the code is already written. Rocketmagnet 12:36, 13 January 2007 (UTC)
    • Oh yeah, I remember seeing your article a long time ago -- it's great! I think that's the perfect introduction to radiosity. Trevorgoodchild 17:25, 13 January 2007 (UTC)

[edit] Iterative Algorithm

Trevor, I'm not sure why you deleted the line about radiosity being an iterative algorithm. The only other place I can see this mentioned is in the paragraph about shooting radiosity. I think that the fact that it's iterative is the highest level thing one can say about the working of the algorithm.Rocketmagnet 09:43, 8 January 2007 (UTC)

  • Actually, you're wrong about this one -- the radiosity method simply defines a system of simultaneous linear equations whose solution is a solution to the radiosity equation. Just like any linear system, there are a multitude of ways to solve this system. Although you might use an iterative solver, you can solve the system exactly (and non-iteratively) as well.Trevorgoodchild 07:14, 13 January 2007 (UTC)
  • I did not know that. I'll cede, but, in most cases, it's done iteratively isn't it? Rocketmagnet 12:41, 13 January 2007 (UTC)
    • Well, many of the solvers used for the FEM (and in fact, many of the solvers used for large systems of equations in general) are iterative, but not in the way you're thinking. For example, in Troutman & Max's paper they use Gauss-Seidel to solve a system representing the radiosity equation, and Gauss-Seidel is an iterative solver. But that isn't necessarily the same as these visual iterations where you "look at" the previous solution step to get the next one.Trevorgoodchild 17:37, 13 January 2007 (UTC)
      • Of course. When I say "iterative", I mean that the code loops over the solution many times, bring it closer and closer, and eventually decides to stop when two iterations are similar enough. I don't mean that it had to be visual. Gauss-Seidel is iterative in exactly the way I meant. Can we put the iterative sentence back in? Rocketmagnet 00:56, 14 January 2007 (UTC)
      • Besides, you could render the result of each iteration of the Gauss-Seidel algorithm. Then it would be visual too. Rocketmagnet 01:17, 14 January 2007 (UTC)

[edit] Quadratic Increase in Computation Time

Early methods used a hemicube (an imaginary cube centered upon the first surface to which the second surface was projected, devised by Cohen and Greenberg in 1985) to approximate the form factor, which also solved the intervening patch problem. This is quite computationally expensive, because ideally form factors must be derived for every possible pair of patches, leading to a quadratic increase in computation with added geometry.

I don't think this is correct in all cases. If each patch takes a constant time to render to the hemicube, then it's correct. Using the texture map method, then each 'surface' takes a constant time, and the number of patches makes practically no difference. Therefore it can be linear.

I think that it would be better to have a section detailing various methods. Rocketmagnet 12:38, 8 January 2007 (UTC)

[edit] Are shadows part of Global Illumination?

Can anyone find a reference or paper stating that hard shadows are considered to be part of Global Illumination? Rocketmagnet 14:52, 9 January 2007 (UTC)

  • Ok, I'll cede that they're not. See the note above.Trevorgoodchild 07:22, 13 January 2007 (UTC)

[edit] What is "Real" Radiosity?

I'm not totally sure about this statement:

Likewise, Radiosity, by Hugo Elias describes a deterministic path tracing algorithm that takes advantage of graphics hardware to accelerate irradiance gathering, by using hemicubes. While this method does indeed compute the radiosity of patches, it does not compute form factors or explicitly construct a system of equations, thus it should not be confused with the classic radiosity method.

Do you have a reference for this? Where do you get the definition of "classic radiosity"? Perhaps "full matrix" radiosity was the method described in the first paper on the technique, but the hemicube method is still considered radiosity. Surely a radiosity method would be any which computes the radiosity of patches. What the algorithm does then is up to it. Indeed, SIGGRAPH 1993 Education Slide Set: Radiosity Overview Page 2, by Stephen Spencer talks about both "full matrix" and "progressive" methods. and the next page talks about "Progressive Radiosity Variants". Therefore pointing to one implementation of radiosity and calling it something else seems odd. Unless a reference can be found, I'll revert this in a couple of days. Rocketmagnet 07:36, 10 May 2007 (UTC)

Unfortunately, Rocketmagnet, I think the burden is on you to show that your method is radiometrically valid... that's how science works. ;) —The preceding unsigned comment was added by Trevorgoodchild (talk • contribs) 22:16, 10 May 2007 (UTC).
Can people please stop calling it my method? I'd love to take the credit for it, but basically I implemented radiosity from what I learned by reading articles and papers. As far as I can tell, it's one of the ways it's done. I believe it's discussed in the links above. The SIGGRAPH paper calls it radiosity. What more proof can I give that people call it radiosity? Rocketmagnet 23:58, 10 May 2007 (UTC)
As for the burden of proof being on me, that the method I used is radiometrically valid, that's way out of my league, and doesn't interest either (should be obvious from the pictures that it works). The fact that other people (who use real equations on slides and everything) seem to say it is, is good enough for me. (Even Mr. 169.229.69.173 seemed to agree that it's radiometrically valid). Rocketmagnet 23:58, 10 May 2007 (UTC)

[edit] Radiosity is first and foremost a physics term

User:Ryulong has been reverting my edits on an attempt to move this page to Radiosity (computer graphics). In my view, radiosity (should that be capital R?) does not deserve to hold this page title.

First and foremost this is a term borrowed from physics. The term that describes a fundamental phenomenon in physics with applications in engineering, optics, thermodynamics, and astronomy. In terms of the broad population or wikipedia users, it seems clear to me that this more fundamental meaning should precede the specialised use relating to this computer graphics algorithm. A disambiguation page is the correct approach.

Without the physical concept described by the physics term, there would *be* no computer algorithm. These are not two different meanings. The computer algorithm is an implementation of computation directional specular radiative transfer that borrows the name of one of the phenomena it models. It does not usurp the name.

My reference is the *very* popular (for mechanical engineers) undergraduate text Incropera and Dewitt, Fundamentals of Heat and Mass Transfer. The term 'radiosity is introduced in the first few pages of the radiation topic, as one of the foundation concepts of radiative transfer. Jdpipe 10:31, 11 June 2007 (UTC)

I agree. "Radiosity" should be the physics article, and "Radiosity_(Graphics)" should be this one. How do we go about getting it changed? Rocketmagnet 14:14, 11 June 2007 (UTC)
Hi Rocketmagnet. I see that you are one of the key authors of this page -- and a good page it is too. Your agreement will be a help on this. There is currently a block on moving the page but after 18 Jun we can progress it, providing there are no objections raised here. Perhaps you will be able to help with filling out that page (Radiosity (heat transfer)). Specifically, mechanical engineer use a matrix-based radiosity calculation to estiamte temperatures of surfaces in a grey-body radiative transfer situation. Thought it might be good to put that on that page, and I imagine there would be some good parallels with your stuff here. Cheers, Jdpipe 11:55, 14 June 2007 (UTC)

[edit] Re: Advantages

I think you missed one important thing: calculation results are viewpoint-independend. —Preceding unsigned comment added by 83.25.52.170 (talk) 19:08, 27 February 2008 (UTC)