Comment by WillAdams
7 hours ago
3D CAD/CAM is still CPU (and to a lesser extent memory) bound --- I do joinery, and my last attempt at a test joint for a project I'm still working up to was a 1" x 2" x 1" area (two 1" x 1" x 1" halves which mated) which took an entry-level CAM program some 18--20 minutes to calculate and made a ~140MB file including G-code toolpaths.... (really should have tracked memory usage....)
That sounds like pretty degenerate behavior. I typically have CAM toolpaths generate in seconds using Fusion or PrusaSlicer.
Is that by convention or is there a good reason that it’s so CPU bound? I don’t have experience with CAD, so I’m not sure if it’s due to entrenched solutions or something else.
> Is that by convention or is there a good reason that it’s so CPU bound?
A lot of commercial CAD software exists for a very long time, and it is important for industrial customers that the backward compatibility is very well kept. So, the vendors don't want to do deep changes in the CAD kernels.
Additionally, such developments are expensive (because novel algorithms have to be invented). I guess CAD applications are not that incredibly profitable that as a vendor you want to invest a huge amount of money into the development of such a feature.
My understanding is that the problems being worked on do not yield to breaking down into parallelizable parts in an efficient/easily-calculated/unambiguous fashion.