Assuming that I can identify the relevant edges (which I can, not included in sample), how can I do this? Fillet Edge seems unable to cope with faces more than 90 degrees apart, so I’m trying to drive Brep.CreateFilletSurface. I can get it to work so long as the radius does not go beyond the faces adjoining the edge:
But I need this to work for an arbitrary (sensible) radius and arbitrary subdivision of faces. I also need to work out how to then combine the fillet surface with the original brep and cap it off etc so that it has the same outcome as the desired result above. Ideally the solution would handle multiple fillets at once and allow neighbouring fillets to “merge” (as is trivial in eg Fusion) - but this may be too hard.
This needs to work from Grasshopper, manual work in Rhino is not an option. fillet_problem_01.gh (28.9 KB)
Thanks @inno - but as noted, any solution needs to work without manual steps in Rhino. The source brep is Grasshopper-generated. I have also spent ages trying to simplify the brep in GH, but I could not find a way. Do you know how? What steps did you perform in Rhino? If I can find a way to simplify the brep in GH, that would be a solution to the problem.
well, I don’t know how you did generate that brep in GH, but the thing of ending up with a double edge in (A) and that edge in the middle of the surface in (B) does not make that whole ondulating surface a good candidate for Boolean/Filletting operations
I can’t easily share the GH definition that generates it, it’s buried inside a large proprietary definition. I had a look, and I can improve the generation of the band (this happens before the arms are added):
However, it looks like this will always have a single edge seam somewhere, which I assume is an inherent characteristic of the geometry representation. This seam might then stop a fillet from working.
I have code that will find a chain of tangent faces, so if only I knew how to merge those faces together, I could solve it that way. But so far, I have not found out how to do that (in GH).
Note: in this simple example, your lofting approach to simplify the band could work, but it assumes that the band surface is “flat”, when it might not be perfectly flat in future use cases. I’d love to find a solution to merging faces that uses the underlying surfaces rather than reconstructing them based on assumptions.
would it be possible to slide that seam in such a way it falls behind those boxes on which the fillets are created? something like sliding the seams in one of these two positions here, in such a way it somehow “gets eaten” by the boolean union?
@Joseph_Oster That looks really interesting. However, it’s quite complicated and it also makes assumptions about the band and arms being replaceable with a simple extrusion. You can see that an inset detail is lost in one of the arms. This is a simplified example, but the real arms have additional complex detail that I’ve cut off (the remaining inset detail is part of that). I’ll bear this method in mind, but I’m going to work on using the standard Fillet Edge with a cleanly-generated band that does not have lots of unnecessary tangent split faces.
@inno Firstly, I confirmed that you can’t have a seamless closed surface - even a primitive cylinder has a seam. When the band is based on a closed curve, the seam is aligned to the endpoint of the curve (the start and end points of the closed curve are the same point). I can move that curve endpoint using Seam, and this moves the seam that ends up on the band.
I should be able to move the curve seam to line up with one of the arms, and then I should be able to use standard Fillet Edge for the filleting. However, needing to know a safe location for the curve seam to suit subsequent operations that are a long way down the line in the GH definition (or even in a different cluster), creates a distinctly undesirable coupling from a software design perspective. There does not appear to be any standard surface seam adjustment component. However, I found this:
If I can move the surface seam, then adjusting the band can happen in the GH definition alongside adding the arms, which localizes the seam adjustment to where it is needed, and where the desired seam position is known.
I do wonder how eg Fusion deals with this: it shows a cylinder as being seamless, and you can fillet without seam-based restrictions, but I assume that the underlying model does have a seam, it’s just hidden from the user. Maybe this is just a weakness of Rhino/Grasshopper’s fillet implementation.
I understand what you say, take into account that moving the seam does not change the trajectory of the curve itself, so you can use the Original_Curve_with_Seam_in_a_bad_position until you are going to extrude your curve vertically: only at that step, just before extruding it, move the seam
let me say it would be much easier if you could give some context to your workflow, in such a way more ways to solve the issue could be considered… as the problem is described it looks like you are in front of a Brep that just appears on the screen “as it is” and it needs to be filleted in difficult locations… but if that Brep -or a portion of it- was also created in GH in an earlier part of that definition, then it might be the case to take the filleting needs into account and intervene on that earlier part of the definition, instead of going crazy last minute
The fact that a closed surface will have a seam, and that OOTB fillet tooling can’t fillet past a (tangent) seam, means that even if you fillet immediately after adding the arms, you still have to deal with the seam potentially lying where one of the fillets needs to go. So you have to jump through the extra step of moving the seam. That of course assumes that you have a very clean surface to start with. A more robust OOTB fillet would take this burden off the user.
Requiring the user to conjure their design with the right incantation to keep a brittle tool happy is one way to go, but then the user can spend a lot of time and effort getting the incantation right rather than just expressing their design intent. This reminds me of freecad vs eg fusion - yes, you can do it in freecad, but you have to get the incantation just right or things will break down the line. In tools like fusion, you are far more free to get on with expressing your design intent and worry far less about the specific incantation.
Further, with large complex GH definitions, and where modules (eg, cluster/hop) can be reused in different contexts, pandering to these incantation requirements imposed by brittle tools really hurts scalability, flexibility and maintainability.
@inno it was easy enough to put something a test to move the seam of a face, so I’ll probably go that way. I hear your point about wider context, but unfortunately that’s not possible for me to disclose. Enough to say that the process being discussed is one small part of a complex set of definitions, and the more accommodating this part is, the better. Projecting specific requirements back into the part of the definition that provides the inputs would be a very undesirable dependency/coupling.
P.S. By the way, the reason my Anemone solution was complicated is that a fillet changes the ‘t’ values on a curve so a list of ‘t’ values connected to the ‘t’ input of a Fillet component won’t work. To get around that, I used a loop with a list of points and Crv CP each time through the loop to get ‘t’ values. Call that “a brittle tool” if you like, but a loop solves the problem.
