This isn’t just basic CRUD software that just needs some Postgres constraints to model trivial business logic. These are genuinely hard problems that mathematicians have been working on for decades.
There exists an insane amount of questions in topology that have (by our current understanding) nothing to do with CAD or even computational geometry.
> These are genuinely hard problems that mathematicians have been working on for decades.
The hard problems that mathematicians in topology work on are nearly always very different from what you think modern topology is about.
I'm not an expert, but these types of heuristics intuitively seem hard to model. The goal is to guess the user's design intent. There's often no single correct answer, it may require information from parts of the system that the core application's model doesn't have, there may be many heuristics depending on what's being designed.
These heuristics seem like exactly the sort of thing that commercial CAD applications can afford to spend resources on, and that open-source community-driven applications would struggle with.
No. Sorry, I should have been clearer. None of the open source programs handle this.
> These heuristics seem like exactly the sort of thing that commercial CAD applications can afford to spend resources on, and that open-source community-driven applications would struggle with.
This seems like one of those things where "the industry" converged to a solution and the people outside of it simply don't know what it is.
Read the article:
> https://wiki.freecad.org/Topological_naming_problem
"This problem is not unique to FreeCAD. It is generally present in CAD software, but most other CAD software has heuristics to reduce the impact of the problem on users."
So, the problem exists in (nearly?) all CAD systems, but in the big expensive commercial CAD programs, a huge amount of manpower was invested to hide the problem better to the user ("heuristics to reduce the impact of the problem on users") so that the users will see much more rarely see such a problem, and thus often won't be aware of the existence of the topological naming problem.
The geometric kernel is doing boundary representation operations so when you do a boolean or a fillet, it doesn’t “edit” existing faces, it computes an entirely new b-rep from scratch. The old faces, edges, and vertices are gone and new ones are created to replace then. There’s nothing to hang a persistent ID on because the entities themselves are ephemeral.
There are solutions to the problem but they all break down eventually. I think freeCAD uses topological tracing and naming schemes so it encodes a face’s identity by how it was created. e.g., “the face generated by the intersection of extrude_1 and the XY plane.” The problem then is that parameter changes or operation insertions in the history can destroy those too, creating a new feature that can’t be easily mapped to the old ones. That’s where all the heuristics come in.
Unique IDs are used internally, but they only last for the lifetime of one evaluation. The hard part is establishing the equivalence between entities across re-evaluations when the topology itself may have changed.