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?
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!
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…
