Expose OCCT 7.0.1 about pythonocc-generator

[henrybaxter]

After reading this tpaviot/oce#589 (comment) I'm even more curious to understand what the 'right' way to approach tracking 7.0.1 with pythonocc would be. @jf--- and @tpaviot would a better approach be to take pythonocc-generator, possibly even start a separate project, and try to work directly with OCCT rather than OCE?

[jf---]

Hi @henrybaxter ,

So I was just writing a history lesson on OCCT vs OCE, but you got there first ;)

OCCT is in a much better state, especially since 7.0.1.
Also the development culture ( git repo, nr of releases per year, replies on forum ) has changed much for the better. OCE perhaps was a wake-up call / did have a positive effect on how things moved fwd.

So, perhaps it is time to rethink OCE's relation to OCCT.
I have little to say on this, since I'm not versed in C++ / havent contributed code to OCE.

I do think OCE can be a more friendlier neighbor to OCCT.
For changes in OCE to be adapted in OCCT, you have to sign a waiver to your rights to the code, and people central to OCE were not to keen.

---

Back to the topic, technically, nothing is stopping you from using pythonocc-generator to OCCT 7.0.1

I'm actually curious to @tpaviot opinion whether pythonocc-generator could support both OCCT and OCE.

I recall that fixes applied OCE ( but not to OCCT ) were necessary for pythonocc-generator to work out. On ton of modernization work has gone into OCCT 7.0.1, so it would be interesting to see about this.

[henrybaxter]

@jf--- understood, that all makes good sense. So I think unless @tpaviot has something markedly different to say, I'll

• make sure I can use pythonocc-generator for the current OCE release (need some learning!)
• branch and attempt to build the same thing for OCCT 7.0.1 (hopefully contributing!)

Along the way I may find OCE has something OCCT doesn't that makes this a terrible idea, or possibly that the contortions to support both aren't worth it, but I guess we'll find out :)

[tpaviot]

OCE and OCCT are binary compliant, you can switch from one To the other as you want. Pythonocc is not OCE specific fyi I use To run the generator over OCCT. OCCT introduces many important changes, I do not know what changes are required To support it. Feel free to Open a branch and or PR

[henrybaxter]

@tpaviot working from the master branches of oce, pythonocc-core, and pythonocc-generator, I have

• compiled oce
• set my wrapper_generator.conf appropriately
• run python generate.py

and what I notice is that the swig interface files are vastly different

henry$ git diff --shortstat
303 files changed, 2256 insertions(+), 29808 deletions(-)

What am I missing?

[henrybaxter]

Regardless, the tests run and everything works 👍 I'm guessing the current pythonocc-core SWIG files were generated using an older version of oce, but it hasn't changed sufficiently to cause problems.

[tpaviot]

@henrybaxter pythonocc-core 0.17 is sync with oce 0.17.2 what does the diff look like? what is your os ?

[tpaviot]

@henrybaxter according to your os there might be differences in the way python gets the files (for instance the glob modules does not returns files in the same order). As a consequance, the order of hxx files may change, but that's all. FYI I'm on Windows.

[jf---]

perhaps stating the evident, but would it make sense to sort the output from glob?

[henrybaxter]

@tpaviot I believe you're right, I do see reordered includes. However, I also see some other changes (possibly classes are reordered?) so due to my unfamiliarity with the generator code, it's honestly difficult to be certain that's the only reason they're different.

If I run https://github.com/tpaviot/pythonocc-core/blob/master/test/run_tests.py successfully (which I did), is this a solid indication everything works? Can I use that as I make changes and be pretty sure my changes aren't breaking things?

@jf--- absolutely, making the thing deterministic and as close to identical as possible on all platforms makes perfect sense to me.

Thanks for your feedback guys, I really appreciate it.

[jf---]

hi @henrybaxter , yes that is a pretty good indication... congrats 👍

[jf---]

hi @henrybaxter , have you been able to make some progress, can we help out perhaps? Curious to hear from you...

[jf---]

beta release OCCT 7.1 is here...
release notes

[henrybaxter]

Hi @jf--- I made some progress, I believe I committed it to my fork of this project, but then my work turned in a different direction and I've had to pursue other things. I'm still interested in working on this, but don't have time at the moment. Feel free to take over, kill this issue, or whatever else. I'll update/reopen this issue when I start working on it again. Sorry about that!

[jf---]

@henrybaxter , no worries 🐼

this was definitely not trying to spark a sense of guilt, rather the realization that perhaps we should consider OCCT 7.1 rather than 7.0.1 as our target

OCCT 7 saw pretty huge changes, which rarely goes without some rough edges here and there...
looking at the changes in 7.1 a lot of work has been accomplished

Personally, I'm very thrilled about the AIS_Manipulator, which paves the way for more interactive work. Also, thrilled about the progress made in rendering... back in the day, I worked on Radiance, a photometrically validated render engine to create these cornell box renderings... to have that in OCC is really something

pic also shows the AIS_Manipulator as mentioned before

[trelau]

This is a shot in the dark, but as I try and wrap my head around the pythonocc build process, is there any value at looking at other C++ binders like pybind11, particularly when moving towards OCCT 7? I'm not familiar with SWIG so I thought it might be worth asking before I march down that path. There supposedly are binding generators for pybind11, but I have no experience with them. Just a thought I wanted to throw out in case there is any value moving forward. Maybe this relates to template wrapping also? Thanks.

[jf---]

What particular advantage would pybind11 bring?
Thing is that when wrapping vast API's there are few tools that can do so as robustly as SWIG
At this point, to displace SWIG would take pretty dramatic arguments.
Could you give an example what super powers pybind11 would bring?

I know its a respectable project, but a core technology such as SWIG is not easily displaced.

[trelau]

I'm not experienced with SWIG or pybind11, so no I can't offer any specific examples. I've just started to try and understand them both, and it seems like the interface code is a little more "readable" in pybind11. I just wanted to throw it out there in case you and/or other experienced developers thought it would be of value. With the overhaul of handles/templating in OCCT 7, I didn't know if there was a reason/opportunity to consider using something other than SWIG.

[tpaviot]

@trelau SWIG is being used since the beginning of the pythonocc project. So far, it has proven to be robust, and is quite stable from a release to the other. Unless there are things that are not possible with SWIG and possible with another tool (pybind, sip, ctypes or whatever) , I don't see any reason to make such a radical change in the pythonocc project. I still did not find time to move up to the latest oce release, I still have quite a few things to fix first. Please report any experiment trying to wrap a more recent oce/occct release.

[trelau]

@jf @tpaviot Thanks for the feedback. My goal is to get proficient with the pythonocc process, but eventually take a crack at SMESH. I would love to have an integrated meshing tool. One reason I thought about pybind was that the netgen project is exposing more and more via pybind, so I wondered if there was a possibly to transfer shapes between pythonocc and netgen someday. Thanks again.

[jf]

wrong person, @trelau

[tpaviot]

@trelau the issue with wrapping smesh is smesh itself. smesh is not maintained anymore by its original creator (@sfotis). If you get a way to take the smesh version available FreeCad, and can compile it with oce-0.18, wrapping is just a game.

[jf---]

@trelau , @tpaviot , so maintaining SMESH is an effort indeed.
our friends at FreeCAD also maintain SMESH so it would be interesting if the effort of maintenance can be shared.

[tpaviot]

Issue closed. Superseeded by #49