Variable fillet in GH?

If you have a Brep/ polysurface in Rhino, you can select a closed loop edge, run the FilletEdge command, and add handles at various points with different radii to make a variable fillet. All good.

Can you do this in Grasshopper? The Fillet Edge command in GH has “E” edge indices of the Brep, and “R” fillet radii for each edge, but I do not see how you could change the radii over a single edge, or multiple combined edges.


1 Like

I think @FlynnAD wants different radii per edge. But I might be wrong.

@DavidRutten you are correct. For example, take a hollow cylinder hitting a larger square plane, and they are trimmed and connected. I’d like to fillet the circle intersection on one quadrant at say, a 1 unit radius, then widening/ softening the fillet to a radius of 3 units on the opposite quadrant.

Is this possible in GH?

Unfortunately (!) you’ve made it so that you can do much in GH, it becomes a bummer to have an idea (which you know you can pull off in Rhino) but find that at a certain point you would have to export from GH and manually do steps in the middle of the process.

And I realize that Fillet Edge does not always work in Rhino (sometimes the fillets cannot be trimmed). But they are still created, allowing the user to go and clean things up. If there is a command in GH for variable fillet, does it/ could it create the fillets even if it cannot trim them?


Not without special coding. I’m not even sure variable fillets are exposed in our SDK.

It seems not. All I can find is the ability to specify different radii for the end-points of an edge, not parameters on the interior of edges.

The concept isn’t difficult for the simple case of surfaces at right angles, like this: (19.0 KB)

But as you can see, both surfaces are completely ignored in this model. It gets more challenging when the surfaces are angled or curved. For any given pair of surfaces, it’s probably possible to adapt this idea but I’m not sure it would apply for the general case.

Be a hero and post a solution. :sunglasses:
Start by posting a series of test cases…


If we can add different radii to the end points - we can division any curve to many curves and make the variable fillet))) But how to ? Its only interesting quastion )) not needed to me at this time) sorry for bad english)))

This isn’t terrible, though it has some quirks. The ‘quadrant’ slider in the blue group chooses one of four possible locations for the fillet.

  • The SubCrv in the yellow group was needed because on these curved surfaces, circles at the end points failed to generate the expected four intersection points.
  • ‘radius’ values at the end points can cause unpleasantness for the same reason.
  • ‘t’ position values can cause unpleasantness, esp. when out of sequence (obviously!).
  • No effort has been made to trim the base surfaces. (29.6 KB)

1 Like

With a little nudging (slider adjustments), it even works when the two surfaces don’t overlap, though the ‘quadrant’ slider takes on a different role. :wink:

variable_fillet_2019Dec2c (32.3 KB)



Here are my initial attempts. I intend to use a closed curve, so I began with that as a default setup. Using a flat base plane along with the extrusions gives the intended result in Rhino. Loft did not work for me in GH (I was probably doing something wrong that it did not create a closed loft for me), so I went on to trying a sweep1 command. With a flat base plane, the GH result is nearly perfect to Rhino’s (attempt 1).

Trying attempt 2 with a slightly curved, extruded base plane seemed to give close results, so I went on to attempt 3 with a doubly-curved base plane and a third radii point. Here I found that the GH sweep1 result does not follow the base surfaces at all (the big plane or the cylindrical/ elliptical extrusions). The resulting GH sweep1 cannot cut the base surfaces because it does not hit them properly. When I saw this, I looked back closer at attempt 2 and found the same thing, that the sweep1 does not cling to the base surfaces (logically, now that I look at it). However, in attempt 3, the sweep1 result at least made a surface. Rhino’s FilletEdge variable command failed to build the surface.

I’m out of the office so I won’t be able to try again till after this week.

VariableFillet01z.3dm (703.0 KB) (27.6 KB)

All mentioned solutions do not even touch the core functionality of Rhino. The premise of any transitional surface command such as fillet, blend and others require to match the surface continuity (under certain tolerances). None of the shown solutions even measure continuity and deviation. You cannot even be sure to have positional continuity on a double curved surface if you just loft arcs together.
These algorithms are non-trivial. On the other hand I never really seen a true and practical use-case of a variational fillet other then for quick and dirty purposes.

