Shrinking fillet surfaces

I’m skeptical that the change that can be made more or less right now to FilletSrf. Adding a blend surface capability to FilletSrf, presumably non-rational degree 5, in place of the rational degree 2 fillet surface, will require a new chunk of code in the command, not just a minor change to the existing code.

Oh, is this what you mean (that I call “tension” or what other software call “form factor”)?

bild

That’s a VariableBlendSrf I was just using with DistBetweenRails in V7 WIP and yeah, that CV distribution isn’t pretty at all, especially when the tool in question doesn’t offer any control over it…

Yes, that is correct. The equivalent of the TrimRefit command is used a lot, to close small gaps and to build substitute surfaces. So I’m really looking forward to trying that in Rhino!

@pascal, So I just tried “TestRefitTrim” in the V7 WIP and that is a very, very useful command. I use the following technique a lot and at first glance, it seems to be automated in a 1 button operation. Very exciting.

Manual approach
-Trim 4-sided single-span surface.
-Duplicate trimmed edges
-Rebuild curves as needed to single span
-Use EdgeSrf to create new single-span surface

Hello Pascal,

I’m really happy how you improved filleting. The shortest edge option for a G2 Blend/Fillet and the nice CV distribution are fantastic!

There is one thing I noticed though. Fillets are made up of multiple spans, with extreme density in some areas. This will make manual filleting more difficult.

Also uneven Control Point Distribution might result in uneven influence to the surface:

Uneven

Can this be changed or optimized to a cleaner single span style? I could imagine that this might impair Rhinos ability to fillet several contours at once, however doing fillets one at a time I would not need this to work, just in case. Simple clean patches are more important for me. Usually single span 7 CPs length wise always works great.

Maybe a “Single Span” Option in the command line would do, so users could decide themselves.

Just to avoid any misunderstanding, I dont mean a single patch for each contour. Surfaces obviously need to be filleted with as many patches as needed, also resulting in more and shorter patches in areas of greater curvature. As long as each patch is single span with an even CV distribution.

Best Regards

1 Like

Hello - the underpinnings for most, if not all of what you are asking are there in V7. Commands, not at already for prime time, like 'testFilletSrfNonRational` have provision for Bezier segments, control over the rail structure etc. Note this command is very unstable at the moment but just to give you some hope. I would love to get these sorts of features properly into a more comprehensive filleting command much as you outline. That said, I am not waiting under water.

-Pascal

4 Likes

Great, I’ll try that!

Was so good the first time I’ll ‘eat’ it again… :wink:

Ah fillets…so many bones…

Lemon-Sole-3

2 Likes

Awesome!

@pascal

I tried the 'testFilletSrfNonRational` command and found some things that should be adressed.

Choosing segmentation-count with deviation analysis is really nice and it is a really good approach, as sometimes fillets serve as “surfaces” for further construction like gaps and draft angle flanges etc. and ideally have as little segmentation as possible.


For full control I would like to control fillets from “both ends”

  • Choosing segmentation-count, resuling in deviation/Match quality (like currently)

  • Choosing Match quality, resulting in Segmentation



Filleting-Segmentation in Rhino seems to be dependant on Surface spans, which results in too many and too irregular fillet-patches. This will be problematic for manual handling and should be avoided.


Instead of Segmentation by Span, segmentation by Curvature should be considered. Meaning each fillet patch covers as much ground as possible until it reaches a certain deformation, which will add the next fillet patch etc.

This way segmentation can be controlled perfectly:

Length2

Also only choosing between Order 4 and 5 length wise is not an ideal approach. Usually fillet patches should have 6 to 7 Control Point Rows lengthwise. This covers the most ground with the smallest amount of patches, as well as (in Theory) making it possible to manipulate fillet contours with G2 continuity (3+3=6), so every patch could be matched to its neighbours at both ends.

Another point is that the fillets do not have a constant radius and do not have a constant circular shape.

This is caused by Bezier geometry not being able to describe a perfect circle.

Currently the filleting only offers arcs of 4th and 5th order, resulting in deviation.

Instead of exact mathmatical representation, and depending on the algorithm, this is commonly solved by using an approximation of a circle with arcs of Degree 6 and Order 7 (7 Control Points), resulting in neglectable deviation. This is the “industry standard” and should be considered to make the fillets compatible with other systems.


As a start I would recommend :

  • For circular fillets: Arcs with 7 Control Points, and 7 Control Point Rows lengthwise

  • For G2 fillets: Arcs with 6 Control Points, and 7 Control Point Rows lengthwise

Best Regards

1 Like

Hello - thanks for the input. I agree that segmenting by curvature or by user-set locations, with deviation feedback, perhaps - would be a good way to split these up.
I’ll bring your comments to our internal arm-wrestling about this.

-Pascal

1 Like

Hello Pascal,

I would like to ask about the progress of this? Are there any new hidden test commands for this?

Best regards

1 Like

The command of my dreams is called “ListAllHiddenTestCommands”.

4 Likes

Not a chance…

-Pascal

Great! :wink:

Hello - No, at least nothing concrete that I know of.

-Pascal

Hmm…I was at least hoping for a roadmap or something…at some point you guys will have to bite the bullet and finally fix filleting :grin: