surface flattening

Have some feature requests, feedback, cool stuff to share, or want to know where FreeCAD is going? This is the place.
Forum rules
Be nice to others! Read the FreeCAD code of conduct!
User avatar
looo
Veteran
Posts: 3941
Joined: Mon Nov 11, 2013 5:29 pm

Re: surface flattening

Post by looo »

@wmayer I don't know if boost python can wrap eigen:arrays to numpy.arrays. this is done automatically in pybind11 if the eigen header is included. also stl:containers are automatically wraped to python.lists.
The other option is to port the library back to older pybind11 versions or include latest pybind11 in the source as a git-submodule. this is the way how other projects do it, but i do not like it that much.
wmayer
Founder
Posts: 20243
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: surface flattening

Post by wmayer »

@wmayer I don't know if boost python can wrap eigen:arrays to numpy.arrays. this is done automatically in pybind11 if the eigen header is included. also stl:containers are automatically wraped to python.lists.
@looo I have added the file MeshFlatteningBoostPython.cpp as an alternative for pybind++ and conversion from numpy arrays is not a problem. As it implements Python's abstract sequence protocol I can use it together with PyCXX to transfer the data to the Eigen matrices.

So far my special constructor method FaceUnwrapper_mesh to create the FaceUnwrapper instance is used and it works. However, when using the flattening command for meshes it always raises an unknown exception inside the function LscmRelax::lscm().

Hence my question whether the mesh flattening works with pybind++. You say that it automatically converts data to/from numpy arrays and stl containers. But I guess you still need a special function to convert the numpy arrays to the Eigen matrices to create the FaceUnwrapper instance, don't you?
wmayer
Founder
Posts: 20243
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: surface flattening

Post by wmayer »

@looo here is line of code that doesn't make much sense: https://github.com/FreeCAD/FreeCAD/blob ... x.cpp#L665
x_dominant is of boolean type and thus cannot be used for multiplication.
User avatar
looo
Veteran
Posts: 3941
Joined: Mon Nov 11, 2013 5:29 pm

Re: surface flattening

Post by looo »

wmayer wrote:However, when using the flattening command for meshes it always raises an unknown exception inside the function LscmRelax::lscm().
meshflatting works for me. internally flatting a face also uses a mesh...

i had a look and the lscm function uses np.arrays for vertices and indices if wrapped with pybind11. this is possible with the eigen or numpy header inclusion. no special conversation needed.
User avatar
looo
Veteran
Posts: 3941
Joined: Mon Nov 11, 2013 5:29 pm

Re: surface flattening

Post by looo »

wmayer wrote: Sun Apr 29, 2018 11:17 am @looo here is line of code that doesn't make much sense: https://github.com/FreeCAD/FreeCAD/blob ... x.cpp#L665
x_dominant is of boolean type and thus cannot be used for multiplication.
looks like i copied this part from some python references. I never used the rotation by min boundary and I guess this function is not used... but i will have a look next time i have access to a fc-dev-env.
there are also things not yet done. the biggest improvement would be the use of a cg solver which allows to project out the nullspace solution. currently the constraints are implemented with a lagrange multiplier which is only solveable with abdirect solver...
User avatar
sgrogan
Veteran
Posts: 6499
Joined: Wed Oct 22, 2014 5:02 pm

Re: surface flattening

Post by sgrogan »

I get some build failures using VS2013 x32, with boost-python1.55 + Eigen 3.3.4
It works for x64 and the same versions as the failed x32 build

Code: Select all

Error	34	error C2719: 'u': formal parameter with __declspec(align('16')) won't be aligned	C:\Users\Chris\GitHub\FCAutoBuild\var\freecad-git\src\Mod\MeshPart\App\MeshFlatteningNurbs.cpp	171	1	flatmesh
Error	37	error C2719: 'u': formal parameter with __declspec(align('16')) won't be aligned	C:\Users\Chris\GitHub\FCAutoBuild\var\freecad-git\src\Mod\MeshPart\App\MeshFlatteningNurbs.cpp	233	1	flatmesh
Error	38	error C2719: 'u': formal parameter with __declspec(align('16')) won't be aligned	C:\Users\Chris\GitHub\FCAutoBuild\var\freecad-git\src\Mod\MeshPart\App\MeshFlatteningNurbs.cpp	275	1	flatmesh
In the next days I will update the Libpack used by AppVeyor to update Eigen3, so we can enable this for AppVeyor.
"fight the good fight"
User avatar
looo
Veteran
Posts: 3941
Joined: Mon Nov 11, 2013 5:29 pm

Re: surface flattening

Post by looo »

