Open Cascade Development Insights. Part 2

[dpasukhi]

Hello, I would like to share more details about the ongoing OCCT3D (Open Cascade Technologies 3D) 7.9.0 release.

The main topic for today is the changes that will impact the Data Exchange (DE) part of the OCCT project. In this context, DE refers to Import/Export operations with CAD formats. The Data Exchange module is crucial as it ensures seamless interoperability between different CAD systems, allowing for efficient sharing and conversion of 3D models.

Changes to Configuration part: [Forum Link]

Changes to other parts will be shared later.

Agenda:

1. STEP Import: User-Defined Attributes
2. STEP & XCAF: Supplemental Geometry
3. STEP Import: Multithreading Transferring
4. STEP: Thread-Safety Improvements
5. STEP: Hiding Internal Headers
6. STEP: GDT (PMI) Improvements
7. IGES & STEP: Option to Avoid XCAF

This list presents only the new expected features. Any bug fixes or small improvements are not included here and will be available in the change log with the final release. The main goals of these DE updates are to extend functionality, increase performance, and improve stability for different scenarios.

STEP Import: User-Defined Attributes

User-Defined Attributes (UDA) are special attributes in STEP files that present "key-value" data. In the XCAF context, these attributes are known as "Metadata." UDAs provide a flexible mechanism to attach additional information to the geometric and topological entities within a CAD file, which can be essential for various downstream applications, such as manufacturing, quality control, and lifecycle management.

Recommendation Practices: [CAX Recommendation PDF]

Implementing UDA into STEP Import extends the options for final users, allowing them to extract and process custom attributes from STEP files. This functionality enables greater customization and adaptability in handling CAD data, particularly for industries with specific metadata requirements.

User-Defined Attributes can be particularly useful in sectors like aerospace and automotive, where detailed metadata associated with parts can include material properties, manufacturing tolerances, and other critical information that supports downstream processes such as simulation, manufacturing, and maintenance.

More details are available in the next article: [Forum Link]

STEP & XCAF: Supplemental Geometry

When designing a part in a CAD system, geometrical elements are often created that do not belong to the actual, i.e., manufactured, shape of the part or assembly but are used to either create other geometric shapes or to carry additional information about the part or assembly. These elements are, in accordance with ASME Y14.41, called 'Supplemental Geometry.'

Updated functionality:

• New XCAF Tool for Supplemental Geometry: This tool allows users to manage and utilize supplemental geometrical elements efficiently within their models. These elements can include construction lines, reference planes, and other auxiliary geometry that aids in the design process.
• New flags for StepCafControl_Reader and StepCafControl_Writer to enable processing of Supplemental Geometry: These flags provide users with control over whether or not to include supplemental geometry during import/export operations. This ensures that the final exported file meets the user's requirements, either including or excluding these non-essential elements.
• Supplemental Geometry labels can relate to the model's geometry or GDT (PMI): This feature ensures that supplemental geometrical elements can be correctly associated with the main model, enhancing the accuracy and utility of the CAD data. This is particularly important for maintaining design intent and facilitating downstream processes such as manufacturing and inspection.

Recommendation Practices: [CAX Recommendation PDF]

STEP File Sample: [CAX STEP File]

STEP Import: Multithreading Transferring

We are introducing an option for performing the "Parsing," "Transferring," and "Healing" stages in parallel mode. The parallel processing capability is designed to leverage multi-core processors, significantly reducing the time required for large and complex CAD file conversions.

Parallel Mode:

Parallel mode decreases the total processing time by distributing some operations between different threads with the chosen multithread provider mode (OCC Threads or TBB). This approach can improve performance, especially for users dealing with large assemblies and complex geometries.

New functionality will be presented in beta mode. Single-thread processing will be the default setting.

Advantages of Multithreading:

• Improved Performance: By distributing tasks across multiple cores, the overall time taken to import and process STEP files is significantly reduced.
• Scalability: As hardware capabilities improve with more cores and better parallel processing capabilities, this functionality ensures that OCCT can scale accordingly.
• Efficiency: Large assemblies and detailed models benefit the most, as the computational load is balanced across multiple processing units, leading to faster turnaround times.

STEP: Thread-Safety Improvements

OCCT3D version 7.8 introduced improvements in STEP thread-safety processing. Some scenarios may still have data race problems. We plan to implement more test cases and validation for multithread environments. Ensuring thread safety is critical for applications that perform concurrent operations, as it prevents data corruption and ensures reliable performance.

Key Enhancements:

• Increased Reliability: By addressing potential data race conditions, we aim to make the processing of STEP files in a multithreaded environment more robust.
• Enhanced Testing: More comprehensive test cases and validation scenarios will be introduced to cover a wider range of multithreading conditions.
• Optimized Performance: Thread-safety improvements will lead to smoother and more predictable performance in applications utilizing multithreading.

STEP: Hiding Internal Headers

STEP Exchange in OCCT is presented by RW interface and internal entity representation. The RW interface is used only in low-level processing and has no use cases in user scenarios.

For 7.9, the DE team is working on decreasing the size of the final package and the number of exported functions. For that purpose, any RW files for STEP processing will be changed to private header files (pxx) and will not be part of the installation procedure or function exporting. This change aims to streamline the library, reduce potential conflicts, and enhance overall security by minimizing the exposed surface area.

