FreeCAD OCAF and reinventing the wheel

[wsteffe]

I think it would likely take more effect to maintain a fork than to write a new framework from scratch. Even today, it is still possible to find something lacking, which may still require forking and maintaining that takes huge effort.

I totally agree. In fact I was soon regretting about my post which might create the expectation of a huge effort from me which I think I will never be able to make.

[wsteffe]

If this is mainly for developers i would request moving this to the developers section?

For me it is ok but I don't know how to move it.

[Jee-Bee]

You can't a moderator have to do it. they shall read it.

[wmayer]

From the beginning on FreeCAD was not designed as a pure CAD system but as a flexible system providing frameworks for different purposes. If it was a pure CAD system then the OCAF framework might have been sufficient but since it's not and we already know that we hit a dead end with OCAF why should we do the same mistake twice?
In German we have a nice saying: Der Esel stößt sich nicht zweimal am selben Stein.

And have you ever looked through our bug tracker? If not then go through it and count all bugs where OCCT is to blame. Many of them could have been easily avoided if handles had been checked for null before de-referencing them or other coding flaws. So, why should we expect to have a rock-solid system with OCAF then?
In FreeCAD's document framework there are for sure bugs too but once we know one, it can be quickly fixed and we don't have to wait another few years for a future OCCT release where it might be fixed.

Are you sure that this attitude to reinvent instead of reuse is helpful ?

Reinventing something is not per se a bad thing. At the beginning of a project you can evolve very fast if you use an existing framework but the problems will appear in long-term. If a framework is not designed flexible enough (and I have my doubts with OCAF) then at some point you hit a dead end and either you live with its limitations or you put huge effort into implementing something new -- this effort is a multiple times higher than the effort you had if you implemented your own solution from the beginning on.

No it was addressing all developers. I was jast wondering if, considering the difficulties related with:
- the current visualization library (Coin3D) that somebody says need to be replaced,

For sure Coin3D -- actually OpenInventor is an old project using obsolete C++ techniques like a heavy use of C macros. Originally it was developed by Silicon Graphics in the late 80's and in 2000 released under the LGPL. AFAIK Coin3D (Kongsberg) used this code base for its version 1.0 which was also available under the LGPL. With version 2.0 they started their own implementation in a clean room fashion (i.e. not sharing any SGI code) and offered their product in a dual license model. GPL for open-source and a commercial license for proprietary products.
The company behind Coin3D stopped the development in 2011 and re-licensed the code under BSD-3. For a long time the code was orphaned but in the last one or two years a small community started to maintain and extend the code basis. So, there is some light at the end of the tunnel...

