aewallin / opencamlib Goto Github PK

MacOS build should be possible on travis.

Could some MacOS user contribute a PR with the required travis.yml changes?

The build process for this is a real pain if you're anywhere without preinstalled boost everything, because you have to install and compile boost, which is insanely massive and slows everything down build-wise.

Boost is mainly used here for foreach loops, which could be turned into C++11 foreach loops, boost graph library, but in a way that could surely be replaced by pretty straightforward structures, and boost.python, which could be pretty easily replaced with pybind11, which is tiny, and doesn't depend on massive libraries.

On a current openSUSE Tumbleweed distribution I get an error invoking cmake, see the logs available at https://build.opensuse.org/package/live_build_log/home:lorenz:CAM/opencamlib/openSUSE_Tumbleweed/x86_64

The cmake invocation there is rather verbose. However, I also get the error with just a

#> mkdir build
#> cd build
#> cmake ..
-- C++ compiler version: 5.3.1 [/usr/bin/c++]
-- setting gcc options: -Wall  -Wno-deprecated -pedantic-errors
--  CMAKE_BUILD_TYPE = Release
-- Boost version: 1.60.0
-- Found the following Boost libraries:
--   python
-- found Boost: 1_60
-- boost-incude dirs are: /usr/include
-- boost-python lib is: /usr/lib64/libboost_python-mt.so
-- boost_LIBRARY_DIRS is: /usr/lib64
-- Boost_LIBRARIES is: /usr/lib64/libboost_python-mt.so
-- found OpenMP, compiling with flags: -fopenmp
-- OpenCamLib version: 11.10-64-g89c21a2
--  configuring src/cutters
--  configuring src/geo
--  configuring src/algo
--  configuring src/dropcutter
--  configuring src/common
-- CMAKE_INSTALL_PREFIX is : /usr/local
-- Python modules will be installed to: lib/python2.7/site-packages
-- Python libraries will be installed to: lib64/python2.7/site-packages
-- linking python binary ocl.so with boost: /usr/lib64/libboost_python-mt.so
-- Found doxygen. Documentation can be built with 'make doc' 
-- dvips command DVIPS_CONVERTER not found but usually required.
CMake Error at src/CMakeLists.txt:424 (include):
  include could not find load file:

    /home/user/opencamlib/opencamlib/deb/package_details.cmake


-- type:
--  'make' for a normal build
--  'make -j8' to build faster (if you have many cpus)
--  'make install' to install
--  'make package' to build a binary deb-packate
--  'make spackage' to build debian source-packages
--  'make test' to run the tests
-- Configuring incomplete, errors occurred!

Incidentally, it seems to work in older versions of openSUSE, see for example the successful log at https://build.opensuse.org/package/live_build_log/home:lorenz:CAM/opencamlib/openSUSE_13.2/x86_64

And it is here, let me know if you want me to alter anything regarding the lgpl license or anything else.
Thanks for your excellent work!

Two days ago I came across http://touch-mapper.org/

It exports STL files from OpenStreetMap data. This allows for creating a tactile map for blind people.

Because I do not have a 3D printer, only a small CNC mill and there's no good CAM software available on Linux, I decided to give a try to opencamlib and wrote an STL to G-Code converter wrapper, see:

Demo: https://github.com/koppi/stl2ngc/wiki Video: https://www.youtube.com/watch?v=ldCAnd6YzOU
and Code: https://github.com/koppi/stl2ngc/blob/master/stl2ngc.cpp

One problem with stl2ngc.cpp is: the zigzag algorithm works, but the G-Code job time is quite too big. I would like to have a mix of the waterline and pocketing algorithms, but I do not know, howto put this idea into code.

@aewallin Can you give me any advice?

Trying to build on PopOS.

