Yeah, good idea. Although a single edge can be convex in one place and concave in another.
Quicker for me to treat the deck edge the same as the bottom chine; radius filets on mid-section polyline curve, âSweep 1â surface on sheer rail intersected, split and mirrored by the âXZâ plane:
1 Like
Sure, but for all-convex or all-concave edges, that might be useful IMO
Or a point for convexity check might be assumed, say mid-domain-point âŚ
It would be good though to post these problems in Rhino, people are actually working on Fillets right now. This is an active area of development so failing cases are important.
1 Like
Filleting has been possible since the first days of grasshopper 1. There are plugins and a native Rhinocommon functionality called âRhino.Geometry.NurbsSurface.CreateRollingBallFilletâ .
However if you donât know how to fillet and you are missing other surface tools you will have a hard time in doing something useful with it. And even if you know how to make something useful out of it you might end up doing things much more complicated and time consuming as doing it manually.
That is what I was ending up in 90 % of all cases. Filleting is a post process of surface modelling and should also be threaded like it. So where is the problem in doing it with the native Rhino command, fixing it at spots of failure or bad outcome?
What you guys expect is that there is a everything fillet functionality just by selecting a edge, which is a bit wrong thinking in my opinion. Sure in Rhino you can select edges and let it calculate automated but at what cost? Sometimes it fails, sometimes cornerfillets look weird. Actually doing corner blends with triangular patches is more a bad compromise rather than good.
Anyway as David said its not up to him, because filleting is such a complex problem that I personally doubt there will ever be a universal algorithm for it.
On the other hand Catia already has a very good and solid filleting functionality which is scriptable (if you donât care about zebras) but in the end its up to the user to decide which filleting strategy he follows which breaks needed functionality down to filletblend, extending/extrapolating, (real) trimming, matching and blendingâŚ
So instead of building a universal algorithm, rhinocommon should be extended in a way that it allows to reproduce a manual approach, which requires functionality as mentioned above (and a user being capable of filleting shapes manually in order to understand the process for automatisation)
Tom, what do you mean by âmanual approachâ here ?
Thanks
hello tom,
basically i agree with your argumentation.
but i quit judging software development (especially grasshopper), before actually giving it a try. when i started off with gh, i very much focussed on its technical qualities or used it for boring repetitive tasks. meanwhile i changed my mind and sometimes even start grasshopper for a simple blendcurve. this may sound and in fact IS time consuming, but gives me enpugh design criteria to justify the additional time.
itâs simply so cool and effective to control the bulges and at the same time subcurve-nudging the original curvesâ endpoints by realtime playing with some sliders.
i neither dont expect grasshopper to spit out THE perfect plus watertight filleting solution for my next sophisicated and complex housing design challenge at the click of a button (after wiring for half a day), but i hope for and look forward to an interesting collection of tools to maybe discover new workflows or simply have fun using it for something i cannot imagine by now.
cheers,
roberto
âManualâ means to reproduce a modelling approach 1 to 1.:
-
create filletblend between two surfaces by an function such as RollingBallFillet (which is not the best since its a rational surface, which increase chances for matching issues later during the process)
-
extend (better extrapolate) fillet surface to the corners and then build the corner blends manually - extending may increase control point count, where extrapolation only moves them in extending direction proportionally.
-
chop of fillet surfaces to make a corner blend possible where (at best) every edge is flowing tangent to its corresponding neighbouring surface edges. This ensures that a corner surface can always be matched.
Better you have a functionality which does not make a face(trim) but rather lets the surface untrimmed by just pulling cvs back to the edge. I call this real trim and its based on extrapolation. Other cad has this function.
Rhinos automated fillet function produces triangular patches, which are difficult to match. so if your base surface has strong curvature you could measure a tangent deviation (âŚif you could measure it, there might be a reason you cant do this in Rhino ;)). However corner blends where 3 fillets meet are easy, but at some situation you have more than 3, which complicates it much more. There are multiple strategies, depending on the appearance of your base surfaces. -
blend and match, as said, for a situation with more than 3 fillets you need more than 1 surface.
Example (Corner where 3 fillets meet, so its rather easy):
1 Like
Donât get me wrong, Iâm not judging Grasshopper, I use it quite a lot. However my relation to it is different. Grasshopper is no replacement for modelling, it just makes automation quite easy. So whenever I need to make something repetitive I use it (at least if Iâm not coding and testing some fun stuff).
However this comes with a big disadvantage, missing surface tools and missing mouse input.
So using Grasshopper is always a compromise and finding a balance where it still is useful is quite important.
If you cannot achieve same quality as with manual modelling, its not feasible.
And if you achieve same quality you need to make sure that the overall time involved is still faster.
So if you need 3 days to create a script which fulfils all criteria, but a manual approach would have taken 2 hours, you made something wrongâŚ
Besides that, if you know how to make blend curves you always get a perfect outcome: So if you have two curves and you extend them to their intersection point, you draw a circle, trim them with circle and blend at the new endpoint. When blending both curves with constant factors you will get a perfect blend with very good curvature. If you donât like the curvature flow you need to accelerate your input curves a bit to get a better transition.
sorry, i should have been more precise here. i tried to explain how i changed my own attitude towards gh.
this sounds like a professional approach and i am sure âyou will get a perfect blend with very good curvatureâ - technically spoken. but in some cases it´s not really the technically perfect blend but something just slightly more âexpressiveâ that i am after. gh offers very intuitive tools for this.
have you ever tried to reproduce your âextend/circletrim/blendâ method in gh? just for fun - sounds like a trivial setup and could be saved as âblend templateâ âŚ
if it is possible to alter the input curves, i also like to use a combination of rhino history and gh occasionally.
btw: the blendcurve issue was just one (out of various) example(s) to explain my attitude towards grasshopper as a design vehicle. i´m not sure if and how this will work with (various) filleting, but i´m curious ⌠
Practically you donât draw that circle you just guess its intersection. instead you set the endpoints of a blend to that guess. The more often you do this, the better the guessing gets. In the end its 4 to 6 clicks depending if you are adjusting the factors or not. Its just completely impractical to make it in Grasshopper in my opinion. Besides that there is a history function for Rhino. In conjunction with command shortcuts for rhino, such as âtrâ for trim or âblâ for blend you are basically doing a lot of operations in 0.5 -4 seconds.
In comparison, in gh you need at least 3 seconds to reference data and another 3 to bake-> ending up in a minimum of 10 seconds for one draw. Not even talking about the concentration penalty when switching from viewport to gh canvas. And even if you match up speed, you do have a problem with not having the same tools available. Native Blend is much more diverse as GH/RC Blend.
However we always talk in different context about different tasks. I actually donât even use Rhino as my main cad tool. Its rather there to assist and automate. I do work in automotive design so I constantly deal with complex surfacing tasks, having mostly surfaces being double curved. So if you donât have much curvature involved and you basically do a lot in 2d, why not⌠In the end its up to yourself how to finish your work.
Thank you for the clear explanation.
I think Iâm using Rhino for different things from what you and Robert you it for,
but the things you say are very interesting anyway. 
Great ! 
If you want to do it correctly, you will get rid of the Mixed edge selector and instead split the mixed edge at the point of inflection so that the convex and concave parts can be selected independently.
That would be a different component. Something which allows you to split brep edges at given parameters.
Not if you want to do the filleting correctly.
Here is a simple example showing how FilletEdge fails if the convex and concave parts are treated as one edge but succeeds if the edge is split into separate concave and convex parts.
ConcaveConvex.3dm (49.7 KB)
FilletEdge is a failed algorithm. If you want yours to be successful do not copy what FilletEdge does.
Nooo. First you split the edges where you want to split them (not necessarily at convex transitions, wherever you want. Then you perform the filleting on those edges that need to be rounded. See? Much more flexible this way.
the component has âXâ, âCâ and âMâ outputs.
wouldnât âVâ, âCâ and âMâ (conVex, conCave, Mixed) be correct?
Maybe. Itâs a tricky one isnât it?