Fillet

[jgomez720]

Description

A tool that enables the user to create a fillet (rounded edge) on any edge of the body.

Functionality

1. The user selects the edges they want to fillet. In some CAD applications, you can also select a face and all the edges of the face will be filleted.
2. The user selects the fillet button.
3. The user inputs the radius of the fillet.
4. Confirm.

OR

1. The user selects the fillet button.
2. The user selects the edges they want to fillet. In some CAD applications, you can also select a face and all the edges of the face will be filleted.
3. The user inputs the radius.
4. Confirm.

Supporting Docs/Images

PseudoKCL

const box = startSketchOn('XY')
  |> startProfileAt([0, 0], %)
  |> line([0, 5], tag: 'fillet1', %)
  |> line([5, 0], tag: 'fillet2', %)
  |> line([0, -5], tag: 'fillet3', %)
  |> close( tag: 'fillet4', %)
  |> extrude(5, %)

fillet({
  radius: 0.50,
  paths: ['fillet1', 'fillet2', 'fillet3', 'fillet4']
})

[Irev-Dev]

I was talking to @jess about this because she's looking to add fillets, and I came back to this and realised there's still some thinking to do on how to be specific about which edge is being selected for the fillet, and to make sure that we have a way of selecting each edge on a given extrusion. Take these stdlib names with a grain of salt, we can probably iterate on these for clarity but here's the idea.
Using the same example

When selecting an tag from the sketch that made the extrusion we need to specify if it's the start or end of the extrusion. The two options I'm suggesting is having a stblib function for bath start and end or to put a side param in

When selecting a edge that runs along in the direction of the extrude, I can see two options. I like filletSurfaceIntersect because it's not so tied to two surfaces that came from the same sketch, like if there is a subtraction and there are two faces with common edge we want to fillet, so long as they both have tags this will work still. filletSegmentHeadEdge is a bit more concise, we could add both.

If there user wants to fillet all the edges around a surface that's easy using the original tag

and we can do something similar for the start end of an extrusion

[jessfraz]

Okay so if you think about Chatgpt as thinking what 95% of the world would assume is the intuitive way to do this and autocomplete the code I asked it what it thought of different approaches, let me know what you think of these I kinda like ->

heres what it said

====

Certainly! When designing a syntax for referencing edges in CAD operations, especially for a programming language, it's essential to ensure that the syntax is not only intuitive but also unambiguous. Here are some alternative approaches to consider:

1. Edge Intersection Function: Define a function that takes two segment tags and returns the edge at their intersection. This could be used directly within the fillet operation.

   fn edgeBetween = (tag1, tag2) => {
       // logic to find the edge between two segments
   }
   
   const part = startSketchOn('XY')
       ...
       |> fillet({radius: 2, edges: [edgeBetween("seg01", "seg02")]}, %)
   

2. Numerical Edge Indexing: After creating a closed shape, edges could be automatically indexed. The user can then refer to these edges using their index.

   const part = startSketchOn('XY')
       ...
       |> extrude(10, %)
       |> fillet({radius: 2, edgeIndices: [1, 3]}, %) // Assuming edges are numbered in the order they were created
   

3. Edge Tag Extension: Allow the user to extend segment tags to edges created during the closure of a sketch.

   const part = startSketchOn('XY')
       ...
       |> close({tags: ["edge01", "edge02", "edge03", "edge04"]}, %)
       |> extrude(10, %)
       |> fillet({radius: 2, tags: ["edge01", "edge03"]}, %)
   

4. Directional Edge Reference: Use a directional keyword relative to the tagged segments to specify the edge.

   const part = startSketchOn('XY')
       ...
       |> fillet({radius: 2, tags: ["above seg01", "left of seg02"]}, %)
   

5. Combination of Tags and Directional Modifiers: A blend of tags and directions could also be used for more complex geometries where directional context is necessary.

   const part = startSketchOn('XY')
       ...
       |> fillet({radius: 2, tags: ["seg01+top", "seg02+left"]}, %)
   

6. Graph-Based Edge Reference: If the CAD model’s data structure is graph-based, where edges are nodes, and their connections are edges, a graph traversal language could be implemented.

   const part = startSketchOn('XY')
       ...
       |> fillet({radius: 2, graphPath: ["seg01->seg02", "seg02->seg03"]}, %)
   

