hckrnws

Solvespace has a fairly robust solution to this problem - for the cases that it handles. It does not create accessible edges for things like the intersection of surfaces, which won't be a big deal until we have a chamfer/fillet tool where you might want to modify those edges. But change an underlying sketch all you want and all geometry built from it will remain intact except for stuff built on something you delete.

IIRC the FreeCAD solution tends to create names of ever-increasing length as you continue building.

I learned about it the hard way, ahah. Now I create intermediary planes for all distances and I extrude planes always with respect to those.

Similar approach is to create a master sketch which is a sketch that defines the major dimensions of your design. You can then 'attach' bodies and planes (or LCSs) to different parts of the sketch. The approaches are similar but it allows constraining all of the distances relative to each other using the sketcher rather than hard-coding or using math expressions. It's the only workflow I've found that doesn't have me pulling my hair out with more complex designs, but it definitely has downsides too (requires excessive subshape binders, sketcher is slow, overall it feels slower than bottom-up design).

I keep making the same mistake. How do you make intermediary planes?

Normally, I select a face and add a datum plane. It's button is in the toolbar with a the datum point and datum line buttons in light blue iirc.

That said, since v1.0, I've had far fewer instances of being affected, and have started doing some direct-on-face features (usually sketches) again.

This is described in the wiki page, at the section solution.

Unless I missed it, the article doesn't answer the first question you'd ask: Why don't they just generate unique IDs for everything and use those internally, instead of names that get changed all the time?

Whether it's unique IDs or names, the problem is the same: topology changes destroy the things you’re identifying. When you have a box and you assign ID face_007 (or a generated unique ID) to its top face, that works fine until you fillet an edge adjacent to that face. Now the kernel has to recompute the geometry and depending on the operation, face_007 might still exist in a different shape, might split into multiple faces, or be destroyed completely.

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.

Sounds like it is maybe an ill-defined problem. So step 1 should be to describe non-ambiguously what should be solved here.

Step 1: Solve the entire mathematical field of https://en.wikipedia.org/wiki/Topology

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.

> Step 1: Solve the entire mathematical field of https://en.wikipedia.org/wiki/Topology

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.

So why is it that every 3D CAD program other than FreeCAD seems to have something that solves this problem "well enough" that most people doing simple designs (aka everything you could possibly print on a 3D printer) don't seem to bump into it?

> So why is it that every 3D CAD program other than FreeCAD seems to have something that solves this problem "well enough" that most people doing simple designs (aka everything you could possibly print on a 3D printer) don't seem to bump into it?

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.

Do you know of any free/open-source examples that solve this problem well?

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.

> Do you know of any free/open-source examples that solve this problem well?

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.

They have that but when you change something, often some elements get deleted and others are added. Now you need to figure out how they relate to the previous elements and that’s very hard it seems.

[dead]

It's what caused me to move away from FreeCad to OnShape. Never had an issue in OnShape but got hit with it every time in FreeCad. The sad thing is that there was a fork for a long time which had addressed this problem, and added other nice enhancements as well, but they never merged that work. I guess every org has political problems and FreeCad is no exception.

The wiki page explains that as from Freecad 1.0, the work done by Realthunder in the topological naming problem has been merged into Freecad. Not that everything is solved. Just to mention that the work of Real thunder was not lost.

Glad to hear it as I moved away before 1.0 happened. RealThunder had other enhancements as well, if I remember correctly. I wonder if those were taken up as well.

Sadly the fast and smooth renderer wasn't taken. So last I tested, mainline v1.1 is still not able to work with big models. Try loading the full Voron 3D printer step file.

This fast renderer also closes and add hashed faces to cross sections views, instead of showing some buggy view of the inverts faces of the model.

Furthermore, the sketcher since mainline v1 is very laggy. Every click lags because its trying to draw the dimensions while you move them around but it's somehow slow and irritably laggy.

Finally in general, mainline also plenty of weird UI jitter and flicker. As if some code is fighting to resize elements back and forth during use.

