Tolerance problem? naked edges when joining surfaces


I have a brep composed of a few surfaces (mainly a loft and some network surfaces). I have issues joining the surfaces, resulting in internal naked edges:

The curves that generate the surfaces are the same (with some shattering/exploding for subdividing them), so I would assume that the output surfaces should join fine.

I suspect that the problem might be related to the tolerance in Rhino, but I tried different values with no success.

Any suggestions or comments would be appreciated.

(sorry for messy GH definition, but I think it is important to include all operations from curves to final brep) (28.2 KB)

The problem appears to be in your network surfaces, which I didn’t analyze in detail. I by-passed them by joining curve fragments to create the planar curve shown in green, then lofted that with the circle (top Loft in yellow group). It’s not quite as nice as what you had but the naked edges disappear. (27.1 KB)

Thanks Joseph,

Your solution works, but as you pointed out the loft is not as “nice” as the network surfaces (+ I have some tangency control with the network surf.).

I am interested in knowing why the network surfaces are not working or why the methodology does not work, given the fact that the input surfaces are the same for both loft and network surfaces.


Are they? The loft uses two planar curves. I understand what you want but have an errand to run this morning and can’t get into it now, sorry.

P.S. Here is a quickie effort to implement tangents at both ends of the loft - gotta go! (35.1 KB)

1 Like

I like that trick for the loft tangency!

I redid the network surfaces with the following method:

NurbsSurface.CreateNetworkSurface Method (IEnumerable<Curve>, Int32, Double, Double, Double, Int32)

in a script, which allows to manually define the tolerances. If I set the edge tolerances at 0.00001 the surface join works well.

I am working with tolerances of 0.001 in Rhino (as default).

To be honest, I am not sure if this is the way to go… is this good practice? It feels like that you should not manually change the tolerances of your components to have a valid geometry?

1 Like

You do whatever it takes! :+1:

Here is an approach using EdgeSrf that works well. I thought it was absurdly complicated until I realized what it replaced! You can see the curves I used if you enable preview on ColorB. The ones you used (straight sides with curves top and bottom) might work as well or better but I wanted a fresh start. (31.4 KB)

This version implements that strategy, though most of the code is identical. (39.7 KB)

Thanks for your feedback and models (definitely need to work on my models’ tidiness! :sweat_smile: nice workflow)

Sorry for the late reply. I am still working on this trying to understand what works, and how the different input parameters and method affect the final output. Basically, I am observing a lock of robustness (i.e. slight modifications in input can make the geometry fail). Robustness is important because this will be part of an automated workflow.

Just wanted to comment if you have spotted that in your solution the surface is twisted around itself at the top and bottom surfaces? do you know why?