Page MenuHome

[MNEE] Removed UV Requirement (and Code Cleanup)
ClosedPublic

Authored by Olivier Maury (omaury) on Apr 12 2022, 6:54 AM.

Details

Summary

Following T94120 TODO list, removed need for shadow caustic caster geometry to have a UV layout. UVs were useful to maintain a consistent tangent frame across the surface while performing the walk. A consistent tangent frame is necessary for rough surfaces where a normal offset encodes the sampled h., which should point towards the same direction across the mesh.

In order to get a continuous surface parametrization without UVs, the technique described here was implemented:
http://lightrig.de/publications/p2014/HSLT/HSLT_supplementary.pdf

In addition to implementing this feature:

  • Shadow caustic casters without smooth normals are now ignored (triggered some refactoring and cleaning).
  • Hit point calculation was refactored using existing utils functions, simplifying the code.
  • The max number of solver iterations was reduced to 32, a solution is usually found by then.
  • Added generalized geometry term clamping (transfer matrix calculation can sometimes get unstable).

Diff Detail

Event Timeline

Olivier Maury (omaury) requested review of this revision.Apr 12 2022, 6:54 AM
Olivier Maury (omaury) created this revision.
This revision is now accepted and ready to land.Apr 12 2022, 6:58 PM
Brecht Van Lommel (brecht) requested changes to this revision.Apr 12 2022, 7:16 PM

I found that with this patch the CPU and OptiX render are quite different, which makes the test fail. We allow some differences but this crosses the threshold, can you check if this is expected?

https://svn.blender.org/svnroot/bf-blender/trunk/lib/tests/render/integrator/underwater_caustics.blend

This revision now requires changes to proceed.Apr 12 2022, 7:16 PM
Alaska (Alaska) added a comment.EditedApr 13 2022, 1:14 AM

Shadow caustic casters without smooth normals are now ignored

I assume this is to avoid the situations in which Shadow Caustic Casters without Smooth Normals have a loss of energy? In which case, the user can still enable specific properties to create this "loss of energy" and that should probably be accounted for in this patch.

  1. Open Blender, change the render engine to Cycles, and setup a Caustic Caster, Caustic Receiver, and Shadow Caustic Light.
  2. Select the Caustic Caster and change it to Shade Flat
  3. Enable Auto Smooth Normals on the Caustic Caster. This will enable MNEE caustics, but it will have a "loss of energy" due to Flat Shading.

Here is a file with everything setup.


Here is how the scene is setup:

And here's where you can find the "Auto Smooth Normals" setting:

Olivier Maury (omaury) updated this revision to Diff 50685.EditedApr 22 2022, 7:46 AM

Changes:

  • Added 2 stop conditions for the newton solver: one on the stepsize lowest value and another one based on the progress distance between 2 consecutive iterations of the same manifold vertex. Adding these conditions helped produce more consistent solves on CPU and GPU backends, which don't reacts consistently to high precision arthmetic operations. This addresses issues raised in D14623 when executing test suite where differences between CPU and GPU backends were quite large (@Brecht Van Lommel (brecht))
  • Added support for most refraction appearance models, which should address T96990 and T96991.
  • Added another validity test limiting MNEE to triangle meshes.
  • Rerouted MNEE contribution from direct to indirect, addressing T96992 in part: More work is needed since only this only appears to work with one light.

Shadow caustic casters without smooth normals are now ignored

@Alaska (Alaska) and @Brecht Van Lommel (brecht), in general we feel that if a user sets up a scene to use MNEE incorrectly, we should make it clear that the scene does not work: In cases where a caster:

  • is not a mesh.
  • does not have smooth normals throughout (required for the manifold walk).
  • does not have a transmissive bsdf.

We turn off casutics all together, deliberately not trying to bring back the "Filter Glossy" default behavior, which could be misleading. What do you think?

Thanks for the updates.

I'll commit this without the render pass fix, because this patch is already getting quite big and I don't think that fix is correct. I'll leave some comments about that inline, a fix for render passes can be submitted in a separate patch.

intern/cycles/kernel/integrator/mnee.h
1082

I think this should be changed to this, to avoid potential double counting of bounces.

const int bounce = INTEGRATOR_STATE(state, path, bounce) + 1 + vertex_count;
1100–1104

We should not be changing the bounces in state, path, only the copy we put in shadow_state, shadow_path to avoid affecting indirect light paths.

This revision is now accepted and ready to land.Apr 22 2022, 6:44 PM