[100%] Linking CXX shared module ../ocl.so
/usr/bin/c++ -fPIC -fopenmp -O3 -DNDEBUG -flto -fno-fat-lto-objects -shared -o ../ocl.so CMakeFiles/ocl.dir/pythonlib/ocl_cutters.cpp.o CMakeFiles/ocl.dir/pythonlib/ocl_geometry.cpp.o CMakeFiles/ocl.dir/pythonlib/ocl_algo.cpp.o CMakeFiles/ocl.dir/pythonlib/ocl_dropcutter.cpp.o CMakeFiles/ocl.dir/pythonlib/ocl.cpp.o ../libocl_common.a ../libocl_dropcutter.a ../libocl_cutters.a ../libocl_geo.a ../libocl_algo.a /usr/lib/x86_64-linux-gnu/libboost_python310.a /usr/lib/gcc/x86_64-linux-gnu/11/libgomp.so /usr/lib/x86_64-linux-gnu/libpthread.a
lto-wrapper: warning: using serial compilation of 11 LTRANS jobs
/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libboost_python310.a(builtin_converters.o): warning: relocation against _ZTIi@@CXXABI_1.3' in read-only section .text'
/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libboost_python310.a(list.o): relocation R_X86_64_PC32 against undefined symbol `PyList_Type' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
make[2]: *** [src/CMakeFiles/ocl.dir/build.make:172: ocl.so] Error 1
make[1]: *** [CMakeFiles/Makefile2:192: src/CMakeFiles/ocl.dir/all] Error 2
make: *** [Makefile:156: all] Error 2

Hey! I was making the AdaptivePathDropCutter node.js bindings and noticed it crashes, then I checked the Python version and saw that that was crashing too, I seem to be to dumb to figure out what's going on and was wondering if you could take a look at it?

I have been playing with the OCL_DropCutter algorithm using a Rotational Scantype in FreeCAD's Path module with significant memory loss. Conversely, with a Planer Scantype, only minor memory loss. It seems that a new instance of the dropcutter is run for each of the rotational scans, which if the model is of any significance can be many.

To test the DropCutter I load a simple model in FreeCAD and use linux pmap to record the process memory before and after a run and am fairly confident the DropCutter memory handling is better now than it was.

My only experience with OCL is thru FreeCAD and with that i am still an amateur. Maybe others with more experience than i can verify the algorithms are still producing good data after these changes.

Coburn

@aewallin @gwicke

Hello and thanks for this amazing library. Up from today I could compile it successfully in windows (VS2015).
I updated the code with this PR#81 and now i got issues in 2 following files at compilation (still in VS2015).
Thanks if you can help me to understand the issue. it is related to the usage of atomic and operator=.

• in clpoint.cpp

  CLPoint& CLPoint::operator=(const CLPoint &clp) {
  if (this == &clp) // check for self-assignment
  return *this;
  x = clp.x;
  y = clp.y;
  z = clp.z;
  if (cc) { //compile error: more than one conversion function from "std::atomic<ocl::CCPoint *>" to a built-in type applies:
  // function "std::atomic<_Ty *>::operator _Ty *() const [with _Ty=ocl::CCPoint]"
  // function "std::_Atomic_address::operator void () const"
  delete cc.load();
  }
  cc = new CCPoint((clp.cc));
  return *this;
  }

• compositecutter.cpp

  //******** facetDrop ********************** */

  // call facetDrop on each cutter and pick a valid cc-point
  bool CompositeCutter::facetDrop(CLPoint &cl, const Triangle &t) const {
  bool result = false;
  for (unsigned int n = 0; n<cutter.size(); ++n) { // loop through cutters
  CLPoint cl_tmp = cl + CLPoint(0, 0, zoffset[n]);
  CCPoint* cc_tmp;
  if (cutter[n]->facetDrop(cl_tmp, t)) {
  assert(cl_tmp.cc != nullptr); //compile error: C2593 'operator !=' is ambiguous
  if (ccValidRadius(n, cl_tmp)) { // cc-point is valid
  cc_tmp = new CCPoint(*cl_tmp.cc);
  if (cl.liftZ(cl_tmp.z - zoffset[n])) { // we need to lift the cutter
  cc_tmp->type = FACET;
  cl.cc = cc_tmp;
  result = true;
  }
  else {
  delete cc_tmp;
  }
  }
  }
  }
  return result;
  }

an automated build, possibly with both gcc and clang, should be set up on travis.

Hello,

FreeBSD reserves locations like /usr/include, /usr/lib for the base system. Everything else goes into /usr/local. When I first tried building ocl I got errors about missing boost header files. I could fix those errors by temporarily creating a symbolic link to /usr/local/include/boost in /usr/include. It would be better if ocl could find the necessary libraries and headers in /usr/local, but I'm not sure how to get that done.

Thanks,

Denver

The cmake configuration checks for git even when cmake is executed from a versioned source download.

Cmake needs to be adjusted to skip this check in this case.

Error:

-- Found Git: /usr/bin/git (found version "2.40.0") 
CMake Warning at src/version_string.cmake:38 (message):
  Git failed (not a repo, or no tags).
Call Stack (most recent call first):
  src/CMakeLists.txt:185 (include)


-- version_string.cmake read from file GIT_COMMIT_ID: 
-- OpenCAMLib version: ..
CMake Error at src/version_string.cmake:39 (file):
  file failed to open for reading (No such file or directory):

    /builddir/build/BUILD/opencamlib-2023.01.11/src/git-tag.txt
Call Stack (most recent call first):
  src/CMakeLists.txt:185 (include)


CMake Error at src/version_string.cmake:40 (string):
  string sub-command REPLACE requires at least four arguments.
Call Stack (most recent call first):
  src/CMakeLists.txt:185 (include)

for the debian PPA one needs "make spackage", but it fails and I don't know why (it was probably working previously):

loading initial cache file /home/anders/Desktop/opencamlib/deb/package_details.cmake CMake Error: Error processing file: /home/anders/Desktop/opencamlib/deb/package_details.cmake src/CMakeFiles/spackage.dir/build.make:60: recipe for target 'src/CMakeFiles/spackage' failed make[3]: *** [src/CMakeFiles/spackage] Error 1 CMakeFiles/Makefile2:219: recipe for target 'src/CMakeFiles/spackage.dir/all' failed make[2]: *** [src/CMakeFiles/spackage.dir/all] Error 2 CMakeFiles/Makefile2:226: recipe for target 'src/CMakeFiles/spackage.dir/rule' failed make[1]: *** [src/CMakeFiles/spackage.dir/rule] Error 2 Makefile:238: recipe for target 'spackage' failed make: *** [spackage] Error 2

The test.js example included in the repository is failing to work. Error Segmentation fault.
I tested with Node v10.x and v16.x on Ubuntu 22.10
Cmake version 3.24.2
The library build was successful.
Any ideas how to fix this?

Hello to all,

is anyone here, who is able to help me and compile lib for the last version of Freecad for Windows? I spend many time to achieve that and I'm absolutely lost.
After compile, please attach the file in comment. Thanks :-) BTW. It would be maybe great to make a folder in repository, or add on release page versions of compiling project. I guess that this can help to many people who is lost with compiling etc. and save many lifes .. :-)

Trying to build the documentation and the suggested make doc does not work.

git clone opencamlib
cd opencamlib/src
cmake .
make doc

make: *** No rule to make target `doc'. Stop.

