It's very clear that one of the roadblocks for FreeCAD is the Coin3D dependency.
There are many issues thast we face because of it:
Coin3D bundles a version of libexpat that crashes FC in different use cases
Coin3D does not support retina and HiDPI very well and therefore many MacOS users suffer the consequences
For a long while, upstream Coin3D development was idle
In the package ecosystem there is much confusion on what is the latest Coin3D point release. Users are packaging FreeCAD with different versions of Coin3D and running in to known issues over and over again. Many downstream packagers find this very frustrating and quit (FreeCAD on Arch was abandoned as a package (still exists in the AUR)).
I bet there are other issues as well.
So, I'm writing this thread to discuss what we can do about this. I know at one point we had our own fork going. But then upstream merged our changes (or some of them?). What is the correct question here? How do we stimulate movement in upstream? What can we do as a community to help coin3d move forward and in the process help us move forward overcoming the issues that it presents etc...
Please discuss...
Part of this effort involves the fact that we have a copy of the source of Quarter in FreeCAD with modifications, so Quarter needs to get packaged and our modifications upstreamed where possible.
Like my FreeCAD work? I'd appreciate any level of support via Patreon, Liberapay, or PayPal! Read more about what I do at my blog.
Not that I mean to hijack the topic, but perhaps it's time to revisit the issue of switching to OSG (or something else)... With the Python3 and Qt5 transitions nearing completion, it may be worth starting a thread to explore that in earnest. The last serious discussion I noted was dated late 2016.
Joel_graff wrote: ↑Sat Mar 09, 2019 8:23 am
perhaps it's time to revisit the issue of switching to OSG (or something else)...
I find odd that in all those topics about the scene graph issue, the possibility of going with OCCT visualization is never considered. After all it's already part of OCCT, on Linux we have no choice to but to bundle the visualization component with FreeCAD so end users have it already (not sure about Windows?), and surely it must have benefited from improvements over the years. As it's a made-for-CAD component, it may already have tools to get things that will require programming in Coin or maybe even OSG, like hidden-line separation in wireframe mode.
Will play around with it a bit tonight and then look at how it could replace coin3d in FreeCAD. (I am not saying that it ever will)
The output of this project will be greater knowledge of OCCT and FreeCAD on my part, in best case i might be able to post some kind of impact analysis for a migration.
When i do this kind of prestudies at work they usually take a few weeks full time work to generate a decent report. This is probably quite complex and i have limited time, so keep expectations low.
Joel_graff wrote: ↑Sat Mar 09, 2019 8:23 am
perhaps it's time to revisit the issue of switching to OSG (or something else)...
I find odd that in all those topics about the scene graph issue, the possibility of going with OCCT visualization is never considered. After all it's already part of OCCT, on Linux we have no choice to but to bundle the visualization component with FreeCAD so end users have it already (not sure about Windows?), and surely it must have benefited from improvements over the years. As it's a made-for-CAD component, it may already have tools to get things that will require programming in Coin or maybe even OSG, like hidden-line separation in wireframe mode.
In the early days of FreeCAD we were using the OCCT viewer and even its document framework OCAF. But at that time the viewer was extremely slow for larger objects and lacked of many features that we got with Coin3d for free. The only big advantage of the OCCT viewer over Coin3d was the available highlighting/selection mechanism but by writing our own nodes we could achieve something similar.
And the whole OCAF was a pain in the ass. We got it working for built-in object types but for all custom object types you had to register them with a very weird plugin mechanism which we never got working reliably. And documentation was either non-existent or very poor.
After spending 2-3 years on this we gave up and started to implement something that we have control over and that we understand.
Is it already possible to add vtk-objects to the view? vtk could be another good alternitive/ addition.
One problem of coin is the slow interaction (dragging) on osx. I see this in the sketcher and also in other application where elements are dragged with the mouse.
looo wrote: ↑Tue Mar 26, 2019 6:01 pm
Is it already possible to add vtk-objects to the view? vtk could be another good alternitive/ addition.
One problem of coin is the slow interaction (dragging) on osx. I see this in the sketcher and also in other application where elements are dragged with the mouse.
vtk and Coin3d are two completely different rendering systems. But ickby succeeded in the FEM module to use vtk stuff inside an Inventor node but I don't know if this is doable in a more general manner. I have never seriously worked with vtk so I don't know its internal working good enough.
