Unexpected shadows' behaviour

[Caterina]

Hi everybody!
I'm having some troubles with shadows on my scene...

I have a scene with a labyrint, a car and some objects that the car can collect while moving (boxes and coins).

There is a point light that moves around the scene (the sun), and two spot lights that moves with the car (car lights). Working just with the shadow generator for the sun, I noticed that

• If I use PBRMaterial for my meshes, I cannot see any shadow (and changes in light's position neither, actually). Now I'm using only StandardMaterial, but I'd like to switch to PBR to have a more realistic effect
• Boxes project their shadow also on the back side of the walls (as shown in picture).
• There are problems if a mesh both receives and creates shadows

I've created a simplified version of the scene, where there is the problem of the shadow on the back of walls, at http://www.babylonjs-playground.com/#M8O41

In the picture there is a screen of my scene with the "multiple" shadows (light's position is the same of the sphere in the right corner).

I'm sure I'm doing something wrong, but I have no idea of what... Can anyone help me?
Thank you and sorry for my bad english

 

[GameMonetize]

Shadows are not computing occlusion this is why you can see the shadows even behind the wall.

Regarding PBR, @Sebavan will soon be able to reply:)

[Sebavan]

Hello,

Here is a working example including PBR for the plane:

http://www.babylonjs-playground.com/#M8O41#1

[Wingnut]

*scratch scratch*  I'm confused.  http://www.babylonjs-playground.com/#M8O41#3

When the sun-sphere/pointLight comes near the camera, having a shadow on the camera-facing side of that wall... is normal/correct?

That just don't make no sense.  The box is not between the light and the wall... when the light is near the camera.  hmm.

#2 issue... should the sphere be changing lighting... as it travels?  The sphere (sun) and the pointLight are parented together.  Their relationship should not change as they travel on the X-axis, or ANY axis, one would think.

I'm having one of those days when everything I touch... breaks... so... I could easily be wrong about these two issues, too. 

[Caterina]

14 hours ago, Sebavan said:

Hello,

Here is a working example including PBR for the plane:

http://www.babylonjs-playground.com/#M8O41#1

Thank you, now this part works perfectly!

15 hours ago, Deltakosh said:

Shadows are not computing occlusion this is why you can see the shadows even behind the wall.

I didn't know anything about occlusion, thank you! Now I have something to work on

12 hours ago, Wingnut said:

*scratch scratch*  I'm confused.  http://www.babylonjs-playground.com/#M8O41#3

When the sun-sphere/pointLight comes near the camera, having a shadow on the camera-facing side of that wall... is normal/correct?

That just don't make no sense.  The box is not between the light and the wall... when the light is near the camera.  hmm.

I'm sorry, but I don't understand what to you mean with "near the camera"... the final effect seemed quite realistic to me, except for the shadows on all the walls' faces, but probably I'm missing something!

12 hours ago, Wingnut said:

#2 issue... should the sphere be changing lighting... as it travels?  The sphere (sun) and the pointLight are parented together.  Their relationship should not change as they travel on the X-axis, or ANY axis, one would think.

Actually the sphere won't be visible in the final scene, I'm just using it to see where the light is; so I haven't noticed the sphere lighting...

Thank you all for your answers!

[GameMonetize]

Quote

When the sun-sphere/pointLight comes near the camera, having a shadow on the camera-facing side of that wall... is normal/correct?

It is not "normal" but expected (due to the maths used in the shader)

[Wingnut]

Thanks.  hmm.  I'm having a difficult time with this.  I think something is wrong.

http://www.babylonjs-playground.com/#M8O41#6

Ok, much simpler PG.  No shadows, one pointLight inside the sun sphere.  Basic.

Can someone explain WHY the light is acting like a spotLight with a lockedTarget?  Why is the lighting on the sphere... not consistent? 

Why is the sphere lighting... "rocking" left/right?  It's a pointLight... gives light equally in all directions.  hmm.  The wireframe should be lit evenly, and not change "look" when sphere.position changes (I think).

*scratch*  It acts like the pointLight has a direction, and lockedTarget.  (did I say that already?)    Weird.  Just weird.  Perhaps I've gone insane.

Sorry to temporarily hijack your thread, Caterina.  I'll get back on-subject soon. 

If we must, we will build some walls with 6 separate planes. In the morning light, we'll set receiveShadows on the sunny-side plane (of the six planes).  In the afternoon, we'll switch receiveShadows to the opposite side.  Or perhaps, we will use a directionalLight and continuously set (in renderLoop) its direction to aim-at 0, 0, 0 as it passes from horizon to horizon.  We will solve this challenge somehow.

[GameMonetize]

The white spot you see is the specular. It depends on three values: light position, object position and viewer position. 

 

[Wingnut]

But but but...

http://www.babylonjs-playground.com/#M8O41#7

Ok, now... light specular = black, sphere material specColor = black.  Still, I see photons rocking back and forth, like sphere is 1/3 filled with milk.  Not supposed to do that, right?  Light is parented to sphere... and it's a point light... all directions equally, yes?

But I could be forgetting something, yet again. 

If we change sun-sphere to BABYLON.Mesh.SINGLESIDE (line 7)... then the whole issue (the moving milk) goes to the TOP of the sphere. 

Me still thinks sphere should be lit evenly, and not change it's shading as light/sphere moves along axis.

You guys jury-rigged something... to get the Sponza pointLight shadows working correctly, didn't ya?  Bet so.  Ya went in there all boozed-up and ya soldered some things together wrong, eh?  *nod*    You needed to "aim" a pointLight, even though a pointLight has no direction, right?  Yuh, yuh, yuh.  Duct tape and clothes pins.  heh 

(Wingy being goofy again)   (maybe) 

[Wingnut]

Ok, check THIS out... 

http://www.babylonjs-playground.com/#M8O41#10

Added a high "ceiling"...  box2... material'd, and placed it above pointLight/sun-sphere.

Position.y = 20 units.  (line 50)   Light affects TOP of new box2, but no light striking bottom of box2.  Now change to...

Position.y = 30 units.  (change line 50)   No light affecting top or bottom of box2.  Now change to...

Position.y = 40 units.  (change line 50)   Light affecting bottom of box2, but no light striking top.

And look at the angle of the lighting on box2... relative to 0, 0, 0.  This is a pointLight... with direction (even though line 21 says "nah") 

I think I am going to get all "boozed-up", now.  heh.  *scratch scratch*

[GameMonetize]

Ok I get it

this is because the light is INSIDE the sphere. this is not supported by babylon.js

[Wingnut]

  You don't expect me to swallow that, do you?  heh

http://www.babylonjs-playground.com/#M8O41#11

THAT's how it is supposed to look.

The issue... is with parenting.  This new playground is prepared to test 3 conditions:

1. Current condition... neither sphere nor light are parents.  RenderLoop animates both.  All looks great.
2. Sphere.parent = light0  (OP line 16, NOP line 27).  Sphere travel-range is much wider than light0 travel-range.  Milk-slosh seen on sphere shading.

Now return to default scene (no parents), then...

3. Light0.parent = sphere  (OP line 15, NOP line 28)  Opposite.  Light0 travel-range is much wider than sphere travel-range.  Milk-slosh seen on sphere shading.

@Dad72 and I talked about this subject... long ago.  At first, he couldn't understand WHY a light would EVER need to be a mesh.parent. I was able to convince him that it would be used for parenting a gizmo to a light, so a programmer could "see" where the light was positioned.  Although we eventually agreed about the use-case, neither of us pursued the issue any further.  No PR's, no further discussions with Deltakosh, we just let it drop on the floor (and on the ceiling). 

Programmers will add a sphere as a (temporary) pointLight gizmo... quite often... in BJS's future (imho).  They will also use box gizmos for directionalLights and hemi's, and cone gizmos for spotLights.  Likely, parenting will be used often... for those things.   Notice... no parenting used in our lights playground demo.

Perhaps lights are not family-minded.  They don't like their parents, and never want to BE parents.    Changes needed?  Thoughts?

[Dad72]

For a gizmo of lights I use cones that functioned. But also working with a PointLight has inside the sphere. 
If It does not work there is definitely a bug I guess. Or the bug was before when it was operating like this (light inside the mesh)

I use this to create a gizmo that has always run. but I did not stay for a while if it still works. Babylon but does support this normally.

var LightPoint = [], parentLightPoint = [];
var matObjectLight = new BABYLON.StandardMaterial("MaterialLight1", scene);
matObjectLight.diffuseColor = BABYLON.Color3.Black();
matObjectLight.specularColor = BABYLON.Color3.Black();
matObjectLight.ambientColor = BABYLON.Color3.Black();
matObjectLight.emissiveColor = new BABYLON.Color3(0.95, 0.91, 0.1);
matObjectLight.alpha = 1.0;

var haloLightTexture = new BABYLON.StandardMaterial("MaterialLight2", scene);
haloLightTexture.diffuseColor = BABYLON.Color3.Black();
haloLightTexture.specularColor = BABYLON.Color3.Black();
haloLightTexture.ambientColor = BABYLON.Color3.Black();
haloLightTexture.emissiveColor = new BABYLON.Color3(0.95, 0.91, 0.1);
haloLightTexture.alpha = 0.2;

var PositionLumiere = scene.activeCamera.getFrontPosition(15);
var countLightPoint = LightPoint.length;
//## Gizmo
parentLightPoint[countLightPoint] = BABYLON.Mesh.CreateSphere("LightPoint"+countLightPoint+"Gizmo", 25, 1.0, scene);
parentLightPoint[countLightPoint].isPickable = true;
parentLightPoint[countLightPoint].material = matObjectLight;
var haloLight = BABYLON.Mesh.CreateSphere(countLightPoint, 25, 2.0, scene);
haloLight.isPickable = false;
haloLight.material = haloLightTexture;
haloLight.parent = parentLightPoint[countLightPoint];
//#####
LightPoint[countLightPoint] = new BABYLON.PointLight("LightPoint"+countLightPoint, new BABYLON.Vector3(0, -1, 0), scene);
LightPoint[countLightPoint].diffuse = new BABYLON.Color3(0.8, 0.8, 0.8);
LightPoint[countLightPoint].specular = new BABYLON.Color3(0.68, 0.68, 0.68);
LightPoint[countLightPoint].parent = parentLightPoint[countLightPoint];
LightPoint[countLightPoint].parent.position = PositionLumiere;
LightPoint[countLightPoint].position = PositionLumiere;

 

[GameMonetize]

I see no problem when not sharing position  (you forgot to clone sphere.position):

 

http://www.babylonjs-playground.com/#M8O41#13

[Wingnut]

Wow.  You're a God, DK!  Unreal.  That would have taken me 150 years to solve.  Thanks Deltakosh.  BOTH parenting options work, now.  Holy crap!

It actually wasn't me that created that line, but I never would have thought... phew.  (Wingy falls to the floor with brain spasms.) 

Ok, back to Caterina's issues.  (sorry for the temporary thread hijacking, Caterina.)

http://www.babylonjs-playground.com/#M8O41#20

I believe that the rotating box shadow should not be seen on the sunny-side of the wall.

Can we remove the box shadow from the sunny-side (the non-box side) of the wall? 

The sunny-side of the wall... must still receive shadows from the cone.

The wall must still receive rotating box shadows on the OTHER side (when the sun is on the right side). 

Any ideas, friends?  thx.