My Reformulation of the Rendering Equation (+Applications)

 Posts: 29
 Joined: Sun Jul 28, 2013 6:53 pm
 Contact:
My Reformulation of the Rendering Equation (+Applications)
Hi,
After a lot of work, reverse engineering, and guessing, I came up with a somewhat different formulation of the rendering equation which I find far more clear and intuitive (if more verbose) than everything else I have seen. It looks like this:
I wrote up the experience, along with a full description and explanation in what I guess you could call a blog post phrased as a tutorial. The link is currently here:
http://www.geometrian.com/programming/t ... /index.php
While I have checked my work and have applied it to rederive the diffuse code found in SmallPT, I don't know whether I have overlooked something. I would greatly appreciate someone skimming my article to make sure it's reasonably sound. Additional comments here are of course welcome.
Thank you!
G
After a lot of work, reverse engineering, and guessing, I came up with a somewhat different formulation of the rendering equation which I find far more clear and intuitive (if more verbose) than everything else I have seen. It looks like this:
I wrote up the experience, along with a full description and explanation in what I guess you could call a blog post phrased as a tutorial. The link is currently here:
http://www.geometrian.com/programming/t ... /index.php
While I have checked my work and have applied it to rederive the diffuse code found in SmallPT, I don't know whether I have overlooked something. I would greatly appreciate someone skimming my article to make sure it's reasonably sound. Additional comments here are of course welcome.
Thank you!
G
Re: My Reformulation of the Rendering Equation (+Application
Hi,
'I hope this tutorial was helpful' for me it was.
Thank you.
'I hope this tutorial was helpful' for me it was.
Thank you.

 Posts: 29
 Joined: Sun Jul 28, 2013 6:53 pm
 Contact:
Re: My Reformulation of the Rendering Equation (+Application
Keep in mind I don't know it's right. I've have used it to rederive SmallPT's diffuse term (and I just now used it to rederive the weighting for explicit light sampling; I'll add that in soon), but that doesn't mean it's necessarily correct.
Thanks for reading!
Thanks for reading!
Re: My Reformulation of the Rendering Equation (+Application
geometrian: thats what you see:
http://blogs.psychcentral.com/alwaysle ... es002.jpg
thats what i see:
http://mikegwaltney.net/blog/wpcontent ... class.jpg
http://blogs.psychcentral.com/alwaysle ... es002.jpg
thats what i see:
http://mikegwaltney.net/blog/wpcontent ... class.jpg
Re: My Reformulation of the Rendering Equation (+Application
This is going to sound harsh but you removed (N*w) from brdf and made it non symmetric and made Em not measure radiance any more. For me there is no progress there. But it doesn't really matter. However, whatever works for you is ok, as long as you keep track of all the details. It will be harder to communicate with others once you deviate from the consensus though.

 Posts: 29
 Joined: Sun Jul 28, 2013 6:53 pm
 Contact:
Re: My Reformulation of the Rendering Equation (+Application
So that's why it's in there! I pulled the N*w_o term out since its function is the same as the N*w_i term, just the other way. I maintain that this way is clearer.you removed (N*w) from brdf and made it non symmetric
Actually, I see that as a benefit. The extra emission from a surface follows some distributione.g., as I noted, a diffuse emitter will emit in all directions with a cos(theta) distribution, and will cancel out the attenuation term outside the brackets, giving a constant factor. A constant Em term in all directions gives rise to brighter surfaces at glancing angles. For me, not having that implicit cosine attenuation is more clear. Apart from transferring energy between points, I don't like the radiance unit.Em not measure radiance any more
Agreed. And really, I'm not tied to this particular formulation. The goal was to try to express every term as simply as possiblewithout hiding projections and scalings and whatnot inside other terms. Even if I don't end up using it, I think doing that was illustrative for me. I just want to make sure I did it correctly.However, whatever works for you is ok, as long as you keep track of all the details. It will be harder to communicate with others once you deviate from the consensus though.
Re: My Reformulation of the Rendering Equation (+Application
Thanks for posting this Ian. I certainly found it helpful.

 Posts: 3
 Joined: Sat Apr 19, 2014 11:15 pm
Re: My Reformulation of the Rendering Equation (+Application
Ian, you rock! Implicit terms in mathematics are the bane of my 3D rendering existence.
Note to others: please always, always, ALWAYS show the "way too much detail, everything is explicit" version first for mathematical concepts, in concrete form, and then, and only then, show the simplified version with all of the implicit stuff omitted. It's much, much easier for nonmathematicians (like myself) to read, understand, and then implement.
All I get from the majority of rendering papers is the idea. The math is almost always too opaque for me to actually translate into code. Posts like Ian's are hugely helpful to someone like me who doesn't know all of the stuff you guys take for granted.
(Yes, I've read PBRT (both versions, multiple times) and hundreds of renderingrelated papers. I'm stuck at square one because NO ONE, EVER explains things like I'm an idiot (except for Ian). It would be awesome if more people did that. None of this stuff is particularly hard, it's entirely terminology and notationrelated IMO.
Note to others: please always, always, ALWAYS show the "way too much detail, everything is explicit" version first for mathematical concepts, in concrete form, and then, and only then, show the simplified version with all of the implicit stuff omitted. It's much, much easier for nonmathematicians (like myself) to read, understand, and then implement.
All I get from the majority of rendering papers is the idea. The math is almost always too opaque for me to actually translate into code. Posts like Ian's are hugely helpful to someone like me who doesn't know all of the stuff you guys take for granted.
(Yes, I've read PBRT (both versions, multiple times) and hundreds of renderingrelated papers. I'm stuck at square one because NO ONE, EVER explains things like I'm an idiot (except for Ian). It would be awesome if more people did that. None of this stuff is particularly hard, it's entirely terminology and notationrelated IMO.