CSM makes any gltf assets with metalness black

When I updated the three.js to r186 all the gltf assets with metalness turns black, when i disabled the csm i the blackening of gltf with metalness materials renders normally.

I’m not seeing that problem (in WebGPU at least). See this example.

there is no problem with WebGPU, only in WebGL, I completely removed the CSM and replaced it with the SunLight, its even better in performance than CSM

Yes, I noticed that increase in performance too.

Also, playing with SunLight and Sky also caused me to realize that the computation of Azimuth appears to be off by 180 and moving the wrong direction (e.g. an increase in Azimuth made the sun go left, rather than right). It appears that the original programmer made the reasonable assumption that north should be Z+, whereas the three.js camera uses a default of Z-. Hopefully, they will change the computation of Azimuth (or change the camera default - which is less likely).

[EDITED for clarity}
But, in the meantime, you can do a manual conversion so that the sun appears in the correct place by taking your desired Azimuth, reversing the value (e.g. -10 to 10) and adding 180 (10+180 = 190). If the number is greater than 180, subtract 360 (190 - 360 = -170, Enter that number as the Azimuth value (-170) and the sun should appear in the right place (-10).
[END EDIT]

Csm is more expensive than directional light but can cover large areas more efficiently, by chopping the view frustum into chunks (cascades) based on depth and using lower res shadow caps for the distant chunks.. but rendering each each “cascade” requires a rerender+mvp matrix update.

the sunlight looks far better and smoother than CSM, the CSM triggers the fan (while racing) but the sunlight, I don’t experience the fan issues.

Yup. DirectionalLight is probably a good choice here until you have larger draw distances. I think CSM (Cascaded shadow maps) are really most relevant when you need shadow coverage off toward the horizon. Most of what I see in your screenshot would be covered by the first cascade of a CSM anyway.. so a DirectionalLight ( the sun light ) is probably fine. Just something to keep in mind if you start doing much longer distance rendering.

I also tried the new SunLight (and, for WebGPU, SunLightNode) addons in my flight demo. It was faster than the old CSM (CSN in WebGPU). But, for some reason, I couldn’t get shadows quite as sharp as the ones in the three.js example. The pillar sizes and scenery dimensions seemed similar to what I was using, so I am not sure why.

I didn’t make the switch because the resulting frame rate on my program was still less than 60. So I stuck with my combination of DirectionalLight(s) and hand-made shadows.

But I think the Sky and SunLight addons are a big step in the right direction for programmers (and vibe coders) who use three.js to create open world programs.

I did a dynamic shadow scalng, depending on the camera height above ground mesh, raycasting every 2sec, as the camera height gets higher the far is multiplied by the height proportion, so the shadow is always crisp

Ohhh, ok I was actually unfamiliar with the SunLight addon. Yeah.. I guess that wraps DirectionalLight and gives it a nicer interface. That’s cool, because the interface to directionallight has always been a little hard to wrap your head around, with it’s .target object etc. It sort of acts like OrbitControls but not.

Yes that’s a good approach. Especially if you have enough movement in your scene to cover the transitions.