There are two critical steps in my script where given closed planar input curve(s), I make a bounding surface and split it using the input curve(s). When I do this, I usually either want to only remove or extract the excess leftover bounding surface.
I have presented 6 cases here out of which I think I can state the following
case 1 & 2 - Index 0 will always be the surface that remains inside the input curve case 3 - Index 0 will always be the outer stencil that remains after splitting. case 6 - Index 0 will always be the outer stencil that remains after splitting. Also the other surfaces will be a reverse list of the input curves (the numbers near the vertices of the curves indicate their list order) case 4 & 5 - no observable pattern
Can I depend on this behavior? Is there any documentation of the surface split component that can help me understand why this happens? It would help a lot if I can depend on this. I am asking since I came across this while looking up how the component works -
No! In general, the sequence of surface fragments should never be relied on. Find another way.
I have some helpful clusters that sort by area, sum of edge lengths or Z height. All have âSmâ (Smallest), âLgâ (Largest) and âGsâ (Geometry Sorted) outputs but that alone isnât enough to correctly cull the fragments in your GH code.
As I type this, I wonder if the âSplitting curvesâ can be used? P.S. Answer is No.
Iâm tired of this and not having fun. I knew long ago that the sequence of surface split fragments was unpredictable. Thought the constraint of closed planar input curve(s) might make a difference but Iâm not finding it yet.
There are six copies of a SrfSplitCull cluster (yellow groups) in this file, all identical of course. Some complexity inside the cluster is probably not necessary (project to plane). I got desperate trying (and failing) to solve issues in R7 that disappeared when I switched to R8.
Thanks a lot for the many solutions, however I have to find a way where I can deterministically draw outputs from the input curves. Most checks require you to to do area/ centroid/ solid operations and these scale terribly when your input size increases to thousands.
By taking advantage of the constraint of closed co-planar input curve(s), I think I have been able to deterministically use Surface Split. Here are my obervations
Condition - The input curves must be Non-Nested, Closed, Co-Planar curves. Given this, you can draw 3 reliable cases
Case 1 There is a single curve and the bounding surface is exact -
Observations:
The surface s0 will be the surface which has c0 as its boundary. The number of extra fragments cannot be predicted.
Case 2 There is a single curve and the bounding surface is offset outside -
s0 will be the bounding surface with its hole corresponding to c0.
s1 will be the surface which has c0 as its boundary. The number of fragments formed here are always deterministic.
Case 3 There are many curves and the bounding surface is offset outside -
s0 will be the bounding surface with holes corresponding to c1,c2,âŚcn
s1=c1, s2=c2, s3=c3,âŚ
sn+1=c0 The number of fragments formed here are always deterministic.
By making use of these cases I am able to skip the time requirement that goes in checking the order.
I donât understand that. The code I posted yesterday doesnât use area or solid operations. We seem to be on different paths. I was going to congratulate you on posting a good âtest benchâ yesterday; six cases that demonstrate different scenarios that any solution must handle. But today you have a different set of test cases with elaborate explanations to read and âcompileâ.
Too much Iâm still reeling from my efforts yesterday. Not sure if you have moved the goal posts or not? I looked at your code but didnât try too hard to understand it.
The project to plane components were not necessary and have been removed. I also realized I had used flatten inside the cluster so refactored to avoid that:
Still donât know why R8 is required? Unfortunately, changes to avoid flatten donât work as well as I had hoped. I thought a single cluster could handle all six cases if the surfaces and curves are entwined, like this:
Apologies, I mentioned point in brep as a solid operation. In my experience whenever I have used it, it has scaled badly in performance for large number of inputs.
I wasnt looking for a solution that will fit for all of them, rather I was trying to see which cases can be predicted. In my follow-up post, I determined that there are 3 cases where you can accurately predict what the outcome of surface split is going to be. For example -
In both these cases, your cluster gives the exact same output order as what the surface split component is already giving me. Now since we know that this is the order that the surface split command outputs, we can skip the sorting step. What I am trying to do is understand these conditions so that I can make use of it to speed up my scripts.
Before I tried BrepInc(Point In Brep), I tried InCurves(Point in Curves), but it got lost in yesterdayâs confusion and desperation. I tried it again now and it works GREAT
As performance is a big issue, I decided to create a benchmark. This version has a âreplicateâ geometry feature (turquoise group) with a âreps_aproxâ Value List(blue group) that allows you to choose the approximate number of copies between 6 and 10000. The âreps_actualâ text panel shows the real number of copies, which is always a multiple of 6 (Case 1 through Case 6).
Ten thousand reps takes 16.4 seconds, of which 15 seconds is SrfSplit
See Profiler value below SrfSplitCull cluster (yellow group).
Internal to the cluster, I replaced Cull with Dispatch and added a âUâ output for âUnusedâ fragments. They use the transparent white preview color, which prevents coplanar interference with blue fragments inside the curves.
I donât see the six test cases? A problem with area centroid is that irregular surface fragments may have their area centroids outside of their surface. Thatâs why PopGeo was used instead.
It works in R8 
