Picking surfaces is easy.

The distance field tells you the distance to the nearest surface at any point. You can have a "surface id field" tell you the id of the nearest surface to any point, and then when you raymarch to find the intersection of a line with a surface, you can read out the ID from the ID field after finding the intersection point. (Of course the ID field is also implemented as a function mapping points to surfaces).

So when the mouse is hovered or clicked in the 3d view you can easily find the ID of the surface under the pointer, and you can draw that surface in a different colour to show it is selected. No boundary representation needed.

The hard part is, given 2 surface ids, how do you add a fillet between them in the general case?

Another idea I had was to set the fillet radius on every min/max node based on the derived surface id's from the child nodes, but I couldn't find a good way to do this without making the field discontinuous.

I have more notes in this blog post: https://incoherency.co.uk/blog/stories/frep-cad-building-blo...

If you have good ideas for this I'd love to hear them and resume working on Isoform.

>Picking surfaces is easy.

That depends on what we mean by surfaces, and in the case of filleting, the user really wants to be picking adjacent faces (as in: an edge between two adjacent faces). That, or even a region to roll a ball along to generate a fillet.

The semantics of fillets even in the simplest case is that it's doing something to the edges, i.e. elements of the boundary representation, so that's a more natural structure for filleting.

>The distance field tells you the distance to the nearest surface at any point.

What you're describing isn't the same. You really are picking solids, not faces.

This wouldn't work even in the simplest case of a cube.

You can define a cube by a distance field:

    f(x, y, z) = max(|x|, |y|, |z|) - 1

If the user wants to fillet just one the edges, then what? You only have one surface (the boundary of a cube), and one ID.

The field doesn't know anything about the edges.

OK, OK, we can ignore this edge case (badum-tss), but even if you only allow filleting "two surfaces", those two "surfaces" (really: boundaries of solids) aren't necessarily going to intersect along one edge (which is what the user wants to fillet).

The intersection may have multiple components. Or may not be manifold.

As a concrete example:

    f(x, y, z) = z - cos(x)
    g(x, y, z) = z - cos(y)

Look ma, no absolute values! Let me smooth-talk a little though:

    f(x, y, z) = z - cos(x)cos(y)
    g(x, y, z) = z - 0.25

.....and that's before we get to the reality where the user's understanding of "edge" isn't topological (as in, component of intersection between surfaces), but geometric (sharp corners).

B-reps can get away with making no distinction between them... Until you have messy geometry from elsewhere.

Say, an STL file from a scan. Or a mesh that came from an F-rep by marching cubes. Or whatever unholy mess OpenSCAD can cook with CGAL.

It doesn't matter if you use F-rep or convert to one: chisel out a cube as an intersection of half-spaces, then cut with half-spaces that narrowly touch the edges.

It'll look like a cube, and it'll be a cube functionally if you manufacture it.

Good luck with that one.

>If you have good ideas for this I'd love to hear them and resume working on Isoform

Well. The good news is that putting fillets on every edge is kind of easy with fields because you can do it with offsets.

If F(x, y, z) is a distance field that defines a solid, G(x, y, z) = F(x, y, z) + c offsets F inwards by c.

G is not a distance field anymore though, it's giving values that arent distances on the outside of convex corners.

Renormalize G to be a distance field, call it G'.

Now offset G' outwards by c: H = G' - c.

Ta-da! Concave corners aren't touched, convex corners are rounded.

Flip the + and -, and you're filleting concave corners (G = F - c is a field that defines an outwards offset that fails to be a distance field inside the body near concave corners; compute G' — the distance field for G; offset G inwards: H = G' + c).

Now, the "just normalize a field into a distance field" is doing a lot of heavy lifting here.

But that can give you something to think about.

It works in the case of a cube if you define the cube to be the intersection of 6 half-spaces. There is a video demonstration of it working (partly) on a cube defined this way in the YouTube link in my comment above.

I define a surface to be the region of space where a particular SDF evaluates to 0. You define a solid to be the region of space where that SDF evaluates to <0, but they're broadly the same concept.

It is no problem to ensure that all primitives & all extruded sketches are defined so that each face gets a different surface id, and you would of course want to do this if you want to be able to fillet them.

You're right that there is a difference between an edge and between a pair of surfaces, but finding edges in SDFs is much harder than finding pairs of surfaces. If they intersect along more than one edge then you'll get the fillet along more than one edge. SDFs don't even have concrete "edges" in the general case. I'm not worried about this. Being able to fillet the intersection of 2 surfaces (solids) would satisfy me, but I haven't even got that far.

I'm not trying to find a solution that involves treating edges as "special". That's B-rep thinking. I don't mind if a "fillet" between 2 surfaces that do not touch but are closer together than the fillet radius creates a bridge between them, as long as it is smooth, continuous, and predictable.

It doesn't have to approximate the B-rep way, it just needs to be practically useful for turning sharp edges into rounded ones in a way that lets the user decide where.