Both surfaces are degree three, with equal UV’s. The corners are coincident and it joins without a Naked Edge into a valid polysurface. I’m not sure it matters, but the surfaces were created using Sweep2 with curves.

I know how to fillet this manually (which is slow going because I have a number of similar conditions on a larger model). Right now, I’m simply on a quest to better understand fillet failures. The file is included if you want to futz with it.

Hi Dave- not sure why yet, but these surfaces behave better of they are untrimmed and retrimmed (UntrimBorder, KeepTrimObjects=Yes, then retrim with thr resulting curves, Join, FilletEdge.) Are these built in Rhino or imported?

Although you can’t see it, there is a tiny extra edge at the top where the surfaces are joined. I’m not sure why Check doesn’t report it, As Pascal suggests, retrimming fixes the problem. It would be great to know how the edge got there. I can’t recreate the problem using sweep. Can you remake this and get the same problem? If so, please let us know exactly how to do it.

There is a new test command called testRemoveAllNakedMicroLoops in the sr8 release candidate. It may have made it into sr7, I don’t have a copy of sr7t handy to check… You can also fix you model by calling that. Since it is a test command, you have to type it out completely.

Pascal and Chuck: Many thanks for the feedback. (You do know it’s a weekend, right!?!?!)

Yes, Pascal’s method works. Thanks!!! Chuck, did you find the tiny edge using the TestRemoveNakedMicroLoops command, or some other way? (btw: WinRhino sr7 does not support this test command, nor does the current version of MacRhino. Downloading sr8 now for WinRhino and will try it and get back to you if it does not work as described).

Unfortunately, I can’t recreate the problem that caused this problem using Sweep2 methods, but here are a few recalled details of how I originally constructed this: The piece shown is a segment of a larger piece constructed in MacRhino. The Sweep2 curves were extracted from larger surfaces (using DuplicateEdge and InterpcrvOnSrf with snaps used). Curiously, one of the three curved rails shows up as six curve segments (which you may have noticed). Huh? Something in the process caused this to happen, since the curve definitely was not created as six segments. Not sure if this matters, but thought I would mention it.

Some questions:

Curve Segments: In situations where a continuous curve is desired from segments, I’ve noticed that Join does not create one curve, but rather a polycurve with multiple segments (and one has to “What” the Joined curves to determine this). While I understand this behavior it is not desired, since generally one wants one curve; not segments. The only method I know of in Rhino to “fuse” all the segments together is to Join them, then Rebuild the curve. Is there a better way?

{would love to insert a carriage return here in a list with indents remaining!}

(On a philosophical note, some might reasonably conclude that the term “Join” is misleading in Rhino. Intuitively, Join implies a type of “fusion” into a larger whole, which exploding alone can not undo—one must cut apart the result since the physical state has changed (as in welding or gluing in the real world). In Rhino, if the result of any action creates a “Poly-Anything”, the words “Combine” or “Assemble” seem more appropriate and less confusing).

Curve vs Surface Edge: When building mating surfaces (using Sweep2, and other methods) one gets the choice after the first surface is built to either use the Curve or the Surface edge. (Intuitively, the surface edge seems a better option to ensure watertight conditions, but inquiring minds, and all that…) Does it matter which is picked?

Micro-Edges?: Possibly related to the mysterious generation of micro-edges, a long-standing frustration (perhaps due to my ignorance) is that it seems very difficult (impossible?) to determine if curve segments “actually” have coincident control points, even though they may appear continuous. And if I hazard a guess, I “think” these segments can even be joined if not coincident (but within tolerances), and even rebuilt into one curve. Either of which may generate micro-edges? Just a guess here…

{would love to insert a carriage return here in a list with indents remaining!}

What is very much desired is the ability to select only one curve for any conditions where segments appear continuous. Then issue a command (something like “Select Adjoining” or “Select Continuous”)—this would then only select curves with genuine coincident control points. By visually seeing a break in the selected curves, this would allow one to correct any conditions where a curve appeared continuous, but the control points were actually not. (This problem seems to happen more often than you might think while working in Rhino, for reasons, I don’t fully understand. Then again, I work with some pretty odd geometry and might be all thumbs!).

Consider this a kind of “Naked Edge” test, not for surfaces, but for curves. I’ve seen this function in PowerCADD and it’s a life-saver. Is there such a thing in Rhino? If not, I submit this as a very strongly desired Feature Request since it might help with this micro-edge problem and a number of other related errors, such as filleting issues.

Curve vs Surface Edge: When building mating surfaces (using Sweep2, and other methods) one gets the choice after the first surface is built to either use the Curve or the Surface edge. (Intuitively, the surface edge seems a better option to ensure watertight conditions, but inquiring minds, and all that…) Does it matter which is picked?

Sweep2 and others can offer different levels of continuity to adjacent surfaces (see the Sweep 2 dialog) but only of the surface edges are picked as input- ‘free’ curves do not know anything about the surfaces they may be near.

Yes! SelChain does indeed help. Since I’ve only seen Chain as a surface kind of option in the past, I never thought to try it on curves. Should have asked this years ago!

I note that the Position option needs to be selected for SelChain to work as desired. The tooltip under Edit > Select Objects > Chain says: “Select curves or edges which touch end-to-end.” Sounds great! However, in practice, the default behavior (unless I changed it somewhere along the line) is Tangent, which causes SelChain to fail if this option is not noticed (or not understood by a new user). An easy improvement would be to make Position the default behavior if it’s not already.

One distinct weakness here is if a segment is selected, then SelChain is executed. It fails. The command only works if nothing is selected when SelChain is executed. Any way to improve this in the future so it works when a segment is already selected? (MacRhino users in particular will appreciate this since they are more used to selecting objects, then choosing actions).

While SelChain helps significantly, it is not a complete solution to the problem at hand. Below is an image of curves that appear to be continuous all the way around when using this command; however, it is actually an open curve. If Rhino could identify where the curve was open, this would be the Holy Grail. A sort of Naked Curves option, that showed the gap location where I’ve circled it, would be a large benefit. Especially useful if the gap is a micro edge.

This situation illustrates a larger and more common complaint that I hear from many new Rhino users: “Death by Options”. As experienced users know, these options are often what make Rhino very powerful, but simultaneously, this can also make Rhino a little baffling to new users, and sometimes frightening them off to another friendlier, but less powerful program.

Two things might help Rhino become a little more friendly, yet maintain its power:

A) Drawing inspiration from Rhino’s existing Mesh command, minimal and commonly used options could be the default, with more advanced options available as Detailed Controls (Win) or the Disclosure Triangle (Mac).

B) A “radio button” to restore the defaults for each command would be great. This would encourage experimentation without getting lost if things go awry when changing multiple variables.