The idea is self-explanatory: “Variable fillet corners” would be similar to the existing “Fillet corners” tool (which is ideal for pre-selecting of multiple curve shapes to apply the same fillet radius everywhere), but with one notable difference - the ability to apply different radius for the fillet depending on the angle between curves. This single-click command could literally save hours of manual clicking with the mouse where even the “Fillet curves repeat” takes too much time to work on paneling designs.
The attached image includes some simple visual representation of what I mean:
Hi Pascal, is that something similar to what “FilletEdge” with “Rail type: Dist from edge” does on solids? If yes, then I think that a setback fillet would do the job, too. Is it an existing command in Rhino? I can only find the basic Fillet that uses radius.
Thank you for that. I always wondered why such a great functionality like “Distance from edge” and “Distance between rails” is missing for doing fillets on curves, too.
If one or both curves are not straight close to the vertex then then there may not be an arc which is tangent to both curves at an equal distance from the vertex.
Yes, useful but in many instances the result will not be exactly as advertised, similar to FilletEdge with DistBetweenRails or DistFromEdge. FilletEdge “adjusts” the rail locations so that a fillet fits and is tangent to the surfaces.
I also think that it will be better to have this option rather than not having it at all. Yesterday I spent almost 5 hours in repetitive mouse clicking to make curve fillets on thousands of hexagonal shapes. Each hexagon was a unique shape and slightly different in size and proportion, and each of these required 12 mouse clicks to apply 6 fillets with 2 different radii, as pictured above. With setback fillet (distance from edge) a similar result would take just several seconds and a couple of mouse clicks.
There is an example probably how to apply fillet with python why not spent the 2 hours to come up with a custom script to pick radii depending on the angle? then you’d just click on the lines that make the hexagon. Not automated enough but will save a lot of time.
Rhino script seems too difficult to me to understand its basics. I guess I’m very bad at learning new stuff. Някои са силни в едно, други в друго.
As I mentioned, I used the “Fillet curves repeat” command (! _Repeat _Fillet), which means that I had to click 12 times to apply 6 fillets to each hexagonal shape. This is still a big time saver while working with hundreds or thousands of curves, because the regular “Fillet curves” command would require 18 mouse clicks for the same result.
Now I figured out that it can be done with much fewer mouse clicks when joining all curves, then using “Fillet corners” to apply 5 mm radius fillets to all the horizontal curves of the hexagons, then explode and run the “Fillet curves repeat” command to apply 2 mm radius fillets to the opposite sides. This why, every hexagon would require only 4 mouse clicks. Basically for 5 000 hexagons that translates to only 20 000 mouse clicks.
My idea (if it’s even possible to be programmed) is to automate that process with just a few mouse clicks, and using preliminary selection of the curves to eliminate the tedious manual picking on every single of them.
Sure, here you go. This is the original size of the wide hexagon that I used to create a honeycomb paneling pattern*, and on top of that the whole pattern was modified with “Cage edit” to fit it along another surface that then I used as a Base surface for the “Flow along surface” command. Basically every hexagon in the honeycomb pattern is a unique shape and slightly vary in size. On the right side I already applied 2 mm and 5 mm radii that make the rounded corners appear visually more natural than using the same radius on all corners.
*Really miss this option in the array tools. A “Honeycomb array” with separately set distance along the X and Y directions, plus shear…
The problem with that is that “Cage edit” will add multiple times more control points to the radius fillets, thus the resulting extruded polysurface becomes overly-complex, bigger in file size and also takes more time to calculate while using “Flow along surface”. Another problem is that after the “Cage edit” command every radius fillet gets distorted, meaning it’s no longer an exact arc.This is why I decided to apply the fillets after “Cage edit”, but before fillets I rebuilt the curves into straight lines to reduce their control point count. This way, the extruded polysurface is as clean as possible.
Hi Pascal, that works very nice! Thanks!
On the hexagonal shape that I just uploaded above, a setback fillet of 2 mm results into 1.7777778 mm radius left and right, and 5.2603986 radius on the top and bottom corners. This is quite close to my target radii of 2 mm and 5 mm, respectively. And takes just 3 mouse clicks per hexagon instead of 12. If it was a polygon with 10 sides (such like a star with 5 rays), that would be still 3 clicks instead of 20.
Pascal, I noticed that a warning window appears while running the script and there are any other object types visible in the scene (points, dimensions, surfaces etc). After closing the warning window, the script still does its job wonderfully, though. This is the message that appears of there is another type of visible geometry in the scene. The warning won’t show up of those other objects are hidden.
CustomGeometryFilter exception boundary
The CustomGeometryFilter() function threw an uncaught exception. It will be disabled.Details:
Type: System.MissingMemberException
Message: ‘Point’ object has no attribute ‘IsPlanar’
StackTrace:
at IronPython.Runtime.Binding.PythonGetMemberBinder.FastErrorGet1.GetError(CallSite site, TSelfType target, CodeContext context) at System.Dynamic.UpdateDelegates.UpdateAndExecute2[T0,T1,TRet](CallSite site, T0 arg0, T1 arg1) at Microsoft.Scripting.Interpreter.DynamicInstruction3.Run(InterpretedFrame frame) at Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame frame) at Microsoft.Scripting.Interpreter.LightLambda.Run4[T0,T1,T2,T3,TRet](T0 arg0, T1 arg1, T2 arg2, T3 arg3) at IronPython.Compiler.PythonCallTargets.OriginalCallTarget3(PythonFunction function, Object arg0, Object arg1, Object arg2) at System.Dynamic.UpdateDelegates.UpdateAndExecute4[T0,T1,T2,T3,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2, T3 arg3) at Scripting(Object , RhinoObject , GeometryBase , ComponentIndex ) at Rhino.Input.Custom.GetObject.CustomGeometryFilter(RhinoObject rhObject, GeometryBase geometry, ComponentIndex componentIndex)
OK, I’ll have a look - thanks for the report…
Yeah, it looks like it’s points that do it - the filter for only allowing planar curves is choking on points because, I guess, they do not have a component index. Or something.
@Rhino_Bulgaria - fixed and updated above. Just my being stupid…