Re: Veach thesis - formula question back
Board:
Home
Board index
Raytracing
General Development
(L) [2012/07/16] [ost
by spectral] [Re: Veach thesis - formula question] Wayback!That's right...
I don't remember the reason/solution, and you ? I remember I have see this in a physics course...
Anyway, maybe I'm wrong, but I have never see anybody taking account this rule... in a renderer !
(L) [2012/07/16] [ost
by Igors] [Re: Veach thesis - formula question] Wayback!For solid angle defined by 4 normalized vectors (p0, p1, p2, p4 incoming from shading point) I've used
 light_dir = (Func(p1, p0) + Func(p2, p1) + Func(p3, p2) + Func(p0, p3)) / 2;
where Func returns cross(vec0, vec1) * acos(vec0, vec1);
It's important to have direction (not scalar only), otherwise specular highlights are very juggy. It was several years ago and now I don't remember where I've found it [SMILEY ;-)]
(L) [2012/07/16] [ost
by ingenious] [Re: Veach thesis - formula question] Wayback!What are you guys talking about?  [SMILEY :?]   The formula is perfectly correct, as it applies to infinitesimally small (i.e. differential) solid angles. If you estimate your lighting integral with a finite number of samples, it'll always be an approximation, and not  because of the G term. The G term does indeed introduce a singularity, but it is not an approximation - it is a result of converting the integration measure from solid angle to surface area.
(L) [2012/07/16] [ost
by graphicsMan] [Re: Veach thesis - formula question] Wayback!Wow, I was starting to wonder if physics had changed.  I don't even understand what the light_dir direction is supposed to represent?
(L) [2012/07/16] [ost
by spectral] [Re: Veach thesis - formula question] Wayback!I don't understand too [SMILEY :-P]
I don't remember where I have see this... but I have already see a document (about physics and not about rendering) that explain that G is an approximation when using very small distance... but I'm not sure it is applicable and related to mathematic. Maybe it is related to some specific light effects in some specific conditions. Will try to find where I have see this in the past.
(L) [2012/07/16] [ost
by Igors] [Re: Veach thesis - formula question] Wayback!>> ingenious wrote:What are you guys talking about?     The formula is perfectly correct, as it applies to infinitesimally small (i.e. differential) solid angles. But count of rays is very finite. For example an area light is a simple rectangle that should be sampled with 100 rays only. In this case the simplified formula would produce dark artifacts nearby the light.
(L) [2012/07/16] [ost
by spectral] [Re: Veach thesis - formula question] Wayback!Maybe because you divide by 0 !?
(L) [2012/07/16] [ost
by ingenious] [Re: Veach thesis - formula question] Wayback!If you estimate direct illumination from an area light source via area sampling, what you will get nearby the light is high variance. This will be due to the singularity in the G term, and not because G is some sort of approximation! And this high variance will result in bright speckles, not darkening. Indeed, area integration is not a good strategy for close distances, hence combining it with solid angle integration with multiple importance sampling can result in a much better estimate. See Veach's MIS paper or dissertation. There is nothing more to this in the context of MC integration.
Now, if you want to actually estimate the solid angle that an object spans for fitering or other purposes, a one-sample approximation becomes arbitrarily wrong the closer the object is to the point of interest. And again, you can (Monte Carlo) integrate over the hemisphere to compute a better approximation of this solid angle. Enough with the hand-waving please  [SMILEY :ugeek:]
(L) [2012/07/17] [ost
by spectral] [Re: Veach thesis - formula question] Wayback!Hi,
I'm still working on my "light tracing" kernel but since a week I got the following strange effect (see first image). I can't get rid of this problem !
I use the same code for my path tracer and my light tracer... path tracing seems good (using the same theory). The main difference is :
Path tracer
1) sample one vertex on the light
2) sample a camera-ray and trace => gives a camera-vertex
3) connect the camera-vertex with the light-vertex
4) continue the camera-vertex
5) Re-sample one vertex on the light
6) Go to step (3) (connection)
...
Light tracer
1) sample one vertex on the light
2) sample a camera-ray and trace => gives a camera-vertex
3) connect the camera-vertex with the light-vertex
4) continue the light-vertex
5) Re-sample a camera-ray and trace => gives a camera-vertex
6) Go to step (3) (connection)
Notice that:
1) I have (in theses images) path of length = 3 (4 vertices max)
2) I have no camera-vertex on the image plane
3) I have try with uniform sampling (for the diffuse shader), this way I don't introduce any "cos"... just constants. I have the same effect. So, it seems to me that I have a problem with my PDF or solid angle somewhere !!
So, if someone has an idea to debug this problem ?
[IMG #1 test_lt.png]
[IMG #2 test_pt.png]
[IMG #1]:Not scraped:
/web/20200811091721im_/http://ompf2.com/download/file.php?id=32&sid=df82ccb71a72e1b73aa022e9096e97fe
[IMG #2]:Not scraped:
/web/20200811091721im_/http://ompf2.com/download/file.php?id=33&sid=df82ccb71a72e1b73aa022e9096e97fe
(L) [2012/07/17] [ost
by apaffy] [Re: Veach thesis - formula question] Wayback!Your light tracing algorithm looks a bit odd, I'd expect the dual of your path tracing algorithm.  Making some minor changes to connect the eye and light vertices before the light subpath is extended (to make light sources directly visible), I'd expect something like this:
Light tracer:
1) sample one vertex on the camera (for pinhole camera this will always be the pinhole itself)
2) sample one vertex on the light
3) connect the camera-vertex with the light-vertex
4) continue the light-vertex (sample emission function if on light source, sample BSDF otherwise)
5) Go to step (3) (connection)
(L) [2012/07/17] [ost
by spectral] [Re: Veach thesis - formula question] Wayback!Thanks,
Sure, I know I don't use the x(0) sample on the camera... why ?
Because it run on the GPU and I would like a 'light path' for each pixel and not for a random pixel (connection between random light path and camera give a random pixel) ! It is why I first generate a ray per pixel and connect this vertex.
It should be the same ! (I just have to account for direct hit).
The main difference is that I sample the light direction (uniform for now) and the first camera-segment is not random (Like path tracing).
(L) [2012/07/17] [ost
by apaffy] [Re: Veach thesis - formula question] Wayback!>> spectral wrote:Sure, I know I don't use the x(0) sample on the camera... why ?
Because it run on the GPU and I would like a 'light path' for each pixel and not for a random pixel (connection between random light path and camera give a random pixel) ! It is why I first generate a ray per pixel and connect this vertex.
Well as long you take this into account in the full path pdf then you're fine.  Essentially you are only light tracing indirect light as a result, but I assume that's intentional.
Looking at your images, it seems that the second vertex of your light subpath only seems to hit part of the scene (seems to cut off part-way down).  I'd check the way you generate rays for your light source emission is oriented correctly in the world (I'd expect them to start on the surface of the sphere and generate a cosine-weighted distribution in the local positive hemisphere of the sample point).
(L) [2012/07/17] [ost
by spectral] [Re: Veach thesis - formula question] Wayback!Yes,
It seems to me too [SMILEY :-P]
1) Yes, I use cosine sampling on the light (hemisphere), I have even try uniform sampling.
2) Yes, it is generated in the right direction, it is easy to check because light-normal = (0,-1,0) in the test scene [SMILEY :-P]
It seems to me that the light hit the top of the box, and diffusely send the light. You see we have 2 bands and exactly where the box start !
Like a missing cos-weighting ! But all the 'cos' are there !
(L) [2012/07/17] [ost
by Igors] [Re: Veach thesis - formula question] Wayback!>> spectral wrote:
So, if someone has an idea to debug this problem ?
I would store paths' segments (maybe colored) in a text file (for 2 or some shaded points). Then load and view stored paths in 3D app
(L) [2012/07/17] [ost
by graphicsMan] [Re: Veach thesis - formula question] Wayback!graphics to debug graphics... I'll +1 my vote for that approach.
(L) [2012/07/18] [ost
by spectral] [Re: Veach thesis - formula question] Wayback!BTW, I have change my code in order to connect to the camera vertex x(0) (camera origin), by intersecting the image plane.
But I got the same effect [SMILEY :-P]-
(L) [2012/07/18] [ost
by spectral] [Re: Veach thesis - formula question] Wayback!For sure, I miss something... please take a look at the following picture that represent my simple scene in 2D.
I use a simple lambert surface, it mean that the same light intensity is emitted (in all direction) from the top of the cube.
On the other side, there is the solid-angles (depth = 2) that will attenuate this band effect, I should have a gradient on the walls.
Finally if I use only theses rules... it is normal to have a band effect ?
So, what do I miss ? is there something else that I forget to introduce ? which rule can remove this band effect ?
[IMG #1 lambert.png]
[IMG #1]:Not scraped:
/web/20200811104439im_/http://ompf2.com/download/file.php?id=34&sid=378c36d1abcf93adaccd3528bdeed2f4
(L) [2012/07/18] [ost
by spectral] [Re: Veach thesis - formula question] Wayback!For sure, I miss something... please take a look at the following picture that represent my simple scene in 2D.
I use a simple lambert surface, it mean that the same light intensity is emitted (in all direction) from the top of the cube.
On the other side, there is the solid-angles (depth = 2) that will attenuate this band effect, I should have a gradient on the walls.
Finally if I use only theses rules... it is normal to have a band effect ?
So, what do I miss ? is there something else that I forget to introduce ? which rule can remove this band effect ?
lambert.png
(L) [2012/07/18] [ost
by apaffy] [Re: Veach thesis - formula question] Wayback!>> spectral wrote:the same light intensity is emitted (in all direction) from the top of the cube.
I'd be careful with your definitions, Lambertian reflectance produces uniform radiance, which means the same energy for each differential projected solid angle.
Are you perhaps missing some conversion from solid angle to projected solid angle in your implementation?  Perhaps this produces the visible banding.
(L) [2012/07/18] [ost
by spectral] [Re: Veach thesis - formula question] Wayback!Thanks a lot,
To give more details, here is what I do...
x0 : point on light
I compute the radiance for the whole surface => Le
x1 : point on top of the box
I convert the radiance this way : L = Le * |Nl.-Wi1| |N1.Wi1| / r*r
Where:
Nl : is the light normal
N1: the normal at x1
Wi1 : is the normalized vector from the light to x1
r : the distance between the light point and x1
x2 : point on the left wall
L = f(x1) * |N2.Wi2|
BTW: I don't divide f(x1) by p(x1) because I use the light pdf (previous step)
where:
f = 1/pi (lambert brdf)
p = 1/pi (lambert pdf)
N2: normal at x2
Wi2 : is the normalized vector from the x1 to x2
(L) [2012/07/18] [ost
by spectral] [Re: Veach thesis - formula question] Wayback!>> apaffy wrote:
I'd be careful with your definitions, Lambertian reflectance produces uniform radiance, which means the same energy for each differential projected solid angle.
Are you perhaps missing some conversion from solid angle to projected solid angle in your implementation?  Perhaps this produces the visible banding.
You're right, but the projected solid angle is only for irradiance (incoming light...). I have also think to a missing solid angle... but in this example there is only 2 solid angles : sa(0) and sa(1), both are approximatively = 1.
I can remove the effect by doing f = f * |N1.-Wi2|... but it is incorrect !
Thanks
(L) [2012/07/18] [ost
by graphicsMan] [Re: Veach thesis - formula question] Wayback!I'm slighty confused.  Are you connecting x1 and x2 with an edge?  In either case it looks like L for x2 is incorrect... you're missing the other cosine in the geometry term.
(L) [2012/07/18] [ost
by spectral] [Re: Veach thesis - formula question] Wayback!>> graphicsMan wrote:I'm slighty confused.  Are you connecting x1 and x2 with an edge?  In either case it looks like L for x2 is incorrect... you're missing the other cosine in the geometry term.
1) I use the geometric term to convert the emitter radiance (Watts/m²/sr) to the x1 irradiance (Watts/m²)
2) Once I have the light on x1, to compute the light on L2 I simply apply the rendering equation [LINK http://en.wikipedia.org/wiki/Rendering_equation] : L2 = L1 * f/p * |N2.Wi2|
Why should I apply a geometric term at x1 ? where G = |N1.-W2| I suppose
(L) [2012/07/18] [ost
by graphicsMan] [Re: Veach thesis - formula question] Wayback!maybe I just misunderstood your diagram.  when you sample surfaces directly, you have to use the integral with measure area, while when sampling directions, you use the one with measure solid angle.  
When you're in one (sampling directions), and you sample, say, a light source, or a surface (or VPL), you have to perform a change of measure, which is what all that geometry term stuff is about.  Sorry, in a bit of a hurry to get more detailed than that now...
(L) [2012/07/18] [ost
by spectral] [Re: Veach thesis - formula question] Wayback!Thanks,
It is not what I do when I use the following formula ?
L = Le * |Nl.-Wi1| |N1.Wi1| / r*r
Where :
x0 : point on light
x1 : first hit
r : distance(x0,x1)
Nl : normal at x0
N1: normal at x1
Wi1= normalize(x0-x1)
First, I choose a random point on the light and a random (hemisphere) direction, then I convert it with this formula, only one time ?
(L) [2012/07/18] [ost
by graphicsMan] [Re: Veach thesis - formula question] Wayback!Depends... is this for generating a new position x1 (determined by x0 and Wi1), or is this sampling the light point x0 to light at a predetermined location x1?  For the latter, yes, this is correct.
(L) [2012/07/18] [ost
by apaffy] [Re: Veach thesis - formula question] Wayback!>> spectral wrote:Thanks,
It is not what I do when I use the following formula ?
L = Le * |Nl.-Wi1| |N1.Wi1| / r*r
Where :
x0 : point on light
x1 : first hit
r : distance(x0,x1)
Nl : normal at x0
N1: normal at x1
Wi1= normalize(x0-x1)
First, I choose a random point on the light and a random (hemisphere) direction, then I convert it with this formula, only one time ?
To add a bit more context from graphicsMan, what you have computed above is part of the contribution of the path.  However, we're doing Monte Carlo integration here, where what we want is the contribution of the path divided by its probability density.  In your equation above, you've basically taken the energy emitted by some differential area at x0, then used the geometry term to compute the energy received by some differential area at x1.  However, when you divide through by the probability density of the path, this geometry term will cancel with the geometry term involved with converting your solid angle pdf at x0 (which you computed when sampling the outgoing light direction) into a probability density wrt area at x1.
To be explicit about what you compute in the Veach framework for your scenario, where you have an eye subpath x3x2 connected with a light subpath x0x1:
You sample x0 with some pdf wrt area P_A(x0).  You sample the emission function at x0 with some projected solid angle pdf P(x0 -> x1), fire a ray and hit x1.  For cosine-weighted sampling this pdf 1.  If you have a pdf wrt to solid angle just divide it by cos(theta) to get the pdf wrt projected solid angle.
You sample x3 at the camera with some pdf P_A(x3).  You sample the importance function at x3 with some projected solid angle pdf P(x3 -> x2), fire a ray and hit x2.
Assuming I've not made any silly mistakes putting this post together, your Monte Carlo sample (i.e. path contribution divided by pdf) should be:
F = (Le(x0 -> x1) * f(x0 -> x1 -> x2) * G(x1 <-> x2) * f(x3 -> x2 -> x1) * We(x3 -> x2)) / (P_A(x0) * P(x0 -> x1) * P(x3 -> x2) * P_A(x3))
(L) [2012/07/18] [ost
by ingenious] [Re: Veach thesis - formula question] Wayback!We already discussed Veach's framework. If you want to go bidirectional, you just have to switch your mindset to this framework. Be sure that you understand the framework as well as possible by experimenting on paper, and then a correct implementation is trivial.
And again I want to express my wondering that people simply don't appreciate the greatness of this framework. Now read the following carefully and at least 3 times. Yes, seriously. At least 3 times:
The greatness of this framework is that the sampling primitive it works with is a full light path that connects the eye to a light source. It also makes a strict separation between the radiance contribution of a path and its sampling density. This is crucial for the application of multiple importance sampling for bidirectional path tracing, and lays the ground for Metropolis Light Transport. The contribution of a path is fixed and never changes. It is the measurement contribution function that we discussed before, which includes geometric factors for *all* edges on the path - nice and symmetric!
The only thing that changes is the path sampling pdf, depending on what technique you use to construct it. This path pdf is a product of the pdfs of each path vertex, each of which is *always* expressed w.r.t. area density. If you continue a path using hemispherical sampling (i.e. random walk), once you hit a surface and create the next path vertex, you immediately convert the sampling density from solid angle to area. This conversion means simply multiplying by a "cos / dist^2" term. Read the chapter in the thesis (I gave a page number before) that describes this factor, draw it on paper, and try to understand this factor.
And now what happens in bidirectional path tracing: You trace one sub-path from each end, and every edge on these sub-paths ends up having this conversion factor. When you connect the endpoints of the sub-paths, this is the only edge that *does not* get such a factor. Why? Because everything is deterministic there - the endpoint have already been sampled, and there's no *new* random decision in this connection.
So what happens *in the end*? And I repeat *in the end* - mathematically, only in the end do you divide the path radiance contribution and the path pdf to obtain an estimate. So what happens is that many geometric terms cancel out, except the ones involved in the connection edge - only for this edge you get the inverse squared distance in the final estimator. And this is the cause for the famous singularity with virtual point light methods.
My recommendation:
1) Turn off your PC
2) Get a pen and a sheet of paper
3) Draw a light path of some length, put the associated radiance contribution terms next to each element of the path
4) Observe what you've drawn, look at the *beautiful symmetry*, appreciate how nice the path contribution looks Le - G - f - G - f - G - We
5) Once you have a good understanding of the path contribution, redraw the path two more times
6) Think of two possible ways to sample this path bidirectionally, and put the path pdf terms associated with the vertices and edges on each drawing
7) Observe then which terms cancel out when you divide the contribution of the path by each path pdf
8) Say out loud "Eureka! Eric, you're the man!"
9) Come back here and share the excitement [SMILEY ;)]
P.S. Once I did the above, I realized why I was so much confused and disappointed by the Advanced Global Illumination book. It deals with a bunch of useless concepts like importance distribution and GRDF, and mentions the path integral on half a page! The bias of the book authors toward their own work has ruined the whole book. It goes into so much detail in radiosity and density estimation, and completely ignores all contributions of Eric Veach, which in my opinion are some of the most fundamental ones. Hell, he's probably the only rendering guy who's work can contribute back to the fields everybody has been borrowing Siggraph material from  [SMILEY :!:]
P.P.S. Sorry for my attitude, I get emotional sometimes [SMILEY :)] Cheers! I hope I managed to help, in spire of all the ranting.
(L) [2012/07/18] [ost
by apaffy] [Re: Veach thesis - formula question] Wayback!+1 to ingenious' post.
I agree you just have to work through the maths yourself until it all slots into place.  For me the Eureka moments were:
* Understanding how the geometry term is used to convert pdfs between projected solid angle and area
* Understanding how all but one of the geometry terms cancel between the path contribution and its (path) pdf
(L) [2012/07/18] [ost
by ingenious] [Re: Veach thesis - formula question] Wayback!>> apaffy wrote:* Understanding how the geometry term is used to convert pdfs between projected solid angle and area
* Understanding how all but one of the geometry terms cancel between the path contribution and its (path) pdf
* How super elegantly multiple importance sampling solves the notorious singularity in short path connections, which has been "researched" by so many people, many of whom still don't understand/appreciate this solution
(L) [2012/07/19] [ost
by Igors] [Re: Veach thesis - formula question] Wayback!>> spectral wrote:
L = Le * |Nl.-Wi1| |N1.Wi1| / r*r
This is a lighting coming from area 1.0. That can correspond to a small or large solid angle. But I don't understand how to integrate. If we get some rays and connect something - it does not mean yet all incoming directions are covered
 >> apaffy wrote:
