I’m trying to trim a surface defined by a curve from Rhino. My initial idea was to create a box from a rectangle, that can be used as a cutting object. This needs to be a box, because i need to trim surfaces in multiple planes with the same cutting shape.
This setup does seem to work great with my first attempt. However, my second input curve doesn’t return a trimmed surface. Does this have something to do with how Grasshopper defines my curve geometry? Curve 1 is a ‘Closed Planar Curve’ while Curve 2 is a ‘Referenced Periodic Planar Curve’?
I hope some of you can help, or tell me how to improve my file. (Some of the components may seem unecessary, but it’s taken out of a bigger context.)
P.S. A funny thing happened on the way to the forum…
I was about to move a single BoundaryafterEntwine to serve both curves and accidentally discovered that GH default behavior turns planar curves into boundary surfaces automagically!
I tried your suggestion with Surface Split as well. It also worked for this single issue, but like Split Brep, it failed in other cases.
Your suggestion with Entwine and project seems interesting! I must admit, I haven’t really worked with Entwire before, so I might look into the file you have attached to learn a bit.
By the way, Srf SL is a cluster I wrote to return smallest and largest surfaces based on edge length, which is much faster than Area when there are many of them.
To be fair, I’m quite certain that SrfSplit works perfectly, and it’s me who mess up the structure in the file. @Joseph_Oster Maybe you can help me understand where I go wrong? I try to project 5 rectangles to each of the 8 surfaces, but I think this is where the problem is.
These “ribs” appear to be identical so you could have created just one and used polar array?
The list of extruded and capped “solid” cutters (now in a purple group) is in a logical, sorted sequence. The list of ‘Surfaces to trim’ is in a different, jumbled sequence that doesn’t match! You got away with it in the sold trim because of the way you grafted but I fixed it using Sort Along Curve in the yellow group.
I added Join after Edges so there is just one curve per notch.
I added PShift and graft in places as appropriate to match the data trees.
I replaced the last List Item with my Srf SL cluster to pick the largest surface.
It’s critical to understand and keep track of what’s happening at every single step. The code would be much smaller and simpler without the sorting and conversion from 3D to 2D cutters.
Thank you for your response, @Joseph_Oster ! There are two sets of ribs, shifting. But you’re right, I could probably have used polar array as well.
I still have some trouble understanding branches and data trees. I understand the logic but lose track of the structure quite easily. I will definitely investigate your file and learn some methods and components! I’m sure this won’t be the last time I run into trouble with branches and structure.
Hah, that’s an understatement. They are constantly the most important issue. I left a copy of my ‘Tree/List Viewer’ tool in the code. The other tool I use extensively is connecting text panels to component outputs so I can see the data tree structures at every step. Enjoy.
Oh, and as mentioned above, the code would be much smaller and simpler without the surface sorting and conversion from 3D to 2D cutters.
This version hides the surface sorting off screen, on the assumption that you can fix that elsewhere so sorting isn’t needed? I suspect the purple group that makes the cutters (rectangular curves) could be simpler too if the planes were created with proper orientation for 2D cutters instead of the original 3D. Notice that projecting the rectangles to planes isn’t needed at all, since they work fine just as they were created. Simpler code is better code.