7. Procedural Edge Identification: Introduce a procedural edge selection where the user can implement a selection algorithm based on their criteria (e.g., selecting edges based on their length or angle).

   fn selectEdgesByCriteria = (criteria) => {
       // logic to select edges based on user-defined criteria
   }
   
   const part = startSketchOn('XY')
       ...
       |> fillet({radius: 2, edges: selectEdgesByCriteria(myCriteria)}, %)
   

The chosen approach should balance ease of use, expressiveness, and the ability to handle complex cases without ambiguity. It should also be designed with the user's mental model in mind, matching how they think about the geometry they're working with.

[jgomez720]

I have a wild idea.

I was talking with @jessfraz and mentioned that this is going to get super complex, once the user starts cutting away more and more material from the base model (or adding), that creates more and more edges that they can potentially fillet. How do you tag these new edges? Sometimes it's not so bad (like the example above), but sometimes one cut can create 14 edges, for example.

Is it possible that we create the tags everytime someone does a command, and the user return them? Let me try to explain.

Take this box:

Now let's say I do a cut that is at a really bizarre angle and asymmetric.

This would create a cut like so:

That one simple extrude created 8 new edges in the body (technically 9, because it cut the previous edge into 2 pieces). It also created three new faces.

So what if we (in the engine) tagged all those new face and edges ourselves, that the user could get by calling some function? Forgive my code, I didn't look up the sketch on face stuff yet. Consider this still pseudocode.

const boxRemove = startSketchOn('XY') // imagine that this is sketching to remove material from the box above
  |> startProfileAt([0, 0], %)
  |> line([0, 3], %)
  |> line([3, 0], %)
  |> line([0, -3], %)
  |> close(%)
  |> extrude(2, remove: true, %)

Fillet({
    radius: .25, 
    edges: returnEdges(boxRemove)[0:3]
}, %)

So what I'm accomplishing in the code is:

1. Create a sketch on the top face of the box.
2. Extrude into the box and remove a cube out of the base model
3. Fillet edges 0 - 3 of the returned edges from boxRemove. returnEdges() returns an array of tags of all the edges that were created from executing the boxRemove. (boxRemove has 9 edges you can return, and three faces. If you want the faces, you could use something like returnFaces(boxRemove), which gives you an array of tags for all of the faces that the boxRemove command created by removing the material). So this command is filleting 4 edges in total (0-3).

This would output something like this:

The only reason I thought of this, is because this was a way of me trying to capture all or most use cases. If I extruded three more times at random orientations/angles into this box, each one of those commands would still return more edges/faces for me to use. So ideally, this would work most of the time. The tricky part is how we (Zoo) label all of those edges.

• What numbering scheme do we use?
• How do we know which edge is first?
• Would the user have to guess and check each edge index to eventually find the edge they need?

I'm certain this requires a lot of work on the backend to have returned items from a command, but just something I thought of.

[Irev-Dev]

Relying to jess

Edge Intersection Function

const part = startSketchOn('XY')
    ...
    |> fillet({radius: 2, edges: [edgeBetween("seg01", "seg02")]}, %)

I do really like having a generic fillet function that takes edges, and then having a number of utils for finding those edges

 |> fillet({radius: 2, edges: [edgeBetween("seg01", "seg02")]}, %)
 |> fillet({radius: 2, edges: [extrusionEdgeTop("seg01")]}, %)

Probably still need something dedicated for filleting all edges surrounding face, just because I'm guessing the engine will want the face_id, not all the edge ids

 |> filletFace({radius: 2, faces: ["seg01"]}, %)

Numerical Edge Indexing

Too brittle, if you update the sketch, you indexes will all be out of whack.

Edge Tag Extension

No different from indexes right, just named indexes? tags should be on the callExpression

Directional Edge Reference

Two ways of doing this

• relative to world coordinates, easier to grok but brittle when things are rotated
• relative to local coords, harder to grok because you have figure out where the local coords ar orientated before you can make sense of it
  This is why I like tags, they don't require an "imagining while squinting" kind of thinking IMO

Procedural Edge Identification

This sounds like cadQuery's "selectors" and I'm open to it, but I worry if done incorrectly it would be brittle.
From memory I remember some of the CQ selectors being like faces.selector(>z) while means the face highest on z-axis. has the same local-vs-world coordinate problem, and you want to make sure faces is a subset to begin with, because if it's the entire scene, than it only a matter of time before there is another face that is higher on the z-axis that the selector will grab instead.

