I was thinking it would be that way, actually.
1 Like
I set camera.maxZ = 200 but it shows âShadow MaxZ = 10000.00â in the inspector 
Live demo at https://codepen.io/ycw/pen/RwNBRPV?editors=0010 (press âinspectâ to toggle inspector)
1 Like
Yes, when you update camera.maxZ it does not automatically update shadowMaxZ itself (it canât, camera.maxZ is not a property that CSM can monitor), but internally shadowMaxZ is taken into account only if it is >= camera.minZ and < camera.maxZ.
Note that if you set camera.maxZ before the CSM constructor, shadowMaxZ being initialized with camera.maxZ, it will get the right value.
You can of course set shadowMaxZ afterward, with sg1.shadowMaxZ = ...
1 Like
got it 
@Robin_McLaut and @Vinc3r, the question about coloring shadow and increasing shadow intensity to counteract the contribution of the environment map on shadows both share some of the same answer.
To start with the easy one, if we artificially increase the strength of our shadows in a PBR environment, we are no longer physically accurate. Our PBR lighting strives to follow what happens in the real world with direct and reflected light though we are limited by real time rendering so multiple bounces of a light ray are simulated by the environment map and global illumination wonât be able to shape shadows based on rays bouncing from nearby surfaces as in a ray tracer. But some lightening of the shadows in a scene based on the environment map should be expected.
For shadow color like you find in the real world, we need to take into account the color of the light and the color of the surfaces bouncing around the shadow. Again, we are limited my real time rendering in not being able to take all of that into account, so in a basic sense a shadow is the absence of light on a surface. It appears like a darker version of the albedo color of the surface the shadow is cast upon, but wonât take into account color bouncing from surrounding surfaces.
If we were to add a color into our base lighting calculations for shadow, we would be moving away from the blinn/phong and PBR models that we adhere to in our lighting calculations. In both of these cases, what we need is a way to create a custom lighting model so that we always have our baseline lighting available but also can create a more artistic or intentional deviation from our lighting models. This is where our Node Material Editor (NME) comes in.
Disclaimer: Right now NME will only replicate our standard shader as the PBR model was out of scope for the initial release, but top of the list for V2 is PBR in NME. But this is what you are looking for:
The Lights node comes with a float output that will generate a mask of the shadows cast upon the mesh and will allow you to use that to multiply a color into the shadows only. This is one way to handle it.
The other would be to completely take over the lighting and do something like derive your lighting from a texture or gradient. Consider this image:
The shadows in the skin shader are not black as in an absence of light, but rather are a color. We could set up a skin shader that samples a gradient and returns a color for each pixel based on the dot product of the surface normal and light direction and reference this gradient:
This is only one technique of many where you can control your lighting in a custom way. We will have some examples launching with the new release demos, but you can see where NME does provide a lot of power to control your lighting.
6 Likes
@Evgeni_Popov, ~ CSM awesome Thanks. Stand-Clapping.
1 Like
Nice explanations, thanks! I definitely have to play more with this NME (good timing, first Mystery Box tut is about that 
)
2 Likes
Thank you for that great explanation.
I wouldnât dig that deep like youâve explained with bouncing off light/reflection in shadows.
Iâm talking about achieving an art style with the color of the shadow. perfect example was in a question in a threejs forum about this topic
The picture this guy used for his example is exactly what Iâm looking for.
Is this something the NME will be able to do with the upcoming changes?
Yes you can get the shadow property out of a Light node and then colored it the way you want:
You can also leverage the ShadowOnlyMaterial which comes with a shadowColor option:
https://doc.babylonjs.com/extensions/shadowonly
3 Likes
Any chance that it will also work with PointLights one day ? Or is it technically impossible ? Maybe stupid question but I dont actually know how it works under the hood, thats why I ask 
1 Like
Itâs not technically impossible but it wonât never be done because it would mean doing 6 * num_cascades depth rendering!
It seems there are techniques to use less than 6 rendering per cascade, but really it is not worth the trouble. Point/spot lights are normally used for small areas and donât need CSM.
2 Likes
Oh I see, you are right, it would be huge amounts of rendering.
You can do something like this:
https://playground.babylonjs.com/#Y642I8
You can change the shadow color / strength in the inspector:
4 Likes
BABYLON.NodeMaterial.ParseFromSnippetAsync("V77XYQ#4": huge!
1 Like
Yes, it is very convenient!
Thankâs a lot! The NME is really sick
This all will come in really handy for upcoming projects. Excellent work youâre all doing - this is awesome!
2 Likes
yes, Iâm late to the party. Sorry =) Good work, @Evgeni_Popov !
So I need to ask if CSM support self-shadowing. iirc, during dev, we didnât look at this at all ?
PG: https://www.babylonjs-playground.com/#IIZ9UU#50
Comment out line 35 and artifacts will appear on the torus.
dynamic case: https://www.babylonjs-playground.com/#1R4XE8#4
Self-shadowing is automatically handled by the shadow map technic, thereâs nothing specific to CSM here.
To deal with it, you should tweak the bias and normal bias values, as for the regular shadow generator:
2 Likes
I keep forgetting I need to tweak, lol⌠I blame single-click raytraced shadowsâŚ
Thanks for the quick response @Evgeni_Popov