FilletEdge appears to work for this producing the same fillet for both objects unless I’m going crazy. What is it you expect to happen here? Do you want some of the new faces to merge?
I tried this model when you first posted it and FilletSrf in the WIP seemed to work more elegantly albeit maxing out around a fillet radius of 10 instead of the 15 you want. Now I’m getting strange results. I opened this issue for you.
Maybe @chuck can chime in why these Fillets are difficult
thanks for having a look at this.
to get the fancy result (in mac os Version 7 (7.27.23032.13002, 2023-02-01)) it is really important to click close to the dot s …
and yes i expect a revolve-like surface - also in the file - edit the post above
I do not get a nice result in Rhino-mac, V7 (see edit)
I think it would be nice, or might avoid some errors, if filletEdge would look at a version of the brep, where the coplanarfaces are merged. - without changing the typology / facedesign of the original brep - just to get the fillets rails / trims / …
Hidden in the abstract art is the correct answer, which isn’t quite as nice as the revolved surface. The other stuff is an added bonus. I guess you’d rather not have it there, and I’ll figure out what’s going wrong. If you just delete it, you’ll be left with this.
as long as you don t tag this topic with “AI”…
… but the algorithm somehow generates points far beyond anything that makes sense, no change to have some kind of test to stop it doing this ?
some kind of simple boundingbox - check at the end of the algorithm… ?
follow by some conditional clean up ?
or some user interaction … (which part do you want to keep ?)
Yeah, it shouldn’t be hard to figure out that this mess doesn’t belong. The problem is due to the edge on the left having the same radius as the fillet, which shoots rapidly up the side.
if i would have studied geometry / mathematic instead of design i would head for a paper:
“traces of spheres in foggy circumstances”. (but maybe this is more a novel…)
for fillets i always imagine a path of a sphere movement…
and as soon as the radius / curvature of the target surface is (nearly) the same (“foggy”) the trajectory should be more careful, more stable, have more inertia…
same for “pointy” fillets - that should and in one point.
sometimes i think, rhinos problematic fillets are also linked to problems of intersect, offset-Surface and Pull…
this is a nice unsolved issue:
there was another crazy example.
(Edit - i found it:)
The problem with Rhino’s pointy fillets and pull and intersect commands is that when there is a plethora of possible solutions Rhino picks the worst one instead of the best.
The best solution of course is not the solution best for Rhino developers but the one is best for the user. In other words, its not the solution that the developer can claim is correct (in this case all the possible solutions are correct), it is the solution that doesn’t sabotage the users efforts to create a sound 3d model.
So when Rhino’s Intersect command is generating a set of points that will be used to create an output curve and the algorithm arrives at an area where both surfaces are tangent (i.e. have the same surface normal direction) it should not dive for the nearest boundary. That strategy may be the easy way out for the developer, but is disastrous for the user. What the algorithm should do is pick that next point that is closest to being in a straight line with the last 2 points the algorithm generated.
The same thing applies for the pointy fillets. The problem with pointy fillets just like the intersect command is that when it gets close enough to an edge it gets sucked to that edge instead of proceeding in the direction closest to which it is currently going. If any edge is going to be involved in the algorithm then it should only be at the point where the edge of both surfaces are closest.
as soon as there is another surface close to the edge and is part of the fillet - but not part of the edge.
rhino s filletEdge Fails…
even if the the Surface is part of the
workaround of course is
or - if possible (like here) build a single surface / split at tangents = no.
see also here
noFillet_close_to_edge.3dm (4.9 MB)
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.
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
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
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
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.
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.
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
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.
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.
see also further up
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…
Another nice example of filletEdge fails
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.)
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: