Similar to this post: Culling parts of surfaces that overlap - Grasshopper , I want to trim overlapping surfaces. But in my case I have arranged the surfaces to determine what is in front (starting with 0) and what comes after that (1,2,3,…). SImilar to Illustrators “Subtract from shape area” I want to delete the overlapping area of the underlying shapes of each surface and in respect to each surface. Any ideas are welcome!
Problem.gh (10.2 KB)
Starts with eight surfaces but ends with only seven…? 
Yep, more clear in top view.
overlapping surfaces_2023Oct1a.gh (33.9 KB)
Top view:
P.S. Update: overlapping surfaces_2023Oct1b.gh (34.0 KB)
1 Like
Thanks. I’m going to implement this in my script, simplify it and give it a thought what to do with cylindrical Breps and how to handle move to origin better. Thanks again. Always very helpful.
Make2D.gh (50.0 KB)
Your Make2D.gh file looks like a significantly different problem, using solids instead of surfaces. Might have additional comments later… (why such complicated geometry?)
My limited experience with Make2D was not pleasant at all!
While the curve from Make 2D is good, I was amazed and disgusted by how incredibly difficult that component is to use
Wow, what a pain!! I finally found something here, which I adapted, but it wasn’t easy at all:
As to my earlier effort in this thread (version Oct1a), I’m not so sure it is correct. For one thing, there is no reason that extrusion distance should be driven by Series. I believe this version makes more sense, using ‘(numSrfs+1) * step’ instead:
overlapping surfaces_2023Oct1b.gh (34.0 KB)
Even so, there might be cases where it fails?
I typically work with solids in Rhino because using the standard Make2d function often results in a more labor-intensive process. However, my primary objective is just to import the geometry into Grasshopper. Once imported, the solids are deconstructed into surfaces. I must admit, for larger files, I’m concerned that loading the geometry alone might overwhelm Grasshopper on my machine. My ultimate aim is to find a method to produce closed curves during this process.
P.S. Thank you for the updated file; I had overlooked it earlier.
I must not understand Make2D because based on some experiments with your solid geometry, I am appalled and horrified all over again. 
Make2D_2023Oct1a.gh (46.3 KB)
Well, thats nice to hear 
. I hate it too.
Here is something that is amusing… The ‘POV angle’ slider (blue group) rotates the reference line around the origin to show that it works from all angles.
IVRay is used from 121 points on each face of the solids (after they pass through SUnion). The purple group creates a list of “obstacles without self” for each face. Any faces without intersecting rays are culled (green group) and then projected to the ‘POV plane’ (yellow group). Some of the projected faces overlap, which suggests they need the Oct1a version treatment.
Make2D_2023Oct1b.gh (73.9 KB) (replaced by version ‘Oct1c’ below, due to error)
Make2D_2023Oct1c.gh (75.7 KB) UPDATED
Amazing! I never understood why Make2D gets so tricky sometimes. I had issues with round objects in my version, but yours solved this problem too. Thanks a bunch!
Make2D should work like Project (to plane). Instead, it does a convoluted relocation of the projection to the origin, making it almost useless. Very poorly designed IMHO.
This version doesn’t change the algorithm, only the controls for the POV plane. Sliders for ‘Azimuth’, ‘Altitude’ and ‘Amplitude’ (distance) make it easy to move the POV plane anywhere, including above or below the geometry being projected.
Make2D_2023Oct2a.gh (77.2 KB)
The first slider in the ‘Tree/List Viewer’ group chooses between branches of projected geometry.
It is very tempting to integrate the Oct1a version with this one…