Bindings for OCCT 7.6 #84
Comments
|
Here's an update. By building on the latest work by trelau in his pybinder project I found the necessary excludes to remove the previous errors related to So now it runs a lot further before failing due to errors seemingly arbitrarily relating to See github actions workflow logs for compilation attempts on all platforms here and the latest commit I made to the generate_wrapper.py script here -> Krande@b0f6dd7 Excerpt from Windows compilation attempt here |
|
Hey, I took another stab at making modifications for the generator to work with OCCT v7.6, and have now gotten a bit further. Now I am reaching almost 50% of the compilation of pythonocc-core for occt v7.6.2 by basically of adding/removing headers and skipping various function members etc.. However, I am running into an issue that I am unable to solve using tricks that seems to have worked until now. The following error is giving me trouble: The full compilation output can be found at: While the files are at: I have tried to include The only thing I've tried that seems to work is to go into the source #ifndef _Contap_ArcFunction_HeaderFile
#define _Contap_ArcFunction_HeaderFile
#include <Adaptor3d_Surface.hxx>
#include <Adaptor2d_Curve2d.hxx>
#include <Contap_TFunction.hxx>
#include <gp_Dir.hxx>
#include <gp_Pnt.hxx>
#include <TColgp_SequenceOfPnt.hxx>
#include <IntSurf_Quadric.hxx>
#include <math_FunctionWithDerivative.hxx>
class Contap_ArcFunction : public math_FunctionWithDerivativeBut as far as I can tell this would require a custom compiled OCCT package on conda which seems unpractical to say the least. @tpaviot @aothms Any advice you could give on this would be much appreciated? |
|
It seems this has been fixed at some point in OCCT upstream where the header is included Open-Cascade-SAS/OCCT@7109a4a#diff-89e4ed09db4b90a88f132a00171a3172f26279c2269e97c6861f90f75c595246 Didn't take the time to figure out what tags include this commit. Maybe 7.6.3 🙏 ? |
|
@aothms Thank you for the quick response! As a matter of fact I just now figured out what was wrong in my attempt at solving this. I was adding the headers in the wrong file I just missed completed where it actually failed: So the tricks that worked before seems to still work. I'll let you know once I have this at a 100% :) |
|
Great, still a bit of a bug though that they resolved, headers should include the headers they depend on. |
|
Yes, I see there is a 7.6.3 Tag, but I'll run through all of it using 7.6.2 to find other issues first. Here's another issue. There is a specific pythonocc-core class Poly_Triangulation does no more provide access to internal array structures: methods Nodes(), ChangeNode(), Triangles(), ChangeTriangle(), UVNodes(), ChangeUVNode(), Normals() have been removed. Methods of Poly_Triangulation for accessing individual nodal properties / triangles by index and implementing copy semantics should be used instead. The same is applicable to Poly_PolygonOnTriangulation interface. https://dev.opencascade.org/doc/overview/html/occt__upgrade.html#upgrade_occt760_poly Handle(Poly_Triangulation) myT = BRep_Tool::Triangulation(myFace, aLocation);
if (myT.IsNull()) {
invalidFaceTriCount++;
continue;
}
aface *this_face = new aface;
//write vertex buffer
const TColgp_Array1OfPnt& Nodes = myT->Nodes();
this_face->vertex_coord = new double[Nodes.Length() * 3];
this_face->number_of_coords = Nodes.Length();
for (Standard_Integer i = Nodes.Lower(); i <= Nodes.Upper(); i++) {
gp_Pnt p = Nodes(i).Transformed(aLocation.Transformation());
this_face->vertex_coord[((i-1) * 3)+ 0] = p.X();
this_face->vertex_coord[((i-1) * 3)+ 1] = p.Y();
this_face->vertex_coord[((i-1) * 3)+ 2] = p.Z();
}I am guessing this is just a matter of basically rewriting parts of the script to no longer point to the Any hints on how I should rewrite |
|
I think you can follow what IfcOpenShell does auto p = myT->Node(i).Transformed(aLocation).XYZ();
this_face->vertex_coord[((i-1) * 3)+ 0] = p.X();
this_face->vertex_coord[((i-1) * 3)+ 1] = p.Y();
this_face->vertex_coord[((i-1) * 3)+ 2] = p.Z();(untested) |
|
Thanks for the tip! But I think I might have found a workaround with limited impact on the existing code base using const TColgp_Array1OfPnt& Nodes = myT->MapNodeArray()->Array1();I guess I'll find out eventually if my hacks and workarounds does/does not break things! |
|
A new day, a little progress and another issue :) I ran into an issue with wrapping an The offending enum definitions in RWGltf.i: And definitions in RWGltf.pyi: Any ideas where I should start looking? Update: I ended up by simply skipping the enum altogether |
|
Okay, I am happy to report that pythonocc-core now compiles successfully on all 3 platforms! In fact, to my surprise all tests are passing on Both Linux and OSX do pass a lot of tests, but are failing somewhere in the
Here are the full logs from the github actions pipelines: https://github.com/Krande/pythonocc-core/runs/7787358841?check_suite_focus=true The conda package of pythonocc-core v7.6.2 is available for testing on windows here -> https://anaconda.org/krande/pythonocc-core/files. I will do some testing myself as well and see if the failing tests on linux are due to changes in the occt v7.6 api or due to changes made in my SWIG adaption. @looooo I thought you might be interested in this given you mentioned in tpaviot/pythonocc-core#1111 an interest in updating pythonocc-core to v7.6. Update: It appears that I actually did manage to pass all tests on windows after all. And the failing test could be the |
|
Wonderful progress! |
|
Thank you @Krande for your work, and sorry for being off for a few months after I took a new job position. I updated the generator to deal with occt7.6.2 headers. Just a few words regarding your commits: there's no need to create a specific swig_modifier for each occt version. Indeed related changes may be needed in future versions, and adding new headers on top of swig files does not create any backward/forward incompatibility. Note that the generate_wrapper.py script is formatted with black using default settings. The ShapeTesselator.cpp file needed a couple of additional tweaks to run on my linux machine and avoir segfaults. I also had to disable the test_curve_adaptor test, which is related to a weird issue, I'm not sure it is even needed. A build is running on Azure, I will report the status. Anyway, congrats for your work! It's not obvious to enter the pythonocc generator, I'm glad to welcome a new contributor. Feel free to submit pull requests, splitted into atomic commits that do solve a documented issue (the build process using conda/azure is quite unstable and may suffer from many side effects). |
|
and thank you @aothms for your pointer to the ifcopenshell cpp code |
|
@Krande the next step is to check/update the pythonocc-demos to the new version. |
|
@tpaviot Just happy to help, and thank you for the feedback! Regarding the changes I made to the |
|
changes for occt762 have been merged into master, pythonocc-core 7.6.2 compilation and tests work fine |
|
That's great! Then I think we can close this issue. |
Hi,
In an effort to (hopefully) help with adding support for OCCT version 7.6.1 (and also learn a bit more of the build process of pythonocc-core in general) I just wanted to share my attempts at recreating the SWIG bindings to support OCCT v7.6.1.
General platform and software version info:
What I've tried
First of I modified the
wrapper_generator.conffile with the location of my pythonocc-core fork and opencascade headers.Now, in my initial attempt at running the
generate_wrapper.pyscript failed when I ran into the following error:I traced the error back to the
RWGltfmodule, and thus removed it from theTKRWMeshlist inside theTOOLKIT_DataExchange.Second attempt at running the
generate_wrapper.pyscript was then successful.Next I tried compiling pythonocc-core after updating the CMAKELIST.txt with the appropriate version of OCCT I wished to compile for.
In my compilation attempt I ran into an error related to
Error: Template 'OSD_StreamBuffer' undefined(excerpt below).I've tried removing references to the OSD module, but that only caused more errors, so it might suggest the solution lies elsewhere.
Further work
While I keep testing, I would appreciate any hints or feedback that would help solving this.
Best Regards
Kristoffer
The text was updated successfully, but these errors were encountered: