Hacker News Reader

Comment by donquichotte | Hacker News Reader

It's also remarkable that while in many areas with "theory-heavy" software development (e.g. compilers), the open-source solutions are arguably better than the proprietary ones, this is not at all the case for mechanical CAD software. I wonder whether the overlap of people who can program, people who know enough math to develop a mechanical CAD software and the people who care about mechanical CAD is just too small for a successful open source effort.

Yes, there is FreeCAD and OpenSCAD, but every time I try to use them, I give up in the end and whip up something in Fusion360.

View on HN

Except that they are not.

Proprietary Fortran compilers beat most of the open source alternatives, when some complain about Fortran performance usually 99% of the times they are using gfortran.

Thanks to its license, many of the cool optimizations used by LLVM aren't upstreamed actually, and are kept by the OEMs like Sony, Apple, TI, ARM for their own toolchains.

In HPC, many of those GNU/Linux clusters done in collaboration with IBM tend to make use of xlc.

No JIT compiler, or GC implementations, for the pure open source managed runtimes tend to be on the same ball park of the work going on Java, .NET and JavaScript, all sponsored by deep pockets corporations.

No CUDA based open source clone beats NVidia and PGI compilers targeting NVidia hardware.

What most open source compilers have is good enough performance so that a large part of the dev population, that isn't willing to pay for tooling, doesn't care anyway.

At least they all use the same file formats and you can switch from proprietary to OSS with a different makefile.

OSS isn't automatically better, but it changes the strategy and tactics that are used. GNU/GCC enabled and unleashed a movement.

What file formats? Text?

That is meaningless if they don't support the same language features, which is why other than Google's inhouse Android Linux fork, the Linux kernel is hardly compilable with anything else other than GCC C dialect.

GNU/GCC might have enabled and unleashed a movement, but thanks to the mass adoption of non-copyleft licenses, its time has come to pass, and in a couple of generations we will be back to shareware and public domain software packages.

> At least they all use the same file formats and you can switch from proprietary to OSS with a different makefile.

Assuming you don't rely on compiler-specific features.

Except that, for CUDA, they do. https://github.com/NervanaSystems/maxas exhibited significantly higher performance than Nvidia's own SGEMM kernel, and https://github.com/mangpo/swizzle-inventor beats all named competitors in the non-texture-memory-input-using implemention. Namely, NVIDIA Performance Primitives, ArrayFire, and Iandola et al ( https://doi.org/10.1109/ICIP.2013.6738436 ).

As for GC implementations: did you consider ZGC in that statement? It's GPL 2.

Yes I did "all sponsored by deep pockets corporations."

Take their money out of the equation and the quality would be as the "state of the art GC" that CPython and MRI Ruby enjoy.

I see. Your sentence structure is a bit confusing and was successful in causing me to parse it as if you were referring to Java, .Net, and JavaScript with pure open source managed runtimes.

I guess people who can do the math would like to get paid properly for their efforts.

I think a big part of why this happens is that a lot of the fundamental math of CAD doesn't have good answers - everything is heuristics and approximations to within a tolerance.

You can get a simple NURBS kernel up and running in maybe 2 dev-years. But getting good heuristics created for all of the common edge cases is what takes the huge number of dev-decades, and what you pay for with one of the commercial kernels. You won't even know what the common edge-cases are until you start getting user reports of things failing, so you'll need to be doing this development with a large community of users.

There is no closed-form formula to tell how long a NURBS curve is. Offsets of NURBS curves are not NURBS curves. Likewise, intersecting NURBS surfaces produces intersection curves that are not possible to represent as NURBS curves.

So something as simple as a fillet is impossible to exactly produce in like 3 ways. Booleans then add the joy of topology to the mix. It's all heuristics and approximations and dirty hacks.

While this is true of programs like Rhino, it's not as true for fusion360. There are no NURBS in fusion360. I would guess that the fusion360 kernel is very focussed on deterministic solutions, specially being constraint based, where the errors in heuristics would multiply across the history. Interestingly, in situations where the math has more guesswork, as I think lofts and such are, fusion can be really quite bad. Rhino is amazingly good (and it's many many years old). Fusion360 is just a baby but it's pretty good for what it does. Once you use constraints based CAD it's hard to go back.

While Fusion 360 does have many non-NURBS procedural surfaces, they definitely also have NURBS. Otherwise you wouldn't be able to import an IGES or step file.

Using a solids kernel with procedural surfaces can help many cases, as you keep the modeling tree around and can recompute portions at higher tolerance as needed. However that's just another cumbersome workaround to the fundamental problem that the math doesn't have clean solutions.

I guess there is a silly amount of work to make a usefull CAD program. FreeCAD etc has no "auto dimension tool" where you can manipulate dimension or set inter object constraints as in even the worst of the commercial CADs Solid Edge. No assembly either or sheet bending tool.

I tried to use FreeCAD but gave up. It is too limited even for simple designs. I would rather use paper and ruler since you can't easely change stuff anyway.

>FreeCAD etc has no "auto dimension tool" where you can manipulate dimension or set inter object constraints as in even the worst of the commercial CADs Solid Edge.

Unfortunately since I have only used FreeCAD and no other CAD tool I may not know what you are talking about but it is possible to create a spreadsheet inside FreeCAD and give each cell an alias which makes the spreadsheet basically act like a hashmap/dictionary. Every input field in Freecad can be filled based upon a formula. You can just <SpreadsheetName>.<variableName> as the formula and then changing the value of the spreadsheet cell will change the part.

>No assembly either or sheet bending tool.

There are addons for that and I agree that having a dedicated addon for everything is bad because now you need to know whether an addon exists for your usecase and how to find it. Someone who fires up FreeCAD for the first time is going to get disappointed.

Honestly, my biggest problem with FreeCAD is that it crashes and freezes on basic operations like chamfers and fillets. When an operation takes 20 seconds the entire application just stops responding. If the fillet cannot be created there is basically a 25% chance that it will crash. If your fillet radius is too large it will simply show nothing so now you have to play around via binary search to find the maximum value for the fillet.

The other problem is that curved surfaces are hard to do in FreeCAD in general. Of course there is an addon for that which makes it easier but I already have a backlog of addons to try out...

Ye I agree. I tried the assembly addon but I could not get the flow and it did not feel native to the app. If I remember correctly the wiki named three alternative addons.

Honestly my biggest problem with FreeCAD might be that I have already learned Solid Edge and Solid Works in school and at work.

Learning to use CAD software is a nightmare and I rather not do it again.

Since I only do wood work out of work it is just simpler to draw by hand than trying to learn FreeCAD properly to maybe learn that it can't do what I want anyway.

The "auto dimension tool" (I do not know the real name) is a magic ruler that let you change dimensions and inter object relations by just clicking stuff. It introduces constrains too. I understand why it would be a nightmare to program.

The problem with open source is that developers mostly want to scratch their own itch. Understanding someone else's problem requires communication, which is something most developers prefer to avoid, so it seems.

CAD is both math heavy and UI heavy. Getting a good UI right is very hard for an open source project.

Reply on news.ycombinator.com