Thrilled to see your post. I've looked at this for about a year now and have just recently given up.
Now, suppose someone says they want the machining to happen on the "real" surfaces, instead of these crappy triangles. Well, a CAD system has dozens of different parametric surfaces. Which one do you want us to start with? You've got your conics, spheres, cubic splines, offset surfaces, bezier patches, NURBS surfaces -- any one of which can be trimmed along intersection curves. The mathematics for each of these gets progressively desperate.
Illustrating your point:
Simplest case the sphere. The top hemisphere is able to be milled, the bottom isn't. A Square-Endmill "finish" surface toolpath is simply radially offset by the tool radius. For a BallEndMill, the center of the ball is the tangential offset of input geometry. For a CornerRoundMill, it's a mix of the two--use the corner-radius to for the ball, then offset by the flat-radius. For a ChamferMill--not that it makes much sense--the CuttingEdge Angle defines the angle to the x-axis, that is the maximum point, before the tool violates the surface. For a Cylinder, the same applies relative to the arc around the surface-axis.
Real-world, three limitations occur to me as significant: Collet Clearance, Shank-Clearance(Shank radius greater than cut radius ), and Length-Of-Cut Limitation. For the first two, there's measurable radius, but I would suggest adding a clearance envelope. I zero my tool-tip but the insertion depth into the Collet may vary. Similarly, the top shank clearance may enjoy a small margin.
Above image is a typical example of why I say that. It''s a 15mm radius Sphere. The collet is modeled as a 14mm radius which is about what I use on a "desktop" cnc. The tool is a 3.175mm Ballnose tool with a 6.35mm shank. Here, the entire sphere can be milled with a reasonable collet clearance. But, with a 25mm radius, the result is:
The calculation to avoid by a specified distance is trivial.
By specifying a 3mm collet clearance--the radius line from surface center to collet corner, the path depth is limited.
That all holds for a cylinder surface that is horizontal. Where the result is a revolved surface on a sphere, its's a a loft between two arcs for cylinder and more generally cones. Once the cylinder/cone is rotated, the tool surface is again a radial/tangential offset, but the Collet/Shank interference calculation is the same as sphere PLUS the interference calculation for a Plane-Surface. Plane-Surface is itself trivial.
Toroids are theoretically the same as cylinder, but swept around the major radius--while keeping the arc tool response aligned to the z-axis. It makes FreeCAD unhappy with the result shape. This isn't a trivial issue because fillet
surfaces are a very typical thing to mill.
As you said--far more succinctly--that is just the beginning of the complexities. Each case is straightforward, but it's overwhelming in its totality...
I know your post with pic is early pass, but I notice that there are red paths shown in the bottom arc carve out, which for 3-axis would violate the model. Is there a 2nd pass that constrains that, or was that for 5th-axis project?
Current Tool definitions don't adequately define a tool 3d tool. I suspect most people use Diameter across the board. I would assume Flat-Radius should be used for tool cutting tip, diameter should be the shank. For a ball, Corner Radius for the ball, Diameter for shank. The tool-definition/manager definition GUI doesn't work that way. Also, it doesn't allow angle input on chamfer. There are a couple of other little issues I ran across.
The suggestions I have for PathWB are:
1) Use "typical" tool definitions for inputs. Length Of Cut, love it or hate it, is a common term. Radius is great for calculations, but tools are bought and referenced to by diameter. I went through McMaster-Carr, MSCDirect, Harvey Tools, and a few other distributers to try look for common terms. I apologize if this differs for other countries--my sampling wasn't exhaustive. I want to avoid confusion about what parameter relates to what from real world tool to PathWB Job.
2) The one relatively trivial thing that I have done is a first pass at constructing a 3d model from the Job-->ToolController->Tool definitions. Where the definitions don't exist, I've "hard coded" which is why a gap is exhibited between the shank and transition to cutting edge displayed in above images.
3) What is important to me about having a 3d model of the tool definition is that it can show incorrect inputs in a very obvious way if the script builds doesn't collapse from errors for missing inputs, but doesn't "cover" for them by best-guessing to cover. My preference is be able to check tool model definitions visually within the contexts of the ToolManager->Add/Edit, or ToolController->ToolInstanceDefinition.
4) It seems like the more practical approach you are defining using meshes often are applied across the entire Job Model. I think it is important to define the 3d space that a tool is allowed to interfere (cut), but the strategies of how to cut that space are a modularly separate task. Roughing, finish, avoidance are all significant. I investigated where a ChamferMill begins to violate a sphere not because I have any interest in milling a sphere with a Chamfer, but because it's reasonable to assume I might want to mill a mold with a shape that transitions from a chamfer to a fillet, etc...
5) I enjoy the atomic aspect of the way that PathWB works, and hope that improvements retain that. Similar to above, I like the ability to select/deselect faces/edges for operations. The complaint I've had with OCL is that left unconstrained, it is indiscriminate about roughing/finish/tool/fixturing/etc... At work, we use PathWB, and appreciate that the entire job isn't attempted unbounded. The learning curve in my experience is less steep with the existing PathWB approach--in terms of the user retaining responsibility to define the job inputs, tools, and operations. I like the ability to order the operations. In an ideal world, I should look at my post-processor to check/notify if I'm tool-changing back/forth to same tool. Occasionally it's necessary, more often, I've messed up my operation order.
One last observation. PathWB Job contains ToolControllers, which include a ToolDefinition. The specific definition might be the default or added when the Job is created, or added later from the ToolManager. It is common for multiple Operations to share a common ToolController. It is also common for multiple ToolControllers to share a common Tool. This is because of roughing/finish, Feeds & Speeds in TC inputs. It wouldn't make sense to process same model twice if finish and roughing are performed with same Tool.
I apologize if I've hijacked. I realize that these are things you've clearly thought through and already figured out. Where I've stated preferences or made suggestions, I don't mean to sound demanding. I'll take anything that gets more 3d model to GCode workflow and say thank you very much. Just thought I'd try to throw what I hope are a constructive 2-cents
... BTW, if you haven't already, scroll through Path-Forum topics and a couple common themes crop up. Ability to do a non-closed loop single edge. Inability to over-cut a partially open pocket.