Remove .shadowDarkness?

[mrdoob]

@MasterJames points out this issue in #7319:

http://jsfiddle.net/xsgebh0b/5/

Of course, this is a matter of setting shadowDarkness to 1 (instead of 0.5).

Which makes me think that we probably should remove shadowDarkness and simplify things. However, I notice that the shadow is 100% black even if the scene has an AmbientLight of 0x404040 and makes me think that the shadow step is in the wrong step.

[Usnul]

I'm not sure i agree. I use fairly light shadows in my work (0.6 or less) because they are pretty wrong to begin with and when you set darkness to high it stands out too much.

[WestLangley]

What @Usnul said.

At least until the time at which the shadowing methodology is replaced.

For now, I prefer this pattern:

light.shadowDarkness = 0.5 * light.intensity;

[mrdoob]

How about we move...

#ifdef METAL

    outgoingLight += diffuseColor.rgb * ( totalDiffuseLight + totalAmbientLight ) * specular + totalSpecularLight + totalEmissiveLight;

#else

    outgoingLight += diffuseColor.rgb * ( totalDiffuseLight + totalAmbientLight ) + totalSpecularLight + totalEmissiveLight;

#endif

out of lights_phong_fragment?

Then, we make shadowmap_fragment output only shadowMask.

And we create a new compose_phong_fragment with this:

#ifdef METAL

    outgoingLight += diffuseColor.rgb * ( totalDiffuseLight * shadowMask + totalAmbientLight ) * specular + totalSpecularLight + totalEmissiveLight;

#else

    outgoingLight += diffuseColor.rgb * ( totalDiffuseLight * shadowMask + totalAmbientLight ) + totalSpecularLight + totalEmissiveLight;

#endif

And we put this chunk after shadowmap_fragment.

I know this isn't the final solution but I think it could be a step in the right direction? At least we solve ambient light and emissive... I think specular wouldn't be correct though, that formula doesn't make sense...

Maybe it should be...

#ifdef METAL

    outgoingLight += ( diffuseColor.rgb * ( totalDiffuseLight + totalAmbientLight ) * specular + totalSpecularLight ) * shadowMask + totalEmissiveLight;

#else

    outgoingLight += ( diffuseColor.rgb * ( totalDiffuseLight + totalAmbientLight ) + totalSpecularLight ) * shadowMask + totalEmissiveLight;

#endif

But then we lose ambient light again...

[mrdoob]

Also... maybe we should remove shadowmap out of MeshBasicMaterial?

[mrdoob]

I'm not sure i agree. I use fairly light shadows in my work (0.6 or less) because they are pretty wrong to begin with and when you set darkness to high it stands out too much.

The idea is to replace shadowDarkness with THREE.AmbientLight.

[Usnul]

do you think it will work with this example?
http://threejs.org/examples/#webgl_shadowmap_viewer

other than that, i think sometimes you may want to have stark contrast in shading of a material because due to direct light but still want to tone down the shadows, in which case ambient light will be pretty low while desiring shadowDarkness to be low also.

[mrdoob]

other than that, i think sometimes you may want to have stark contrast in shading of a material because due to direct light but still want to tone down the shadows, in which case ambient light will be pretty low while desiring shadowDarkness to be low also.

But this is hacky and not like light works...

[mrdoob]

Ok. So, as far as I understand the proper solution would be to merge shadowmap_fragment into lights_phong_fragment. The reason shadowmap_fragment was done like that probably was so we can reuse the same code with MeshLambertMaterial and MeshBasicMaterial. The compromise is that we get shadows that work in all materials but are just black masks...

/cc @tschw @mkkellogg

[Usnul]

it is hacky and not like the light works, but it is a good way to cover up hacks like shadow maps :D
If we want a true representation of how light works, we need better shadows that you'd not be ashamed to bring home and introduce to your parents or we need path tracing. Low-res shadows and various artifacts differ in their impact case-by-case, and impact is subjective in each instance, so as much as I agree that it's a hack - i don't think there's a one right solution here. Just one opinion of a bow tie wearing cat.

[mrdoob]

@Usnul I'm trying to achieve #6420.

[RemusMar]

@Usnul I'm trying to achieve #6420.

