Fillet fails examples 2023-03 - hammering collection

This fillets are really annoying.would be nice to have a solution form the software without the need of manual workaround.
Not to be redundant but this is easily solved in parametric software.

1 Like

This is a great example. It’s one of the biggest reasons Rhino fails imo. Rhino just doesn’t realize it can delete faces or move the edge or something lol – or add coplanar face…etc.

I’ll be relentlessly reflecting on this over time, and any others I can think of.

This is a great example too, one that’s been on my mind. I’ll share similar stuff in the future.

I played with this file a little bit, and I’m really surprised how bad Rhino is at the fullnose radius

wow :man_facepalming:t4:

I was messing with file tolerance and almost got it to work:

Yeah, I can’t get it to work. I had no idea it was this bad lol

1 Like

Changing tolerances in the middle of modeling is a great way to cause problems with edges not matching and similar.

An absolute tolerance of 2.0 is an almost certain method of causing assorted problems, including with edges.


I’m thoroughly aware of that probability.

But when Rhino fails to fillet even the most simple task, I think it warrants a little adjustment to tolerance – even if it’s “in the middle of modeling”.

I also tried building the model from scratch after tolerance instances changes.

I’m thoroughly aware of that. I’ve been around the barbeque since 2004.

@davidcockey Why does Rhino fail to fillet the most simple task regardless of tolerance?

Notice how the changes to the tolerance almost got it to work? – probably nothing tho right?

That’s why I was changing it :tipping_hand_man:t4:

I thought, “oh maybe it’s having a hard time doing it ‘exactly’”. And it almost worked I thought.

lol. I’m good. I’ll change it when I want. :imp:

Or can lead to some operations succeeding – like joining edges to become ‘closed’.

Tolerance is relative. If I get a file from a client and the model has errors under a tolerance of 0.0001", but it will close @ 0.0005", I’ll be changing the tolerance mid-build if I want to move forward with said relativity. :beers:

Probably true, unless the operation isn’t working cause there isn’t enough tolerance, then the user can decide to do so if they want. That’s probably why the option is there.

I made a tool pallet specifically for doing so in V5, maybe I should share it with you ta ruffle some feathers :joy:

I should rename it ‘mid-build tolerance toggle’:


I literally made that pallet in like 2011 or so, for a client as per their request.

They’ve been asking me to do it again recently – they’re not very good about managing their pallets.

So, it’s been on my mind – I’ll probably make a new version for V7 soon. :smiling_face:

If Rhino fails to successfully fillet the most basic full-nose-radius geometry regardless of a dozen different tolerance combinations, then the problem isn’t the ‘tolerance changes mid build’.

‘Tolerance’ should be a ‘threshold’ that Rhino can use to deviate various transformations.

I was merely changing tolerance as an experiment to see if it was related.

Now I know, Rhino probably isn’t failing due to tolerance strictness. It’s failing due to something else. :white_check_mark:

180 degree edge

surfaces near the edge (additional…)

see also further up

1 Like

here is another nice example, where _filletEdge fails

done manual with _filletSrf…
(and a few tricks to use _filletEdge for most of the stuff…)

clamp_2023.3dm (5.1 MB)

… it was the original Idea of this topic just to collect examples…

1 Like

Another nice example of filletEdge fails

1 Like

I think that’s a good thing, but at some point these issues should be distilled down to the principle causalities that lead to these failures.

These examples seem to becoming redundant.

I’m pretty sure there’s a list somewhere that explicates what’s causing every single failure.

The developers probably have a list by now, I’d imagine. Right?

Probably one of the main reasons ‘filletsrf’ doesn’t fail when ‘filletedge’ does, is due to lack of trimming requisites.

‘filletedge’ fails alot due to adjacent edges to the edges being filleted.

(You could probably split an edge, within a ‘filletedge’, with an adjacent edge, upto any successful ‘filletedge’, and that ‘filletedge’ would fail.) :tipping_hand_man:t4:

So, with that well-known causality, what code is missing in Rhino that would overcome said causality?

Maybe there’s a pattern throughout Rhino with other commands. This issue sounds similar:

even if there is already a lot of work above…
I will keep collecting:

Variable fillet on Polysurface

  • my guess, this example also shows some weakness of the current algorithms:

with a tricky setup (left, splitAtTangent = No, mergeSrf) FilletEdge can do the variable fillet, with a standard polysurface (right) not:

fillet edge setting:


fillet_fail_Stecker_00.3dm (3.6 MB)

Background … Detail of this power-plug

kind regards -tom


Thanks. I have added this to the list of existing fillet edge issues.
Please understand that this will take time to fix, where hopefully we can do something for v9.


… take the time needed… great to know somebody is working on it.


see also post above


:joy: :sob: :sob: :sob: don’t worry Rhino still like ya :smiling_face_with_three_hearts:

Hope we get Rhino to fillet better someday. :sweat_smile:

That looks like a good thread, imma check it out. :beers: