tpaviot
commented
7 years ago @looooo thank you for this proposal, which makes sense. But it's a long development process.
-
the current oce master is 0.18.2-dev (0.18 and 0.18.1 has been released). Both 0.18 and 0.18.1 are binary compliant with occt 691. It's important to understant that oce and occt are not exclusive, the question is not to choose one rather than the other. The difference between oce and occt is just the timeline, i.e. oce has a delay over occt release cycle. In an ideal world, everytime occt releases a new version, a new oce version should be released a few days or weeks after. But it's a painful work ;
-
the current master branch, 0.18.2-dev is intended to receive bugfixes over latest 0.18.1 release. 0.18.2 might not be ever released, if no one contribute any additional patch ;
-
it's possible to create a new branch, named 'occt710', including a oce-0.19-dev that is fully binary compliant with occt710. There are 3 steps : first copy/paste occt710 (just a few minutes), then apply the set of patches we have at oce (I would say from 150 to 200), solve conflicts etc. And the last one ensure it buids on most platforms.
-
There's no need to create another repository for a new occt fork ; use oce, which is already an occt fork, to upload occt710 and apply patches. It has been created in this purpose.
-
there have been several major changes from occt69 to occt7, it's not sure that our patches can be applied, may be it would be better to restart from scratch as you suggest ;
-
porting smesh to oce-0.19 (occt710) should be quite easy (latest salome720 is based upon occt7) ;
-
porting pythonocc to oce-0.19 will take more time.
My current plans are:
-
port smesh to 8.2.0 (i.e. extract smesh from latest salome8.20 release). This is a WIP (branch https://github.com/tpaviot/smesh/tree/review/salome-smesh-820). It still doesn't compile on windows and osx, been tryin
-
support netgen531. This is the netgen version officially supported by salome. @trelau tested netgen61 and 62, found some issues. Many people work at salome, skilled mesh engineers, my opinion is to trust them and to move up to netgen6 when they officially support it ;
-
integration smesh-8.2.0 into pythonocc ;
-
After that, move the underlying oce version (slowly move up all that stuff to occt-710).
If someone decides to go on with occt710 into oce, the previous plan might be changed.
trelau
looooo
hobbes1069
luzpaz
FreeCAD has a smesh version included. We have adopted the latest netgen. For conda everything is currently based on occt7.1.0. My personal view is that your approach to have smesh in an external repo is much better than ours where we include all the smesh sources directly in the code. I would like to bundle forces towards an external smesh based on the latest sources. The main problem in my eyes is the divorced oce-library. While python-occ and this smesh-version use oce FreeCAD has adopted occt. Would it be possible to create a simple fork of occt7.1.0 as a oce18-dev and adopt the necessary diff from older oce-versions slowly? Having the same base (oce based on occt7.1.0) would decrease the maintaining work. (FreeCAD also slowly moves towards conda-packaging, and we have a occt-version available with conda-forge: https://anaconda.org/conda-forge/occt/files) Somehow it would make much sense to have only one oce/occt.
So my suggestion is to:
As there are not many people working on all these difficult libraries, I think it would make much sense if we could bundle our forces and work towards a common oce/occt base. As I do not have any insights into your development plan, I would like to know which points you agree with, and what the current plan for oce, python-occ and smesh is. Maybe we can find some common points...