> I've seen people quote a good modern CAD kernal as a 100 man year project.

Where Fabrice Bellard when you need him? :)

Why is BREP so challenging? I hear these sort of statements a lot. But often they turn out complicated as much because it’s a crusty code base built on hacks of hacks. What am I missing?

SDF do seem like a cool option. They’re computationally expensive but I’d bet the ray tracing features coming out in GPUs would help with that.

I do think 100 man years is an exaggeration, or maybe they're talking about fully reverse engineering an existing CAD kernel and all the weird proprietary extensions it supports.

In my uninformed opinion working with meshes is hard. In the interest of comparing apples to apples I'll compare a CSG-based approach (joining two mesh objects together) with an SDF-based approach (joining to SDF objects together).

If you want to merge two mesh spheres together you need to do a lot of work. First you need some way of telling whether a point is inside or outside of another mesh. This is because you need to be able to delete all the vertexes/points/faces that are inside the other mesh. So you do that, and you delete all the points/vertexes/faces that are colliding with the insides of another object. Then you need to stitch the two meshes together. This is a whole thing, you need to find the boundary where the two meshes would have collided, create a bunch of new edges along that path while also taking into account where the existing faces on both objects are going to be.

There's a lot that can go wrong during this as well, it's possible for your geometry to be "non-manifold" which means it has no clear inside or outside, and it's really easy to accidentally make an object non-manifold when you're stitching it together with another object. There are issues where sometimes meshes look alright but in reality there are two edges on top of each other, or a face with zero area, or all kinds of crazy stuff. Making a tool that can reliably stitch two meshes together is a pretty big challenge. Than you start talking about adding fillets to vertexes, and how that affects the mesh geometry of other attached faces, and you're having to write some really complicated error prone code for N different combinations of situations. Like what if the chamfer abuts another chamfer? What if it abuts a spheroid? A bunch of edge cases (heh) depending on the faces that your edge butts up against.

With SDFs you just check if the point is inside one object or the other, and than re-generate the mesh from scratch. You write one not-too-difficult mesh algorithm and everything else is basically just OR/XOR/AND-ing things together. It makes defining geometry geometry about as simple as possible, just write a function that can say whether a point is inside your geometry or not. Something you need to be able to do for mesh based CSG anyway, but with a bunch more complications.

This is also why tools like openscad can't do fillet/chamfer joins after 10 years and the tool I threw together in a few weeks can.

https://github.com/traverseda/PySdfScad

Sdf based approaches are just so much better! Agreed.

How do you apply geometric constraints to SDFs?

Excited to see you here!

One approach would be to construct one solid SDF object out of a bunch of 2D SDF object segements: https://iquilezles.org/articles/distfunctions2d/

The "Parabola Segment - exact" and "Polygon - exact" examples in particular. Probably requires some combination of the two for your use case. Basically turn your lines into 2D SDF objects that define the outside of your object.

I think most of those objects actually could be chained together, like the actual quadratic bezier example has a real interior and exterior when you look at it more closely: https://www.shadertoy.com/view/MlKcDD

So yeah, the intersection of a bunch of line segment SDFs like that could do it. A bit more completed than that but that's the basic principle. Not sure about the performance... There is probably a more efficient way to do it, but I don't have the math skills to figure it out.

Oh cool, I’ve used solve space a few times.

My personal idea for how I’d engineer for that is to reframe the problem as “the geometry is a program in a programming language”, and have ways to calculate surface Normals, derivatives, etc.

But you are absolutely correct that choice of representation / data structure makes a huge difference in what’s easy to calculate. And perhaps the best approach would be to internally have tools that can map between different data structure representations based on the calculations on the calculation at hand

How do you perform functions on faces, edges, points and other topological entities with SDFs? Such operations a necessary for parametric CAD.

I would contest they are generally necessary. Applications of parametric CAD are many. Can a jeweller designing a parametric ring do without them? Probably.

That said, you can e.g. calculate derivatives of the SDF and, simply speaking, when they 'flip' you know you found an edge or corner. You can project onto the SDF along a plane or line and 'record' the intersection, use it as input in your model etc.

Similarly, you can treat an area bounded by such edges as a face etc.

Just because there is nothing out there yet doesn't mean it can't be done.

I also predict a great future for SDF based CAD for the simple reason that manufacturing methods mostly used for prototyping now (3D printing) will become more common for final pieces.

And there is no need for an explicit representation (higher order surfaces or polygon meshes) of the shape to get tool paths (often derived from 2D bitmap slices) for these methods.

One thing that probably won't change is the need for things which we design to be made of multiple parts which must be assembled together. For any serious application this requires specifying geometric dimensioning and tolerancing information, which ideally should be tied to the topological entities in question.

I'd argue that this information is becoming even more important with the rise of 3d printing and other digital manufacturing tools. If this information can be included in the CAD data, the manufacturing tool might automatically determine how best to manufacture the part to meet the required tolerances.

Topological information is also useful for analysis. We may wish to apply a load or boundary condition only on a face.

At the moment you don't. What I'm suggesting is that you could build up a conventional BREP-based datastructure, and than use SDF to "render" it. This gives you a very clear separation between your data structure and your meshing algorithm, and as I understand it a big chunk of those "100 man years" would be in dealing with the meshing algorithm and edge cases in it.

I suspect that having a generic meshing algorithm that will always mesh your datastructure with no edge cases would significantly reduce the time needed to implement a CAD kernel. You just need an algorithm that can tell you if a given point is inside or outside of your BREP. All you really need for that is a surface that points at a given direction, and the ability to tell whether a point is under the surface or not. Define your surfaces as BREP, render them using SDF, only have to write one meshing algorithm.

That being said I disagree with your definition for parametric CAD. Mostly the name, I get that you're talking about BREP based CAD. That is one way to do parametric CAD, but CSG can also work, especially if you can do more advanced operations like a filleted difference or union, or blends between two shapes, or other advanced CSG operations. I don't think that CSG-based CAD is inherently worse as long as you've got the ability to do things like fillet/chamfer CSG operations.

You probably don't need to do a fillet along an edge if you can do a fillet where you subtract one object from another, something that SDFs can do easily: https://github.com/fogleman/sdf#smooth_difference

>>these the the central core that understands BREP and implements the geometric operations.

> I've seen people quote a good modern CAD kernal as a 100 man year project. It's probably not going to happen, maybe there's some avenue for government funding?

Perhaps the leverage of AI coding assistants will bring it down to a few man years over the next 5.