Oh and the pie menu also wasn't copied either. On the realthunder fork a double press on "g" brings a menu under the mouse that quickly list the geometry near the cursor sorted by type, highlighting it as you hover on the selection. This is fantastic because of how bad freecad is at guessing what you are trying to select.

But mainline got a new color scheme and torturously slow UI animations that cannot be fully be disabled. This shows where are the priorities in my opinion.

To finish on a note of hope, at least I have noticed more open source projects using freecad rather than proprietary alternatives lately.

Realthunder also lets the sketchers use projected geometry as real geometry, rather than only as construction geometry. And automatically creates shapebinders, which is very convenient. I still prefer it, but 1.0 works better with add-on toolboxes like Lattice2.

The ability to pull in projected geometry as real geometry or construction geometry is in the release candidate for V1.1 that should be released reasonably soon. There's a lot of other cool features in V1.1 as well.

I treat FreeCAD as a rolling release, using the dev version on a decently complex model [0] and it has been a really good experience so far. Lots of useful features and fixees going in all the time.

[0] https://github.com/dekay/vpin-cabinet/

Oh yes, which is so useful. I am still using his now outdated fork. Hoping that at some point mainline gets performant enough for me to switch and learn new workarounds to different bugs.

This isn’t accurate. FreeCAD merged the main changes from that fork (RealThunder) to fix (well, mitigate) the problem. That’s the big thing with 1.0.

Although… as others have noted, this is a problem with basically all CAD packages, as on a fundamental level, it depends on user design intent. Just some have enough bandaids that it’s more rare.

My statement was accurate as of _when_ I moved away from FreeCad. I'm happy they merged the RealThunder work. But they dilly-dallied for a long time while people were demanding a fix and one was available. Doesn't speak well of their org politics.

The org politics (which has actually improved tremendously in the last 3 years), in particular related to realthunder's solution, was related to code compartmentalization and maintainability. Yes realthunder's solution worked, and he submitted massive monolithic PR's to FreeCAD main for integration and then basically disappeared. Ultimately, it ended up getting chunked out into smaller parts and reverse engineered and restructured by a couple of other FreeCAD dev's under grants paid for by FreeCAD and it took them about a year to accomplish. The man who did the bulk of the work, Brad McLean, unfortunately died shortly before 1.0 released with all of his work included in it.

Not trivial work.

I’ve experienced similar problems (not totally sure if they were exactly the “topological naming problem” but certainly similar from the description) in Solidworks many times. Not usually a major problem - just a reworking or removal / re-adding of some features needed.

I’ve not encountered the same issue in FreeCAD 1.1 (to which I’ve transitioned recently). There are of course other frustrating niggles in FreeCAD, but not this one (yet).

I had the same experience, but instead of moving away from FreeCAD to OnShape, I moved to the fork that you mentioned, by RealThunder. Works great! Eventually the main branch mostly caught up.

How does OnShape handle that problem? The linked page seems to make the case that most CAD suffers from this, others just "hide" it better;

> 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.

Most CAD software have a mapping algorithm that remaps the new features to the old features after a topological restructure using a combination of topological id systems and heuristics.

Solidworks and Onshape don’t “hide” it better, their algorithms are better and break down in much more complex models than FreeCAD. Each one also tends to have its own quirks so as you learn to use the software you get a bit of intuition on how to best model certain features to avoid angering the topological naming gods.

I don’t think I’ve ever seen Solidworks break down in a simple model, it’s always been in complex shapes using advanced features.

I think the word “solve” is better than “hide” here.

Fusion 360’s heuristics are so good that I rarely run into these problems. When I do, it’s usually because it was a drastic change to a previous feature in the timeline and I’m expecting to encounter issues because it’s a really fundamental change.

that's basically because all commercial cad software are built on the same 3 geometric kernels (none of which are open source) and have robust and mature solutions. FreeCAD's is improving over time but it's a game of catch-up and the math and algorithms involved are complex.

The kernel FreeCAD uses doesn't really have a robust heuristic for this, so FreeCAD had to implement its own.