* Understanding how the geometry term is used to convert pdfs between projected solid angle and area
I've not this understanding and would be interested in explanations if possible
Thanks
(L) [2012/07/19] [ost
by apaffy] [Re: Veach thesis - formula question] Wayback!>> Igors wrote:apaffy wrote:
* Understanding how the geometry term is used to convert pdfs between projected solid angle and area
I've not this understanding and would be interested in explanations if possible
Thanks
I think the best I can do is direct you towards sections 8.1 and 8.2 of the Veach thesis, which covers this topic in detail.
Section 8.1 shows the geometric relationship between differential projected solid angle and differential area (equation (8.2)).
Section 8.2 uses this to convert between pdf wrt projected solid angle at x to pdf wrt area at x' (last equation in section 8.2).
(L) [2012/07/19] [ost
by spectral] [Re: Veach thesis - formula question] Wayback!>> Igors wrote:spectral wrote:
L = Le * |Nl.-Wi1| |N1.Wi1| / r*r
This is a lighting coming from area 1.0. That can correspond to a small or large solid angle. But I don't understand how to integrate. If we get some rays and connect something - it does not mean yet all incoming directions are covered
Not only, it is simply the "G" (geometric term). Le can come from a larger area. But in general it is used for dA (unit differential area).
 >> apaffy wrote:
