Sometimes surfaces don't fully generate code when trying to 3D mill

[Siemenc]

As discussed in issue #61, it seems like there's cases where a surface doesn't generating code in specific areas. I 've experienced this before.

[zohozer]

I can confirm this. In my computer I do have the same result.

[Siemenc]

Here's another case of an object that doesn't completely mill with finish pass. I added 3D model for testing.

200922 Finish pass fail model.zip

[Siemenc]

I think it has to do with the resolution of the mesh which is used as an obstacle in the mesh collision component or with how the the points for positioning the milling bits are being generated.

This is what it looks like on the inside, so it seems like the collision detection component does its job correctly.

[Siemenc]

Came across another one causing issues in the latest version, so just wanted to add it here for debugging at some point

210613 3D mill bug.zip

[JensDyvik]

It looks like our 3D toolpath logic struggles with "valley like" inward curving of the surface.

I managed to reproduce the bug in stable release v1.02. An fix in this case was to disable collision detection (new feature in version 1.02). This also took calculation time down from 20 seconds to 3 seconds. The roughing toolpath unfortunately does not cover the entire surface though:

I guess it is another reason build a new more stable and faster collision detection logic. Changing from a flat end mill to a ball nose did not help.

Leaving collision detection on but changing the tolerance also made continuous finishing toolpaths, but now the roughing toolpath is still not covering the entire surface. I think the problem is that the end mill tollpath is offset sideways in (in certain surface angles) to compensate for the end mill radius, and that makes the collision detection chop the path. Increasing the tolerance made the matter worse not better, i will investigate.