automates tests, if possible including test coverage, should be set up.
this could work on travis-ci, or a similar service.

It would be good to have pre-built binaries as a PPA (mainly for Ubuntu, Debian I guess).
Alternatively or additionally some platform that supports win/mac packages would be good too.

There are a couple of existing PPAs - but one well-maintained is better than many poor ones...

• @aewallin last updated in 2012: https://launchpad.net/~anders-e-e-wallin/+archive/ubuntu/cam
• @kkremitzki freecad extras https://launchpad.net/~freecad-community/+archive/ubuntu/ppa
• @neomilium https://launchpad.net/~neomilium/+archive/ubuntu/cam

There is no homebrew or macport available for opencamlib.
ref: Schamschula/macports#4

Hi,

I am trying to install opencamlib on Ubuntu 14.04 by following the step 2 and 3 of the README file. I encountered the following error at the make step. I'd appreciate it if you could help me solve the issue. Thanks,
Takeo

[ 39%] Building CXX object CMakeFiles/libocl.dir/dropcutter/batchdropcutter.o
In file included from /usr/include/boost/assert.hpp:50:0,
                 from /usr/include/boost/graph/detail/adjacency_list.hpp:39,
                 from /usr/include/boost/graph/adjacency_list.hpp:246,
                 from /home/takeokatsuki/opencamlib/src/common/halfedgediagram.hpp:25,
                 from /home/takeokatsuki/opencamlib/src/algo/interval.hpp:27,
                 from /home/takeokatsuki/opencamlib/src/algo/fiber.hpp:25,
                 from /home/takeokatsuki/opencamlib/src/cutters/millingcutter.hpp:29,
                 from /home/takeokatsuki/opencamlib/src/dropcutter/batchdropcutter.hpp:29,
                 from /home/takeokatsuki/opencamlib/src/dropcutter/batchdropcutter.cpp:29:
