Author Topic: CShading_Shadows  (Read 5644 times)

2020-06-20, 00:11:58

cjwidd

  • Active Users
  • **
  • Posts: 1077
    • View Profile
    • Artstation
tl;dr - CShading_Shadows produces unusual results, or I'm using it incorrectly:

watch x2.0 speed
« Last Edit: 2020-06-20, 07:22:07 by cjwidd »

2020-06-20, 00:29:26
Reply #1

TomG

  • Administrator
  • Active Users
  • *****
  • Posts: 5463
    • View Profile
Quick questions - are you using the new "masks visible in reflection / refraction" settings? And what happens with the same scene under, say, 5.2 rather than latest daily (trying to see if this is something that is different in the latest daily, or something that is different with this scene).
Tom Grimes | chaos-corona.com
Product Manager | contact us

2020-06-20, 01:27:55
Reply #2

cjwidd

  • Active Users
  • **
  • Posts: 1077
    • View Profile
    • Artstation
TomG, good question - I knew I forgot to mention something. The 'propagate masks' feature is enabled in this scene.

Support ticket has been created - link to scene file included:

#186466 Corona 6 (DailyBuild Jun 18 2020) - CShading_Shadows

2020-06-29, 16:59:18
Reply #3

maru

  • Corona Team
  • Active Users
  • ****
  • Posts: 12754
  • Marcin
    • View Profile
Hi cjwidd, I just briefly checked your scene and here are my observations (I will leave the full investigation and conclusion to George though, so please do not take this as the final answer):
1) For some reason, the scene is rendering very slowly. There is a lot of noise and it just stays there, only changing the pattern rather than refining. I am not exactly sure why.
2) It seems that the lighting in the scene is mostly GI. If the light and shadows are created by GI, then Corona cannot create a Shadows pass as you would expect it. The Shadows pass can only be correctly created when using direct lighting.

So if there is a Corona Light object shining onto something, and it is casting a shadow - this shadow will be registered by the Shadows render element.
If there is a light shining onto a wall, and this wall reflects light, which then hits and object, and this creates a (bounced) light + shadow situation - then the Shadows render element is helpless.
Marcin Miodek | chaos-corona.com
3D Support Team Lead - Corona | contact us

2020-06-29, 23:56:13
Reply #4

cjwidd

  • Active Users
  • **
  • Posts: 1077
    • View Profile
    • Artstation
Hey Maru, I have a response from George K. in my inbox from the help desk about this issue, but I have not had time to assess the instructions that were provided. I just want to communicate to y'all that I'm not ignoring your advice, I've just been busy with work, and I will step through your suggestions on my end ASAP.

2020-06-30, 15:53:20
Reply #5

maru

  • Corona Team
  • Active Users
  • ****
  • Posts: 12754
  • Marcin
    • View Profile
I just want to communicate to y'all that I'm not ignoring your advice, I've just been busy with work, and I will step through your suggestions on my end ASAP.
No problem at all. We understand you really well. :)
Marcin Miodek | chaos-corona.com
3D Support Team Lead - Corona | contact us

2020-07-08, 11:04:03
Reply #6

3dboomerang

  • Active Users
  • **
  • Posts: 214
  • Head of 3D
    • View Profile
    • 3DFLOW
"The Shadows pass can only be correctly created when using direct lighting."

Ok.. But when is this handy? In what scenario would this be used? I never had a render in my life without GI bouncing around? Is this a bug then or just something that doesnt and won't exist?

I just had a client asking to remove shadows in certain areas of a huge scale architectural render cause the sun's direction was unfortunate. So this "trick" is kind of relevant.

Atm we're using gamma and brightness post on masked areas..

Grts

2020-07-09, 02:14:25
Reply #7

cjwidd

  • Active Users
  • **
  • Posts: 1077
    • View Profile
    • Artstation
The response provided here by @Maru and in the support ticket by @GeorgeK does help resolve the issue as I've described it (thank you!), but I think it points to a sort of gap in the workflow:

1. CShading_Shadows cannot be used to subtract from tonemapped images, i.e. linear workflow only
2. CShading_Shadows cannot be used to subtract from lighting scenarios involving more than direct lighting

It seems that in the example I described in my video - with the fluffy plant object - it was sort of a fluke (happy accident) that the CShading_Shadows pass was able to be used in the way it was shown.

It would be better if there were a shadows pass render element that could be used to subtract shadows arbitrarily from the image in post, i.e. regardless of lighting, regardless of tonemapping. Technically speaking, that might be magical thinking(?)
« Last Edit: 2020-07-09, 02:18:07 by cjwidd »

