OCCT 8.0.0: Developer Insights

[dpasukhi]

Dear OCCT Community,

With Version 8.0.0 on the horizon, I want to share some deep insights into our current development process and the technical evolution.

🚀 Development Insights: The Philosophy of 8.0.0

The primary focus of OCCT 8.0.0 is modernization, performance, and reliability.

We have undertaken extensive refactoring to clean up the architecture, remove deprecated methods, and align the library with modern C++ standards. While the core logic remains consistent - meaning applications will likely require adjustments rather than architectural rewrites - this modernization is a strategic move. It ensures OCCT remains maintainable, secure, and efficient for the long term.

Key Technical Changes

Here is a high-level look at how we are modernizing the codebase:

1. Native C++ Types: We are deprecating custom types like Standard_Real and Standard_Integer in favor of native types (double, int). This simplifies the code and improves compiler compatibility.
2. Standard Math Library: We are deprecating OCCT-specific math wrappers such as Abs, Min, and Max. The codebase is being updated to use the standard STL library directly (e.g., std::abs, std::min, std::max) to reduce redundancy.
3. Namespace Updates: We are introducing the shorter occ namespace to replace opencascade for brevity and modern styling.
   • Note: While the new standard is occ, current code samples may still utilize the full opencascade namespace during the transition.
4. Modern Handles: Macro definitions for Handle are being replaced by direct template syntax using the new namespace.
   • Old: Handle(MyClass)
   • New: occ::handle<MyClass>
5. Modern Containers: We are phasing out NCollection aliases (e.g., TColStd_SequenceOfReal) to encourage direct usage of template classes.
   • Example: occ::Seq<double> or NCollection_Sequence<double>
6. New Aliases: Introducing short aliases in the occ namespace (e.g., occ::Seq<T> for NCollection_Sequence<T>).
7. Standard Attributes: Replacing macros like Standard_NODISCARD with standard C++ attributes: [[nodiscard]], [[maybe_unused]], etc.
8. Error Handling: Updating basic Geom functions to use std::optional for return values, reducing reliance on exceptions for absent values.
9. Safety & Speed: Widespread implementation of constexpr and noexcept specifiers.
10. C++17 Standard: The codebase is being updated to C++17 to leverage modern language features.
11. Consolidated Failures: Reducing the number of custom failure types (based on Standard_Failure) and consolidating them into a centralized structure.

---

🔮 Roadmap & Future Concepts

We are currently validating several major enhancements for the 8.0.0 release cycle. While these features are in various stages of planning and development, our roadmap includes:

• Standardized Exceptions: A targeted migration to std::exception to replace Standard_Failure.
• Documentation Upgrade: Migrating documentation from Doxygen to a Markdown-based system for significantly better readability and accessibility.
• New "ODE" Format (Announcement): A proposed format in the DataExchange module to replace the legacy BRep format. ODE (Open Data Exchange) focuses on pure topology but features a modern architecture, versioning support, and extensibility.
• New "XDE" Format (Announcement): Extending XCAF support with XDE (eXtended Data Exchange). This format focuses on assembly and product structure data (colors, layers, materials) with a modular architecture designed for easy feature addition.

---

🛠️ Extra Activities & "Light OCCT"

New Modules

• TKHelix: Available now in version 8.0.0rc2, providing support for helix and spiral curves.
• New Modeling Module: An additional modeling module is currently in development for the final release.

Announcement: Light OCCT (Beta)
We are actively developing an Open Source wrapper named Light OCCT, scheduled for a beta release close to the OCCT 8.0.0 launch.

Light OCCT is designed to lower the barrier to entry by prioritizing usability, safety, and performance. Key goals for this wrapper include:

1. Modern C++ Interface: Reducing boilerplate and integrating seamlessly with modern C++ applications.
2. Enhanced Safety: Incorporating built-in best practices to improve application reliability.
3. Simplified API: An intuitive, user-friendly interface that flattens the learning curve.
4. Multi-Language Support: Out-of-the-box bindings for Python and JavaScript/TypeScript (Web support).

Stay tuned for more technical deep dives as we approach the release!

Best regards,
OCCT Dev Team.

[gumyr]

The build123d team is very pleased to see strong progress in OCCT, and we’re excited about the ongoing improvements in robustness and new functionality. The new “Light OCCT” Python bindings are of particular interest to us. Build123d currently uses OCP, and we are curious about the long-term vision for these new bindings.

Specifically: Is the goal for "Light OCCT" to eventually cover the full OCCT API, or is it intended to be a more focused subset?

For context, build123d relies on the following OCP modules:
APIHeaderSection, Aspect, BOPAlgo, BRep, BRepAdaptor, BRepAlgo, BRepAlgoAPI, BRepBndLib, BRepBuilderAPI, BRepCheck, BRepClass3d, BRepExtrema, BRepFeat, BRepFill, BRepFilletAPI, BRepGProp, BRepIntCurveSurface, BRepLProp, BRepLib, BRepMesh, BRepOffset, BRepOffsetAPI, BRepPrimAPI, BRepProj, BRepTools, BinTools, Bnd, Font, GC, GCPnts, GProp, GccEnt, Geom, Geom2d, Geom2dAPI, Geom2dAdaptor, Geom2dGcc, GeomAPI, GeomAbs, GeomAdaptor, GeomConvert, GeomFill, GeomLib, GeomProjLib, Graphic3d, HLRAlgo, HLRBRep, IFSelect, IGESControl, IVtkOCC, IVtkVTK, IntAna2d, Interface, LocOpe, Message, NCollection, Precision, Prs3d, Quantity, RWGltf, RWStl, STEPCAFControl, STEPControl, ShapeAnalysis, ShapeCustom, ShapeFix, ShapeUpgrade, Standard, StdFail, StdPrs, StlAPI, TColStd, TColgp, TCollection, TDF, TDataStd, TDocStd, TopAbs, TopExp, TopLoc, TopTools, TopoDS, XCAFApp, XCAFDoc, XSControl, gce, gp

We’re eager to understand how "Light OCCT" may evolve and how we might align with it in the future.

[dpasukhi]

Goal of Light OCCT is not give you OCCT as is.
It is wrapper, not swig one. It is manual C++ wrap around C++. And Python and JS will be totally the same API as c++.
It means, you will not have APIHeaderSection class or any other class that you have in OCCT directly.
You can check the poc version of Light OCCT, the idea of final version will be similar: https://dpasukhi.github.io/OCCT-Light/api/
_
If some extra functionality will be needed, it will be trivial patch to extend the API on your end. But you will need to know C++ first.