/home/takeokatsuki/opencamlib/src/dropcutter/batchdropcutter.cpp: In member function ‘void ocl::BatchDropCutter::dropCutter4()’:
/home/takeokatsuki/opencamlib/src/dropcutter/batchdropcutter.cpp:158:37: error: ‘ntriangles’ was not declared in this scope
             assert( tris->size() <= ntriangles ); // can't possibly find more triangles than in the STLSurf 
                                     ^
/home/takeokatsuki/opencamlib/src/dropcutter/batchdropcutter.cpp: In member function ‘void ocl::BatchDropCutter::dropCutter5()’:
/home/takeokatsuki/opencamlib/src/dropcutter/batchdropcutter.cpp:218:37: error: ‘ntriangles’ was not declared in this scope
             assert( tris->size() <= ntriangles ); // can't possibly find more triangles than in the STLSurf 
                                     ^
make[2]: *** [CMakeFiles/libocl.dir/dropcutter/batchdropcutter.o] Error 1
make[1]: *** [CMakeFiles/libocl.dir/all] Error 2
make: *** [all] Error 2

for the help of others installing this great package on ubuntu 16 I needed to install the following in order to get the installation to run:

git clone git://github.com/aewallin/opencamlib.git
cd opencamlib
mkdir build
cd build
sudo apt install cmake
sudo apt install libboost-program-options-dev
sudo apt-get install doxygen
sudo apt-get install texlive-full
cmake ../src
make -j4
sudo make install

use an automated on-line documentation system like readthedocs.

ideally this should build documentation for both the c++ and python APIs, e.g. based on doxygen for c++ and docstrings for python.

Hi @aewallin,

Would you consider making me a maintainer for this project?
It would at least make merging all changes in a lot easier ;)

I try to run the C++ version of the test_example file, but the corresponding G02 code is not generated in the curve area. What is the problem?

Hi there,
Could you provide (or point me to) detail instructions on how to install OpenCamLib on Mac OS?
Thank you!

The opencamlib python module could/should be distributed on pypi https://pypi.org/

Ideally installing should be as easy as "pip install opencamlib" - on all supported platforms!

So it can be represented in downstream repos/projects/package-tracking sites.

hello I'm trying to build ocl in arch to use with blendercam

when runnning cmake it fails with the following error

http://dpaste.com/3FRYJ4J

thanks

This issue is to discuss the work needed for a new release in July 2019.

• build is currently broken - is this a real or a travis issue?
• we have 3 open pull-requests by @vespakoen - do we wait&merge or skip these?
• the cmake build system has grown complex - do we change this now or later?
• cmake minimum version bumped to 3.14. use the kitware PPA to get latest cmake if needed.

any other issues before a release?

I cannot make a lib for python, anyone can do this job?

I created a PR for a conda-package of opencamlib. This won't work out of the box, so help is needed. Applying the cmake to work with conda-build will also help with getting the cmake more consistent for different platforms.

