Shadow-casting Bug

In the referenced fiddle, shadows do not appear unless either (a) the shadow-caster is set to receive shadows, or (b) the render order is reversed.

sphere = new THREE.Mesh( geometry, material );
sphere.castShadow = true;
//sphere.receiveShadow = true; // un-comment to show shadow on plane <=========
scene.add( sphere );

var geometry2 = new THREE.PlaneGeometry( 100, 100 );
var plane = new THREE.Mesh( geometry2, material );
plane.rotation.x = - Math.PI / 2;
plane.position.set( 0, - 5, 0 );
plane.receiveShadow = true;
scene.add( plane );
//plane.renderOrder = - 1; // un-comment to show shadow on plane <=========


I discovered this when investigating #11387… Not sure if the issues are related.

  • Dev
  • r85
  • All of them
  • Chrome
  • Firefox
  • Internet Explorer
  • All of them
  • Windows
  • macOS
  • Linux
  • Android
  • iOS

Author: Fantashit

3 thoughts on “Shadow-casting Bug

  1. This issue can be simplified to the following:

    An object that receives shadows cannot share a material with an object that does not receive shadows.

    That is obvious if you understand how the #defines work.

    Thing is, .receiveShadow is a property of an object — but the property actually applies to the object’s material.

  2. Yes. I bumped into this issue when trying to remove skinning from Material.

    The main problem is that, at the moment, a material can only have one program. But depends of the object, that material may produce one program or another. So, at render time, we check if that material has already compiled a program and we use that one. It works most of the times, but it breaks when the material is used by different types of objects (Mesh vs SkinnedMesh) and/or objects with different parameters (.receiveShadow).

Comments are closed.