Call for Ideas: Shaping the Architecture of OCCT 8.0.0

[dpasukhi]

🚀 The Road to OCCT 8.0.0

As we ramp up development for Open CASCADE Technology 8.0.0, we are looking at a unique opportunity. Major releases are the right time to introduce breaking changes that improve the long-term health, performance, and usability of the library.

We have our own internal roadmap for modernization (C++17, infrastructure changes, etc.), but we want to ensure we are addressing the pain points that you—the community developers—face daily.

🏗️ What we are already considering

To give you an idea of the scope, here are some architectural changes currently on the table:

• Standardization: Migrating from Standard_Failure to std::exception for error handling.
• Modernization: Implementing STL-compliant iterators for NCollection containers to support range-based for loops and standard algorithms.
• Cleanup: Removing deprecated math wrappers (Abs, Min, Max) in favor of std:: equivalents.
• Renevew: Update TopoDS_TShape elements with modern approach
• API Consistency: Addressing long-standing inconsistencies in naming conventions and method signatures.

🗣️ We want your input

If you could change one thing about the OCCT architecture that requires breaking backward compatibility, what would it be?

We are looking for feedback on:

1. API Design: Which classes or packages are the most difficult to use or inconsistent?
2. Performance: Where do you see the biggest bottlenecks that might require architectural changes to fix?
3. Modern C++ Integration: What C++17/20 features would significantly improve your workflow if OCCT supported them natively?

Please share your thoughts, specific examples, or even pseudo-code below. Let's build a better foundation for the future of Open Source CAD.

[eryar]

Modernization: Implementing STL-compliant iterators for NCollection containers to support range-based for loops and standard algorithms.

• Is it possible to use STL containers instead of NCollection containers? STL containers are easier to debug, and you can clearly know the data inside the container.

• Modern GPU: Vulkan support?

Performance: Where do you see the biggest bottlenecks that might require architectural changes to fix?

• Boolean algorithms performance and robust;
• Visualization performance: LOD for large model;

[dpasukhi]

No, STL containers are not planned and will not be planned to be used instead of NCollection. It is point of performance. STL is terrible :(
Debugging is a part of Netvis files, it is good idea to provide netvis files.

Vulkan is on our long term planning, but it is not planned for closest time.

Boolean is continue to be improved, it is incremental thing.

LOD is something that already possible with custom code. It is a good idea to extend existed code. For now Poly_Triangulation already have kinda LOD, but not fully integrated within modules.

Thank for ideas!

[gsegon]

Hi Dmitry,

For me, the biggest pain point is Thread-Safety, It is hard to debug and requires extra effort to design and work around these issues. For example, at the moment of writing, I am looking at TSan showing a data-race for BOPAlgo_Builder::Perform for the case when Parallel SetRunParallel is set to true. When set to false there is no race. On the other end, I have gotten used to using OCAF and like it quite a lot, but again, some/most functionality is not made for concurrency. It would be nice to have thread-safe versions. For example, I use TFunction_Driver and TFunction_Logbook extensively, or rather, I've redesigned them slightly to be thread-safe and will probably do the same for others I use significantly. Not a huge problem, but "concurrency-friendly OCAF framework" would be amazing to have :).

API Design: Which classes or packages are the most difficult to use or inconsistent?

For my use, OCAF. Primarily due to concurrency constraints.

Performance: Where do you see the biggest bottlenecks that might require architectural changes to fix?

No comment at the moment.

Modern C++ Integration: What C++17/20 features would significantly improve your workflow if OCCT supported them natively?

I would say ranges/views can be a significant improvement to TDF iterators. To give you a feeling, here is an example code from one of my tests where I use a custom TDF_ChildRange that implements std::ranges::view_interface

    // 1. Collect Work Items
    std::vector<TDF_Label> target_labels;
    for (const auto& label : TDF_ChildRange(doc->Main().Root(), true) | has<PartAttribute>) 
        target_labels.push_back(label);

This will iterate through all labels that have a PartAttribute that is a TDF_Attribute. It is more of a convenience improvement but I think it would go along with modernization nicely.

Best regards!
~ Gordan

[dpasukhi]

Thank you a lot for your feedback!
OCAF indeed is at the moment is not thread safe and some client request to improve it. It will be planned to 8.0.0+ release and originally will not impact a lot of ABI and API.

Yes, ranges is one of our next steps. Thank you for specific sample. At the moment, i will include that request to the 8.0.0 preparation (in case of enough time we will introduce it).

[gsegon]

Also, in a few cases I had a conflict of the Handle() global macro with a other libs. Any plans on refactor of this, so that it is opt-in and disabled by default? Not a big deal to work around, but maybe worth to mention.

Edit: Or enabled by default, but with an option to disable by consumer. Either way...

[dpasukhi]

Handle replacement to template is already prepared and waiting for merge.
Handle(...) will be debrecated.

[maltaisn]

I've just started using the library, so I haven't really used the API in depth. Here's a few suggestions that come to mind:

• Put everything on the new occ namespace, not just things like handle. This is standard for libraries.

• Handle API improvements:

  • Creating a handle is typically done like this Handle(T)(new T(args...)). To me this looks out of place, new is very rarely used nowadays. Smart pointer types in std have a helper function, like std::make_shared. Would it be possible to provide and standardize the use of such a helper?
  • handle->IsKind(STANDARD_TYPE(T)) => handle->IsKind<T>()
  • opencascade::handle<T>::DownCast(handle) => handle->DownCast<T>()

• The current Natvis file supports a limited number of types, it would be great to support more: gp_ types, map collections. TopoDS classes, etc. Also, a GDB pretty printers file would ease debugging outside of Visual Studio.

[dpasukhi]

Handle is intrusive smart pointer. It has all in inside class. It is not relevant and almost impossible to not use new.
Namespace is not possible to use in most classes as a naming convention of OCCT.
handle already in namespace.
Thank you for idea about nartvis.
Down casting with template looks amazing!!!! Thank you.
_
As for namespaces, modules and simple detailed API it is a part of OCCT Ligh
_
Thank you for your feedback!

[maltaisn]

Handle is intrusive smart pointer. It has all in inside class. It is not relevant and almost impossible to not use new.

What I'm talking about is providing a wrapper similar to std::make_shared:

template <typename T, typename... Args>
requires std::is_base_of_v<Standard_Transient, T>
opencascade::handle<T> make_handle(Args&&... args)
{
    return opencascade::handle<T>(new T(std::forward<Args>(args)...));
}

Which does use new but hides it. This is easily defined by the user, but it seems logical to me that the library would provide it.

[dpasukhi]

Patches for the Handle also will be in plan for new release.
Many thanks for the ideas.

[eryar]

Set color, material aspects .etc. for AIS_MultipleConnectedInteractive, and can connect object with gp_GTrsf for more flexible instancing render. This will reduce more memory and improve render performance.

[adam-urbanczyk]

I mentioned this in an issue, but will plug it here too: it would be great to get rid of all the functions/methods using pointers [handles] passed by reference. I suppose a modern equivalent would be to allocate in the functions and return a pointer or tuple of pointers.

Cf. #985 (comment)