Comments on: The Rendering Equation – A Pictorial Introduction I see where the visibility term confusion comes from. I was implicitly assuming the hemispherical formulation of the rendering equation throughout (Wikipedia is to blame, see rendering equation), but as you point out, there are other equivalent formulations; one of those being the surface/area based formulation, which does have an explicit and necessary visibility term. The visibility term I talk about in the post is something quite different. Some papers I read have before insert a hemispherical visibility function into the integrand in the context of the hemispherical formulation, and that was the context I was referring to. Working in real-time, that term becomes pretty important and it's at the forefront of your thoughts quite frequently. Maybe the title of the post is misleading in this respect, perhaps the term rendering equation should be replaced with what RTR calls the reflectance equation.> In the same vein, I can show how your first code snippet is equivalent to the second code snippet.The first code snippet *is* supposed to be equivalent to the second, that was kind of the point. That is, given the second code snippet, what do we need to do to our lights to make them work in the context of the first. I didn't go into other light types, and in fact made a special effort not to use jargon. I tried to not even mention terms like radiance (but failed), and certainly didn't want to go anywhere near dirac delta functions. After all, it's supposed to be an introduction to some of the concepts.Regarding PRT - I see your point . Reading back on it my phrasing was a bit clumsy there and implied that the whole light field was being storing as opposed to just the transfer function.Thanks for your feedback, I will update the post with your clarifications. I see where the visibility term confusion comes from. I was implicitly assuming the hemispherical formulation of the rendering equation throughout (Wikipedia is to blame, see rendering equation), but as you point out, there are other equivalent formulations; one of those being the surface/area based formulation, which does have an explicit and necessary visibility term. The visibility term I talk about in the post is something quite different. Some papers I read have before insert a hemispherical visibility function into the integrand in the context of the hemispherical formulation, and that was the context I was referring to. Working in real-time, that term becomes pretty important and it’s at the forefront of your thoughts quite frequently. Maybe the title of the post is misleading in this respect, perhaps the term rendering equation should be replaced with what RTR calls the reflectance equation.> In the same vein, I can show how your first code snippet is equivalent to the second code snippet.The first code snippet *is* supposed to be equivalent to the second, that was kind of the point. That is, given the second code snippet, what do we need to do to our lights to make them work in the context of the first. I didn’t go into other light types, and in fact made a special effort not to use jargon. I tried to not even mention terms like radiance (but failed), and certainly didn’t want to go anywhere near dirac delta functions. After all, it’s supposed to be an introduction to some of the concepts.Regarding PRT – I see your point . Reading back on it my phrasing was a bit clumsy there and implied that the whole light field was being storing as opposed to just the transfer function.Thanks for your feedback, I will update the post with your clarifications.

]]>
By: David Neubelt/2011/02/09/the-rendering-equation-a-pictorial-introduction/#comment-338 David Neubelt Thu, 10 Feb 2011 07:24:07 +0000 Sorry for the confusion I had deleted my post earlier which Mark then responded to.Anyway, for point (3) Visibility is not a hack and it can be shown that you can rewrite the integral instead of being an integral over the hemisphere to be an integral over all surfaces in the scene then the visibility term needs to be in it to be equivalent.-= Dave Sorry for the confusion I had deleted my post earlier which Mark then responded to.Anyway, for point (3) Visibility is not a hack and it can be shown that you can rewrite the integral instead of being an integral over the hemisphere to be an integral over all surfaces in the scene then the visibility term needs to be in it to be equivalent.-= Dave

]]>
By: David Neubelt/2011/02/09/the-rendering-equation-a-pictorial-introduction/#comment-336 David Neubelt Thu, 10 Feb 2011 06:43:12 +0000 Thanks for the feedback David. 1) Yes definitely. I certainly didn't mean to imply that directional lights were the only light types you could integrate. Sometimes I suppose there's just as much information in what you don't say as what you do say.2) Sure, but that's only part "radiance transfer" part of it. The "precomputed" in the acronym is a giveaway that it's trying to store data in a more compact form for later retrieval.3) My point was simply that if you're trying to fully model the physical world, then visibility is a hack. Every surface is a light source in that it's either emitting light, reflecting light or both. I didn't say where visibility originated, I just said it was used in realtime and offline rendering, because well, it makes sense a lot of sense to. Thanks for the feedback David. 1) Yes definitely. I certainly didn’t mean to imply that directional lights were the only light types you could integrate. Sometimes I suppose there’s just as much information in what you don’t say as what you do say.2) Sure, but that’s only part “radiance transfer” part of it. The “precomputed” in the acronym is a giveaway that it’s trying to store data in a more compact form for later retrieval.3) My point was simply that if you’re trying to fully model the physical world, then visibility is a hack. Every surface is a light source in that it’s either emitting light, reflecting light or both. I didn’t say where visibility originated, I just said it was used in realtime and offline rendering, because well, it makes sense a lot of sense to.

]]>
By: Sven Bergström/2011/02/09/the-rendering-equation-a-pictorial-introduction/#comment-334 Sven Bergström Wed, 09 Feb 2011 16:44:58 +0000 Thanks for all your comments. Alex, I'm a big fan of your work on LBP. It is for me still the best looking *and* most fun game on the PS3.Regarding the shadows - simple and brute force. The scene itself was about ~1.4m in diameter. Each shadow map was 512*512 and covered the whole scene. I used a poisson disc distribution with a 3cm radius. Each shadowed pixel is done with 64 PCF samples, per light. Let's just say it was geared toward being instructive over practical :) Thanks for all your comments. Alex, I’m a big fan of your work on LBP. It is for me still the best looking *and* most fun game on the PS3.Regarding the shadows – simple and brute force. The scene itself was about ~1.4m in diameter. Each shadow map was 512*512 and covered the whole scene. I used a poisson disc distribution with a 3cm radius. Each shadowed pixel is done with 64 PCF samples, per light. Let’s just say it was geared toward being instructive over practical :)

]]>
By: mmalex/2011/02/09/the-rendering-equation-a-pictorial-introduction/#comment-332 mmalex Wed, 09 Feb 2011 15:31:33 +0000 Interesting read. Very well written. Interesting read. Very well written.

]]>
By: Fabrice Lété/2011/02/09/the-rendering-equation-a-pictorial-introduction/#comment-330 Fabrice Lété Wed, 09 Feb 2011 12:14:11 +0000