First of all thanks to the developers. I have tried some surface tools and fillets in Rhino6 and I am very impressed. For me it is a great step forward that must be fully recognised and appreciated! But I have to agree as well.
It would of course be very desirable, if the fillets would work much more robust.
For example: if I would like to bring a bigger round on a edge / corner, that has already a smaller round. In this case the (solid) fillet command should be able to trim, match and join automatically as shown in the PDF: Rhino6-fillet-improvement.pdf (1.8 MB)
Look at that fillet!
The software of Autodesk, is called 123d, and is also free!!!
Surely the kernel will be used is Parasolid, thus fillet of its kind in Rhino will never see them, even in 20 years!
If rhino had inside an engine for generating fillet of this type would become one of the best CAD in circulation! Easy to use, comprehensive tools, and powerful!
Why Rhino fillet of this type often generate problems?
If you wanted to make a fillet of red border? If I choose a small radius Rhino manages to discreetly run it, but if I exaggerate, for example, by choosing a radius 2: nothing! fillet problem.3dm (162.0 KB)
(Look around here at 10:40):
Rhino is able to fillet such edge corners only if you select and adjust all edges in one row. In everyday situations this is not convenient. In many cases it can happen that you want to bring a bigger round on a edge / corner, that has already a smaller round. But this is not possible right now. It is a pity!
Especially because the FilletEdge already detects that the value is âtooâ big. This should lead to a Trim of the Intersecting TrimObjects like OffsetCurve (for example) does it already.
why FilletEdge fail to make the shown Filleting even with RailType options set to DistFromEdge,
if OffsetCrvOnSrf + Trim + BlendSrf is able to make it work?
Hi MTI - - yeah⌠this is BlendEdge, I guess and what it does not like here is that the radius of the existing vertical âfilletâ drops down to about 22 out in the middle, and the rails for the 29 blend cannot handle that - this works with a âtrueâ fillet, FilletEdge at 30 and 29.
Well, it is hard to make even a round section fillet wrap on an edge that has a smaller radius than the fillet radius - that leads to self-intersections, so, no, off hand I doubt that this one will work cleanly in V6.
I teach rhino to product design students. I donât know much about programming, but I know rhino already for a long time and I think I know what goes and I understand why some tools doesnât work in some situations and how to handle it anyway. But it is very laborious to explain every single student in each case, why it doesn´t work and how to make it manually. I experience that nowadays many students are impatient for such modelling issues. For them it is to cumbersome and they are not willing to fix that much.
And I guess that technically (theoretically) it is possible to develop a software solution for such cases?
Especially the FilletEdge / BlendEdge Command could be very powerfull tools for industrial designers, but therefor this commands have to deal with such corners automatically. To fix very often almost everything manually, because a FilletEdge / BlendEdge couldn´t run around one âtoo smallâ corner, is very often too much work and doesn´t seem to be most convenient in a working routine.
In my view, this is one of the most urgent imperfection in Rhino.
Attached some ideas.
what is it about the self-intersections? Related to the FilletEdge / BlendEdge Problems I attache a screen capture to this post that shows the self-intersection problem with the OffsetCrvOnSrf command, but not with the OffsetCrv command?
(unfortunately Rhino 5, Rhino 6 currently not at hand)
many greetings
Yeah, Offset does some cleaning up at the corners to avoid the reversed loops. OffsetDrvOnSrf does a rather different thing - it extends offsets to the edges of the surface. In the case you show it is not the most useful tool, to be sure.