forum-boundarysrf.gh (41.0 KB)
Boundary Surface is somehow projected to construction plane. Is it because the edge curve loops are in different planes? I expect the surfaces to be created where there are up in space…
Confirmed in R5. Really bizarre! I have no clue… This is wrong.
Ack! Yeah, ok, I get that but still. Bizarre and wrong.
Test with other curves it work fine
We don’t know what is the problem with internalized curves
It works as expected when the polylines are replaced by circles. The original post demonstrates a bug.
forum-boundarysrf_2019Sep25a.gh (44.0 KB)
P.S. This version keeps the circles in the same planes as the original polylines:
forum-boundarysrf_2019Sep25b.gh (53.3 KB)
1 Like
Further proves my point that if boundary curve loops are in different planes, the component fails.
Graft puts them on “individual cases” where there is only one plane, i.e. its own.
What do you mean? The GH files I posted use the same internalized curves as the original from @Will_Wang. I created a new file because the color preview settings in Will’s file were not showing surfaces at all for some reason. The behavior is the same in both.
Just to note that this is “standard” Rhino behavior - the component Boundary curves does essentially what Surface>From Planar curves does… Note the “Planar” part… If the boundary curves are not planar in Rhino, then they are projected to the active CPlane. The planarity criteria is pretty strict, depending on how the RhinoCommon method is called. If there is no tolerance argument passed, it uses some very tiny value IIRC…
I replied to Will_Wang, i don’t see your file
yet in his case, the boundary curves are in different planes and seem to work ok
Each of the polylines in this case is planar. I suspect that internally, circles (and polygons) retain their reference plane while arbitrary planar polylines don’t?
forum-boundarysrf_2019Sep25c.gh (118.9 KB)
Just another of the many quirks in GH, I guess. As usual, we just have to deal with it.
They do though. Here if I reference planar polylines made in Rhino they all form unprojected surfaces in their “native” plane. That’s why I suspect that the curves might be “slightly” out of planarity…
Early on, I tested for plnarity using Planar. All returned “True”:
Yep. But that what I’m trying to (poorly) explain - there are different criteria for planar in Rhino - not all functions use the same tolerance. Some use file tolerance, some use the built-in “zero tolerance”… I know this because I run into this with both scripts as well as normal Rhino commands.
What you can try - I don’t have time now - is to get the plane and re-project the input curves to that and then run that output into the boundary component. If that fixes it, my theory is correct. If not, then I’m out in left field… 
I thought of that too; no joy this way:
Due to the sloped portion, there are actually four different planes here, two in each branch. Not so easy to isolate those for projection from the curves given, but I’m not sure it would make any difference. GH has many rough edges like this… We cope with work arounds.
Dunno, tried something like that here too - each branch has 1250 closed planar curves that have one of two planar orientations - four different planes in total… Still works…
Having downloaded the original .gh above, I note if I disconnect the internalized curve component then reconnect it to the boundary surface component, i see this in the Rhino command line:
If I bake the curve component to extract the original curves and I run Rhino’s native PlanarSrf on the baked result, I get this message:
And PlanarSrf projects everything to the active CPlane.
If back up and run SelSelfIntersectCrvs (my own script, Rhino now has a native function as well) on the baked curves I get 4 results:
If I eliminate those, PlanarSrf then works “in-place”, and I’m sure the GH boundary surface component will as well… So it’s not a GH problem, it’s an input geometry problem. 
1 Like