I think I've found the problems with my C# drop-cutter algorithm. The first bug was a trivial one where in the edge-test the rotation of the segment-under-test was messed up. The second one was not the facet-test itself but incorrect surface normal data. There's something going on that makes pre-calculated surface normal data not 'stick' correctly to the triangle object for later use. So here I'm re-calculating the normal data again just before the facet test.
The next step is to speed up things with a smarter kd-tree based search for which triangles are under the cutter. I've added bounding-boxes to the Cutter and Triangle classes. Running the above example the DropCutter function is called a total of 4735000 times, and of those only less than 5%, or 236539 to be exact, are useful calls, i.e. the triangle bounding box intersects the cutter bounding box, which means there's a chance that we are contacting the cutter against the triangle. The idea with the kd-tree then is to pre-search for triangles under the cutter to make less of those (supposedly expensive) redundant calls to DropCutter.
On my T5600 processor machine the above example runs in about 5 seconds. (1894 triangles, about 4.7 Million calls to DropCutter of which ca 240k calculate something). I've made a list of useful CAM-related things to work on: CAMToDo.
Now that looks pretty!
I would concentrate on filling missing algorithms and leave optimizations later. That way you won't lose the optimzations if changes are needed and code is easier to follow, too.
hello Anders,
thank you for your response to forum question.
do you know why they do not like to discuss sw matters? or the forum is only for their products sale?
thank you again for your comments, i am looking at?
elwolv
Hi Elwolv,
I have no idea why the moderators of CAD_CAM_EDM_DRO would not like to see discussion about CAM or real-time software on the list. Ofcourse it could get a bit technical, but I don't see why that would be a problem.
AW
Have you seen optimization notes from Julian :
http://www.freesteel.co.uk/wpblog/2007/09/offsets-of-triangulated-surfaces/
Hi Neel,
Yes, interesting post again by Julian. There are a lot of obvious optimizations that I haven't looked at yet.
Right now I would be more interested in adding functionality. When we have something nice that works I could then work on a bucketing scheme to make it faster.
For raster-finishing we need a function that takes a bunch of triangles and calculates the 'outline' as seen from above (along the z-axis).
Then we need another function that takes this outline and generates zigzag-paths inside it.
When we have those two, the raster-finish strategy steps along the zigzag path at some sample-rate and uses dropcutter to compute the z-coord of the tool at all points.
The other major thing I'm thinking about (but not making much progress...) is 2D offsetting. That will be required for a lot of strategies very early on too.
anyway, hopefully people interested in open-source CAM don't hold their breath for anything. I'll write some more code when I feel like it and when I have a clear idea for an algorithm or function in my head.
my code is at http://code.google.com/p/monocam/
Anders
Hey, I just wanted to let you know i've started looking some at the code again, trying to get my head around opengl some more ^_^
Good to hear that, I thought the project was dead.
http://web.media.mit.edu/~neilg/fab/dist/cam.py is a python code which can create Z slices and Raster passes on STL model.