@wmayer
I see the benefits of pybind11 in the easy c++ eigen <-> python numpy wrapping. I guess something like this is not easily achievable with pycxx and boost python (although there are maybe some extension for boost.python https://github.com/personalrobotics/Boost.NumPy_Eigen) In my mind pybind11 is the easiest way to get this done.
In my mind array-libraries are fundamental for a cad-library, therefor I would really like to see some easy wrapping tools directly available in FreeCAD.

Maybe we can think about including pybind11 as a submodule to solve the version problems. As pybind11 is header only I don't think this is a big deal. I voted for outsourcing libraries in the past (smesh) but I guess in this case (as we use a direct copy of the sources) it isn't a big deal to include the headers directly. pyocct currently does the same.
wmayer
Founder
Posts: 20243
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: surface flattening

Post by wmayer »

sgrogan wrote: Thu Apr 26, 2018 7:00 pm
looo wrote: Thu Apr 26, 2018 6:37 pm To build the flatmesh library you have to use pybind11 instead of boost-python.
So this removes the boost-python dependency. I like that I've never been able to successfully build the debug version on windows. :)
Yes, it's very tricky. In the past I also always failed to build it. But yesterday I built the latest boost 1.67 for Py3 and gave the debug build a new try.
Here I found the relevant information why it failed. boost by default always links the release version of Python for a debug build and you must actively set the option that you want to create a debuggable version.

According to it should work to set the property <python-debugging>on in the project-config.jom file but for me it showed no effect, instead I had to set it in the command line.

The steps to achieve the boost debug version is:
  1. Add this to the project-config.jom file

    Code: Select all

    using python : 3.6 : C:/Projects/FreeCADLibs_12.0_x64_VC12/bin/python.exe : C:/Projects/FreeCADLibs_12.0_x64_VC12/include/python3.6 : C:/Projects/FreeCADLibs_12.0_x64_VC12/lib ;
    
  2. In the libpack folder tmp. rename your release python36.lib, make a copy of python36_d.lib and name it python36.lib. This is to avoid that boost links the debug _and_ release version of Python.
  3. Code: Select all

    b2 link=shared threading=multi variant=debug python-debugging=on --prefix=C:/Projects/LibPack/src/boost_1_67_0/install_dir --build-dir=C:/Projects/LibPack/src/boost_1_67_0/build_dir --with-python stage
This creates the files boost_python36-vc120-mt-gyd-x64-1_67.lib and boost_python36-vc120-mt-gyd-x64-1_67.dll. Due to to the "y" in the lib name cmake might fail to find the lib file. So, you can remove this letter.

An alternative to the option python-debugging=on is to edit the file wrap_python.hpp and add this after the _DEBUG.

Code: Select all

#define BOOST_DEBUG_PYTHON
And then do

Code: Select all

b2 link=shared threading=multi variant=debug --prefix=C:/Projects/LibPack/src/boost_1_67_0/install_dir --build-dir=C:/Projects/LibPack/src/boost_1_67_0/build_dir --with-python stage
Do not forget to undo the changes in wrap_python.hpp

When you inspect the dll with the Dependency Walker you will see that it depends on python36_d.dll. And when rebuilding the flatmesh module it now works to load it in debug mode.
wmayer
Founder
Posts: 20243
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: surface flattening

Post by wmayer »

looo wrote: Tue May 01, 2018 8:52 am @wmayer
I see the benefits of pybind11 in the easy c++ eigen <-> python numpy wrapping. I guess something like this is not easily achievable with pycxx and boost python (although there are maybe some extension for boost.python https://github.com/personalrobotics/Boost.NumPy_Eigen) In my mind pybind11 is the easiest way to get this done.
In my mind array-libraries are fundamental for a cad-library, therefor I would really like to see some easy wrapping tools directly available in FreeCAD.

Maybe we can think about including pybind11 as a submodule to solve the version problems. As pybind11 is header only I don't think this is a big deal. I voted for outsourcing libraries in the past (smesh) but I guess in this case (as we use a direct copy of the sources) it isn't a big deal to include the headers directly. pyocct currently does the same.
The biggest problem with pybind11 is that it requires C++14 features and thus you must upgrade to at least VS2015 on Windows which for me is not an option (at the moment). Btw, the library should actually be called pybind14++.

Yesterday I had a look at some automatic Eigen3 <=> numpy <=> Python conversions and you can achieve the same with boost.python, too. Theoretically it should suffice to implement these converters and register them to boost.python which at runtime then uses them. The only problem is that I didn't get it running and thus needed to create the debug version of boost.python.
User avatar
looo
Veteran
Posts: 3941
Joined: Mon Nov 11, 2013 5:29 pm

Re: surface flattening

Post by looo »

wmayer wrote:The biggest problem with pybind11 is that it requires C++14 features and thus you must upgrade to at least VS2015 on Windows which for me is not an option (at the moment). Btw, the library should actually be called pybind14++.
Ah you are right. I forgot about this hurdle.
Can you explain why vs2015 is no option currently for you... I don't see any big show stoppers.
Yesterday I had a look at some automatic Eigen3 <=> numpy <=> Python conversions and you can achieve the same with boost.python, too. Theoretically it should suffice to implement these converters and register them to boost.python which at runtime then uses them. The only problem is that I didn't get it running and thus needed to create the debug version of boost.python.
Hmm I have to say, that I do not like the double effort to create the bindings. Any change has to be done on both bindings...
Such solution is not very clean in my eyes. I think it's better to disable the flatmesh library if no pybind11 is available.
Post Reply