Page MenuHome

Shadow Pass with .0001 intensity lights works better!
Closed, ArchivedPublic


Relates to: T25524

When generating a shadow pass, if you add 6 spot lamps -- intensity 0.001, non-shadow-casting -- at orthographic points (top, bottom, left, right, front, back) the results of the shadow pass are drastically different (and, in my opinion, *better*) than it is without the 6 lamps. See attached image for an example of how the shadow pass changes (though the main image doesn't change at all, or not enough to be discernible).

**IN THE ATTACHED BLEND*** render the current scene, which will return the shadow pass to the render window. Notice how it only shows shadows that have been cast by other surfaces (including surfaces on the same mesh, as with suzanne's ears and nose). Then turn off the renderability of the "DummyLamps" group and rerender. This is how the shadow pass is typically returned. The shadow details, especially on suzanne's face, are lost due to the "self-casting" shadow (presumably caused by the normals facing away from the only active lamp in the scene, similar to how a diffuse shader behaves).

For compositing purposes, the shadow pass with the six-lamp hack is much more useful, especially when compositing with real-world objects.

Fellow blenderer Sebastian König seems to agree with me on this (though we rely on Ton to make the decision; this is our second attempt to sway him!), and has posted a 5-minute video demonstrating the issue when compositing over real footage:

This is a followup on a less specific bug post that has since been closed:
Other conversations have been held recently at blenderartists: and

Event Timeline

Look; I'm not ignoring that there are design issues in Blender, but I prefer to spend most of my time on crucial fixes first.
There is a lot of 2.5 stuff that doesn't work yet - and which was meant to be coded.

The bug tracker is also not for reporting issues with Blender that fail to satisfy expectations, there are plenty of other channels for this (like irc, mailing lists, and OK... twitter!).

The issue is simply this:
- when a normal is pointing away from a lamp, it doesn't check for shadow (since it won't get light). That saves render time :) But it could do this, and then return a shadow.
- the render system - with ray trace - is also too complicated to store reliable shadow information separately. Instead, the shadow factor is being retrieved by comparing the raw diffuse pass (without shadow) and the final diffuse part. The rule then applied is that shadow-pass x diffuse = final diffuse.

So... for regular 3d renders in environments that works fine. (assuming you use shadow pass to get finer control over shadow).
For sebastian's case it fails yes, he only wants casted shadows exclusively.

The problem then still is boundary cases on spheres or smooth surfaces... the terminator problem, where shadows are being found whilst diffuse says it's visible for light.

Anyway, in our developer maillist it was discussed too, Matt Ebb pointed at the limited use as well.
We might be able to solve it with a 'cast shadow' pass or so... but for this we have to dive in our shading pipeline, which I rather prevent to do now.

Lastly: Sebastian can always drop in #blendercoders irc for advice or reviews, or he can mail bf-committers too. Twitter and vimeo is fun, but not efficient really.

Ton Roosendaal (ton) changed the task status from Unknown Status to Archived.Jan 10 2011, 4:26 PM