search

petrasvestartas / compas_wood

Project for Timber Joint Generation. Documentation:
https://petrasvestartas.github.io/compas_wood/latest/
MIT License
37 stars 2 forks source link

overlap with compas_cgal? #9

Closed jf--- closed 3 months ago

jf--- commented 3 months ago

hi @petrasvestartas,

it seems that compas_wood overlaps quite a bit with compas_cgal? specifically: src/frontend/src/wood/include

petrasvestartas commented 3 months ago

Short answer: @jf--- yes, it started literally from compas_cgal package, gradually modifying it and applying to my PhD timber joinery detection to collect scattered past IBOIS, EPFL projects codes into library.

Long answer -> the history of the project is quite interesting:

Initially, I had a C# project working in Grasshopper, but I wanted to develop a project independent of Rhino. I was used to this workflows due to my working experience at CITA and IBOIS. But there was always a "wall" of .NET which complicated PInvoke process when you need to implement any other 3rd party library. Simultaneously, I aimed to learn several other things: C++, CMake, OpenGL, and primarily develop within Compas.

Subsequently, I rewrote the code using OpenNurbs and PInvoke for .NET.

Then had a meeting with Tom about integrating my code into Compas which helped to understand how to do this correctly. He suggested looking at compas_cgal, which greatly inspired me. Honestly, it took me time to get out of .NET world because I was writing in such a way since bachelor in architecture... But it was really worth to learn from compas_cgal.

A challenge with pybind11 was the build times when using setuptools (this is what compas_cgal was at least at that time), as precompiled headers could not be activated, nor could any other form of parallel build. This meant it could take multiple minutes to debug even a simple C++ coding error unless the project was split into separate C++ and Python C++ binding segments or pre-written static libraries were utilized.

Currently, I am developing version 2 during some weekends. I tested nanobind, which facilitates CMake builds and offers a very transparent binding process, with almost identical Python and C++ code. This is because it allows direct exposure of C++ types in Python, resulting in less overhead for wrapping and simpler syntax, all built using pyproject.toml. Additionally, C++ structures, classes, and enums require minimal binding and can be directly used in Python to avoid double conversion, which was previously necessary even when using eigen matrices that still had to be converted to CGAL types. This approach appears to be a promising and straightforward process.

CGAL is primarily used as a kernel for data types, but it could be replaced with your own implementations of points, vectors, planes, and a few intersection methods. I continued using CGAL due to my familiarity with it from other projects like Cockroach for pointcloud processing and various custom research projects, supported by the developers' helpful assistance, especially with more complex algorithms.

jf--- commented 3 months ago

thanks for sharing the insightful evolution of the codebase @petrasvestartas, especially wrt nanobind.