The successor in interest of SGI Inventor is TGS Inventor (or whatever it's called now. It changes its name every few years) and there are many improvements and extensions since v2.1. Another clone is that of MeVisLab which also seems to be under heavy development.

What I want to say is that OpenInventor is an extremely well-designed piece of software (one of the best I have ever seen) which is still extendible after 30 years and can be combined with new techniques. In FreeCAD I was able to implement an improved renderer for meshes based on vertex-buffer arrays or another contributor improved the handling of huge STEP models. Or ickby was even able to use some vtk rendering stuff inside an OpenInventor node.

The only real issue I see at the moment is what will happen to OpenGL in long-term. Will it completely disappear and replaced by the Vulkan API? But these are things that we don't have to decide now and I don't think it will emerge any time soon.

[wsteffe]

hi wmnayer thanks for your deep analysis.

If a framework is not designed flexible enough (and I have my doubts with OCAF) ...

I agree that OCAF may not be as flexible and general purpose as Coin3D. In fact I think that it could be used only for CAD data (exluding meshes/FEM ...).
But for that specific purpose it may be better suited. I do not want to say that I am totally sure, there are too many usage cases that nobody will never be able to anticipate.

Just to make a simple example let us consider the linkage problem which was a hot topic in the last time.
Here realthunder may help to better understand the broblem and I think it may be a usefull discussion in both cases:
The outcome may be that linkage implementation would have been simpler with OCAF or that the current solution implemented by RT is anyway very good and would not be better or simpler with OCAF.

In the RT page I read:

The biggest challenge of making Link work is to solve the selection ambiguity problem. Because with Link, the same object can now appear in many different hierarchy, e.g. with a Link that links to a group, the child object now appears in two different coordinate system. Saying some object is selected may now be ambiguous. We must include the hierarchical information of the selected object. We shall call the hierarchy of a specific selection its Selection Context.

But this fundamental problem, I think would have not arised at all with OCAF data structure because with it the selection would automatically return a label which is an unique identifier in that data structure. More TDF_labels may be associated with the some geometrical object (trough their TDF_reference attribute) and they represent in that way different instances of that object. Each label (instance) may have attached a placement and a presentation attribute. So it is possible, in example, to assign different colors to different instances of a part in an assembly. And the geometrical data (which exclude the colors) are still reused.

This simple example let me to think that the OCAF structure was not so bad conceived after all.

Anyway I do not want to negate the merits of Coin3D and I may agree that at this point, after many years of investments (in terms of hours not money) it would not be a good idea to throw it away.

Perhaps the best strategy would be to take inspiration from OCAF and to try to bring the useful concepts inside of the current FC framework.

[triplus]

As for our viewport, therefore Coin3D. In my opinion it won't get replaced, unless it will at some point in the future stop working on some platforms. Like macOS possibly dropping OpenGL completely and Coin3D not to gain a viable solution/backend to overcome such issues. The main problem with Coin3D therefore isn't related to not being a good option for FreeCAD. The problem is we currently don't know if it has a future or not. That is if it will get ported to support new emerging technologies or not.

As for the discussions and possible viewport porting related efforts, that does make sense. As if some day we will need to migrate, we should have some understanding, on what makes the most sense. Python bindings are likely a must. Maybe projects like Qt3D will evolve to a solution we need. Currently Qt3D likely isn't there just yet. Give it another decade and maybe it will become a perfect fit. Or as it is a commercial endeavor it could get dropped completely.

[ezzieyguywuf]

With regards to OCAF and Topological Naming, or more specifically the TNaming framework that OCC provides, I think I can provide a bit of insight (or at least some personal thoughts/opinions).

My initial approach to the topological naming problem was to do as you have suggested and utilize the existing TNaming functionality. You can see my initial approach/attempt here on gitlab (incidentally, I probably need to update the links in my original posts that jee-bee links earlier in this thread, as they all point to github and I've moved that repo to gitlab).

At the end of the day, while I believe that TNaming can do what we need, I had two main problems with it:

1. It is rather cumbersome to use (I could deal with this if it wasn't for number 2)
2. It is rather difficult to debug

Due to poor documentation on OpenCasCade's part, I found it very difficult to figure out why things were not working right when they weren't working right. This is either a consequence of me being thick and not understanding their documentation (for they do have a rather detailed guide that I've read a few times...) or their TNaming interface is just not user-friendly enough to lend itself to easy use.

Due to the difficulties, as well as the fact that, at the end of the day, TNaming essentially requires you to specify how each TopodDS_Face gets modified in order to provide a persistent reference, I decided that I would instead write my own "TNaming substitute" that requires the same inputs as TNaming (so, no more difficult to use), but provides better documentation, unit tests, and access to constituent variables for troubleshooting/debugging (easier to develop).

[triplus]

Indeed i remember you have mentioned this in the past, that you have tried out the OCCT TopoNaming solution. Thanks for the feedback. I could imagine the situation with using their solution for viewport purposes could be similar. That is their solution for viewport just isn't some general purpose solution and therefore they likely just add whatever they need at some point. Good documentation usually is hard to get. Frameworks like Qt on the other hand put much more emphasize on generalization, being up to date with latest technologies, caring about mobile platforms ...

P.S. When it comes to FreeCAD TopoNaming solution(s). We will still need to have some more in-depth discussions in the future. I imagine that after Part::Link effort gets sorted out, TopoNaming will come next.

[ezzieyguywuf]

Indeed i remember you have mentioned this in the past, that you have tried out the OCCT TopoNaming solution.

I was trying to find the post where I talked about the issues I had with TNaming, but I couldn't find it

[triplus]

Likely this:

https://forum.freecadweb.org/viewtopic. ... 38#p225338