Page MenuHome

Fix T91733, T92486: Cycles wrong shadow catcher with volumes
ClosedPublic

Authored by Brecht Van Lommel (brecht) on Nov 3 2021, 7:50 PM.

Details

Summary

Changes:

  • After hitting a shadow catcher, re-initialize the volume stack taking into account shadow catcher ray visibility. This ensures that volume objects are included in the stack only if they are shadow catchers.
  • If there is a volume to be shaded in front of the shadow catcher, the split is now performed in the shade_volume kernel after volume shading is done.
  • Previously the background pass behind a shadow catcher was done as part of the regular path, now it is done as part of the shadow catcher path.

For a shadow catcher path with volumes and visible background, operations are
done in this order now:

  • intersect_closest
  • shade_volume
  • shadow catcher split
  • intersect_volume_stack
  • shade_background
  • shade_surface

The world volume is shaded in both the shadow and non-shadow catcher paths
now, which means the fog is assumed to already exist in the footage. We may
consider adding an option to control this, or change the default. With a
volume object this control is already possible.

This includes refactoring to centralize the logic for next kernel scheduling
in intersect_closest.h.

Diff Detail

Repository
rB Blender

Event Timeline

Brecht Van Lommel (brecht) requested review of this revision.Nov 3 2021, 7:50 PM
Brecht Van Lommel (brecht) created this revision.
Brecht Van Lommel (brecht) planned changes to this revision.Nov 3 2021, 7:50 PM
Brecht Van Lommel (brecht) retitled this revision from Fix T91733: Cycles wrong shadow catcher with volumes [WIP] to Fix T91733, T92486: Cycles wrong shadow catcher with volumes.Nov 4 2021, 7:56 PM
Brecht Van Lommel (brecht) edited the summary of this revision. (Show Details)

More changes, ready for review now.

Overall sounds cool!

The world volume is shaded in both the shadow and non-shadow catcher paths now, which means the fog is assumed to already exist in the footage

This is not what I'm not sure about. It is quite hard to replicate atmospheric effects with decent exact match, To me it seems more straightforward and useful to consider wold volume as CG.
@Sebastian Koenig (sebastian_k) What's your thoughts here?

Consider world volume CG by default instead.

I'll commit this as is since I have some other changes on top of this I want to do, it fixes a crash, and it would be good to get user testing as soon as possible.

I can commit additional changes if you find anything in code review.

This revision was not accepted when it landed; it landed in state Needs Review.Nov 5 2021, 9:02 PM
This revision was automatically updated to reflect the committed changes.