POTA bidirectional seems to lose energy of edge bokehs (0001 only)

[zpelgrims]

This seems due to a bug in the light sampling code? In the js demo I found that I can converge to backtraced light paths that should not be possible (e.g vignetted by the lens)..?

[zpelgrims]

Try writing out the light sampling data again.. From previously debugged data, the values exploded at low iteration counts: https://mail.google.com/mail/u/0?ui=2&ik=fdab72bd6c&view=lg&permmsgid=msg-f:1587332565163531078

Does the same happen in my case? Or is it because the solver it runs out of iterations (> 100)?

[zpelgrims]

Answer from johannes:

of course i do not remember pretty much anything now :)

let me try:

the "dampen" factor is exactly what you thought, something that doesn't go the whole newton step but only a fraction. this is needed because (guessing here):

• we have an interleaved newton method, that optimised for position and direction not at the same time but first one, then the other, etc. of course going down one derivative may be too much for the other dimensions, so dampen is better

• we don't consider curvature (i.e. the tangent frame on the surface changes as you move on the lens, so the half vector would change due to this effect, too), which may lead to slightly inaccurate estimates for the solver.

are you using our code directly? using a smaller dampen factor would require more iterations to converge, and i think we give up after a certain iteration count (hence different results are possible). with a too large factor, you'll get a lot of overshoot which may lead to divergence, too.

the javascript thing just visualises the rays as they go through in organge. so that these are drawn is not by mistake, but just for reference. these are only shot towards the entry side of the bounding box of the lens, so the set is incomplete.. really a rough reference.

the green path thinks it converged, but ray tracing it reveals that it's actually blocked by the housing of the lens (the 2nd element just after the aperture in your case).

this is one of the more fundamental shortcomings of using polynomials instead of honest ray tracing: you don't know the precise geometry of the lenses any more and can't use them as blockers.

that said, usually lenses are designed in a way that only the aperture determines what is blocked and what is not (all control to the photographer). in the lens description, the precise geometry of the aperture is usually guesswork (lenses are normalised to 100mm to begin with etc). i'm guessing that the max aperture in this case should be smaller than what is drawn in the image. if it was a bit smaller, the first circle there would have to be a little lower and the ray would go through.

hope that helps. cheers, jo

[zpelgrims]

Is the value explosion normal? print the numbers in the javascript demo, maybe that's just how the values behave when there is NO solution?

[zpelgrims]

this only happens for 0001 .. ignore for now & solve later.

Definitely due to failing newton iterations,

[zpelgrims]

closing in favour of #223