Minor Bug in List Order for Boundary Surface Creation

I found some odd behavior for the list order after creating boundary surfaces from a list of curves. As far as I can tell, none of the input curves are overlapping or inside of each other and all are closed. Since the boundary surface component can create trimmed surfaces with holes from multiple input curves, it’s not entirely unexpected that the list order is different. However, I would have thought that if all of the curves are independent of each other (no nested curves inside inside another curves boundary, no overlapping curves, etc.), that the list order of the resulting surfaces would be the same as the list order of the input curves.

This can be solved with simply grafting the input so that each original curve is on it’s own branch, so this is a very minor issue, but it is a bit unexpected. Any idea why this might be happening? Is there something weird about the input curves that would cause this to happen that I could check for beforehand?

Boundary_Surface_Bug.gh (25.3 KB)

Boundary Surfaces cares not for your ordering. It will reorder the input in order to speed up inclusion testing.

If you plug your curves directly into a surface parameter, you’ll get a 1:1 conversion into boundaries.

Thanks! I never knew you could plug a curve into a surface parameter. I know that parameters attempt to convert one data type into another (e.g. number to integer) but I never thought it would convert closed curves into surfaces. I’ve been using boundary surface for this sort of thing (and probably making a lot of errors in list order that I never noticed) since probably explicit history!

1 Like

Hmmm, this is not good.

I just run into this issue and it drove me mad. I made a boundary surface from a list of rectangles, and I couldn’t tell where the error was… Until I finally found that the boundary surface component was messing up my list order. Pretty annoying.

Maybe boundary surface is trying to do too much in one single component? I just wanted my closed curves to become surfaces…

I knew about the surface parameter work-around but sometimes it is not ideal…