FreeCAD OCAF and reinventing the wheel

[wsteffe]

Many years ago FreeCAD team decided to use Coin3D for visualitization instead of OCC internal Viewer and OCAF because the latter was too complex, bad documented and it was difficult to customize the nodes.

More recently FreeCAD acknowledged the importance of reusing part/shapes in an assembly framework instead of copying them.
Realthunder started his big LinkStage3 project to address this issue. More specifically, as stated in his webpage (https://github.com/realthunder/FreeCAD_ ... /wiki/Link LinkStage3) LinkStage3 should allow the linkage/reuse of objects (or containers) with the possibility to redefine/override positions and appearances.
But those issues were already addressed by the OCAF data structure (look in example at the section "Standard Document Services/External Links" in the OCAF documentation) . This is the reason why a TPrsStd_AISPresentation object is attached to a label of the OCAF tree instead of being attached directly to to shape.
I do not know if the RT implementation of the linkage mechanism is superior to that one provided, since a long time, by OCAF. For sure it has not solved the documentation issue of OCAF considering that nobody (apart of RT) seems to understand how it works.

An other big contribute of RT deals with the topological naming issue which is also considered very important for progressing to FC 1.0. But also this one was already addressed (at least partially) in the OCAF framework (see https://dev.opencascade.org/doc/overvie ... t_ocaf_5_6) and FC team again decided that this work it is not good and must be rewritten from scratch.

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

[Jee-Bee]

about the topological naming i give you some reading material.

i think you understand a bit more if you work trough it.

https://forum.freecadweb.org/viewtopic.php?t=2656
https://forum.freecadweb.org/viewtopic.php?t=2980
https://forum.freecadweb.org/viewtopic.php?t=4608
https://forum.freecadweb.org/viewtopic.php?t=15847
https://forum.freecadweb.org/viewtopic.php?t=17670
https://forum.freecadweb.org/viewtopic.php?t=27278
https://forum.freecadweb.org/viewtopic.php?t=27582
last one from the wiki
https://www.freecadweb.org/wiki/index.p ... ng_project

I think it give some background info about ocaf too... but i'm not sure. at least it give some of your answers

[wsteffe]

about the topological naming i give you some reading material.

Yes, I may understand that the the topological naming is a very complex issue which is not solved inside of OCAF. In fact I said that OCAF only partially addressed it.
To be more specific I think that OCAF is providing a mechanism to store the transitions applied to the goemetrical entities that are attached to the labels of the data tree. There are a few transition types (generated, modified, deleted ...). An other important aspect is that OCAF assures the persistency of these data so that the transitions may be retrieved after reopening an OCAF document.

Of course is up to you to find a good algorithm which, using these data, is able, in example, to regenerate a fillet you expect after you have changed a previous sketch (in the history list) and replaced a straight edge with an arc. I am sure it that is very difficult to write the CAD algorithms in such a way that they handle in a robust way the many different actions which may invalidate a model. I am also convinced that RT has done a good (and necessary) work on this topic.

But I think that the services offered by OCAF (registering of transitions and persistency of these data) were still valuable.
Considering also the other useful services provided by OCAF (visualization, inter document linkage .. ) perhaps it were better if FreeCAD were based on it than recreating all these functionalities from scratch.

[Jee-Bee]

I said that OCAF only partially addressed it.

i know. but that wasn't what i meant.
I meant that i'm quite sure that in the discussions i post the OCAF is touched including some of it's limitations.
I don't know OCAF well enough to say some sensable words about it. I can only say read the previous discussions and when it's not clear ask.

I'm quite suree use parts of the OCAF but don't know how much
I think that in this files are some examples https://github.com/FreeCAD/FreeCAD/blob ... eMaker.cpp

I think this is the related file from the framework but as i said don't sure...

Code: Select all

# include <TopoDS.hxx>

can somebody correct me if i'm wrong?

[wsteffe]

I think this is the related file from the framework but as i said don't sure...

Code: Select all

# include <TopoDS.hxx>

Jee-Bee, that file is not about OCAF but about topological shapes.

You should look instead for declarations like:
#include <XCAFDoc_Application>
#include <XCAFDoc_DocumentTool>
#include <XCAFDoc_???>
#include <TDF_Label>

[chrisb]

... and FC team again decided that this work it is not good and must be rewritten from scratch.

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

I am not sure who the adressee of this post is. Who is this "you", who is this deciding FreeCAD team?

is it realthunder?

I guess you still remember the other topic where you have been told in length, breadth and depth how the development of FreeCAD works. If I understand your post correctly there is some hard to understand code which might be (very?) helpful. To bring FreeCAD forward it would be of great help if you can provide a whatsoever small demonstration using FreeCAD structures how it can work. There is no one around here whom we can ask to research the usefulness of this stuff and as it is a really complex matter we might run into a dead end by simply using it per order by some FreeCAD team.

Please note that reuse of software components is in many cases heavily overestimated. In software engineering exists the rule of thumb that if you have to change more than 30% of the code you are better off with a completely new development.

[Jee-Bee]

as i said i'm not sure

[wsteffe]

I am not sure who the adressee of this post is. Who is this "you", who is this deciding FreeCAD team?

is it realthunder?

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,
- the acceptance of the RT LinkStage3 which seems very complex and not easy to grasp by many developers
it would make sense to reconsider the decision (taken many years ago) to not use OCAF.

In that case the visualitazion service of OCAF would replace Coin3D while the OCAF capability of linking external documents (as required in the assembly) could be used in place of the link mechanism offered by RT. I do not think that two linking mechanism are equivalent but the OCAF one could be sufficient for what concern the assembly requirements. For an assembly importing an existing part I would just expect that the latter is loaded in a dynamical way. This means that If I reopen the assembly after having updated the part I would like to see the updated part also in the assembly. When I am inserting multiple instances of the same part I would expect that the the memory usage doesn't grow to fast because the shape data are reused. I think that those requirements may be met easily with the OCAF framework.

Finally the OCAF data structure could provide a mechanism (which should be efficient because local) to save the history of each node in the data structure.

I have a small experience with OCAF and perhaps I could help to try this solution. Unfortunately I have no knowledge of the FreeCAD internals and I do not know where it does interface with the current document structure (which should be replaced by a customized OCAF document).

But may also be that my proposal doesn't make sense because of many other things that I do not have considered.

[realthunder]

I actually have the same feeling when I was researching for topo naming and step importing. I can see that OCC seems to have provided everything we need here. Why not just use them from the beginning. My guess is that at the time FC started, OCC lacks many functions we have today. It may had worse documentation. And it was not a full open source project at that time. 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. Just look at my situation here. I maintain LinkStage3 because I want something that FC team does not accept at the moment. Imaging wanting something from OCC that they don't accept?

[Jee-Bee]

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