This is my second attempt at a machining simulation where a moving milling tool cuts away voxels from the stock material. To save space an octree data structure is used to store the voxels, and to produce a nice looking surface you store the signed distance to the exact surface in each vertex of the octree. You then use marching-cubes to extract triangles for a distance=0 isosurface in order to draw the stock.
Unlike my first attempt, this works well enough to warrant further experiments (on the to-do list are: differently shaped tools, colouring triangles based on which tool cut the voxel, lathe operations, material removal-rate, etc.). It should be straightforward to hook this up to the EMC2 G-code interpreter so that any G-code, not just densely sampled CL-points from OCL, can be simulated. You could also flip the sign of all the numbers, and simulate an additive process, like 3D printing (reprap / makerbot).
This approach to machining simulation is described in a 2005 paper by Yau, Tsou, and Tong.
nice work!
It would be interesting to know the wall-clock time the simulation takes...
currently it takes too long.
The triangles should be "cached" and only those triangles which are deleted/added should be changed at each step. The data structure for the triangles should be close to the datastructure which the rendering-systems wants for drawing. Now I'm using VTK and all triangles are requested at each step and they move from the octree into a c++ list, then to a python list, and then through the VTK python wrappers back into c++ again... not very efficient.
The octree partitions space into discrete voxels. If we also allow the cutter to only be positioned at these discrete points in space, then we can build up a lookup table of the distance-field, and just do a table lookup instead of computing the signed distance at each point. (I'm not sure this computation is the bottleneck right now).
AW