The problem with (3D) CAD I've heard is that the Open CASCADE CAD kernel is a huge mess. So as much as they update and fix FreeCAD (and they've made a lot of good progress, but it's still very rough around the edges) they're always going to be hampered by that. And making a new CAD kernel is a massive undertaking.

▲

crote 8 hours ago | parent | next [-]

While this is definitely true, for a long time FreeCAD hasn't exactly made it a high priority to properly work around that.

For example, the Topological Naming Problem (as I understand it) is made quite bad due to OpenCASCADE design - but as we've seen with 0.19 and later it is possible in a lot of cases to work around that. But that's a lot of really hard work with relatively little reward, so for years it languished on the backlog, and users had to deal with even trivial designs randomly blowing up in their face for no clear reason.

The result is a CAD program filled with footguns. Nobody wants to address structural issues, so you just pretend they don't exist, hide a half-baked tutorial on a Wiki on how to work around the worst of them, and blame the user for holding it wrong.

Commercial applications can solve this by shoveling copious amounts of cash at any skilled developer who is able to make any real-world improvement - even when it's not a perfect solution yet. FLOSS applications have to wait for a developer to come around who is masochistic enough to tackle it for free.

▲

wincy 13 hours ago | parent | prev [-]

Question for someone who is very far away from this kind of development - why does CAD software need a kernel that’s wholly separate from the UI? Why aren’t they the same thing? I just don’t understand the abstraction that necessitates writing the software this way.

	▲	duffmancd 8 hours ago \| parent \| next [-]
		It is much like a game might use a physics engine, or a new language might use the LLVM backend. To overly simplify, a CAD kernel will keep a list of operations (make a cube of this size here, drill a hole of this depth here, round these edges but not those). And combine that into a final volume. These responsibilities only get more and more complex as a part gets more complex - so using a pre-built engine allows CAD software to focus on tools and workflows to translate human instructions into lower-layer kernel geometry: the UI/UX. It also crosses into compatibility, if you use the same Kernel as another CAD it is much simpler to export/import from them. Otherwise you would have to reimplement their kernel (or enough of it), or be stuck exporting triangulated versions of the final volume - sort of like converting an image from vector to raster.
	▲	crote 8 hours ago \| parent \| prev [-]
		Same reason a browser uses a separate library for image decoding, or font rendering. A CAD kernel is a very complicated piece of heavily specialized math. The UI itself is there to let the user construct the input data for the CAD kernel and to display the resulting output. Doing that translation in a user-friendly way is already hard enough without having the kernel smeared out all over the rest of the application.