conda-forge/staged-recipes#8474

Hi, this issue is basically a replica of aewallin/openvoronoi#39 for this repo; I've finished the Debian packaging for opencamlib in advance of the relicensing, and it seems like Python 3 support doesn't work out of the box. While I can build against Python 3, when I try python3 -c 'import ocl' I get ImportError: /usr/lib/x86_64-linux-gnu/libboost_python-py27.so.1.62.0: undefined symbol: PyString_Type. So, there are a few tweaks to be done yet.

As the build system is becoming increasingly complex, maybe it would be good to split the project into a purely C++ part, which seems quite stable over time.

On the other hand the bindings have seen lots of changes, breaking the build etc, and issues with python2 vs python3, which maybe could be handled better in a separate repo focusing on just that particular binding.

Comments? PRs? ;)

"make" runs without error until 100%, but when attempting to link cxx shared module ocl.so I get the error

`_PyRuntime' can not be used when making a shared object; recompile with -fPIC' and the final link fails.

[linux mint 20.2, Python 3.8]

Dear developer,

You might want to have a look at the patches used in the Debian package I just uploaded for NEW approval, https://ftp-master.debian.org/new.html. The patches are available from https://salsa.debian.org/science-team/opencamlib/-/tree/master/debian/patches. I am not sure which ones would be useful to include upstream.

C:/dev/mingw64/include/c++/8.3.1/math.h:66:12: error: 'constexpr bool std::isnan(double)' conflicts with a previous declaration
using std::isnan;
could you give me some advices?thank you

Hi,

FreeCAD has recently adopted an OCL solution for 3D surface paths. This seems to work very well in terms of geometry but produces alternating cutting directions, which often leads to poor machining finish. The choice of climb or conventional cutting direction is a basic machining requirement. It is not usual to mix the two or be ambivalent about the choice of cutting direction.

Here is an example of a cut using an 8mm ball-end tool to cut a cylindrical form in Al alloy. The difference in finish is quite dramatic. If the job could be done with consistent cutting direction it would have a given a really nice finish.

I was told the paths were created by OCL and the issue needed to be raised here. Is this something which can be controlled by the caller by better exploiting OCL API or is this an issue which requires changes in OCL itself?

Thanks for any comments on where/how this needs to addressed.
Best regards.

An arc-filter in python, developed for slic3r:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?LinesToArcs

If this algorithm is good, it should be converted to c++, extended to handle all planes (XY, XZ, YZ), and added to opencamlib.

When you call e.g. waterline.run() or waterline.run2() from python, it takes some time inside opencamlib, doing stuff only with opencamlib structures. Because of the python global interpreter lock, this blocks all python threads, meaning a) you can't do multiple different operations at once (e.g. run waterlines at multiple z values) and b) everything else in python hangs while any opencamlib operations are running.

Or alternatively, one could make waterline support taking a list of z values and running them in parallel, given that it is likely to be run on multiple layers anyway, and it would save reloading the stl for each thread.

Hi Mr Wallin, I made some changes to CMakeLists.txt trying to compile this under Arch (manjaro).

I changed some lines because Arch doesn't have /usr/local/python2.7/, instead its located at /usr/lib/python2.7

execute_process(
    COMMAND python -c "from distutils.sysconfig import get_python_lib; print get_python_lib(0,0,\"/usr/local\")"
    OUTPUT_VARIABLE Python_site_packages
    OUTPUT_STRIP_TRAILING_WHITESPACE
) # on Ubuntu 11.10 this outputs: /usr/local/lib/python2.7/dist-packages

execute_process(
    COMMAND python -c "from distutils.sysconfig import get_python_lib; print get_python_lib(plat_specific=1,standard_lib=0,prefix=\"/usr/local\")"
    OUTPUT_VARIABLE Python_arch_packages
    OUTPUT_STRIP_TRAILING_WHITESPACE
)

to:

execute_process(
    COMMAND python2.7 -c "from distutils.sysconfig import get_python_lib; print (get_python_lib())"
    OUTPUT_VARIABLE Python_site_packages
    OUTPUT_STRIP_TRAILING_WHITESPACE
) # on Ubuntu 11.10 this outputs: /usr/local/lib/python2.7/dist-packages

execute_process(
    COMMAND python2.7 -c "from distutils.sysconfig import get_python_lib; print (get_python_lib(plat_specific=1,standard_lib=$
    OUTPUT_VARIABLE Python_arch_packages
    OUTPUT_STRIP_TRAILING_WHITESPACE
)

Now cmake seems to no return any error:

$ cmake ../src
-- The C compiler identification is GNU 5.3.0
-- The CXX compiler identification is GNU 5.3.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- C++ compiler version: 5.3.0 [/usr/bin/c++]
-- Found PythonLibs: /usr/lib64/libpython3.5m.so (found version "3.5.1") 
-- setting gcc options: -Wall  -Wno-deprecated -pedantic-errors
--  CMAKE_BUILD_TYPE = Release
-- Boost version: 1.60.0
-- Found the following Boost libraries:
--   python
-- found Boost: 1_60
-- boost-incude dirs are: /usr/include
-- boost-python lib is: /usr/lib64/libboost_python.so
-- boost_LIBRARY_DIRS is: /usr/lib64
-- Boost_LIBRARIES is: /usr/lib64/libboost_python.so
-- Try OpenMP C flag = [-fopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Success
-- Try OpenMP CXX flag = [-fopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_DETECTED - Success
-- Found OpenMP: -fopenmp  
-- found OpenMP, compiling with flags: -fopenmp
-- Found Git: /usr/bin/git (found version "2.7.0") 
-- version_string.cmake git set GIT_COMMIT_ID: 11.10-64-g89c21a2
-- OpenCamLib version: 11.10.64
--  configuring src/cutters
--  configuring src/geo
--  configuring src/algo
--  configuring src/dropcutter
--  configuring src/common
-- CMAKE_INSTALL_PREFIX is : /usr/local
-- Python modules will be installed to: /usr/lib/python2.7/site-packages
-- Python libraries will be installed to: /usr/lib/python2.7/site-packages
-- linking python binary ocl.so with boost: /usr/lib64/libboost_python.so
-- Found Doxygen: /usr/bin/doxygen (found version "1.8.11") 
-- Found doxygen. Documentation can be built with 'make doc' 
-- Found LATEX: /usr/bin/latex   
--  called with SRC_DIR is = 
--  called with version  = 11.10.64
-- architecture is: 
-- architecture is: 
--  CPACK_DEBIAN_DISTRIBUTION_RELEASES : lucid;maverick;natty;oneiric;precise;quantal
--  CMAKE_SOURCE_DIR is = /home/carlos/Documentos/opencamlib/src
--  descr file = /home/carlos/Documentos/opencamlib/src/deb/debian_package_description.txt
-- type:
--  'make' for a normal build
--  'make -j8' to build faster (if you have many cpus)
--  'make install' to install
--  'make package' to build a binary deb-packate
--  'make spackage' to build debian source-packages
--  'make test' to run the tests
-- Configuring done
-- Generating done
-- Build files have been written to: /home/carlos/Documentos/opencamlib/build

But after compiling and installing python2.7 shows this:

$ python2.7
Python 2.7.11 (default, Dec  6 2015, 15:43:46) 
[GCC 5.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import ocl
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: ./ocl.so: undefined symbol: _ZN5boost6python6detail11init_moduleER11PyModuleDefPFvvE
>>> 

And python 3.5.1 this:

$ python
Python 3.5.1 (default, Dec  7 2015, 12:58:09) 
[GCC 5.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ocl
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: /usr/lib/libboost_python.so.1.60.0: undefined symbol: PyClass_Type
>>> 

Maybe its due to a linking error? or something related to boost? Sorry about my poor programming skills.

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.

With a reasonably updated ubuntu/boost install I get multiple build warnings:

/usr/include/boost/timer.hpp:21:1: note: #pragma message: This header is deprecated. Use the facilities in <boost/timer/timer.hpp> instead.
21 | BOOST_HEADER_DEPRECATED( "the facilities in <boost/timer/timer.hpp>" )

Blendercam uses openlib for drop cutter.

Use of opencamlib triggers some form of singularity when using the cone cutter.

Other cutters tested and appear to work well including the similar cylinder cone with the cylinder reduced to very small ballcone

Hello,

I get a warning when compiling on VS2019, that was not when previously compiling in VS2015.

smart_weave.cpp
##[warning]src\algo\smart_weave.cpp(338,33): Warning C4834: discarding return value of function with 'nodiscard' attribut

for( in_edge_itr = in_edges.begin(), out_edge_itr = out_edges.begin();
in_edge_itr < in_edges.end(), out_edge_itr < out_edges.end();
in_edge_itr++, out_edge_itr++ )

in 2nd line of code
in_edge_itr < in_edges.end() with the operator <

What is the consequence ? Can someone have an idea for a fix ?

Thank you

An FYI for others struggling to compile on a python 3 version.

I failed all afternoon until I upgraded my cmake.

cmake 3.10 was broken, but cmake 3.14 worked

The call to check_ipo_supported, introduced in PR #142, causes CMake 3.25.2 (on Arch Linux) to error out:

CMake Error at /usr/share/cmake/Modules/CheckIPOSupported.cmake:169 (message):
  Policy CMP0069 is not set
Call Stack (most recent call first):
  CMakeLists.txt:94 (check_ipo_supported)


CMake Warning (dev) in CMakeLists.txt:
  No cmake_minimum_required command is present.  A line of code such as

    cmake_minimum_required(VERSION 3.25)

  should be added at the top of the file.  The version specified may be lower
  if you wish to support older CMake versions for this project.  For more
  information run "cmake --help-policy CMP0000".
This warning is for project developers.  Use -Wno-dev to suppress it.

I'm not very familiar with CMake, but either adding cmake_policy(SET CMP0069 NEW) or cmake_minimum_required(VERSION 3.15) to src/CMakeLists.txt seems to fix this.

The copy constructor for ocl::Path is a no-op, not copying anything from the source object. Why is it there? As far as I can tell, the code build just fine without the copy constructor. If it is needed and wanted, what about making it a proper copy constructor which make a copy of the content of the source object.

Here is a draft patch removing the copy constructor, and including a simple implementation of the list copying.

--- opencamlib-salsa.orig/src/geo/path.cpp	2023-09-11 12:07:29.133078761 +0200
+++ opencamlib-salsa/src/geo/path.cpp	2023-09-11 12:07:29.125078733 +0200
@@ -28,9 +28,12 @@
 Path::Path() {
 }
 
+  /*
 Path::Path(const Path &p) {
+  std::copy(p.span_list.begin(), p.span_list.end(),
+	    std::back_inserter(span_list));
 }
-
+  */
 Path::~Path() {
 }
 
--- opencamlib-salsa.orig/src/geo/path.hpp	2023-09-11 12:07:29.133078761 +0200
+++ opencamlib-salsa/src/geo/path.hpp	2023-09-11 12:07:29.125078733 +0200
@@ -98,7 +98,7 @@
         /// create empty path
         Path();
         /// copy constructor
-        Path(const Path &p);
+        //Path(const Path &p);
         /// destructor
         virtual ~Path();
 

Since the license change for openvoronoi has gone smoothly, this is a near duplicate issue for OpenCamLib:

FreeCAD already has dropcutter and waterline operations using OCL but the GPL3 license with strong copyleft provisions is too restrictive to allow linking and packaging with applications like FreeCAD that are LGPL. This means users have to install OCL manually.

If opencamlib was re-licensed LGPL2.1, inclusion in other applications would be easier and interest in using the library would increase.

I'm willing to help with any re-licensing effort and FreeCAD community will help with debian packaging if re-licensed so we can use it.