Yep. Here it is in hard maple where I had the original problem. This cut is entirely equivalent to the Estlcam cut. I think I could reduce the tolerance even further without data starvation, but don’t think I need to.
One other interesting point is that this gcode file is still only about 60% the size of the Estlcam file. I did notice the Estlcam algorithm was not nearly as efficient, but that likely does not account for that much of the size difference. I believe they are by default using a higher tolerance, and if that file didn’t result in starvation then even further tweaks to the Fusion parameter would probably work. I suspect .003 would be just fine.
This is a much closer view than the previous.