Experiment with Cycles Shadow Catcher
Build = arc_patch_D1788_Win7.x64-3189ea0
Add missing light accumulation to next iteration setup kernel
This update includes:
- Rebase against latets master
- Style fix reported by Thomas
- OpenCL implementation by Hristo
- OpenCL tweak to solve speed regression
Our local benchmark machine shows 1% slowdown on RX480. Not sure yet
whether it comes from the flackynbess of the system (it seems to be
slower than our previous machine) or it's a slowdown caused by our
If more people tests OpenCL before/after this patch on scenes without
shadow catcher it'll be great.
Update against latest master
Update once again, used wrong flag in previous update
- Updated against latest master
- Enabled background color by default now (seems to match to what people are requesting).
- Worked around issue in scenes where there's just a shadow catcher and background (such case would cast shadow on the shadow catcher caused by indirect background light). Not fully happy here with the solution, but not sure what we can do better here.
- Applied patch from Lukas so hopefully we are more aligned with denoise branch.
Worked around compilation error of OpenCL kernel
Initial provision was to avoid dereference of the argument when building without shadow tricks. But guess that;s not important since all platforms should be including that sooner or later (OpenCL split might be a problem).
Let's just switch to single state here.
Don't have strong opinion here. If that makes easier to merge with denoiser, let's just move it.
Was giving some usual issues with address spaces. But now i look into the code and seems we can just change it to path_radiance_accum_background(ccl_addrspace State*) without issues.
Not sure why that wasn't done in original change. Will doublecheck and update.
Mainly rebasing against latest master, don't expect any difference in behavior
@Lukas Stockner, i've tried implementing your idea of using non-MIS-weighted
numbers for the shadow, but there were following issues:
- It made BPT somewhat darker shadows than with PT
- I'm not sure we can store MIS weight in BsdfEval anymore: this weight is different for different terms in the BSDF eval sum, so don't think we can divide final sum bu overall MIS weight to get number we want?
@Brecht Van Lommel, can we start some discussion about what is the best approach to get
this into master? What i have in mind is:
- Figure out whether i got Lukas's idea right.
- Make this an Experimental option, so we keep some margin about making possible changes in the render results if we'll re-consider some parts of the change to work better with denoiser.
Fix typo in light sampling
Was causing missing shadows in files with no world in certain cases.
Rebase against latest master
More real work is upcoming.
Fixes for branched path traders
Was missing some scaling factors here and there. Also did some simplification
of what needs to be stored to have properly calculated shadow.
Once thing i still didn't manage to solve is difference between PT and BPT
when catching shadow in a scene lit by only world AO.
Fixes for AO
BPT gets closer to PT with change and it's seems logical thing to do anyway,
but somehow there is still some difference in AO between BPT and PT.
Also disabled shadow tricks for split kernel OpenCL -- it's a bit tricky to
implement them in this kernel.
Solved issues with just a background light
- Solves issue with colored lamps
- Solves issues with GPU
- Both PT and BPT are expected to work
Update self-shadoing part of the patch.
This is more a code dump of a local branch, not somewhat really finished or so. Underlying math is the subject for rework since it's not quite physically based at all.
Publishing to start collaboration with other Cycles developers who are looking into solving this puzzle.
What do we consider a shadow catcher?
That's a good question actually, and there's no single formulation of what it exactly is and mathematically it's a bit malformed in the constraints we're working on.
Ideally shadow catcher is a difference between image rendered without artificial objects and with them.
Such approach gives best ever shadows, but takes 2x more time to render.
So for good usability we need to get some assumptions, make system a bit more biased but give artists an useful tool.
Shadow catcher is mainly used by VFX artists to inject artificial objects into real footage. At least that definition we'll stick to
in Blender. Hence here's what shadow catcher should be capable of doing:
Receive shadows from other objects: be totally transparent when there's no shadows cast on it, be more opaque in shaded areas.
Ignore self-shadowing and shading. Shadows caused by occlusion with itself already exists in the footage. Same applies to the
shading -- all shading caused by material itself are also in the footage already.
Interact with other objects in the scene. This sounds a bit tricky but makes sense actually.
Consider situation when one needs to put sharp glossy object into the footage: you'll want objects from a real scene to be reflected in the artificial object.
And often you'll want the object on which shadow is to be cast to be reflected in such situations.
Surely you can escape with copying object and playing with ray visibility, but that's complicated scene setup instead of making it simpler.
Be affected with indirect light. Cycles is the GI render engine after all!
How to use the shadow catcher?
Create an object on which you want to receive shadow.
Create some basic material setup which is close to a real object.
Enable "Shadow Catcher" in Object buttons -> Cycles Settings.
Be happy! (hopefully, once we've debugged all the code)
What this patch actually contains?
It contains all the bits which tries to implement definition of shadow catcher above.
It is trying to implement it all in a way so we don't need to make big changes in the ray integration loop, hence it has some tricky magic to deduct what was the received shadow from the light passes and will fail in certain situations,
mainly when there is no direct lighting of the object at all.
It is totally tweakable to become more artists friendly, i just didn't have enough time to try all the ideas and used whatever latest semi-working formula was.
Major changes are in fact made around shadow_blocked() to exclude shading from self. This part is based on an older patch which tried to expose it to an user.
That exposing settings are somewhat malformed and shouldn't really be used. In fact, we should remove those settings from the interface.
but it's not working caustic https://yadi.sk/i/DWcl3wnI3Fx7e6
@ sahnoune moussa should work try d/l again :)
@David Tucker This is built on Windows 7 .x64 You could try using https://www.winehq.org/ Not sure if it would work or not. Or just apply the patch (arc patch D1788) and compile on your mac :)
@Jeffrey Reale Is on the 2.79 Target list to be in the master :) https://wiki.blender.org/index.php/Dev:2.7
Quick question.... is there a way I can install this patch for version 2.78a? Or do you have a version that's for the new version?
If I can be any help in testing - david [at] tucker [dot] fm
i need someone to upload Blender 2.78.3 - Cycles: Shadow Catcher i can't get it from here every time i try to download it its stops before its complet
i realy neeed it so if anyone can upload it for me (send me the link my email is firstname.lastname@example.org) that would help me a lot thank you people
Shadow catcher working ok on cycles with GPU enabled.
One node in compositing for correct shadow – cool! Save many time. Thanks!
Log in to leave a comment.