Shadows, receiving shadows vs point light


a) uncomment line 50, cloned sphere is now completely dark. Now comment line 46: cloned sphere is now showing the correct lighting. So it was in shadow previously, but where is the shadow coming from ?
b) reset the pg: now uncomment line 48 and 50. Ground and cloned sphere are now completely dark. By previous reasoning, both are in shadow but again where is the shadow coming from that is large enough to cover the ground as well ?
c) And why does the instanced sphere never cast a ashadow on the ground ?

what did I miss or is this wai ?

Hiya PL, good to see you again.

No fix yet… just a name-labeled playground… assists in bringing helpers up-to-speed… quicker. :slight_smile:

If you’d like to adjust your URL in initial post, and/or have me delete THIS comment… PM me… can do. Sometimes 0-reply questions get faster attention. Your call.

1 Like

You have generally to fine-tune the shadow zmin/zmax and bias values when dealing with shadows (which is a pain…).


Look for the //! added comments: I have changed the light shadowMinZ and shadowMaxZ as well as shadowGenerator.bias.

Regarding the instanced sphere not casting shadow: it seems the original mesh needs to cast shadow for the instanced meshes to also cast shadow. I have added sphereclone in the shadow caster list and it now works.


@Wingnut: hey, good to see you too ! PG looks cool, thanks !

@Evgeni_Popov: Thanks for all the fixes. I tried with a directional light instead and the behavior is extremely inconsistent comparatively. PG:

No need for bias or shadowMinZ/MaxZ and no need to add shadowcaster for sphereclone. I have a nagging feeling I’m missing smthg either way. I am going to mark your reply as the solution. Major thanks to everyone for helping, cheers !

1 Like

The behaviour is not really better (except for not having to put sphereclone in the shadow caster list).
Try to raise a little sphere1:



No more shadow under sphere1 and sphere2 should be partially in shadow because sphere1 is above sphere2 and the light direction is (0,-1,0).

Tweaking some parameters:
I don’t think you are missing anything, the thing is that setting shadows in a scene is a notorious difficult task (try to read some litterature about it, you will see it’s more or less a complete mess… That’s my conclusion, in any case).

Having CSM (Cascaded Shadow Mappping) would certainly help for some cases, but don’t expect to just set some lights, shadow casters / receivers and have everything working automatically: it won’t happen (even for big players like Unreal or Unity).


I agree to ‘a complete mess’. Coming from artist bg, I’m used to single button ray traced shadows. Shadow maps is a pita. My one-liner:

this.shadowGenerator = new BABYLON.ShadowGenerator(1024, this.light1);


Pushing to a 4k shadow map means low end devices get screwed.

I’m gonna go cry a little…

Yes it is a PITA and it is even worse in webgl where we have limited resources :slight_smile:
Anyway I tried to summarize here all the options you have:


Great resources!

In the Improving the projection matrix precision I would also add to try to maximize the value of minZ as the near plane position does impact the shadow precision quite a bit.


Sigh, not whining or anything but I’ve tried most of the options in the doc (short of writing my own shader). Started this thread cos I couldn’t get better shadows EXCEPT by pushing map res to 4096 which resulted in me trying out other lights and setups. see below pic:

Left is the oneliner as per previous post w/o the options but at 4096. Right is with all the options tweaked (bias, forcebackfaces, normalbias, minZ, maxZ, cleanbonematrixweight yada yada). My conclusion is that map res was the main contributing factor towards shadow quality. The options largely reduce artifacts. 4096 causes fps drop on lower end devices (tested on 8yr old win10 x64 laptop with 2 cores) which is not acceptable for my use case.

Can submit PR if it will allow me to use 1024 and give me the quality as of the right pic w/o a perf hit on low end devices. Tell me its not a webgl limitation and I can fix it. No shadow expert but I guess no harm trying…

Is your light a directional light? If yes, I think Cascaded Shadow Map would help a lot, but unfortunately it is not supported by Babylon yet.

If you have a PG we can try to have a look.

Also, it seems weird that you still have those jaggy edges if you are using some filtering (PCSS or something else).

pinging @sebavan :smiley:


Yes, I’m using a directional light. No filters were used, I thought the jaggy edges were inherent ? Even in the bjs doc, if you zoom in, there are also jagged edges.

I did a quick search on github, is the cascaded shadow map the one like this?

If so, I can port it over or adapt to bjs and get the PR up.

Yes that’s it.

Regarding the filters, I was speaking about the usePoissonSampling, useExponentialShadowMap, etc properties. Have you tried to enable one? It should normally help for the jagged edges.

nope, in the screenshots, no filters were used. I got all sorts of funkiness when I switched them on, so I turned them off and concentrated on getting the best quality w/o them first. .The ground does have bump map and its a fairly huge ground, about 100 by 60 (iirc) from the bounding box size. see: PBR texture splatting (up to 64 textures)

I think I will study and look to port the csm into bjs if @sebavan/@Deltakosh is fine with it.

Most definitely for me !!!

I wanted to look into it for 4.2 but hey if the community beats me to it, it is even better :slight_smile: and I ll focus on other topics no worries.


It will take a while, I have to study from scratch. Initial browse seems like the csm src from github doesn’t use the same mechanism as bjs, which heavily relies on RenderTargetTexture. Not a straightforward port…

This some good reads by following the links inside it as well: OpenGL Cascaded Shadow Maps – Make Games, Not War

This is what I would rely on for the implementation.


Trying to get the frustum visualized with lines in PG: (press z to activate) but the far lines do not show as a continuous rectangle. Anyone with a quick fix or alternative way? I need the visuals to show up so as to figure out if the algo for splitting the frustum is working later.

edit: nvm, added more lines in…seems like I can visualize the frustum enuff:

1 Like

I find that to be also a great resource: Tutorial 49: # Cascaded Shadow Mapping