Of course, yes. I could see the flaws but it was an irresistibly simple flourish. Here’s a closer approximation using ‘BiArc surface frames’ in the first green group. Then the second green group trims the surfaces. (35.6 KB)

I can see where the fillet fails to join the trimmed surfaces, but this gives me another idea… :thinking:

I’ve been down this path before, the territory looks familiar… (46.5 KB)

At sufficient resolution and nudging, these surfaces join as a single “Open Brep” polysurface.
Not claimed to be general purpose by any means. UV directions are assumed here (though could be resolved in code…), and maybe other aspects.

Still, a worthwhile effort with simple tools, simple ideas

1 Like

Better? More “robust”? Handles intersection of convex surfaces as well as concave. (51.1 KB)

1 Like

I still don’t think this is right way to go. The reason is that you use way too many cps. This is brute force way. In order to hold continuity you increase the cp count so much that the error gets minimal.
Instead setting the surface based on the curvate and rematching the fillet after creation should be a better approach. I’m not saying, I’m able to code something up, otherwise I would have. My point is just that such algorithm requires much more work and has much higher complexity. If I’m on computer having CAD, I might measure the deviation to show you the problems.


I’m happy with this version today. It handles multiple pairs of surfaces, thanks to Andrew Heumann’s FlipLast cluster. (Very useful! Thank you @andheum for that one.)

The pair of zero/one sliders (blue group) allow choice of quadrant for the fillet when the intersecting surfaces overlap. The most difficult part was choosing which piece of each split surface to keep. Splitting is an optional step, after all? (75.8 KB)

This cyan group off the left edge of the canvas is a good demo, by itself.


I’ve been following this thread while working on fillets for this design to be 3D printed:

What ultimately worked best for me was to create a roughly circular curve on the vase and on each spout, pick an end point on one curve and the closest point of the corresponding other one, then a third point between the 2. I then used these 3 point to make an arc and used 2-Rail Sweep to make the fillet shapes.

This works well for the geometry I have, but I wonder if it would work with the geometry shown in Joseph’s post above. More specifically, could an arc actually follow the 2 rails and make a nice smooth shape that maintains tangency with both surfaces?

well I would disagree here. You can see that you only hold positional continuity, but tangency should be minimum. The point is, you cannot match a double curve surface by taking curves, matching them and create a surface from continous curves. Matching a surface is more complex then matching curves. Sometimes it is even not possible to match two surface together within a given tolerance. A lot is determined by the smoothness of the surfaces temselves and the way they meet eachother. The stronger the curvature of them, the more difficult it gets.

What I ended up usually was to prepare the surface and matched them in a manual process later on. Grasshopper, even Rhino is lacking good matching capebilities for such situations. As an alternative most CAD platforms offer Autofillet functionality, which work sometimes better sometimes worse. But almost any Autofillet functionality increase cp count, even if this is not required. Therefore in my production data, I almost matched manually within Icem Surf. If you are experienced its done relativly fast. And if you consider filleting as a post process you only need to do it once or twice anyway. So I personally wouldn’t spend so much time on it within Grasshopper.

As a rule of thumb, prepare as much as possible automated (within GH) and do the rest in a manual process. This is a much more realistic workflow.

Thanks for that insight Tom, I do get your points. My situation is not real production, but rather 3D printing at home. For my parts to come out looking Ok my geometry can tolerate small (< 0.01 mm) gaps because the slicer software generates continuous filament loops that fuse together.

I do agree that true tangency (matching 1st derivitives) is a difficult thing. In my post I should have used the words continuous contact instead. Careful inspection of my parts shows that there is actually very little true tangency, but the arcs work well enough - and the part is small enough - that normal people won’t notice the angular mismatches.

Of course, like you said, if one is building airplanes such an approach won’t work. But that’s not what I’m doing these days.

Is actually not that bad! I’m a bit surprised, but I guess this is due to the fact that your surfaces are very close to planar and very smooth in itsself (Order 3 Bezier) .
Here I measured the tangent deviation: