I found a bug in the Boundary Surface component. The output surfaces are in a different order than the order of your input curves.
The funny thing is that if all of your curves have the same direction, this issue doesn’t occur. Also if you first graft the Boundary Surface input and then flatten the output it works, but that defies the parallel aspect of the component.
See attached image. The numbers in White are how the ordering should be, the Green numbers are from the first graft than flatten method. And the red numbers are what happens naturally with the component and as you can see they’re off.
Not a bug. The boundary surface component is not intended to keep order in a list.
A flat list input actually is assumed to be a set of curves that constitute one surface. To create a rectangle from four lines, you don’t want to keep three null results and guess at where the correct result will come out. You want one surface where four lines used to be. Take eight lines to draw two rectangles and you get two surfaces. The component doesn’t expect the cuves to be grouped. They can be in any random order. No real way to keep a consistent order of input curves in the result.
If creating one single surface from the set fails, the component gracefully tries to find other solutions of closed curve loops. But original curve ordering may be lost due to some neccessary reordering to find the first closed loop.
The Graft/Flatten or better yet Graft/PShift approach is the natural grasshopper way to keep your curves grouped (in your case the single curves in order)
If you’re converting individual curves into individual surfaces, you can just plug the curves directly into a Surface parameter. That’s a 1:1 conversion which retains ordering. It’s only if you expect that multiple curves end up being part of the same surface (either because they form a closed loop together, or because surfaces must have holes) that you need the Boundary Surfaces component.
See, that’s why I called it “dark magic” in the other post…
The underlying geometry type of Surface does not contain trimming. Grasshopper may or may not decide to convert the Type according to the context. Like feed a closed curve into a Surface input and it will be converted to a trimmed surface (if possible).
Feeding the trimmed boundary surface to a surface component doesn’t untrim, because, like @DavidRutten said, any curve input to a surface gets converted to a trimmed surface. This is good for most cases, as it “just works”.
Now for the C# component, we explicitly request a surface type for input. After whatever conversion in the input section, this is resolved to a Type, that cannot contain a trimming curve. We just pass that to the output and get the untrimmed surface.
“Surfaces” in Grasshopper have always supported trims. They are basically single-face-breps. This has caused some confusion because “surface” in RhinoCommon does only refer to untrimmed patches.
However the Rhino UI also calls single-face-breps “surfaces”, so this confusion was there all along.
Yup, sadly RhinoCommon does not contain a type specifically for single-face-breps. You either get a surface which does not support trims or you get a brep which may support many faces. The BrepFace type cannot exist on its own, it needs to be part of a brep structure, but if your script needs to deal with trimming data then your type hint must be Brep.
I guess, that’s the case where I stumbled upon the problem back then. Probably tired to streamline some GH definition by inserting custom C# components and by literally translating the definition lost the trims.
Thanks David, I should have known the boundary surface takes multiple curves into account for possible surface creation (and therefore retaining list order becomes unattainable). I’ll try the surface component.
Best,
Arie
