How to use the notestool? Can this tool be used to add custom attributes in a step?

W

wormjianke

CAD practitioner
Hello everyone, I watched "Lesson 15: Export OpenCascade assemblies to STEP with names and colors" on YouTube and found it very inspiring. However, it didn't mention custom properties. Has anyone tried using custom properties? I found a tool called notestool in the official documentation, but I haven't been able to implement it. I earnestly request help from all of you experts!
 
Quaoar

Quaoar

Administrator
Staff member
Hello @wormjianke and welcome to the forum. To the best of my knowledge, this "notes tool" has been introduced to prepare XDE for usage in one of OPEN CASCADE's commercial tools (DMU Reviewer). I don't think these notes can be passed in STEP format. All in all, you should probably avoid relying on fancy metadata in STEP because such data will most likely get lost on import in a 3-rd party system, like Fusion, Catia, SolidWorks, you name it. That is why, in the 21st century, people still use colors to label features and pass engineering semantics from one system to another.
 
W

wormjianke

CAD practitioner
Hi, quaoar!
I have watched your videos, which have been very helpful to me and are undoubtly the clearest description videos I have ever seen.
Have you ever heard of User Defined Attributes (UDA, Metadata, property)?
Do you think using User Defined Attributes can solve this problem?
I heard that OCCT 7.9.0 will soon be able to import and export User Defined Attributes, which is expected to be released in quarter 2. Do you think this timeline is accurate ?
Thank you for your time. Your prompt response would be highly appreciated.
 
Last edited:
Quaoar

Quaoar

Administrator
Staff member
I think that, generally speaking, supporting more and more of the recommended practices orbiting around the STEP standard is the right way to go. OPEN CASCADE (as well as Datakit and some other interested parties) have contributed a lot to the development of the STEP ecosystem and truly innovated the field. But you should also keep in mind the commercial aspects that underpin such developments. For example, OCC has recently introduced the "support of kinematics" in STEP, but it cannot be used without some extra tools that have never been open-sourced. So the first question I have here is: will UDA interfaces be complete, or are they "introducing" them in the same way as kinematics (i.e., they put them in the open source only because, architecturally, there's no better place to put generic classes, while all readers and writers will be published closed-sourced). I hope that I'm wrong here and that this contribution is going to be truly innovative.

But even then, there is another aspect to the problem. Look at what happened to all the efforts related to AP242, which was considered an ultimate solution to MBD (model-based definition). While this AP242 protocol is feature-rich, commercial vendors are not in a hurry to develop their tools for its full support. Why? Because it would inevitably improve the compatibility of one commercial system with another, while it's not what they really want (they want to keep their users within the perimeter of their walled commercial gardens). So it brings us to the next question: What happens next when you manage to put your UDA in a STEP file? If such STEP files will circulate within the perimeter of your own software, then it's all fine: you write them, you read them. But once you drop such a file into SolidEdge or somewhere, all these UDAs will magically disappear like motor oil in my car.

So, to sum it up, I'm looking at this upcoming change with moderate optimism, because if there's a mission behind OCC, then it's all about open source modeling and better STEP support. Would I ground the architecture of my software on the expectation that OCC delivers some fancy API for STEP-native metadata? Nope, it's too uncertain, and we already have kinematics "support" as an example of a false promise. If I were to add some metadata to my CAD project, I would just go the standard path with OCAF: custom attributes are exactly what OCAF was designed for. Later on, if I see that OCC provides a decent solution to UDA, I would just exploit it by converting my OCAF-based data model to STEP entities using their interfaces.
 
W

wormjianke

CAD practitioner
Thank you very much."They want to keep their users within the perimeter of their walled commercial gardens" I couldn't agree more.
I understand, I have to implement writing and reading metadata by myself.
Also, do you have any recommended resources for using OCAF to add metadata?
Thank you for your time. Your prompt response would be highly appreciated.
 
Quaoar

Quaoar

Administrator
Staff member
With OCAF, people usually select one of these options:

- XDE -- the OCAF interface provided by OCC for data exchange.
- Bare OCAF -- here you will mess around with labels and attributes by yourself bottom-up.
- Interface libraries, e.g. TObj (part of OpenCascade) or ActiveData (part of Analysis Situs).

Since we developed ActiveData in our team, we are using it almost exclusively in cases where geometry is just a data type, among many others. This is, for example, the case for pre-/post-processors (right now we are developing a module for Salome with ActiveData objects). In tools like CAD Processor and DMU Reviewer (owned by OCC), and in similar tools we develop for ourselves, where the central object is a CAD assembly, we use XDE. XDE is the OCAF format specialized to working with parts, instances, assemblies, colors, layers, names, etc. Since its backbone is still the same OCAF, you can freely extend it to add your notes and other metadata (by setting your attributes to non-occupied labels, e.g. 0:2) and provide all necessary programmatic interfaces to access it.

The XDE interfaces are quite horrible, but they have proven themselves to work reasonably well. We derived our own facade over XDE to give it useful API services and a common entry point: https://gitlab.com/ssv/AnalysisSitus/-/blob/master/src/asiAsm/xde/asiAsm_XdeDoc.h?ref_type=heads

Since you're interested in UDA, it looks like XDE is the closest relevant "dialect" of OCAF. Alternatively, you can step aside completely from OCAF and design your own persistence core in a database (whatever), e.g., using sqlite or mongodb. These approaches are also used in the industry, and, as far as I know, they are kind of well-proven (e.g., I heard that the sqlite-ish approach was in use by Shapr3d).
 
You must log in or register to reply here.
Top