herbk wrote: ↑Fri Sep 07, 2018 9:01 am
3D Surface has one big wrong starting point in my mind: It works allways with the whole object.
As written above, most areas of a part can be done verry well with existing OPs. It should be possible to reduce the working area of 3D Surface of the area where it's needet.
This has been my concern as well Herb. I've looked at this a lot, and have some initial coding done to generate face by face surfacing, but in doing so, I've realized that PathWB is currently constructed in a very 2d manner for 3d software.
Each Job does require parsing when generating paths for a single face to ensure no milling incursions into other Faces. There is a context.
Knowing what is allowed to be cut and deciding how much to cut at what feed rate with what tool are separate questions. This amounts to bounding the results to make them usable.
As stands, Jobs have Tools and Tool-Controllers associated with them. 3d surfacing operations require only the diameter and geometry of the tool, and care not at all about Feedrates and other variables within the Tool-Controller. Typically, multiple Tool-Controllers often exist within a single Job using the same Tool, allowing different Feed Rates. It makes no sense to Parse the model redundantly. For each Tool geometry, the Tool-Path perspective of the 3d Job Model is identical, so any OP should reference a common parsing.
Before calling OCL, you could separate the Job Model into sections by Faces. Here, I take the bounding of local face I create in algo, but then use it to create a separate Job and apply OCL.

- SemiBoundedOCL.png (204.25 KiB) Viewed 704 times
As seen, this gets closer, but still is problematic as follows:
1. Only a finish pass, assumes roughing completed already.
2. Paths now only consider current face, and cut into other faces, where the Face Boundbox is used to bound the paths.
What is needed is further bounding, which I show below, in concept, by stealing another piece of geometry that I create in my algo.

- BoundedOCL.png (224.16 KiB) Viewed 704 times
I cannot actually do an intersection with the Path Wires as they are not a Shape, but in abstract, this shows next step required...
In looking at this overall issue this last year or so, a couple of other things become clearer to me.
1. The 3d Stock Model is underutilized. The defaults Heights--a perpetual problem area--should not be a 2d/text input, but a 3d shape based on the stock used.

- StockModel.png (249.27 KiB) Viewed 704 times
2. All "Roughing" begins on--or just below--the stock top, and Rapids travel is typically never allowed within the Stock Model.

- RoughingStockModel.png (212.96 KiB) Viewed 704 times
3. Once a face is used for milling, no face below it can be milled without damaging the top face, so there is an "incursion zone" below it.

- IncursionZone.png (220.45 KiB) Viewed 704 times