Build 7250
I just posted another build, 7250, to http://www.grzsoftware.com/files/MeshCAM-Setup.exe . There are is one bug fix, pointed out by Christian, where low-polygon models could gouge. This was a bug added during my optimizations a month or so ago and I did have to give up part of my speed gains to fix it. I haven’t benchmarked the update yet but I’ll do that in the next few days.
Another user, JB, pointed out a use case for MeshCAM that I hadn’t spent much time thinking about. He’s using MeshCAM for 2D work using the waterline function. The path linking in that module assumes that a roughing pass has been used and anywhere not covered by the geometry is a free path to move the tool in. I added a "Use Full Retracts Only" option to waterline that will stop this behavior since it can run the tool into part of the unroughed stock. The only case I can think of using this is when using waterline without roughing first. Most of you will want to leave this unchecked. Let me know if you think of any other uses for this.
I’m still working on the bugs everyone has submitted and am going to try and keep this release pace up until I get everything resolved (assuming I can replicate the bug reports).
"Normal" retracts on the left, Full retracts on the right.
Build 7248
I just uploaded another build to http://www.grzsoftware.com/files/MeshCAM-Setup.exe . It contains only one fix- Joe S. helped provide me with a file that demonstrated the rare "horizontal edge gouging problem" that has been lurking for a while. I was able to reduce the file to only two triangles that demonstrated the problem and find the bug. It was in an area deep within MeshCAM so I tried to limit the changes to the minimum required to make the problem go away. As it stands I believe the problem is gone but I may go back and reengineer some of this code for V3 to make it more robust.
Build 7246
I just uploaded a new build that fixes the crashing that could appear when calculating the toolpaths for image geometries. I’m not sure when this bug got put in there but it should have been evident for quite a while. I had a user, John K., that put some heavy duty debugging work in to help me find it. It ended up be due to the multithreading try to read and write the same memory locations at the same time. Rookie mistake.
http://www.grzsoftware.com/files/MeshCAM-Setup.exe
I have a couple of more outstanding bugs to work through in the next week or two and then this will be moved to the main download page.
Build 7242
I just uploaded the latest build to: http://www.grzsoftware.com/files/MeshCAM-Setup.exe . It will also be detected by the "Check for Updates" command. There are a small handful of changes and two big ones- the ZMap memory reduction and the finish pass speedup. I really hope to make this the LAST release before calling V2 done so if no big bugs are found then this is it. As always, let me know what you think.
ZMap Here to Stay… For Now
My initial attempt to eliminate the ZMap failed pretty badly- the offset time tripled. This was mainly due to the offset being calculated to the accuracy of the finish passes. Although this represents a big improvement in accuracy, since the ZMap is currently calculated at a lower resolution than the finish pass, it’s probably totally unneeded. I did some testing to see if I could do some type of hybrid approach and the results were promising. Unfortunately, it will be too big a change to add right now so the final ZMap elimination will be deferred until V3.
On the positive side, I did reduce the memory requirements for the ZMap by 25%. Those users pushing the limits of their PC this might benefit from this.
Expect a new test release in a few days.