Getting to the root cause of naked micro edges

Continuing the discussion from Simple trim fails here:

Hi @Gijs,

I’ve been struggling to get a reproducible example of the trim issue. I’ve established that if I create the surface with naked micro edges I get a problem but if I can create the surface without them then I don’t. But how come a surface surface built from the same edge curves sometimes has them and sometimes doesn’t?

Here are examples of that:

Here are the edge curves - note that they seem to be identical to the document tolerance of 0.001:



However, dig deeper and the curves are not the same. Increase the display precision to six decimal places, and zoom in to a point we’re told not to bother with, and you start to see minute differences:

It would appear that these differences, three orders of magnitude smaller than the document tolerance, are somehow sufficient to introduce naked micro edges. And in this case, _RemoveAllNakedMicroEdges can’t.

As a complication to the investigation into this, if you move a curve in one model the 0.000001mm needed to make it the same as the other and subsequently undo the move, the curve does not necessarily return to its original position. In the final image above, the highlighted curve originally crossed the magenta curve at its end.

naked_edge_problem_hull 001_isBad.3dm (303.7 KB)
naked_edge_problem_hull 001_isGood.3dm (292.2 KB)


Hi Jeremy, while fiddling with the file, I managed to extract a reproducible case:
join_these.3dm (401.9 KB)

As for the naked edges, but also the above case, I’m quite certain that this is due to working with singularities. I recommend after making and matching these surfaces, to explicitly set the points to a single XYZ location with SetPt
Zebra at the singularity also is a good indicator (parallel view, zoomed):

After SetPt:

fixed_with_setpt.3dm (502.0 KB)

Nevertheless, I will make a report to see what can be done. I think Rhino should automatically setpt these singularities.

1 Like

There is nothing mysterious about what caused your geometry to go kaput. It is completely predictable.

Here is what happened:
You created the 3 sided patch with edgesrf and that command correctly made the singularity at a point that was the average of the endpoints of the edge curves even though the endpoints of the edge curves were off by a microscopic amount (about e-08). You then mirrored about the Y-axis. This means that you have two valid surfaces with their singularities about .000000001 mm apart because the singularity was not perfectly on the y-axis.

Then you started using Matchsrf.
When you matched the two surfaces for average tangency that ripped 2 of the control points out of the singularity of each surface. Then when you matched the other edge for curvature and that ripped another 3 points out of their proper location. While MatchSrf is moving control points for matching its also adding control points to meet the “Preserve other end” constraint. So now you have instead of a valid 3 sided surface with a singularity, you have a 4 sided surface with 3 good edges and a tiny microscopic edge. The 4th microscopic edge is composed of 6 control points scattered about.

This bug in Matchsrf has been brought to the attention of McNeel decades ago.
It makes no sense for Rhino to be pulling singularities apart in an attempt to match edges. It just produces garbage geometry while actually making the continuity between surfaces worse, not better.


It shouldn’t be ripping the singularity apart in the first place. That is the bug. The singularity should be treated as a single point by MatchSrf.

1 Like


Thanks for taking the time to write such a detailed and lucid post.


I agree, let me see if this bug is listed in the first place, otherwise I’ll add it.
RH-75308 MatchSrf incorrectly modifies singularity