Thanks, Pascal! I updated the plug-in now and it accepts numerical input, just like the regular “Fillet” command. 
I noticed that the preview would disappear in many instances, however, I figured out how to make it visible 100% of the time - you just need to slide the mouse cursor along one of the input curves. Not sure why, but it works that way.
@Jarek , @Rhino_Bulgaria - Esc should work now, updated above - I was just being an idiot…
-Pascal
2 Likes
Thanks, Pascal! I like the newly added red circle that gives a better visual feedback about the overall shape and how the fillet is affected by the circle tangents. Really nice job.
thanks but this doesnt work over here. Unless I pick the far ends, the preview is limited to roughly mid-way of the segments to fillet, then dissapears…
really nice, this is going to be useful in many cases. I noticed too that the preview sometimes disappears and found a way around it. @pascal instead of using the parameter of the first curve as fixed, you can instead use working_curve1.Domain[0] and if that fails use working_curve1.Domain[1]
I found a few more bugs:
- the script fails if picking the same curve object twice.
- the script fails if entering a too large radius for the selected curves.
wishes:
-would be nice if this also worked on a polycurve.
-would be nice if one can fully consume curve 1 or curve 2, in such a way that the radius sticks to the end of the curve once selecting ‘beyond the end’ of the curve
1 Like
Hi Gijs - thanks for testing…
Yep, I put a cheap checker in there for now for use with the rs function (next update), but I’ll use a proper GetObject() eventually and filter it better.
This should work - I had it working, but I’ll double-check.
Did you get this to work in the GetPoint() dynamic feeback drawing code? In there, I was trying various ways to test multiple parameters to get a valid circle but could not get it working, only the first attempt seems to be accepted. I’ll fuss some more. It for sure has to do with the pick parameter on the first curve simply being too far from the tangent location beyond a certain point, as far as I can tell.
I’ll see if I can get it working on polycurve segments…
-Pascal
Yes it works, see the attached: FilletCrvTest_modified.py (11.7 KB)
As for the fully consume curve 1/2: here this works if the second curve can be consumed only: well, sort of, it leaves a curve behind with length 0
1 Like
I realized that surface or polysurface edges can’t be used as an input curve. Could this be upgraded, too, if I’m not asking too much?
Heh - none of this is asking too much - it should indeed work like that - it’s just a matter of getting to it - I have not had a chance to test Gijs’ fix yet.
@Gijs - thanks very much for this - it looks like arranging the code as you have - check both before calling the drawing code, avoids two calls to the circle drawing code, one of which may fail which causes the rest to fail.
-Pascal
1 Like
yes, basically I am trying at start and end parameters and one will always work (as far as I’ve tested)
There is one other bug I found: if the second curve gets consumed fully, it will fail at the line where the curve in the doc is replaced, since crvs[1] becomes none
Yep, OK - I’d tried changing the parameters only after the first drawing failed - just dumb, because once it fails, it doesn’t do anything else…
I’m looking at the curve-consuming bits…
@Gijs , @Rhino_Bulgaria - see if this is on the right track - I incorporated Gijs checker and it should work on brep edges as well as curves and it should do the right thing, I think, where the curves are consumed. I still do not like how the tracking is biased to the second curve… still thinking about how to make that better.
FilletCrvTest.py (13.8 KB)
-Pascal
1 Like
Hi Pascal, I tried the new version but I’m unable to find differences with the previous version. I like how the real-time preview gives a better idea about the radius fillet that I can apply via the keyboard.
I have two more suggestions for this tool:
-
When the radius fillet reaches the very end of one of the two curves, it would be nice if it stops there so that a radius could be created, no matter which one is picked first. Currently, this is only possible if the shorter input curve is selected as the 2nd one.
Edit: I noticed that you already wrote about that in your post above. -
When the two input curves are not close enough, make it possible for this tool to extend them in the same fashion as the default
! _Fillettool does so that a smaller radius could be built, too.
Hi Bobi - it should work on coplanar brep edges now -did that not work?
The preview should ‘last longer’ and not disappear so soon when one curve is a lot shorter.
-Pascal
1 Like
Ah, yes… I totally forgot to test it on surface edges, probably because I already knew that the previous versions were unable to do so. 
This will definitely help. Thanks again to you and @Gijs for the great work on that tool!
Hi @Pascal,
This is working very smooth now, no more problem with disappearing radius regardless of the cursor position. Also nice touch with allowing Brep edges as input, over here hardly ever would have a need for that though but many other folks will enjoy this I am sure.
The biggest oustanding wish for this tool is to work with Polylines / Polycurves. I know it’s a bit more complicated, but maybe not that hard to do. The logical steps could be:
- Get 1st Curve (note that Rhino command delelects the 1st one after the initial pick)
- Get 2nd Curve (which will be possible to pick the same one if the above deselection is implemented)
- if they are 2 separate objects, continue as normal, but if they are the same object then:
- check if they are two separate segments of a Polyline/Polycurve that share the same end - if so, explode the Polyline, remember components, operate on the picked two and at the end, whether canceled or successful, stitch it all back together : )
I know at least in RS if GetObjectEx is used, the pick point can be known in order to identify the polyline segment… I am sure in Python/RhinoCommon it can be done, too.
The original wish for this topic came from our typical workflow of tracing shapes and street networks, which is often easier to do ignoring all fillets at first and then adding them manually as a next step. But typically these are polylines and we would not want to explode them.
Which brings me to two more wishes/ideas for the tool:
a) add “Join” option so the fillet part is joined with the filleted curves into one object (original Rhino tool has it and for us it would always be a default=Yes)
b) would it make sense to add “repeat” option, or eventually we can have this script on a macro using Repeat method? Quite often this will be used on a sequence of segments.
Thanks a lot for all the work on this - already super useful. If you can pull off the above, be careful- the next step for you is a new Rhino meshing code 
–jarek
that was just a very tiny thing 
all credits to Pascal
1 Like
Even more Pascal magic that should be included in Rhino as standard? I think I’ve lost count now on how many good scripts there are.
I see more than one link in this thread, though. Which is the latest and greatest version?
2 Likes
Hi Jarek - - yep, I’ll get to the polycurve part, it’s been part of the plan from the start - about as you suggest, I think, but I just wanted to get the basic functionality working correctly first. I think it is mostly there. The red circle was added for debugging, I’ll take that out (sorry, @Rhino_Bulgaria …) unless y’all feel it is really helpful and not noisy…
I’ll also try to get the blend mode preview correct, that should not be too hard. And add curvature graph And ‘bulge’ adjustment. And…
-Pascal
1 Like