* Understanding how the geometry term is used to convert pdfs between projected solid angle and area
I've not this understanding and would be interested in explanations if possible
[/quote]
Take a look at the paper "A Survey of Importance Sampling Applications in Unbiased", it is explained in section (3.4)
(L) [2012/07/19] [ost
by spectral] [Re: Veach thesis - formula question] Wayback!Thanks for all your comments...
I'm currently reading the Dietger document and also I use the Veach thesis... as proposed by Ingenious I do everything in paper. So,
I have see in the Veach thesis (page 228) the following formula to convert a pdf from directional to area.
UnitConversion.png
When I have the following formula and apply the conversion, I got the following result :
UnitConversion2.png
Just to compare to my path tracer, where I use the following formula :
UnitConversion3.png
Does someone can explain please ?
Thanks in advance
(L) [2012/07/19] [ost
by ingenious] [Re: Veach thesis - formula question] Wayback!Check your formulas again. They're also quite hard to understand with the short notation you've used - only you can tell what the terms mean [SMILEY :)]
In your path tracer you should be multiplying with the cosine between the normal at the current point and the sampled scattering direction. The cosine that cancels out in the area integration formulation is the other cosine - at the surface where you land. And you never consider this cosine explicitly in your path tracer. Which is actually quite unintuitive in the solid angle formulation - why do you multiply by the outgoing cosine but not with the incoming? Fortunately, with Veach's area formulation, it's clearly visible that this discrepancy is due to the path sampling procedure, which makes some terms cancel out - the path contribution is still symmetric, as it's independent on how the path has been sampled. Furthermore, if you were to choose some arbitrary point in space and use it as a vertex on a path, it'd be trickier (though possible) to explain what happens with the estimator for that path in the solid angle integration formulation.
(L) [2012/07/20] [ost
by spectral] [Re: Veach thesis - formula question] Wayback!Right,
I have rewrite my equation in a more clear form [SMILEY :-P] sorry... I have update the pictures.
What I don't understand is why I got the other cosinus in my caculus !
(L) [2012/07/20] [ost
by apaffy] [Re: Veach thesis - formula question] Wayback!Hi spectral,
Firstly, in the "UnitConversion.png" diagram, p(w_o) is actually pdf wrt solid angle.  This is why the equation has a missing cosine in this diagram.
You can convert this to projected solid angle (let's call this p_\perp) as follows (paste into LaTeX to see this in a nice form - as an aside having something like MathJax on this forum would really help):
p_\perp(w_o) = p(w_o) / |cos(\theta_o)|
If you plug this into the units conversion equation you get:
p_A(x')
  = p_\perp(w_o) |cos(\theta_o)| |cos(\theta'_i)| / ||x - x'||^2
  = p_\perp(w_o)  G(x <-> x')
Note that we had to use pdf wrt *projected* solid angle to make everything nicely symmetric and be able to use the G term.  This now matches the equation at the end of section 8.2 as I posted earlier.
Your next diagram "UnitConversion2.png" doesn't make any sense, please explain what you are trying to do here.
In your final diagram "UnitConversion3.png", I think you are showing some part of the Monte Carlo term (i.e. path contribution over path pdf) as you extend the path, but if so I'd expect you use w_i not w_o (since in a path tracer you are always sampling w_i).
I'm going make a guess I and assume that the p(w_i) in this equation of yours is wrt solid angle, in which case the cosine is present because your pdf is wrt solid angle, but you actually need to sample wrt projected solid angle when path tracing, i.e:
F = f(x') / p_\perp(w_i) = f(x') |cos(\theta_i)| / p(w_i)
Hope that helps!  (As another aside, whenever people write a pdf, I wish they'd be completely clear what the measure is for this term i.e. area/solid angle/projected solid angle.)
(L) [2012/07/20] [ost
by spectral] [Re: Veach thesis - formula question] Wayback!Right,
I have to use Wi and not Wo because I sample x' and not x ! Thanks for the clarifications... it become clear  [SMILEY :idea:]
So, finally I'm back to my code, just to test what I've learned... and I'm surprised that the code is now even easier, simplified !
I even find this beautiful symmetry in my code  [SMILEY :mrgreen:] (this will be great to improve coherence on the GPU !!)
Please, let me try to solve the following example :
bdpt_example.png
I solved it this way :
bdpt_solve.png
Can you tell me if it is correct, just to check that I have understand ?
(L) [2012/07/20] [ost
by apaffy] [Re: Veach thesis - formula question] Wayback!Hi spectral, glad to hear things are starting to get more clear.  Your diagram is a great start, but I don't agree with your equation for the final Monte Carlo sample.
As ingenious posted above, what you need to write down is:
* The path contribution.  This has great symmetry being Le G f G f G f G f G We (for your path with 6 vertices), and is independent of how it was sampled.
* The path pdf.  This is also greatly symmtric being P_A(x0) P_A(x1) ... P_A(x5)
You then divide the two to get the sample value.  What you need to do is:
* Convert all the interior area pdf terms of path pdf into projected solid angle pdf (using the geometry term in the formulae in previous posts).  For example using P_A(x4) == P_\perp(x5 -> x4) G(x5 <-> x4).
* Let the geometry terms cancel out for efficiency
You'll end up with an equation that contains:
* Le(x0->x1) and We(x5->x4)
* f for all interior vertices
* P_A(x0) and P_A(x5)
* P_\perp for x0->x1, x1->x2, x5->x4 and x4->x3 (or if you want to use pdf wrt solid angle, P(x -> x') for these cases and some cosine factors)
* The geometry term just for G(x2 <-> x3)
I won't spoil the fun by just writing down the answer. [SMILEY :P]
(L) [2012/07/20] [ost
by apaffy] [Re: Veach thesis - formula question] Wayback!Also please when you write "pdf" state the measure.  For example:
Path space pdf  = pdf wrt area product measure
P_A(x) = pdf wrt area at x
P(x -> x') = pdf wrt solid angle of ray x->x' at x
P_\perp(x -> x') = pdf wrt projected solid angle of ray x->x' at x
This really helps to not lose track of what's going on!
(L) [2012/07/20] [ost
by spectral] [Re: Veach thesis - formula question] Wayback!Thanks,
So , I have retry and got this solution. But I have some doubts about the value of p(x0->x1) and p(x4->x5).
Can you clarify please ?
bdpt_solve2.png
(L) [2012/07/20] [ost
by apaffy] [Re: Veach thesis - formula question] Wayback!>> apaffy wrote:You'll end up with an equation that contains:
* P_A(x0) and P_A(x5)
First line is great!  Something happened to your maths between the first and second lines, your pdf conversions are not correct.  Your final equation will contain P_A(x0) and P_A(x5) as I noted above!
Edit: actually I already wrote down the final sample equation for 4 vertices on [LINK http://ompf2.com/viewtopic.php?f=3&t=516&start=30#p1436 viewtopic.php?f=3&t=516&start=30#p1436] if you wanted a hint (although in this post please note P(x->x') is wrt projected solid angle). [SMILEY :)]
 >> spectral wrote:What are the values of P(x0->x1) and P(x4->x5)?
You mean P(x0->x1) and *P(x5->x4)*.
P(x0->x1) is defined by the angular emission model of your light source.  For emitters that emit hemispherically from a surface, this looks a lot like Lambertian reflectance.
P(x5->x4) is defined by the angular emission model of your camera.  This usually computed by sampling the film from a fixed point on the aperture, then converting this into an angular pdf.
(L) [2012/07/20] [ost
by spectral] [Re: Veach thesis - formula question] Wayback!Okay, professor.... finally I have :
bdpt_solve3.png
If I understand, we also have (compared to your previous post) :
P_A(x0) = 1/Pi if I emit uniformly
P_A(x5) = ???
P_\perp(x1 -> x2) = 1
P_\perp(x4 -> x3) = 1
But why ?
(L) [2012/07/20] [ost
by apaffy] [Re: Veach thesis - formula question] Wayback!>> spectral wrote:Okay, professor.... finally I have :
I'm just trying to point you towards the method for the answer, sorry if the to-and-fro is annoying. [SMILEY :)]  And I agree with your result in "bdpt_solve3.png"!
 >> spectral wrote:If I understand, we also have (compared to your previous post) :
P_A(x0) = 1
P_A(x5) = 1
P_\perp(x1 -> x2) = 1
P_\perp(x4 -> x3) = 1
But why ?
These aren't necessarily 1.  More detail:
P_A(x0) is usually 1/lightArea, assuming you have one light and you sample its area uniformly.
P_A(x5) is usually 1/apertureArea for your camera.  For a pinhole camera yes this can be 1 since sampling a pinhole is deterministic. [SMILEY :)]
P_\perp(x1 -> x2) and P_\perp(x4 -> x3) are defined by how you sampled the BSDFs at x1 and x4 respectively, so these are only 1 if the BSDF at that vertex is a perfect mirror reflection.  For Lambertian BSDFs, this will be 1/pi as usual.
(L) [2012/07/20] [ost
by spectral] [Re: Veach thesis - formula question] Wayback!Ah great [SMILEY :-P],
In a previous post from Ingenious, he tell that in BDPT the connection segment is deterministic and so P_\perp(x1 -> x2) = 1 and P_\perp(x4 -> x3) = 1 !
1/pi is the pdf in solid angle, not in projected solid angle ? I have to convert 1/Pi in projected solid angle ?
(L) [2012/07/20] [ost
by apaffy] [Re: Veach thesis - formula question] Wayback!>> spectral wrote:Ah great ,
In a previous post from Ingenious, he tell that in BDPT the connection segment is deterministic and so P_\perp(x1 -> x2) = 1 and P_\perp(x4 -> x3) = 1 !
The deterministic connection is between x2 and x3!  x1->x2 and x4->x3 are sampled (at x1 and x4 respectively)!
 >> spectral wrote:1/pi is the pdf in solid angle, not in projected solid angle ? I have to convert 1/Pi in projected solid angle ?
Sorry I was assuming cosine-weighted sampling, which has pdf wrt projected solid angle of 1/pi.
(L) [2012/07/20] [ost
by spectral] [Re: Veach thesis - formula question] Wayback!Great,
Just for the fun, the final answer (I hope) :
bdpt_solve4.png
So, thanks for all your help, explanations and patience [SMILEY ;-)]
(L) [2012/07/20] [ost
by apaffy] [Re: Veach thesis - formula question] Wayback!Personally I would keep the equation generic by keeping Le(x0 -> x1)/p(x0) and We(x5->x4)/p(x5) in there, which you can then specialize in code for the light/camera you are going to use, but this looks correct given your light/camera assumptions.
(L) [2012/07/20] [ost
by spectral] [Re: Veach thesis - formula question] Wayback!Yes, I agree... thanks for the council... it is just to be complete for the current exercise !
I'll do that way...
Thanks... have a nice week end
(L) [2012/07/20] [ost
by spectral] [Re: Veach thesis - formula question] Wayback!Just another question, does cos(theta_5) = 1 for a pinhole ?
Because in most path-tracer I have see there is no cos term in relation to x(5) ?
Thanks
(L) [2012/07/20] [ost
by apaffy] [Re: Veach thesis - formula question] Wayback!I have always considered the film/pinhole to be geometrically planar, in which case yes I have included a cosine term to compute the pdf wrt projected solid angle (as the equations require).  I've always viewed this as additional vignetting due to points on the film away from the center not being perfectly perpendicular to rays from the aperture.
I guess you could construct a camera where the film geometry is parabolic to always perfectly face the aperture, which would cancel this effect out, but it might be easier to just correct for vignetting as a post-process if you don't like the effect.
(L) [2012/07/21] [ost
by ingenious] [Re: Veach thesis - formula question] Wayback!The thing with the camera is the following. In BDPT you need to compute the area pdf of the first point hit from the camera, let's call this point 'x'. How do you normally compute the area pdf  of a point? Convert the solid angle ray pdf to area measure, as desperately discussed above [SMILEY :)] So, you need the solid angle pdf of the camera ray, which you then convert to area measure once you trace it and hit 'x'.
Now how you do compute the solid angle pdf of the camera ray? You might think it's something uniform, but it's not. The reason is that a camera ray is usually generated by uniformly sampling the pixel area on the image plane. A uniform image plane area density results in a non-uniform solid angle density for the ray direction. The solid angle pdf can be computed by multiplying the uniform image plane area pdf (which is simply 1/image_size) by the inverse of the factor you use for the conversion above, i.e. 'dist^2 / cos(theta)', where 'dist' is the distance from the pinhole to the image plane point, and 'theta' is the angle between the ray direction and the camera viewing direction. This is all very simple to derive geometrically on a piece of paper, and I'm puzzled by the obscure explanations of the camera model in BDPT in all related documents I've seen. It's just converting measures area -> solid angle -> area. So in summary, the camera cosine appears in the pdf of the first point seen from the camera.
(L) [2012/07/21] [ost
by spectral] [Re: Veach thesis - formula question] Wayback!Interesting... I will give a try too ! Thanks for clarrifications...
Finally I'm back to my code and I got better results... but, with light tracing I got some strange fireflies...
it is a problem I have already see (see "Light Rays Only"):
[LINK http://wwwx.cs.unc.edu/~sjguy/ImgSynth/ass3/main.html]
[LINK http://graphics.ucsd.edu/~iman/BDPT/]
I was expecting to have the exact same image for both PT and LT, my pdf are 1/Pi so there is no division by 0 !
If you have an idea ? maybe it is common or not !?
bdpt_pt.png
bdpt_lt.png
(L) [2012/07/21] [ost
by spectral] [Re: Veach thesis - formula question] Wayback!It seems to be a problem with the geometric term, when ||x-x'||² is small ?!
To remove my fireflies, I cancel any sample when this value < 10 ! It is not really a good way to fix it.
Do you have another suggestion ?
Thanks
(L) [2012/07/21] [ost
by ingenious] [Re: Veach thesis - formula question] Wayback!We've discussed this singularity many times already. This is normal. Full bidirectional path tracing with multiple importance sampling avoids the issue.
The two pages you've linked to both seem to have buggy BDPT implementations.
(L) [2012/07/21] [ost
by Igors] [Re: Veach thesis - formula question] Wayback!Maybe this link can be helpful
[LINK http://www.sjbrown.co.uk/2011/05/09/virtual-point-light-bias-compensation/]
(L) [2012/07/23] [ost
by spectral] [Re: Veach thesis - formula question] Wayback!Thanks for the link,
I have to try MIS now, but because I'm on the GPU I have to take an approach, up now I have read the Dietger (recursive MIS...) paper and will give a try.
But before it is still interesting to try the method proposed on the Simon blog. What I understand is the following :
 >>
1) I compute K = max( (G-b)/G , 0)
2) if K != 0 I bypass the connection (don't account the current vertices) and (a) continue the eye path and (b) multiply the eye-throughput by k
For now I play with a fixed 'b=0.1' and 'b=(1/|A|)/f )' , I have less fireflies but still get some differences compared to the path traced image.
The corners are darker (like using simple clampling method, it is the discussed bias !) and still got some noise fireflies on the cubes bottom !
[IMG #1 singularities.png]
[IMG #1]:Not scraped:
/web/20200811103433im_/http://ompf2.com/download/file.php?id=47&sid=2d323faa3be0c1fd980427f5c42fabba
(L) [2012/07/23] [ost
by spectral] [Re: Veach thesis - formula question] Wayback!Thanks for the link,
I have to try MIS now, but because I'm on the GPU I have to take an approach, up now I have read the Dietger (recursive MIS...) paper and will give a try.
But before it is still interesting to try the method proposed on the Simon blog. What I understand is the following :
 >>
1) I compute K = max( (G-b)/G , 0)
2) if K != 0 I bypass the connection (don't account the current vertices) and (a) continue the eye path and (b) multiply the eye-throughput by k
For now I play with a fixed 'b=0.1' and 'b=(1/|A|)/f )' , I have less fireflies but still get some differences compared to the path traced image.
The corners are darker (like using simple clampling method, it is the discussed bias !) and still got some noise fireflies on the cubes bottom !
singularities.png
(L) [2012/07/23] [ost
by Zelcious] [Re: Veach thesis - formula question] Wayback!You are missing a point. Don't bypass connection when k!= 0, clamp it (with the same b of course). That is reason for your incorrect result.
(L) [2012/07/23] [ost
by apaffy] [Re: Veach thesis - formula question] Wayback!If you read the Kollig and Keller paper, you'll see how this recursive bias compensation technique can be reformulated as a weighting scheme for multiple importance sampling in a bidirectional path tracer.
Maybe not directly helpful for you, but I found this to be really insightful.
(L) [2012/07/23] [ost
by ingenious] [Re: Veach thesis - formula question] Wayback!>> apaffy wrote:If you read the Kollig and Keller paper, you'll see how this recursive bias compensation technique can be reformulated as a weighting scheme for multiple importance sampling in a bidirectional path tracer.
Maybe not directly helpful for you, but I found this to be really insightful.
Indeed, and people seem to often overlook this part of the paper, which is the most insightful one, as it puts everything to place [SMILEY :)] Though the only advantage I see to it is the easier implementation than Veach's heuristics. It can be a good reason to justify implementation, but in general it's suboptimal to the power heuristic.
(L) [2012/07/23] [ost
by spectral] [Re: Veach thesis - formula question] Wayback!Thanks a lot,
I have try to add both (MIS + bias compensation) but still got a strange noise on the box !
The pseudo-code looks like this ( easier to write than equation in the forum for now [SMILEY :-(] )
Bias compensation
Code: [LINK # Select all]float b = lightArea/ bsdf(x);
float k = max(G-b)/G, 0);
if (k != 0)
{
 lightPath_throughput *= k;
 return min(b, G);
}
MIS
I use several parallel bdpt paths, so for now I just try to MIS between threads (if they have the same path length):
Code: [LINK # Select all]foat sumPdf = 0;
color r = 0;
for(int i = 0; i < THREADS; i++)
{
pdf = lightPath[i].path_pdf * cameraPath.path_pdf;
sumPdf += pdf;
r += r * pdf;
}
r /= sumPdf;
(L) [2012/07/23] [ost
by spectral] [Re: Veach thesis - formula question] Wayback!But how MIS can fix the problem ? The problem is due to very small value of ||x-x'|| and G is not part of the path pdf ! G is not related with the way we sample... there is no relation !
What do I miss ?
I was also thinking to merge the vertices when ||x-x'|| is too small... but it will introduce a an error in the image, so I have to take a sheet of paper a find a theoretical solution before [SMILEY :-P]
BTW: I have just found this paper, looks interesting : [LINK https://graphics.cg.uni-saarland.de/fileadmin/cguds/papers/2011/georgiev_sigasia2011/VertexMerging_SigAsia2011.pdf]
(L) [2012/07/23] [ost
by Zelcious] [Re: Veach thesis - formula question] Wayback!>> spectral wrote:But how MIS can fix the problem ? The problem is due to very small value of ||x-x'|| and G is not part of the path pdf ! G is not related with the way we sample... there is no relation !
What do I miss ?
[/url]
You are missing the conversation from solid angle to area measure. That contains ||x-x'||.
(L) [2012/07/23] [ost
by apaffy] [Re: Veach thesis - formula question] Wayback!>> spectral wrote:But how MIS can fix the problem ? The problem is due to very small value of ||x-x'|| and G is not part of the path pdf ! G is not related with the way we sample... there is no relation !
What do I miss ?
Due to MIS, that sampling technique will be assigned a small enough weight that the Monte Carlo sample will no longer be huge.  And your MIS pseudo-code in the post before that makes no sense, you need to compute the pdf (or usually pdf ratios) for all the techniques that could sample your current path, then use this to compute the MIS weight (for your current path).
(L) [2012/07/23] [ost
by ingenious] [Re: Veach thesis - formula question] Wayback!>> spectral wrote:I was also thinking to merge the vertices when ||x-x'|| is too small... but it will introduce a an error in the image, so I have to take a sheet of paper a find a theoretical solution before
BTW: I have just found this paper, looks interesting : [LINK https://graphics.cg.uni-saarland.de/fileadmin/cguds/papers/2011/georgiev_sigasia2011/VertexMerging_SigAsia2011.pdf]
That works too indeed [SMILEY :)] But gives you an estimate of different type of transport, i.e. one fewer path segment, and is useful for other types of transport (caustics). Just go back to the pen and paper exercise - draw one length-3 path (i.e. 3 edges), where one of the edges is really short, much shorter than the others. Then compare the (product area) pdfs of two possible ways to construct that path, where one of the ways is by connecting along that short segment. You'll see that the other technique has a much higher sampling pdf, and will thus be weighter much higher in a MIS combination.
(L) [2012/07/24] [ost
by spectral] [Re: Veach thesis - formula question] Wayback!When I compute the MIS weight, I have to use pdf in differential area and not in solid angle to compute my MIS !
Today, I use pdf in solid angle my path pdf is just the product of all theses pdf expressed in solid angle !
It seems easier to compute the L value (see picture below). So, I should I convert all theses pdf to dA before for MIS computation ?
Th eproblem is that I have to compute the product of all the path pdf in solid angle (the one I will use when I connect with a segment) and also, I will compute the path pdf in dA for the MIS ! I have to compute 2 path pdf (in different units). Or maybe it is better to compute L = LE G f G f G f G We directly and use P_A(X0)...P_A(X5) as the path pdf to avoid to compute the 2 paths pdfs ? It is a question of implementation you will tell me... In fact, using the pdf is solid angle avoid to play with the G term (and avoid some possible divisions by a very small distance !). Do you have councils for the implementation to avoid as much as possible conversions and possible division by 0 (or division by very small values) ?
[IMG #1 REA.png]
BTW, in my path pracer, I use the power-heuristic to mix the bsdf-sampling and light-sampling, both paths have the same length but theses are different paths. Is it incorrect ? Simon, you tell that I can "only" use MIS to mix the same path with different sampling techniques ?
[IMG #1]:Not scraped:
/web/20200920123200im_/http://ompf2.com/download/file.php?id=48&sid=529164880d70aa4ad0f37f38438dc76c
(L) [2012/07/24] [ost
by spectral] [Re: Veach thesis - formula question] Wayback!I have also check the pbrt code and found the following code / math.
The compute the W(Xj) this way :
    power-heuristic = lightPdf_da*lightPdf_da / (lightPdf_da*lightPdf_da+bsdfPdf*bsdfPdf)
Their bsdf_pdf is not computed in dA ! By example, for diffuse material they use |dot(wi, Ns)|/Pi => This one is expressed in solid angle ?!
(L) [2012/07/24] [ost
by Zelcious] [Re: Veach thesis - formula question] Wayback!This is how MIS works:
You have a path generated by one of several sampling strategies. Lets say you generated the path by connecting to a VPL and the other sampling strategy you use in your software is plain Path tracing.
In this particular case the connection was really close causing extremly high G term. This is correct since the likelyhood of a really close connection is equally low so for it to be correct you have that division by square distance.
However in this case you also have another sampling strategy, path tracing. Now lets consider if you had created this very same path by path tracing, then the G term would have been canceled out. So when we are using MIS we balance the pdf with all the ways we could have generated the very same path. In this case with path tracing and VPL. However to do that we need to compare the same thing, the contribution F needs to be the same. So we could convert to Area measure like in veach thesis or introduce a G in both contribution and pdf for the path tracing case. It's been there all along, it's just been canceled.
Hopes it makes sense.
Remember: Compare the probability of the path with all the ways it could have been created by your software and make sure the contribution part, numerator, is the same before you begin.
MIS is not a way to weight different paths, it is always the same path by all the ways it could have been generated. That said there is nothing stopping you from doing several MIS at the same time. Like when sampling a light by angle or area.
(L) [2012/07/24] [ost
by spectral] [Re: Veach thesis - formula question] Wayback!Right, I understand... its efficient ! Veach framework is really incredible... I fall in love [SMILEY :lol:]
(L) [2012/07/26] [ost
by spectral] [Re: Veach thesis - formula question] Wayback!First, thanks for all your help up now...
Now I'm back with MIS questions. I have the following formulas and if I have (a) and (b) and compute the value of 'I' I got the following !
What do I miss please ?
BTW: theses formulas are coming from "a survey of importance sampling applications in unbiased physical based rendering" (page 15 & 16)
[IMG #1 MIS01.png]
[IMG #1]:Not scraped:
/web/20200920123200im_/http://ompf2.com/download/file.php?id=49&sid=529164880d70aa4ad0f37f38438dc76c
(L) [2012/07/26] [ost
by Dietger] [Re: Veach thesis - formula question] Wayback!I assume you are referring to equations (3.3) and (3.7). Note that equation 3.3 does not correspond with your equation a. Equation 3.3 sums over a collection of N different samples X_1 ... X_N, which in BDPT terms is the collection of bidirection connections generated by a single eye and light path. Each 'sample' here is a single light transport path connecting the eye with a light source. These samples are than combined using equations 3.3 and 3.7 to form the combined Monte Carlo sample I (a bidirectional uber sample, if you will  [SMILEY :D]). However, in your equation a, you simply re-use the same sample X repeatedly.
(L) [2012/07/26] [ost
by spectral] [Re: Veach thesis - formula question] Wayback!Thanks a lot for your answer,
So, I have redo the same but taking care of X(o)...X(n) and here is what I got :
[IMG #1 mis.png]
You see, in the last equation, there is a p_t(Xj) in the denominator and the nominator, they cancel ! Or they are not the same ?
Something else, in the equation (3.3) you use L_i(X_i), then even in your recursive MIS computation you need to keep track of each vertex position, normal etc... to compute each L_i(X_i)... so, you're still limited with the path length ?
Thx
[IMG #1]:Not scraped:
/web/20200808121342im_/http://ompf2.com/download/file.php?id=50&sid=d3b7546728382b3854f7ccbc582b7bf1
(L) [2012/07/26] [ost
by spectral] [Re: Veach thesis - formula question] Wayback!Thanks a lot for your answer,
So, I have redo the same but taking care of X(o)...X(n) and here is what I got :
mis.png
You see, in the last equation, there is a p_t(Xj) in the denominator and the nominator, they cancel ! Or they are not the same ?
Something else, in the equation (3.3) you use L_i(X_i), then even in your recursive MIS computation you need to keep track of each vertex position, normal etc... to compute each L_i(X_i)... so, you're still limited with the path length ?
Thx
(L) [2012/07/27] [ost
by spectral] [Re: Veach thesis - formula question] Wayback!I have just discover that Anthony Pajot also has this formulation in his thesis, page 47 [LINK http://www.irit.fr/~Anthony.Pajot/publis/master/MasterIrit.pdf].
But so, why not directly computing thus formulation ?
(L) [2012/07/27] [ost
by Dietger] [Re: Veach thesis - formula question] Wayback!Yes, for the balance heuristic they do cancel. However in the power heuristic they do not cancel out. Also, sometimes it is acceptable (and convenient) to use approximations of the probabilities for computing MIS weights, in which case they no longer cancel. For example, for practical Russian roulette schemes it is often somewhat cumbersome to compute the correct reverse Russian roulette probabilities. Instead you could use a simpler approximation for the Russian roulette probability (or ignore it altogether) for the MIS weights. Although using approximations can compromise the theoretical optimality of your MIS weights, this may be acceptable for the sake of convenience.
(L) [2012/07/27] [ost
by spectral] [Re: Veach thesis - formula question] Wayback!>> Dietger wrote:Yes, for the balance heuristic they do cancel. However in the power heuristic they do not cancel out. Also, sometimes it is acceptable (and convenient) to use approximations of the probabilities for computing MIS weights, in which case they no longer cancel. For example, for practical Russian roulette schemes it is often somewhat cumbersome to compute the correct reverse Russian roulette probabilities. Instead you could use a simpler approximation for the Russian roulette probability (or ignore it altogether) for the MIS weights. Although using approximations can compromise the theoretical optimality of your MIS weights, this may be acceptable for the sake of convenience.
Thanks, I see... interesting [SMILEY :-D]
And about the following question [LINK http://igad2.nhtv.nl/ompf2/viewtopic.php?f=3&t=526#p1531], do you have an advice ?
Thx
(L) [2012/08/10] [ost
by spectral] [Re: Veach thesis - formula question] Wayback!Hi,
Just another question, what to do in a BDPT when a light-ray or camera-ray hit a light ?
Should I :
1) If the previous vertex is not specular, I stop the ray
2) If the previous vertex is specular, I accumulate the light radiance
Should I do this for both camera and light path ?
(L) [2012/08/10] [ost
by Dietger] [Re: Veach thesis - formula question] Wayback!These are just yet other sampling strategies, so you should just mix them with the all the others bidirectional strategies using MIS. If an eye path hits a light source, you should accumulate the MIS corrected radiance, weather the last vertex was specular or not (this is already accounted for by MIS). The same is true for light paths hitting the camera, although most people just ignore this strategy for simplicity, as its contribution is usually low. The probability of randomly hitting the image plane is infinitely small for pinhole camera's and close to zero for finite aperture lenses except for regions with massive DOF.
(L) [2012/10/20] [ost
by jameszhao00] [Re: Veach thesis - formula question] Wayback!Quick question:
I was writing out and simplifying the path integral formula and noticed an extra cos term appearing near the sensor parts. Am I simplifying something incorrectly? I've always seen eye path throughputs start at 1.
For example, for a ED-L path with 1 light vertex, we have (all pdfs are in solid angle, geometry-like terms in [...])
We * W(a->b) * [cos(a_wi) * cos(b_wo) / |a-b|^2] * f(a->b->c) * [cos(b_wi) * cos(c_wo) / |b-c|^2] * Le
divided by
P(We) * P(Wa->b) * [cos(b_wo) / |a-b|^2] * P(C)
becomes
We/P(We) * W(a->b)/P(Wa->b) * cos(a_wi) * f(a->b->c) * [cos(b_wi) * cos(c_wo) / |b-c|^2] * Le/P(C)
And for a pinhole camera, We*W(a->b)/(P(We)*P(Wa->b)) = 1 (is this incorrect?) so we get
cos(a_wi) * f(a->b->c) * [cos(b_wi) * cos(c_wo) / |b-c|^2] * Le/P(C)
Why is there an extra cos(a_wi) in there?
We*W(a->b)/(P(We)*P(Wa->b)) = 1 comes from [LINK https://sites.google.com/site/qmcrendering/Siggraph2012Premoze-BidirectionalPath.pdf?attredirects=0]
back