Shading normal issues w. adjoint bsdf

Practical and theoretical implementation discussion.
dawelter
Posts: 37
Joined: Sun Oct 29, 2017 3:15 pm
Location: Germany

Shading normal issues w. adjoint bsdf

Postby dawelter » Sat Feb 16, 2019 9:35 am

Hi there,

I seek help for robustly implementing Veach's correction for shading normals for the adjoint BSDF, i.e. for photon mapping or light tracing.

The problem: According to Veach we should add a correction factor that compensates for using shading normals instead of geometry normals:
eq5.18.PNG
eq5.18.PNG (4.41 KiB) Viewed 427 times


However, wo*Ns/wo*Ng can become arbitrary large since the denominator does not cancel and can become very small at grazing angles. I saw this factor go up to 1000. And this introduced ugly fireflies in my render. I clamped the factor to 10 as a band aid fix. But this is certainly not very pretty. It did help though with no noticeable change in the image.

How do production renderers deal with this?

I took a look at PBRT's implementation and found that in BDPT they use the correction straight forwardly
https://github.com/mmp/pbrt-v3/blob/mas ... pt.cpp#L55

To my surprise I did not found the correction in the photon mapping code!
https://github.com/mmp/pbrt-v3/blob/mas ... m.cpp#L403
There ist just the regular

Code: Select all

Spectrum bnew =
beta * fr * AbsDot(wi, isect.shading.n) / pdf;


Did I manage to find a bug? Is it a conscious decision to omit it to prevent fireflies?

shocker_0x15
Posts: 70
Joined: Sun Aug 19, 2012 3:24 pm
Contact:

Re: Shading normal issues w. adjoint bsdf

Postby shocker_0x15 » Fri Feb 22, 2019 3:14 am

I don’t have a clear answer for your question, but I think there is a limitation with shading normal because it doesn’t have physical basis (as Veach noted).
One apparent way to mitigate arbitrarily large values is using well polygonized model which has shading normal similar to geometric normal...

I completely agree with your surprise.
I felt the same surprise when I saw the implementation of PBRT v3.
It should take the correction factor into account in renderers other than BPT too in my opinion because PBRT is not a production oriented, it is education oriented.

dawelter
Posts: 37
Joined: Sun Oct 29, 2017 3:15 pm
Location: Germany

Re: Shading normal issues w. adjoint bsdf

Postby dawelter » Sat Feb 23, 2019 8:45 am

Hi.

Thanks for your reply. At least it is good that I didn't totally misunderstood something there.

For some reason the correction factor went way down, when I used another mesh (higher res version of the stanford bunny). I could swear it has a similar amount of jagged edges. I start to think, that either I have a weird bug somewhere, or the mesh has errors.

Apart from investigating this, I will stick to clamping. It should be fine.

shocker_0x15
Posts: 70
Joined: Sun Aug 19, 2012 3:24 pm
Contact:

Re: Shading normal issues w. adjoint bsdf

Postby shocker_0x15 » Sat Feb 23, 2019 9:58 am

It might be help for you to visualizing the relation between geometric normal and shading normal like this:
clamp(
RGB(
0.5 + 10 * (dot(shadingNormal, geometricNormal) - 1),
0.5 + 100 * (length(geometricNormal) - 1),
0.5 + 100 * (length(shadingNormal) - 1)
)
, 0, 1)

This shows completely a gray image in the ideal and correct situation (shadingNormal == geometricNormal and the lengths of two normals are 1).
Multiplier like 10 * or 100 * are used to exaggerate difference from the ideal.

dawelter
Posts: 37
Joined: Sun Oct 29, 2017 3:15 pm
Location: Germany

Re: Shading normal issues w. adjoint bsdf

Postby dawelter » Sun Feb 24, 2019 2:23 pm

Doh! :x I was about to file an issue. Instead I got my answer right there ...
https://github.com/mmp/pbrt-v3/issues/209

@Shocker: Yeah ... It's a bit overkill but if I cannot understand the differences between the mesh otherwise, why not. ;-)


Return to “General Development”

Who is online

Users browsing this forum: No registered users and 5 guests