My Reformulation of the Rendering Equation (+Applications) back

(L) [2013/07/30] [ost by Geometrian] [My Reformulation of the Rendering Equation (+Applications)] Wayback!

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:
[IMG #1 Image]

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:
[LINK http://www.geometrian.com/programming/tutorials/clearer_re/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

---

[IMG #1]:Not scraped: https://web.archive.org/web/20210506001214im_/http://latex.codecogs.com/gif.latex?%5Cvec%7BL%7D%28%5Cvec%7Bx%7D%2C%5Cvec%7B%5Comega%7D_o%29%20%3D%20%5Cleft%5B%20%5Cleft%5B%20%5Cvphantom%7B%20%5Cfrac%7B1%7D%7B%5Cvec%7BN%7D%5Ccdot%5Cvec%7B%5Comega%7D_o%7D%20%7D%20%5Cint_%7B%5COmega%7D%20%5Cvec%7BL%7D%28%5Cvec%7By%7D_i%2C%5C%2C-%5Cvec%7B%5Comega%7D_i%29%20%5Cleft%28%20%5Cvec%7BN%7D%20%5Ccdot%20%5Cvec%7B%5Comega%7D_i%20%5Cright%29%20%5Cvec%7Bf%7D_r%28%5Cvec%7Bx%7D%2C%5Cvec%7B%5Comega%7D_i%2C%5Cvec%7B%5Comega%7D_o%29%20%5C%2C%20d%5C%2C%5Cvec%7B%5Comega%7D_i%20%5Cright%5D%20+%20%5Coverrightarrow%7BEm%7D%28%5Cvec%7Bx%7D%2C%5Cvec%7B%5Comega%7D_o%29%20%5Cright%5D%20%5Cfrac%7B1%7D%7B%5Cvec%7BN%7D%5Ccdot%5Cvec%7B%5Comega%7D_o%7D

(L) [2013/07/30] [ost by Lo1] [My Reformulation of the Rendering Equation (+Applications)] Wayback!

Hi,

'I hope this tutorial was helpful' for me it was.

Thank you.

(L) [2013/07/30] [ost by Geometrian] [My Reformulation of the Rendering Equation (+Applications)] Wayback!

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!  [SMILEY :)]

(L) [2013/07/31] [ost by Geri] [My Reformulation of the Rendering Equation (+Applications)] Wayback!

geometrian: thats what you see:
[LINK http://blogs.psychcentral.com/always-learning/files/2010/04/SAT-math-examples-002.jpg]

thats what i see:
[LINK http://mikegwaltney.net/blog/wp-content/uploads/2010/11/2387-math-class.jpg]

[SMILEY :D]

(L) [2013/07/31] [ost by Zelcious] [My Reformulation of the Rendering Equation (+Applications)] Wayback!

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.

(L) [2013/07/31] [ost by Geometrian] [My Reformulation of the Rendering Equation (+Applications)] Wayback!

>> you removed (N*w) from brdf and made it non symmetricSo 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. >> Em not measure radiance any moreActually, I see that as a benefit. The extra emission from a surface follows some distribution--e.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. >> 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.Agreed. And really, I'm not tied to this particular formulation. The goal was to try to express every term as simply as possible--without 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.

(L) [2013/07/31] [ost by Tristan] [My Reformulation of the Rendering Equation (+Applications)] Wayback!

Thanks for posting this Ian. I certainly found it helpful.

(L) [2014/04/20] [ost by erichocean] [My Reformulation of the Rendering Equation (+Applications)] Wayback!

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 non-mathematicians (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 rendering-related 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 notation-related IMO.