[wishlist] Batch (multi scan) API

[gwicke]

CAM applications like FreeCAD often need control over transitions between independent OCL scans. For this reason, a typical pattern is to submit one scan line or contour to an OCL dropcutter at a time, and then retrieve the results. While there is some scope for parallelization within such a "scan task" (using BatchDropCutter, for example), this parallelization is fairly fine grained, and suffers from high overheads.

It would be desirable to instead exploit parallelism between independent scans all sharing the same STL. This would allow an application like FreeCAD to schedule all scans for a high level CAM operation in parallel, and then retrieve the corresponding (separate) results for each of those scans. Doing the same while sharing the same STL and internal kd-tree is difficult for Python clients, especially when forking is not available (typically Windows).

API sketch

• Expose a single dropcutter like object, with a single STL and corresponding kd-tree. Ideally, support plain dropcutter, adaptive dropcutter, and waterline algorithms. Use non-parallel but efficient implementations by default.
• Scan API:
  • Accept multiple scan line segments, either as a key-value dict, or as an array.
  • Return corresponding results, either identified by original keys, or in the identical array order as the inputs.

[coburnw]

Maybe this is saying the same thing but coming from a different place...

I have been using OCL primarily for rotational paths. Since omp (perhaps for good reason) isnt used for the the stl rotation, scans can take a very long time. The way i am dealing with that is to tell ocl to use only one process, break the rotations into groups for the number of processors available, and have dispy run the scans, reassembling them afterwards.

My point is that perhaps ocl is trying to do too much. Maybe removing omp and the various path utilities, and focusing on the kdtree and a point drop cutter. The path generation could be left for either extender libraries or the apps themselves to implement. When i look at the problem, i see way too many edge cases.

in terms of wishlist, mine would be

• the ability to drop a cutter onto a non-planar stl by specifying a 3d starting point in space, a 3d ending point and cutter orientation with the result being the point of cutter contact between those two points.

• an arbitrary cutter that one could (only for example) draw up in freecad, export as an stl to be given to ocl to use. The only reason to have built in cutters would then be when the geometry lends itself to good speed optimization (which could be all of them for all i know).

This library works incredibly well for me as is. Just wanted to add some thoughts.

c.

[gwicke]

@coburnw, I think the current implementation is assuming a constant drop direction, and indexes surface polygons essentially in 2d. That is fine for my use case (parallel scanning of independent lines on a single surface), but supporting full 3d would require bigger changes and performance trade-offs.