In theory yes, but in practice no.
At least.
It doesn’t even work right when you set up a skm to have 6 sockets that determine light coverage for rogue-like games most of the time.
And its generally due to meshes, the fact you cant really know unless you look for if they are transparent. The fact that foliage may or may not trace depending on wind, the fact that you have to trace all nearby lightsources increasing computational runtime costs, etc.
So the chanches of it working better than you defining a shaded area are kinda slim.
And/or depends on how the trace is conducted.
Btw, instead of “keeping track” you could just bake textures of the sun area based on the same mathematical infromation.
Write to RT > save the RT for use if in engine, or use the RT after generation.
Since its an RT, you can write one tree, place the next and write that progressively (the more you write the more it costs, so keep write calls batched as much as possible).
Once you are done writing the read cost is always neglegible, so you can perform operations off said texture.
A stoopid approach - because performance is a thing - would be to set up a live trace of the same behaviour while trees that cast shade are made to output a decal that’s only seen by a scene capture2d set to orthogonal and capturing only those items that compose the shadowing. (Rather than a dacal, a properly srtup niagara emitter?)
It could be useful if you set it to update only when update operations occur - say like player chops a tree.
Overall, get used to dealing with textures to store data since you can easily save it.
But do consider that even on avarage CPUs saving a straight up array of data with some tuples (loc v3 + radius, so a v4) is probably eons faster than it is for the Pc to write to texture.
so long as you don’t go looping over the saved array