Hi All,
Once again, I am playing around with the compositor to see how far it has come with 2.5.
But I am still stuck at the basic task of extracting the shadow pass. Blender does not seem to be able to do this correctly.
Can someone look at my scene and tell me why the cube shows up in my shadow pass and the shadows show up in my composite even though I have turned on “remove” shadow from composite?
Thanks!
25_shadow_pass_problem.blend (548 KB)
HI,
Had a look at your blend file and I notice that the Plane when I load it into the most recent version of Blender seems to have a material that is set to show environment (if you look at the render material preview, it shows as a graduated blue to white, of the sky color). That would mean the plane at least would not catch a shadow. No matter what I tried altering the settings of the mat for the plane seemed to make no difference. I did find that changing the material type from surface to halo and then back to surface fixed that issue though. After doing that everything seemed to work as normal for me. Though again I am using the most recent svn version of blender and it could just be a weird issue with my version.
I have attached 2 pictures showing a before and after and the altered blend file in case it helps any.
Also not sure if this help but the way shadow passes are dealt with in recent svn version of Blender changes because it had a bug, so maybe that could be why.
25_shadow_pass_problem_altered.blend (527 KB)
Also atom if you find that the issue goes away when you toggle between surface and halo modes of material display, would you mind reporting it as a bug with the blend file of your attached, bet they would be interested in getting that fixed.
Interesting. I disabled “Shadows Only” for the floor material and it worked fine:
Shadow passes in Blender have been tricky for me in the past, though I’ve always found a way to pull off what I needed. But I’m afraid I can’t tell if this is a bug or a feature…
It may be usable if I matte the alpha from the above with it. But it is not really fine.
Consider the shadow image. It displays a shadow on the floor and a shadow on the cube. Both are black. But to see the real problem, change the shadow color of the lamp to something obvious like “RED”. ReRender. You will notice that only the floor shadow changes to red. The dark face of the cube remains black. So we think, oh we have to turn on transparent shadow for the cube as well. I try that and the face remains black while the floor remains red.
Also, the alpha is not being outputted for the shadow pass.
Using r33371.
As I understand it, a shadow pass doesn’t output an alpha outline for the shadow – that’s what the “Shadows Only” option does for a material. A shadow pass generates an image that you composite (with a multiply blend mode, for instance, where white is everything without shadow, black would be full shadow). I agree that the darkness where there is alpha around the plane is a little annoying. I think it would be better if that were white, so you only had darkness where shadow is cast. Not sure why they do it that way…
As for the shadow ON the cube, I think I see what you’re talking about. I think you’d call that diffuse shading, not shadow. To demonstrate, turn off casts shadows for your lamp and you’ll see that the cube is still shaded dark on the side opposite the lamp. But the cast shadow on the ground has disappeared. That’s because the darkness on the cube is caused by the shading settings (under the Diffuse and Shading options). Give it an emit value of 1 and you won’t have any shading. So it seems like the shadow pass shouldn’t cast any darkness on the cube because it isn’t actually receiving a shadow…
So I’m with you now, Atom, and I’m wondering if this might be something akin to a bug…
Yeah! I’m also for bug!
Maybe not a bug technically, but definitely something that is just not right.
It is really annoying and makes certain compositing tasks a PITA.
I did some poking around the bug tracker and couldn’t find anything about this, so I just submitted it:
http://projects.blender.org/tracker/?func=detail&aid=25524&group_id=9&atid=498
Please add comments/clarifications there if you like!
Followup: Ton closed the above bug submission with the following comment: “What you mix up is diffuse shading - which only evaluates light when a normal points to the light sours - and shadow. Shadow is based on occlusion of faces, the backside of spheres or objects are not shadow, thats just diffuse shaders at work.”
Despite my immense respect for Ton, I’m still a little puzzled. So I’m going to break this down into smaller bits of puzzlement instead of one big “shadow passes don’t make sense to me” comment. If you’re interested in this (sebastian, perhaps?) take a look at the thread I just started and help me determine if it should be submitted as a bug:
http://blenderartists.org/forum/showthread.php?t=206440&p=1769560
@benu: A specific light setup (6-lights) is not really a solution for me. See my comment in your follow up link. It really still is a bug.
Especially when we look at output from a “professional” program like Cinema 4D:
This is correct output:
Now look at Blender’s output: (Incorrect)
If what Ton says is correct, why is the face of the cube included in the shadow pass at all? Shouldn’t it have been removed if it was only being shaded…? Also the alpha is being rendered in the wrong color. Alpha should be rendered as white (i.e. not shadow) not black. (as we see in the upper corners)
I’m with you, Atom. But as I’m not a coder, I have to convince the coders (Ton, in this case) that this is something to change. I think the example in the followup post makes a decent case, so hopefully that will help. At any rate, I’m glad to have a workaround in the meantime.
I’m just uploading a video that demonstrates the problem of the shadow pass. Maybe we can convince Ton to change it! 
Edit: actually this should have gone to the other thread… 
Here’s the link:
http://vimeo.com/18589305
Perhaps Ton interprets being in shadow as not just the shadow that falls off the shape, but also the part of the object itself in shadow, as the basic definition of ‘being in full/partial shadow’ is not being directly lit by the lightsource.
As I’ve never had a problem with the shadow pass being this way, I wonder if there could be an option to make the shadow pass calculated the way C4D does it (and perhaps expanding the shadow pass options to allow for multiple shadow passes from different light groups.).
I said it could be made an option because changing how the shadow pass works to what it considered the standard could break compositing setups for some scenes that currently use the pass as is (which may include the ones in Sintel)
I know it’s an old thread, but just wanted to add my support to having this looked at, again. AFAIK the new receive shadow options don’t really help much, and if as Ton said, the unshaded diffuse areas are different to shadows technically, it would make great sense to not include them in the shadow pass, or exclude them when the exclude render pass option is used, or an option for both.
I’m thinking this will probably drive the Mango team nuts, so maybe this will be fixed up soon…
I doubt it will be fixed. Rather we will (hopefully) have a decent shadowpass in Cycles. Solving that bug in Blender Internal would mean to rewrite the whole shadow pass thing, and that is not going to happen, since the focus will be on the new renderengine Cycles.
