First I am trying to understand the basic CAM algorithms. That involves testing them and playing with them in MATLAB. Then I think I will try to implement them in some language. It probably make sense to use C, but call the C-functions and do graphics etc. in Python.

After that we'll see if there is enough interested open source developers to really build a working GUI around the algorithms. I'm not particularly good at OpenGL or GUI programming. CAD file import (DXF, IGES, etc etc) is another major thing which I don't find particularly thrilling to program.

As you noted the brute-force thing eats up a lot of memory. So does triangulated surfaces, but I think they are the industry standard currently. That would be another major thing for a working CAM system: everything except points, lines, arcs, and triangles will have to be tessellated into those primitives(at some given resolution).

For a cutting simulation you would use exactly the type of model you describe, a forest of 'match-sticks' standing up along the z-axis and being shortened to the proper length wherever the cutter travels. I understand the Freesteel stock model works like this, but it is somehow adaptive so you use a dense grid of match-sticks where you need them, and less sticks in flat areas.

In addition to this drop-cutter stuff the other major thing that is needed for basic CAM functionality is 2D curve offset. With those two basic algorithms I think we can create most toolpaths that we have used on our mill. I don't think adaptive stuff and 'intelligent' complex 3D paths are needed to make a first open source CAM package that would still be popular among users.

Anders

But wouldn't a brute force approach be a sensible solution with today's computing power? Just draw depth maps of cutters and machined model with adequate resolution (1µm grid?). Then just compare them point by point to ensure that they stay within allowed depth. Cutter map could be used to "eat" the model map so it would be easy to figure out the rest material.