search

mitsuba-renderer / mitsuba3

Mitsuba 3: A Retargetable Forward and Inverse Renderer
https://www.mitsuba-renderer.org/
Other
2.09k stars 246 forks source link

'Thin' objects with wrong facing normals #1340

Closed xacond00 closed 1 month ago

xacond00 commented 1 month ago

Description

I've been testing the Cornell Box scene from here: https://mitsuba.readthedocs.io/en/stable/src/gallery.html, wanting to visualize the surface normals by computing cos theta with the ray direction / or even from local frame. I quickly found out, that when intersecting thin objects - mainly "rectangles", the cos theta result are sometimes negative (which they shouldn't be, since the surface got intersected with primary ray, so the normal should be facing towards the camera).

The situation can be seen here (ignore the left white strip, I shifted the camera a little): bad_normals The two boxes' and walls' normals look fine, but the walls facing the camera return negative values.

As far as I know, this would also screw up next event estimation, since the bsdf pdf computation and sample function ignore any samples with negative si.wi ? Am I missing something ? Are the rectangles orientated, so that they have only one normal ? The BSDF is two sided btw.

Steps to reproduce

  1. Generate first surface interaction from camera rays via scene intersection
  2. Compute cos theta of surface x ray.direction
xacond00 commented 1 month ago

Oh I see it in the code now. You just pass the precomputed normal into surface interaction... But haven't found flag that would allow the 2D primitive to be "bidirectional", only to flip normals, which still breaks the importance sampling from the other side of the shape ?

Btw. this is not the only broken scene, "Bedroom" has curtains that have also black normals from one side...

Edit: oooohhh, the flipped normals are handled in the "twosided" bsdf... That's why the lighting computation still works. However I do wonder, why doesn't the geometry default to returning always valid normals, with a "front/back facing" flag ?

njroussel commented 1 month ago

However I do wonder, why doesn't the geometry default to returning always valid normals, with a "front/back facing" flag ?

Wouldn't this be equivalent to having a signed normal? The sign bit is the back/front flag.

I think you've answered all your questions yourself now :sweat_smile: Can I close this ?

xacond00 commented 1 month ago

However I do wonder, why doesn't the geometry default to returning always valid normals, with a "front/back facing" flag ?

Wouldn't this be equivalent to having a signed normal? The sign bit is the back/front flag.

I think you've answered all your questions yourself now đŸ˜… Can I close this ?

Yeah, but there is no way to tell if the surface is "front facing" towards the given direction without additional context. Ie I was testing visibility of reprojected samples from other view than primary, and thought the cos(theta) of primary samples must be always positive, so I went with "cos(theta2) > 0" test to determine whether the second view sees the same side of the shape, which would work fine logically, except not when the normals can be backwards. After I found out, I modified it so that I test whether the sign of both cos(theta)'s is the same. It's just a convention thing from other path tracers rather than a real issue, I guess... So yes, this can be closed.