Concave Cylinder Edge Fillet.gh (12.3 KB)
Am I missing something simple here? Seems like I should be able to fillet both ends of this cyclinder.
Edit: I’ve since tried a couple more work arounds, including cutting the cylinder in half lengthwise, and also rotating the sphere’s 180° so the UV’s didn’t line up as before, and various other UV intersection adjustments, neither solved it.
Neither does using Brep Edges and/or Combine Curves.
Looks like another GH quirk to me.
Yes. Fillet Edge expects a list of edge indices (index values), not edge curves.
Skip the List Item and connect the slider directly to the ‘Edges’ input or connect a text panel list of index values instead:
Nice, interesting distinction, thank you, glad to learn it was my inexperience and not a software limitation!
Yes. Fillet Edge expects a list of edge indices (index values) , not edge curves.
Yup - that’s what I’d call a quirk. Nicely done Joseph.
I hear you. I seemed to me like a quirk, but one thing I learned long ago is that usually when I blamed the software it turned out to be my incomplete understanding of something ha!
I agree it may be callled edgeIndices.
But if you see it from a developing point , if you feed curves in, the component would need to identify the curves on the brep.
This seems to be way too complicated, when you instead just can identify them with the indices.
Just curious - what other GH components want indices as input arguments? And how is one to know which these are?
Hover your mouse over any component input and it explains what type of data it expects.
Of course - but…my first question was the important one. I’m not aware of any other component that wants an index value. Apparently there are some. But how to tell which ones they are?
List Item, Cull Index, Insert Items, Replace Items, Split List, Sub List (Subset, a domain of indices)
Good to know - thanks.
So of all the geometry related components (meaning those that don’t deal directly with list items), this is the only ones that explicitly want an index as input. I’d say that qualifies as a quirk.
Not in the least, it’s documented and works as expected. Quirks are a completely different animal.
I remember the faces input of the construct mesh component causing misunderstanding as it expects a list of vertex indices that form a meshface instead of meshfaces. But there as well it’s explained hovering over it. Sometimes the name on the input just is a hint, because of space I imagine .
It makes sense to me now after being educated.
I was kind of thinking about it but didn’t quite understand yet, that if I input the geometry of the brep, then input an edge as a curve, how would the fillet command interpret that if I’ve separated the edge as a curve.
But it makes sense for it to be telling fillet which numbered edge of the brep to fillet, rather than a curve that is coincident with the actual edge of the brep. Makes total sense to me now that I realized it completely in my mind, with some clarifying education.
Ignoring what other components act on indices, in the case of brep edges and faces it’s particularly complicated because they cannot exist in isolation. The only way to have an edge, is to also have the entire brep it belongs to.
You can of course always convert an edge into a standalone curve, but you can’t do it the other way around. Not every curve is the same as some brep edge. Just as not every (xyz) point lies on a given curve. This is why you often need curve parameters when using curve components, and why you need edge indices when using edge components.
Improvements are possible in this area and I plan to make them in gh2. Instead of just integers for edge indices, a new datatype will be added which is smart enough to be constructed both from integers in case you wish to identify edges by index, or from curves in case you wish to identify edges by shape, or from points in case you wish to identify edges by coincidence.
Thanks David for your explanation of why things (in particular, edges) work the way they do. Like the OP I too was at a loss to understand why FilletEdge wouldn’t work the way I expected. I did not think about how the FilletEdge code would know which edge and adjoining surfaces it would have to work on. I thought that it would “just know” because I was giving it both the edge to be filleted and the geometry on which the fillet needed to be generated.
Both me and the OP got stuck on this because FilletEdge worked OK when we gave it the first (Index = 0) edge, but not on the second one. I thought “well maybe it has something to do with outside vs inside”, so I tried rotating the geometry 180 deg. so the bottom was at the top. But of course this also failed because all I did was put Edge #1 where Edge #0 used to be. I also tried things like employing BrepEdges and JoinCurves - but I was clearly barking up the wrong tree (pun intended.)
Of course, if I had done what Joseph pointed out (hover over variable name) I would have immediately known what to do. Regrettably that concept just completely eluded me. So what we (me) have here is a brain problem, not a technical one. I’m sure you see lots of those.
Well it’s a bit of both. Some of this stuff is fairly complicated and/or totally outside anything you would have encountered in school classes (unless you did cs or maths). So a certain amount of confusion is to be expected. But we can probably do better at the other end as well. Better error messages, better tooltips, better documentation.
