Shadow Pass with .0001 intensity lights works better! #25566

New Issue

ben u · 2011-01-09T22:49:59+01:00

ben u commented

2011-01-09 22:49:59 +01:00

Relates to: #25524

%%%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: http://vimeo.com/18589305

This is a followup on a less specific bug post that has since been closed: http://projects.blender.org/tracker/index.php?func=detail&aid=25524&group_id=9&atid=498
Other conversations have been held recently at blenderartists: http:*blenderartists.org/forum/showthread.php?t=206440 and http:*blenderartists.org/forum/showthread.php?t=206226%%%

**Relates to**: #25524 %%%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: http://vimeo.com/18589305 This is a followup on a less specific bug post that has since been closed: http://projects.blender.org/tracker/index.php?func=detail&aid=25524&group_id=9&atid=498 Other conversations have been held recently at blenderartists: http:*blenderartists.org/forum/showthread.php?t=206440 and http:*blenderartists.org/forum/showthread.php?t=206226%%%

ben u commented

2011-01-09 22:49:59 +01:00

Changed status to: 'Open'

Ton Roosendaal commented

2011-01-10 16:26:45 +01:00

%%%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.%%%

%%%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 commented

2011-01-10 16:26:45 +01:00

Changed status from 'Open' to: 'Archived'

Ton Roosendaal closed this issue

2011-01-10 16:26:45 +01:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Shadow Pass with .0001 intensity lights works better! #25566