I've continued work on scripting towards more controlled native 3d milling operations, and am finally at a point where things are beginning to come together. I still have a lot to implement, but as I look through the forum, I see lots of interest in the topic generally. I wanted to give a sense of what I'm trying to do as I think it's at a point where I can explain it and see what feedback I get...

As an algorithm, the concept--which can be roughly thought of as "carving the turkey", goes as follows:

--Parse the 3d model faces into toolpath envelopes that represent the maximal cut required to finish the face, without regard to other geometry or interference.

--This response is generated from the "finish" cut surface upward to the top height of the stock. My intent is that existing 2d paths (zig-zag, etc...) can be generated on the flat top surface, and used to decide how to actually implement the milling of that 3d space. Because the Tool-Path-Envelope is generated this way, it represents the area the "infinitely small" tool-center is allowed, for a tool of diameter D. The zig-zag path is therefore allowed any where within that surface--ideally, everywhere within it--and so the 2D offset can have an essentially 0.0 mm tool diameter Tool Diameter minimum for Path) specified, with offset specified only by the Step-Over parameter of the PathArea function.

--While parsing the geometry, a separate shape is generated for each face from the surface offset, downward to the stock bottom--a "Keep Out Zone", representing the closest that the specified mill is allowed to approach the surface without touching it.

--Once all faces have a "Maximal Tool Envelope" and a "Keep Out Zone", most of the calculation is set up. By using Keep-Out-Zones to carve away intersections with Maximal-Tool-Envelopes, the optimal available cut is almost realized. I say "almost" because I may need a 3rd response, which allows an over-ride of portions of Keep Out Zones--for example, if a half-cylinder is encountered, that also has cuts in the model...

What I've worked on to this point is generating a response to external solid/convex cylinders. I've done this so that much of the work translates directly to other similar geometries--Cones, Toroids, and Spheres are in line and will fall out of this. Flat faces are also fairly straight forward, and will be next in line to implement. Surfaces of extrusion and anything else using BSplines I'm kicking the can on because they are more complex.

Also falling out of this would be the ability to work on non-looped surfaces. My goal is that long term, this should calculate where the tool is allowed to exist relative to the 3d model, BUT, the selection of what operations are desired over what bounded area, would be a subset of the desired areas/operations within that envelope...

In the images attached, the calculations are done for a 4mm square-endmill on a cylinder with 310-degrees of inclusive angle, positioned to show the Maximal Toolpath Envelope generated at various angles. I don't show vertical, as I need to rework it now that I figured out angled/horizontal responses. The orange line represents the "Start" of the XY horizontal plane, the light blue line the "End". Silver and Brown lines show the geometry start/end for inclusive angles < 360-deg. A large yellow line shows the geometry surface axis, and then two reference lines represent the XY plane components of the +/- Surface Axis vector. A Point may be observed that marks the Mill-Radius offset.

Angled, inclusive upward.
Rotated around surface axis so that the "missing arc" is upward facing.
Now, horizontal.
At 9-deg from vertical.
I've only worked on square-mill to this point, but ballmill is actually easier as it's a straightforward 3d offset from surface to the center of the ball. The squaremill path is relative to the center of the tip of the mill, and that's why on horizontal cylinders, the tool is tangential to top of ellipse, but offset by mill radius at sides.

This image shows an error condition that I still need to trap, where the top ellipse is specified 180-degrees out, and the loft thus is wrong...
I've been working against Part WB geometric primitives, but am aware that PartDesign WB geometries require a bit of different handling to get the orientation correct in 3d space. As I said, lots to do to implement fully.

Note, the computation times are reasonable, and shown in the Report view.

Best,

Josh