There have been some discussions about filleting in Rhino and Grasshopper (see below)
From my point of view, edge filleting is a mandatory step in any object design. When working with GH, it is frustrating to have to “finish the job” in Rhino for the sake of filleting.
Are there any filleting plans for Rhino/GH2 ?
Brep edge fillets (which is what I assume you’re after, as opposed to creating fillet surfaces between two independent surfaces) have been added recently to the Rhino SDK. I guess I can expose them as a component for Rhino 6.1
How do you imagine such a component to work? I.e. how would you like to specify which edges require filleting?
(logged as RH-43267)
Good point,
Fillet and chamfer for breps should be like the ones for curve (FilletSharpCorners, FilletDistance).
As input they should also have the Indexes of the edges of the brep that should be filleted or chamfered.
Thanks!
Thanks for the answer. I have no clear idea of how such a component would work. In the use case below, there is a volume which is the result of a “cap” component.
I can imagine a “fillet” component which takes the volume as an input (a closed brep). Another input is the edge I would like to filet (the top one in the above use case). I can imagine the “fillet” component takes another input which is the index of the edge, as mentionned by Bogdan. Another input would be the radius of the fillet.
And how will figure out the index of an edge?
But how do you specify it? By edge index (in which case, how do you know which edge has which index)? As a curve that has the same shape as the edge? As a point that is very near each edge (like a mouse-click)?
Using BrepEdges component maybe ?
We could specify one value for all edges or a list of different values for each edge individually…
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:
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.
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.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.
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.
