Can Filletting be available in grasshopper2?

Okay, so the Brep Edges component outputs three curves for your extruded wobbly shape (the bottom loop, the top loop, and the vertical seam) along with three indices. What steps do you take next? How will you determine that the second edge (index=1) is the one you actually wanted?

I ask because it sounds like it would be both very difficult and very labour intensive to have to come up with all this logic to specify edges each time you want to fillet. And it’ll be hard enough if the edges are nice. If they are not then you may have to figure out which edges together form closed loops.

I’m wondering if there aren’t better ways to programmatically describe the active edges. For example:

  • Specify a set of faces, whose boundary edges ought to be filleted. Faces could be specified by planarity/area/topology/trimmedness/distance-to-point/…
  • Specify edges based on geometric properties such as linearity/planarity/length/general-tangent-direction/distance-to-point/closedness/angle-deviation-of-adjacent-faces…

It sounds that the process of sorting would be much more complicated than the actual fillet.

It might be more useful to have those sorting tools as separate components to be used in other situations as well. And keep the fillet component as simple as possible.

One way to pick the right edges to fillet would be to tag them with 3dText.

Agreed. It will balloon the number of components needed, but it’ll also remain the most flexible this way.

It will become a new set of Analysis components under Surface Tab.

Sort surfaces by:
planarity/area/topology/trimmedness/distance-to-point

One which sorts surfaces that are parallel to other planes would be useful.

(Ex: To sort out all surfaces which are not horizontal, for facade area calculation.)

In my understanding, the above specification is a way to extract the edge from the volume from a specification. Could the active edge be defined as an additional input ?

for instance, in the below example, the fillet the closed curve that was used to generate the surface.

It’s pretty slow, but it works.

Next up, add a bunch of components for actually creating edge index lists.

12 Likes

Super nice!
Could it work with parallel computing? Total nr of edges / core nr ?

No, fillets of adjacent edges depend on each other and can thus not be parallelised easily. Maybe some steps can be, but that’s up to the core Fillet developers.

That’s fantastic! Well done. Will it work on a shape like this? To apply a ~3" radius to both sheer rails (the outboard edges of the deck). That deck consists of two surfaces that meet at a peak down the centerline, Curious to see the result at the bow? My past efforts with filet failed miserably on stuff like this.
boat_hull
boat_hull.gh (9.4 KB)

Happy New Year

I did not rewrite fillet logic from scratch. If Rhino can’t do it, Grasshopper can’t do it either (I tried, it doesn’t work). You’ll have to complain about this in the regular Rhino category. Then, once/if they fix it it’ll also start working for GH.

1 Like

that´s great news and the first video impression looks very promising!
as a next step i would welcome the option to give each edge its individual radius.
and finally hoping for variable edge fillets! guess it would make components quite complex, when specifying various radii at different parameters along an edge.
i have not yet tried the announced V6 improvements regarding edge fillets. but if they really become more reliable, this could be a huge step forward in combination with grashopper fillets.
looking very much forward to any development in this field !!

This is already possible. The current component can handle a single radius, or a list of different radii. It does not support different radii per edge. Technically the SDK method does provide for this, but only at edge end-points. If this is a badly needed feature another component will have to be made.

Convex / concave ?
… Assuming that is not already handled by signed angle between adjacent faces.

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