Ricardo, that's probably the best way to go on.
cheers

[mrdoob]

Hmm... If we want to have nice shadows, I think we may need to remove shadow support in MeshLambertMaterial and MeshBasicMaterial...

[RemusMar]

If we want to have nice shadows, I think we may need to remove shadow support in MeshLambertMaterial and MeshBasicMaterial...

In the real world the shadows have nothing to do with materials.
They depend on geometry (meshes) only.
A cube of stone / wood / metal will cast the same shadow.
cheers

[Usnul]

@RemusMar
I'm not sure we're thinking in the same key. A cube of wood would have softer shadows than a cube of metal because of how light will interact with edge for each material. If we take into account light penetration it gets even more tricky. I'm sure you're aware of that, just wanted to make sure materials aren't dismissed out of hand.

[RemusMar]

A cube of wood would have softer shadows than a cube of metal because of how light will interact with edge for each material.

Don't mix them up.
They will have the same shadow.
Same geometry does not mean different edges.
cheers

[Usnul]

@RemusMar light warps around the edges of geometry in real life depending on material. Beyond this, both umbra and penumbra can have different brightness based on glossiness of back surface.

[RemusMar]

light warps around the edges of geometry in real life depending on material.

Come on ...
I'm not talking about reflections, refractions and other "goodies".
An opaque mesh will cast the same shadow independent to its material.
Just test by yourself in a shiny day ... LOL

On the top of that: we don't need a THREE.js bloated with all kind of worthless features.
cheers

[mrdoob]

In the real world the shadows have nothing to do with materials.
They depend on geometry (meshes) only.
A cube of stone / wood / metal will cast the same shadow.

MeshBasicMaterial and MeshLambertMaterial can't be compared to real world materials.

[RemusMar]

MeshBasicMaterial and MeshLambertMaterial can't be compared to real world materials.

In fact I was trying to help you in the above posts.

I think we may need to remove shadow support in MeshLambertMaterial and MeshBasicMaterial

Yes.
Make the shadows independent on material (except those with alpha channel, obviously).

[mrdoob]

Fixed!

http://jsfiddle.net/6rpjjh5r/

Sorry guys, but shadowDarkness is gone, use AmbientLight instead. shadowDarkness at 0.5 is actually the one making the shadow acne more obvious than it should.

It's still not as good as #6420 but should be a step in the right direction (and it works in all materials).

[mrdoob]

Before and after:

[WestLangley]

How about showing the three.js revision on the Editor GUI?

[mrdoob]

How about showing the three.js revision on the Editor GUI?

Good idea!

[mrdoob]

Hmm... I guess this also solves the backside shadow bug!

[mrdoob]

Before...

After...

Adding another light source still shows the backface issue though.

@WestLangley I wonder if instead of shadowMask we can compute a color to be negated. Would that be too nightmare-ish? I guess the only benefit of doing thins would be that we would still support MeshLambertMaterial.

[WestLangley]

@mrdoob

I also wonder if something like this would be beneficial?

shadowMask *= vec3( 1.0 - shadow * shadowDarkness );

[tschw]

OT: Wow! Editor with shadows 👍

[mrdoob]

I also wonder if something like this would be beneficial?

shadowMask *= vec3( 1.0 - shadow * shadowDarkness );

Hmm... I guess we can still keep shadowDarkness until the final solution.

[mrdoob]

OT: Wow! Editor with shadows 👍

😊

[MasterJames]

praise ≡ ∃Ƨ☤@я¶ {
    dɹɐᴉƨǝ(Ɩ);
}

[autotel]

Hi! sorry for waking up the death.

I just wanted to suggest that many lights emiting shadows will render unrealistic results in a scene that has an ambient light:
When there are two light sources and two shadows overlap, you will get a darker shadow than when a shadow is not overlapping.
I think the mixture is not additive, nor sustractive, but rather a weighted average according to each light's intensity. ShadowDarkness is a misleading variable...

[mrdoob]

@autotel probably better to do a render with Blender or something :)

[autotel]

Yup. I understand. Is like after that we will start thinking about caustic effects and stuff; a bit out of browser's scope. Often this place is used for feature requests, but in this case I just wanted to point out that possibility.
Thanks for keeping up with three btw. Awesome lib!