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 ?
No fix yet… just a name-labeled playground… assists in bringing helpers up-to-speed… quicker.
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.
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.
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 !
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).
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…
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?
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.
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…
Trying to get the frustum visualized with lines in PG: https://www.babylonjs-playground.com/#5KP7IL#1 (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.