2020-07-09, 11:22:26
Reply #8

maru

  • Corona Team
  • Active Users
  • ****
  • Posts: 12754
  • Marcin
    • View Profile
I don't fully get the arguments here. I would need a few examples of where it makes sense for you to negate the shadows, and where it does not.

Quote
1. CShading_Shadows cannot be used to subtract from tonemapped images, i.e. linear workflow only
This is a general rule because of the way blending operations work (adding color values, subtracting them, etc). I don't think there is a way to overcome this.
As a workaround, you can save your post settings in a CONF file, then reset tone mapping, then compose your image in PS or other app, save to EXR, open in CIE and apply your CONF file.

Here are my thoughts...

Let's say we are rendering an image like this:



The object on the wall is casting a shadow from direct light. This is easy.

The object on the floor is casting a "shadow" from indirect light (bounced off the left wall).


If we want to get rid of the direct lighting shadows, that's easy:




Now I am trying to imagine what you would want to achieve by getting rid if the "indirect lighting shadows".


You would either end up with a fully black screen (if you would remove indirect lighting whatsoever).

Or you would end up with a fully black screen with direct lighting on top of it (if you would remove indirect lighting and keep direct lighting), which is basically the CEssential_Direct render element:




Or you would end up with something like pure diffuse color without any shading (if you would negate the indirect lighting in a similar way as the direct lighting shadows are negated, leaving only indirect lighting):




Or you would end up with something like pure diffuse color without any shading with direct lighting on top of it (if you would negate the indirect lighting in a similar way as the direct lighting shadows are negated, leaving only indirect lighting, and then you would add direct lighting on top of the result):




I don't think any of the above examples is desired. Could you maybe try "simulating" the effect you are after? For example, render an image, and do some adjustments in Photoshop to showcase what your desired end result would look like? (or just mark in red the lights / shadows that you would like to remove or adjust in some other way).
Marcin Miodek | chaos-corona.com
3D Support Team Lead - Corona | contact us

2020-07-10, 03:31:06
Reply #9

cjwidd

  • Active Users
  • **
  • Posts: 1077
    • View Profile
    • Artstation
This is a general rule because of the way blending operations work (adding color values, subtracting them, etc). I don't think there is a way to overcome this.

It's probably a good idea if I prepare an example - just for the sake of illustration - but frankly the discussion starts and stops with what you've said here^. Namely, what is being asked for just isn't possible because of the way image compositing works.

Regarding the workaround:

Code: [Select]
Save post settings in a CONF file > reset tone mapping > compose in PS > save to EXR > open in CIE > apply CONF file
I think this workflow is just too circuitous, although it does resolve the feature request. Corona Renderer, as it pertains to tonemapping, seems to be moving toward an omnibus solution that enables users to do look development entirely in the renderer - echoes of Ludvik's suggestion(?) - and so I would have some concern that adopting a workflow like that, just to be able to address shadows in a single render element, is sort of a step in the wrong direction(?)

Regardless of whether that is true, the workflow you described seems to be the only realizable solution for now.

2020-10-17, 01:22:51
Reply #10

cjwidd

  • Active Users
  • **
  • Posts: 1077
    • View Profile
    • Artstation
I *keep* coming back to this issue and I feel I have to propound that a more generous shadows pass is needed - I cannot be the only user of Corona Renderer that needs flexible control over shadows in post.

I acknowledge the workflow that has been described above, but it really comes down to the indirect lighting and the unresolvable noise. It is only a minutia of cases in which there is *only* direct lighting in the scene, so I would think it would make sense to address the shadows pass to support that lighting information *EVEN IF* it would require linear workflow compositing.

2022-12-22, 20:17:29
Reply #11

actrask

  • Active Users
  • **
  • Posts: 142
    • View Profile
    • actrask.com
I'm getting the same problem with the Cshading_Shadows render element.

For instance, where are all the shadows under the desks?

2022-12-22, 20:18:31
Reply #12

cjwidd

  • Active Users
  • **
  • Posts: 1077
    • View Profile
    • Artstation
What's up homie :D

2022-12-23, 02:41:19
Reply #13

actrask

  • Active Users
  • **
  • Posts: 142
    • View Profile
    • actrask.com
haha what's up man funny to see you around these parts

So I think I figured it out, seems the Cshading_Shadows render element isn't very helpful. You need to use the ShadowCatcherMtl material on the objects you only want to see shadows on and save out that masked rgb pass

edit; to help with comping, set highlight compression to 999 and adjust the contrast to 4-5
« Last Edit: 2022-12-23, 02:45:54 by actrask »