[jessfraz]

okay lets go with Edge Intersection Function

[jessfraz]

instead of this: filletFace({radius: 2, faces: ["seg01"]}, %)

what if it was |> fillet({radius: 2, edges: [getAllFaceEdges("seg01")]}, %)

for consistency

[Irev-Dev]

I'm happy with that too.

we might just need to git the engine and ask, "what are all the edges for this face_id", and then gives those edges back to the engine afterwards, instead of just giving it the face_id and asking it to fillet all edges.

We (client side) won't know the edges without an engine endpoint because of the case @jgomez720 pointed out.

Take the face labeled 4. That face has 4 edges that come from a subtraction, and that's really engine domain to tell us which edges come from that operation.

[jessfraz]

im also going to try for all edge functions start with edge because for autocomplete thats nice

[Irev-Dev]

On naming, we might want to not use the term "face" because it implies a planer surface. Maybe we use "surface" instead. Because when getting surfaces by tag that came from an extrusion they can be either (think extruding an arc or spline), and you still might want to fillet all the edges of that non-planer surface.

I think Face should be reserved for planer faces, so sketchOnFace is a good example since it has to be planer.

unfortunately surface has 3 more characters that face, shell was the only other alternative I could think of, and that's not great, we could use "surf", since unless you're using kittycad to design a surfboard there's probably not a lot of confusion there.

Oh patch might not be a bad term.

[Irev-Dev]

Replying to Josh.

Because things can get so complicated with "boolean" type operations of solids, I have been trying to bang the drum of Segments with tags HAVE to be the base abstraction for all modeling i.e. you should not be able to just instance a cube for example because you have no way of accessing edges and faces after the fact with anything other than something like indexes. which is horrible from a readability perspective.

If you take two solids and combine them in some boolean operations, as long as you have tags that enable you to reference each edge and face of the two solids going into the boolean operation then you will still be able to access each edge and face individually after the operation, no matter how complex they are for the simple reason that the face tags are transferred in the process.

I do like your ideas in that I think getting "metadata" from modeling operations, so getting all of the new edges created from a cut is very cool. But I wouldn't want to promote it as a best practice for selecting edges for fillets.

Easier to describe with diagrams so let me try re-create you example.

The two input shapes with each of the important face taged

"top" would be the the end of an extrusion, which doesn't have a tag persay, but we can access it all the same. (I've used purple for the back side faces i.e. the ones you shouldn't be able to see)

When we cut the left hand shape into the right hand shape, the faces of are transfered.

This allows us to select any of the old or new edges with the tags we already have.

Why I like this so much is because it's stable, for example if we focus on the edgeBetween 1 and 4

If we were to start drag the object that's being subtracted to the left, if we go far enough, this edge will disappear as it "falls off" the other solid. so trying to fillet that edge might return an error or warning depending on how we setup up, but what we don't want to do is start filleting random edges unexpectedly.
If we fillet the first three edges that are returned, returnEdges(boxRemove)[0:3]:

1. I don't know intuitively how one would know which order the edges would come back in
2. if the edge between 1 and 4 that we were talking about was one of those first three edges, once that edge disappears this code is just going to fillet some other random edge to make up for the one that doesn't exist anymore.

What I do really like about your ideas though is returning an array, I think it would be wise for a edgesBetween('tag1', 'tag2') to always return an array, which most of the time will be just one element, but that will gracefully cover situations like the edgeBetween('top', 'b') which has been split into two separate edges from the cut

And there is nothing stopping an edge from being split into many many more edges depending on how complex the subtracted shape is.
I think an array is appropriate here, but I think these cases will be the less common cases.

Main emphasis on the above is "stable", I really want to solve the "brittle" model problem. That in part is going to have to be by letting users have if statements for handling cases where edges etc faces disappear after adjusting a parameter or other errors, but we can eliminate a lot of the problems ahead of time with good API design. And the above is the best I have to offer atm.

Also linking this for posterity, since some of these ideas were discussed, long from 😬
KittyCAD/kcl-experiments#3

[jgomez720]

This is sweet. I never thought of it as the transferred face from the tool to the target (talking subtraction boolean terms). I like your way Kurt. This would take care of a majority of cases