@PeterFotiadis Theeeere we are On the road again 
OK I’ll see what gives if I remove some sensitive parts of code and do Frankenstein stuff on that WA thingy.
That said the main millisecond issue is that this ugly Trim thingy doesn’t work (both ways i.e. with the trimming Brep either flipped or not, meaning that SDK says things that never happen) and thus one must take the long way home … and this costs some milliseconds (life sucks).
For instance (this is an abstract portion of WA - NOT for your case) imagine blue breps (buildings curvy or not) and (the wireframe) some freaky shadowVolume (don’t ask) .
This (very fast) is what happens if you Trim the blue things with the shadowVolume (not flipped) i.e. all the BrepFace portions that are outside the shadowVolume:
But for the inverse thing (inside) the Trim delivers the same result (no matter if the shadowVolume is flipped) and thus the long way home takes some time:
ok, back to point cloud than. Don’t know if that was what David did (can’t read this script 
), but how about that?
shadow_re.gh (13.7 KB)
I like it, but could be a faster.
Really? O.o
Took about 1 sec at my computer… Maybe because I did it in Rhino 6?
Maybe someone can translate this into a fastet version 
I nice solution would be to use a 3D Minkowski Sum (they call it ‘Glide’ below):
https://doc.cgal.org/latest/Minkowski_sum_3/index.html
to extrude your shadow-casting geometry along the sun’s angle and then trim this new volume to the ground and other collecting geometry.
I haven’t seen an implementation of this in GH though…
Cheers,
Steven
Hi David,
Is it possible to write the same code but instead of getting a pointcloud, get outlines/surfaces/meshes?
The issue with Mesh shadow is the lack of “casters” input.
Thanks
1 Like