But I am just going to put this here so the general thoughts incorporate a fundamental problem before significant labor investments go too far:
What is a probable, viable, possible answer to the geometry kernel problem?
Parasolid, arguably the leader and generally most capable geometry kernel we have today, is or at least I can't see past...
...is just not something easily duplicated.
There are a bazillion man months of time in that body of code. And those are hard hours!
For those unfamiliar, the geometry kernel is the piece that resolves geometry cases to make operations possible. Imagine a cylinder and rectangle. Now imagine they have some common volume. They intersect, in other words.
Put a fillet on one edge to blend the edge.
How many literal edge and corner cases can you come up with?
There are way more than you think!
Now multiply that tiny problem space with all the geometry used every day.
And then multiple that time again by what it takes to make it robust.
And the whole thing, as it stand today is not even multi-threaded!
Any CAD that we expect to see even moderate general use in a professional sense, needs this piece.
How do we, meaning anyone interested in CAD this way, get past this?
I wish there were some OSS type license for Parasolid. It could be treated like the Linux kernel.
Whatever replaces Parasolid and friends, should be treated like the Linux kernel.
The closest we have is Open Cascade.
Sorry. I do not want to piss on a good vision. But this has to be said.
Great comment! I think the size and scope of BRep modeling kernels is lost on 99% CAD users. IMHO: I have reached the point where I think there should be a generation of library development before a CAD application is even considered. This is coming from a person who has spent 10 years on an open source cad application, so I am not naive. The modeling kernel, of course, is lacking but also 3d visualization needs some love. More options in that space, but still lacking.
Thanks a lot for the thoughtful and respectful reply! I really appreciate that you raising the engine issue without dismissing the whole idea.
Although building such engine requires tons of work, but the engine we’re having is indeed a bit of old. Except for the problems I mentioned, you also mentioned they’re still single threaded. That’s why I think it’s still worth building a new one, especially when there’s no good open sourced one currently.
I’m a big supporter of open source. If we have something like that in the future, we should of course make it open source like Linux kernel and allow everyone to enjoy the benefit of it.
CAD is close to my heart. I jumped in during the 80's as a high schooler running on an Apple 2! Even back then, limited 8 bit CAD could do a lot. And it was one application that helped me see the future! Product design was gonna change as manufacturing already was and the people who knew CAD were gonna be there.
Now here we are, and the CAD companies own design and manufacturing.
I had a flash of an idea this morning reading your comment:
Perhaps we could license Parasolid for a year, or maybe we try what tomfoolery I am about to put here with Open Cascade.
Maybe an AI model of some kind can get us a leg up?
Going back to the fillet example I put here earlier, I want to share a bit of backstory...
I was at SDRC, who had built out a fantastic concurrent engineering and analysis system called I-DEAS. I loved that CAD software and was an applications engineer and trainer on it. Taught many groups of engineers how CAD works, and I got to do that on a system that had collaboration built in from the beginning! Fully revision controlled concurrent engineering and analysis. Fun stuff.
But it died.
My years of skills gone. Kernel could not keep up. So I moved all that onto what is NX today and many of the best parts of the software I loved ended up being implemented because some mergers resulted in the same smart people being product managers! I am particularly redeemed!
And therein lies the lesson of the geometry kernel. You build your true skill on Parasolid systems or risk seeing them lying dormant, cast aside.
The kernel upon which I-DEAS was built was written in Fortran 90. Beautiful software too. It offered capabilities well ahead of Parasolid in some ways, but consistently failed on some common geometry cases that come up rather frequently. Things tangent to things, touching a a point was a big one.
One thing I taught was overbuild or underbuild. Rather than draw a rectangle tangent to a circle to prepare for an extrude, place that end of the rectangle inside the circle and let a boolean operator sort out the two resulting solids.
So yeah, build it kind of wrong so the kernel can build solids. Messy. :)
I was in a room talking to the people who do fillers. Edge blend to some of us.
We talked about my fillet gauntlet. It was a collection of geometry cases that fillet operations failed to complete.
Parasolid could always resolve more of them, and it did that with fairly sloppy tolerances. The SDRC kernel was catching up each rev, but the trend line looked like a decade of analysis of the successful resolutions, and coding for those, wash, rinse repeat a lot.
I wonder if it might be possible to generate geometry cases using parameters such that whole problem spaces could or can be created. Have good kernels solve and train an AI on all that to see what it may then solve differently?
I really appreciate your reply — it's an honor to hear from someone with such deep experience in the field. Your insights from decades of working with CAD and kernels are incredibly valuable, and it means a lot that you'd take the time to share them here.
The idea of parameterizing geometric problem spaces and learning from how different kernels handle them is strikingly similar to what compiler researchers have done in CS: generating corner cases, analyzing compile errors, and training AI to self-correct. AI coding is used widely in the industry currently, with tools like cursor gaining huge popularity.
And the move to a text-based representation is what makes this all tractable — binary formats never gave us that level of observability or editability. With source-level CAD, it becomes much more realistic to analyze failures, share test cases, and eventually integrate AI tools that can reason about geometry the same way they reason about code.
Today, a solid consists of the following entities that follow the golden rule; namely, each edge is shared by two and only two surfaces: [0]
Solid Cubish
6 faces bounded by 4 edges each, having endpoints, etc...
Each edge is a curve [1] that lies on the surface so as to bound it to a precision small enough that there are no gaps between the curves and the surface edges they define.
Various bindings and or other data elements:
Centroid
Vertices, each attached to three edge endpoints considered equal given a system tolerance.
[0] Where an edge is alone, the resulting non manifold has a hole in it somewhere, and or is a surface body where a large number of edges stand alone.
Where an edge is shared by more than two others, that is a self-intersecting body.
Neither case is actually manufacturable
[1] In modern CAD, everything is a curve. Lines are NURBS curves having only two control points. Earlier CAD actually used all the entity types directly, not just deriving them on the fly from the NURBS.
Arcs are curves with 3 specifically placed control points.
Hyperbola, Conic, Parabola, are the next order up, 4 control points, and above that is the Bspine. 5th degree, and above curves.
Why can't we tokenize those things gs?
At the core, it is all NURBS curves and surfaces. Those two can represent all that we need.
The relations are all just text, names of entities and how they are related.
Even the NURBS have text forms.
Eg:
Plane [point 1, 2, 3...]
That data is where both the problems and answers are, in this training sense.
How can it not?
What I put before was basically the idea of generating a case, say conic section and cube/rectangle.
Generate common volume case 1 in modern kernel and output text representation of it. That exists today.
Then generate ideal edge blend solution 1, and minimum radius case 1, maximum radius case 1.
Output those and we have in text:
Problem case 1 of problem space 1.txt
Ideal, or common edge blend solution.txt
Max radii case 1.txt
Minimum radii case1.txt
Then proceed to generate a bazillion of these, until the problem space of a conic section intersecting a rectangular body is represented fully enough for AI models to operate and even potentially demonstrate emergent behavior like they do on text and code today.
Edit: Ahh, I see. Lol, read in the cad code and have an AI rewrite it? Maybe, but doubtful.
I live seeing efforts like this.
But I am just going to put this here so the general thoughts incorporate a fundamental problem before significant labor investments go too far:
What is a probable, viable, possible answer to the geometry kernel problem?
Parasolid, arguably the leader and generally most capable geometry kernel we have today, is or at least I can't see past...
...is just not something easily duplicated.
There are a bazillion man months of time in that body of code. And those are hard hours!
For those unfamiliar, the geometry kernel is the piece that resolves geometry cases to make operations possible. Imagine a cylinder and rectangle. Now imagine they have some common volume. They intersect, in other words.
Put a fillet on one edge to blend the edge.
How many literal edge and corner cases can you come up with?
There are way more than you think!
Now multiply that tiny problem space with all the geometry used every day.
And then multiple that time again by what it takes to make it robust.
And the whole thing, as it stand today is not even multi-threaded!
Any CAD that we expect to see even moderate general use in a professional sense, needs this piece.
How do we, meaning anyone interested in CAD this way, get past this?
I wish there were some OSS type license for Parasolid. It could be treated like the Linux kernel.
Whatever replaces Parasolid and friends, should be treated like the Linux kernel.
The closest we have is Open Cascade.
Sorry. I do not want to piss on a good vision. But this has to be said.
Peace and good luck!
I used voice input on this. Pleqse forgive typos.
Great comment! I think the size and scope of BRep modeling kernels is lost on 99% CAD users. IMHO: I have reached the point where I think there should be a generation of library development before a CAD application is even considered. This is coming from a person who has spent 10 years on an open source cad application, so I am not naive. The modeling kernel, of course, is lacking but also 3d visualization needs some love. More options in that space, but still lacking.
Thanks a lot for the thoughtful and respectful reply! I really appreciate that you raising the engine issue without dismissing the whole idea.
Although building such engine requires tons of work, but the engine we’re having is indeed a bit of old. Except for the problems I mentioned, you also mentioned they’re still single threaded. That’s why I think it’s still worth building a new one, especially when there’s no good open sourced one currently.
I’m a big supporter of open source. If we have something like that in the future, we should of course make it open source like Linux kernel and allow everyone to enjoy the benefit of it.
Me too, and you are quite welcome!
CAD is close to my heart. I jumped in during the 80's as a high schooler running on an Apple 2! Even back then, limited 8 bit CAD could do a lot. And it was one application that helped me see the future! Product design was gonna change as manufacturing already was and the people who knew CAD were gonna be there.
Now here we are, and the CAD companies own design and manufacturing.
I had a flash of an idea this morning reading your comment:
Perhaps we could license Parasolid for a year, or maybe we try what tomfoolery I am about to put here with Open Cascade.
Maybe an AI model of some kind can get us a leg up?
Going back to the fillet example I put here earlier, I want to share a bit of backstory...
I was at SDRC, who had built out a fantastic concurrent engineering and analysis system called I-DEAS. I loved that CAD software and was an applications engineer and trainer on it. Taught many groups of engineers how CAD works, and I got to do that on a system that had collaboration built in from the beginning! Fully revision controlled concurrent engineering and analysis. Fun stuff.
But it died.
My years of skills gone. Kernel could not keep up. So I moved all that onto what is NX today and many of the best parts of the software I loved ended up being implemented because some mergers resulted in the same smart people being product managers! I am particularly redeemed!
And therein lies the lesson of the geometry kernel. You build your true skill on Parasolid systems or risk seeing them lying dormant, cast aside.
The kernel upon which I-DEAS was built was written in Fortran 90. Beautiful software too. It offered capabilities well ahead of Parasolid in some ways, but consistently failed on some common geometry cases that come up rather frequently. Things tangent to things, touching a a point was a big one.
One thing I taught was overbuild or underbuild. Rather than draw a rectangle tangent to a circle to prepare for an extrude, place that end of the rectangle inside the circle and let a boolean operator sort out the two resulting solids.
So yeah, build it kind of wrong so the kernel can build solids. Messy. :)
I was in a room talking to the people who do fillers. Edge blend to some of us.
We talked about my fillet gauntlet. It was a collection of geometry cases that fillet operations failed to complete.
Parasolid could always resolve more of them, and it did that with fairly sloppy tolerances. The SDRC kernel was catching up each rev, but the trend line looked like a decade of analysis of the successful resolutions, and coding for those, wash, rinse repeat a lot.
I wonder if it might be possible to generate geometry cases using parameters such that whole problem spaces could or can be created. Have good kernels solve and train an AI on all that to see what it may then solve differently?
Maybe man years boils down to compute/watt hours?
I really appreciate your reply — it's an honor to hear from someone with such deep experience in the field. Your insights from decades of working with CAD and kernels are incredibly valuable, and it means a lot that you'd take the time to share them here.
The idea of parameterizing geometric problem spaces and learning from how different kernels handle them is strikingly similar to what compiler researchers have done in CS: generating corner cases, analyzing compile errors, and training AI to self-correct. AI coding is used widely in the industry currently, with tools like cursor gaining huge popularity.
And the move to a text-based representation is what makes this all tractable — binary formats never gave us that level of observability or editability. With source-level CAD, it becomes much more realistic to analyze failures, share test cases, and eventually integrate AI tools that can reason about geometry the same way they reason about code.
Perhaps text answers are possible?
Today, a solid consists of the following entities that follow the golden rule; namely, each edge is shared by two and only two surfaces: [0]
Solid Cubish
6 faces bounded by 4 edges each, having endpoints, etc...
Each edge is a curve [1] that lies on the surface so as to bound it to a precision small enough that there are no gaps between the curves and the surface edges they define.
Various bindings and or other data elements:
Centroid
Vertices, each attached to three edge endpoints considered equal given a system tolerance.
[0] Where an edge is alone, the resulting non manifold has a hole in it somewhere, and or is a surface body where a large number of edges stand alone.
Where an edge is shared by more than two others, that is a self-intersecting body.
Neither case is actually manufacturable
[1] In modern CAD, everything is a curve. Lines are NURBS curves having only two control points. Earlier CAD actually used all the entity types directly, not just deriving them on the fly from the NURBS.
Arcs are curves with 3 specifically placed control points.
Hyperbola, Conic, Parabola, are the next order up, 4 control points, and above that is the Bspine. 5th degree, and above curves.
Why can't we tokenize those things gs?
At the core, it is all NURBS curves and surfaces. Those two can represent all that we need.
The relations are all just text, names of entities and how they are related.
Even the NURBS have text forms.
Eg:
Plane [point 1, 2, 3...]
That data is where both the problems and answers are, in this training sense.
How can it not?
What I put before was basically the idea of generating a case, say conic section and cube/rectangle.
Generate common volume case 1 in modern kernel and output text representation of it. That exists today.
Then generate ideal edge blend solution 1, and minimum radius case 1, maximum radius case 1.
Output those and we have in text:
Problem case 1 of problem space 1.txt
Ideal, or common edge blend solution.txt
Max radii case 1.txt
Minimum radii case1.txt
Then proceed to generate a bazillion of these, until the problem space of a conic section intersecting a rectangular body is represented fully enough for AI models to operate and even potentially demonstrate emergent behavior like they do on text and code today.
Edit: Ahh, I see. Lol, read in the cad code and have an AI rewrite it? Maybe, but doubtful.
A bounty on... um yeah. 'Nuff said.
https://en.wikipedia.org/wiki/Open_Design_Alliance