BrepJoin component not behaving correctly Rhino6 GH1

forum-surfaces.gh (24.9 KB)

In this file if I bake from the BrepJoin component I get a naked edge.
But if I explode it in Rhino and rejoin in Rhino I get a good interior edge.

Bug?

I think this is a tolerance issue.

If I take a script component and use the RhinoCommon method, depending on the tolerance value I set I get a naked edge, and interior edge or even 2 separate breps…

forum-surfaces.gh (21.6 KB)

I thought the same but it seems that GH takes Rhino’s tolerance. But how does it produce different results?

OK, now I get your point…

Anyways, looks like a Rhino 6 problem to me, I only have Rhino 5 and it works as expected…

With my standard tolerance settings I get the same results both in GH and Rhino (2 breps or failure to join), if I increase the tolerance i get one brep with “good” interior edges also both in GH and Rhino.

I’ve encountered this problem for several years when making parts for 3D printing. Since the input for a 3D printer is an STL file, naked edges are strictly verboten - because the slicing program that produces the printer control code has no idea how to deal with them.

This is a great example of the problem, and it tends to confirm my belief that the basic cause is tolerance - just as dsonntag noted. To verify this here’s a full-size image of the part with naked edges highlighted:

As you can see, the naked edges are exactly as Will described. To verify the naked edge really was there I made an extreme blowup of that edge:

The gap shows that the 2 sides of the part really do not coincide. Consequently the part is not “watertight” and cannot be 3D printed. I have no idea how other CAM type software might deal with it.

In the past what I’ve done to reduce the impact of this issue is to use Rhino’s Solid/Create Solid and Solid/Boolean two objects commands. Sometimes that approach actually works, but unfortunately not with this part.

The last bit of info I have is that when creating an STL file from the baked geometry I specify a tolerance of 0.02 mm. This is less than the smallest move my printer can make and it has always worked well - provided of course that the slicer program can complete its job of creating GCode for my printer.

I think the issue still warrants attention from dev team.
Under same tolerance, Rhino commands can execute better than GH. That seems an inconsistency I’d love to see eliminated.

1 Like