Benefits of Hiding Internal Headers:

• Reduced Package Size: By limiting the number of exposed headers, the overall size of the OCCT package can be reduced, leading to faster download and installation times.
• Simplified API: Users are presented with a cleaner, more concise API, making it easier to integrate and use OCCT without delving into unnecessary details.

STEP: GDT (PMI) Improvements

STEP AP242 continues to implement new functionality to meet the growing needs of industries. New features for validating measurements for correct conversion into system units and new ways to connect point detection and connection to supplemental geometry are planned for integration into OCCT 7.9. These improvements are essential for maintaining the integrity and accuracy of geometric dimensioning and tolerancing data throughout the CAD data exchange process.

Key Improvements:

• Unit Validation: Ensuring that all measurements and dimensions are accurately converted into the appropriate system units during the data exchange process.
• Enhanced Connectivity: Improving the connection between GDT annotations and the associated geometric elements, including supplemental geometry. This ensures that all design specifications and tolerances are correctly interpreted and applied.
• Industry Compliance: Aligning with the latest industry standards and best practices to support the diverse and evolving needs of various sectors, such as aerospace, automotive, and manufacturing.

IGES & STEP: Option to Avoid XCAF

Some user scenarios do not require XCAF data storage. Previously, STEP and IGES ToolKits (TK) allowed extracting TopoDS_Shape only from the reading process. After the reorganization of TKs in 7.8, that functionality was not available. OCCT 7.9 will return that option through the configuration process. This means TKDESTEP/TKDEIGES will avoid any CAF dependencies during runtime or compile time. With these changes, the DE_Wrapper functionality for these DE formats will not be available in this type of configuration.

Advantages of Avoiding XCAF:

• Streamlined Processing: For users who only need geometric data, avoiding XCAF can simplify the data exchange process, reducing complexity and overhead.
• Performance Boost: By bypassing XCAF, the system can process data more quickly, which is beneficial for applications that require rapid data loading and conversion.
• Flexibility: Users can configure their data exchange workflows to exclude XCAF, tailoring the functionality to their specific needs without unnecessary features.

---

Feel free to share your thoughts and ideas in the comments.

Best regards,
Dmitrii, Technical Leader of OCCT 3D.

Original

[lavender-lee]

Hi, @dpasukhi Is it possible to introduce a .clang-format file to make the code (at least for the head file) have a unified style?
For example:

• clear the tab in code, see this file
• avoid the too long column, such as this
• clear big chunks of the commented code, see here or here

[dpasukhi]

Hello, the clang-format already exist for OCCT code style for internal usage.
I can make it public after a few updates.
But unfortunately, it will be not possible to update whole code base with new rules at one iteration.
The reason - too much changes will be and git history will be overloaded. Another reason - merge conflicts with old changes.
I think about perform the clang-format on whole code base, but there are a lot of not positive things will be.
I once did that, my local git cache was creasy... And after that any recache operation takes too much time. But that idea still not close, I still search for a solution. If you have any ideas - welcome (about avoiding some problems with upgrading).

[lavender-lee]

@dpasukhi it will be not possible to update whole code base with new rules at one iteration Yes, I also agree with that. Recenly, I have been learning the approximation technique of OCC. Hence, I formats the code of AdvApprox and AdvApp2Var package just for learning.

[lavender-lee]

My suggestion for formatting code is just and only one package in each time. Hence, this will be a long-term process.

[lavender-lee]

[dpasukhi]

Good idea, it is possible to detect packages that usually not touched by maintaining and just stable by default.
Thank you, i will check that approach. And check if my PC survive after that :)

[lavender-lee]

The gxx type file should be removed from include folder, this is because they are been compiled into library.

[dpasukhi]

Thank you for idea. I'm not sure that always. I need to check. I'm afraid that in some dark parts they are used for header generation, not only cxx. But it must be fixed.

They needs to be removed even from source code, because it is a old approach and not readable at all

[lavender-lee]

The OCC use gxx and macro to mimic the template-like functionality. Which is very hard to debug:(

[dpasukhi]

Yes, almost not even possible to debug, only cout :) Debugging, code reading and compiler time are suffering.
It is a long term iteration to remove them. At the moment a lot of gxx were removed for last years. I hope once they just will no more exist)

As for installing, It is a great idea.

[dpasukhi]

Issue: #159

[lavender-lee]

BTW, does the OCCT team has the old docs (paper/technical report or other useful text) from the french team? Especially for the math part, such as adv_approx, adv_app2var. I think they are very important to maintain or improve the code. Thanks very much. The main theory is approximation theory, howerver, I cannot figure out which part the code use?

[dpasukhi]

As a documenstation - probably no. I was reorginized the internal documentation and didn't find.
As for a scientific article - I guess, yes. But I'm not sure that it is survived somewhere. I will check it and ask the memories of some developers.

[lavender-lee]

So I would like to know which developer is maintaining this part in the cuurent team of OCCT? And I think it is not bug-free. In my option, b-spline approxmiation is very interesting and I have been learning it for many years. For B-spline, OCCT use some different methods compared to papers I read.

[dpasukhi]

I can't share the personal details. For maintaining not assigned people for these functionality at the moment. As for a "open source" consultation, I guess no option for now.

But here a few developers available for critical (commercial) bug fixing in that area.

[lavender-lee]

Got it. Thanks!