Best choice: XCAF or TObj?

Hello, "TObj"  is rarely used nowadays. I even thought to mark it debracated.

CAF and its childs are ready to work with TStdDoc_Document, labels and nodes, attributes,...

Undo/Redo is a main OCAF's attribute functionality. These attributes are used for both of your formats. I really recommend to use basic implementation of OCAF attributes and work around it. As for a XCAF, it has some attributes, but I do not recommend to build application around. And even more then that, you can apply your own visualisation logic on both of them and easily import data from DE on both formats or own format.

If you want consulting about application architecture around CAF, you can use our commercial service (see CAD consulting services | CAM consulting engineers)

As for a CAM, we have a multiple projects, where OCAF used as a application kernel (path tracing, geometry detecting, collising detecting, feature recognition, recompulating, manipulation, scaling and any other possible functionality around 2D and 3D are possible with pure OCAF).

Best regards, Commenter-1.

Indeed, XCAF was designed for Data Exchange - it is kind of a common ground between different CAD formats (STEP, IGES, etc.); it can be extended, but that might be error-prone, as it more like a native format for OCCT documents with its XBF and XML persistence.

TObj was designed for defining application-specific data model, but doesn't have direct mappings to XCAF attributes, hence such conversion should be done at application level. It is extensible by design and provides a better C++ abstraction layer for this than low-level OCAF.

Both are based on low-level OCAF, technically support Undo/Redo and persistence via drivers.

Here is another post about OCAF/XCAF/TObj.

Thank you so much for your answers, seeing the ups and downs i will try with XCAF as base for now and then see where i go from there.

Just for clarification, the company i work in has a CAM system that has become a monster with many antipatterns in it and a messy architecture, so we dedicate 70% plus effors for bug fixing instead of adding new features. But the company does not have the resources (mainly time) to create it all from scratch. So i am independently (in my free time) trying to create a solid and extensible base from where a new product can be developed with way less cost (ofc i will get paid for it if the company is interested). Because of all this, i sadly do not have the budget for the commercial services and i am sorry if i annoy you too much with questions in the forum.

As well, even if XCAF may have bugs and may not be ready for a production environment, as im a single developer doing it on my free time, it will be easier for me to try to work with it and fix/report/extend it, than redoing something simmilar to XCAF on my own (plus i just started learning OCC FW 1 month ago).

Thank you so much,

OCAF/XCAF are ready to be used in production. And used in CAM application in decades. XCAF by default is normal approach, but you will need to make your own attributes on top.

OCCT offers the custom development and/or "bug fixing and improvements in OCCT". So, in any cases you can rely on our team and support in the future.

Open CASCADE Technology: OCAF Have a very powerful functionality "function mechanism with dependencies between data and real-time updates and massive undo".

Best regards, Commenter-1.

Great! Thanks a lot, already working in the code to do the switch to XCAF.

Just as a side note, love the myXXX, theXXX and a/anXXX, i've been using simmilar prefixes for ages and never came across anyone else using anything with the same idea (i use m_XXX l_XXX p_XXX as well as op_XXX, member, local, param, out param). In simple environments is easy to know the scope of vars, but in huge applications its easy not to know whats what with a simple glance (and failing to see that i am changin a member attribute can be catastrophic).