repro: https://playground.babylonjs.com/#11BH6Z#854
I understand animated off-screen meshes are not worth animating, but what if I really wanted to have them keep animating while off-screen (as in repro above) ? Would I have to jump thru a lot of hoops just to make it work for said animated mesh ? What if I had a whole bunch of animated meshes on and offscreen?
Just a genuine question, I’m curious about the overhead: including lighting, shadows, the whole shenanigans. Also, how should I go about detecting a mesh is off-screen ?
In this case, just flag as alwaysSelectAsActiveMesh and you should be good to go 
The overhead is mainly cpu but you want it anyway so I do not think that there will be a huge harm.
2 Likes
That’s great !
I did some tests: animated moving dude vs shadows
Against csm, the positioning and targeting of followCam makes it hard to get the right shadows to show vs the usual shadowGenerator class (line 27 toggle).
example from doc
For stationary meshes, there shadow artifacts when moving/zooming the default camera. I guess they stem from the shadowGenerator interacting with meshes becoming active/inactive. Its not a great viewing experience.
Guess I’ll stick with simply detecting a mesh is off-screen and notifying the user for now. On that note, is there an easy way to detect mesh is off-screen ? Or should I just validate against getActiveMeshes from scene ?
You could try to check _isActive on a mesh despite being hidden for now
1 Like
ok thanks! gonna hold off on this for a while, haven’t figured out what’s wrong with the animated dude and csm not showing. Something about the cascades in the spy cam is bothering me. hrmm…
Repro: https://playground.babylonjs.com/#11BH6Z#856
Not 100% sure, but I think this is a bug. Zoom in/out and the csm shadow in the minimap is affected by the zoom of the main camera. If you zoom in close, the shadow in the minimap disappears. Toggle line 27 and you can see that it doesn’t happen for the regular shadowGenerator.
Let s check if @Evgeni_Popov has some bandwith for this one as I have no clue what is happening at the moment
bump!
I’m speculating that csm is camera-centric and the cascades get fouled up for the RTT’s camera. A way forward is to exclude csm from the RTT’s camera and still allow a user to setup the regular shadow generator specific for the mini-map. Kinda like what we do for materials alr.
Can you please create an issue in the repo? I will not categorize it as a bug but more a limitation
We will improve that in the future if we capture the requirement in the repo