OCCT-Light, CascadeScope, and New CAD Data Work: A Developer Insight from OCCT3D #1282
Replies: 1 comment 3 replies
-
|
I wanted to give it a try, but build fails with There seems to be no |
Beta Was this translation helpful? Give feedback.
-
|
Hello, my apologies for inconvenience. Could you share the OS and interested binding? To be sure that it is will be available to download. After merging of BRepGraph changes i also will inform that the project will be able to build correctly ;) |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the quick reply
I work on MacOS arm (Apple Silicon)
Does this mean BRepGraph will change in OCCT 8? |
Beta Was this translation helpful? Give feedback.
-
|
in 8.1.0-dev yes. In 8.0.x - no. in 8.1.0 a lot of new functionality will be added and interfaces will be a little reorginized, but the logic will preserved. OCL is targeting 8.1.0 version and will be stabilized with newer interface during development circle. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
We are currently working on several connected OCCT3D activities. From the outside they may look like separate topics: a multilanguage SDK, a browser and desktop CAD inspection application, and a new family of exchange and patch formats. In practice, they all point to the same direction: making CAD data easier to access from applications, scripts, browser tools, local tools, and AI-assisted work.
This sounds simple, but CAD makes it difficult. A CAD model contains topology, geometry, mesh data, attributes, assemblies, document references, visualization state, and a lot of history hidden behind the final shape. When we expose it as one large file, most tools can only load it, save it, or try to modify the whole thing at once. The next generation of CAD work needs a more exact interface: tools should be able to refer to a face, edge, solid, assembly item, attribute, or mesh item by a stable ID, ask for local model information, and propose a small change that the CAD application can check.
flowchart LR A["Open CASCADE Technology"] --> B["OCCT-Light"] A --> C["CascadeScope"] A --> D["OBE / ODE"] D --> E["OBP / ODB"] B --> F["SDK for many languages"] C --> G["Browser and desktop inspection"] D --> H["Exchange with stable UIDs"] E --> I["Readable partial patches"]OCCT-Light as a compact SDK
The first part of this work is OCCT-Light, a multilanguage CAD processing SDK. The current direction covers C, C++, Rust, Python, Go, WebAssembly, TypeScript, JavaScript, Node.js, Java, and C#. The list of languages is important, but the main idea is a compact and predictable API for OCCT functionality.
OCCT is a large native C++ CAD kernel. That power is the reason it is used in many serious engineering applications, and it also makes clean bindings across many languages difficult. OCCT-Light approaches this through a stable C ABI: handles, plain data structures, clear status codes, and versioned options. On top of that layer, each language can have a thin API that feels natural in that language.
This gives us one reviewed low-level contract. Language bindings can share the same behavior, generated APIs become easier to test, error handling becomes more consistent, and the public API becomes easier to understand for both developers and tools. OCCT-Light also starts from topology: graph nodes, identifiers, stable UIDs, iterators, options, and clear ownership. Scripts, services, and AI assistants work much better when they can name and inspect the items inside the model.
OCCT is the CAD kernel used by tools such as build123d and CadQuery. OCCT-Light explores a direct OpenCascade SDK path for this kind of code-driven CAD processing. It is open source and currently in an early prototype stage.
flowchart TD A["Open CASCADE Technology"] --> B["OCCT-Light Core"] B --> C["Stable C ABI"] C --> D["C++"] C --> E["Python"] C --> F["Rust"] C --> G["Go"] C --> H["Wasm / TS / JS"] C --> I["Node.js"] C --> J["Java"] C --> K["C#"]CascadeScope as an inspection application
The second part of the work is CascadeScope, a pure C++ CAD inspection application designed to work in the browser, Windows, Linux, and macOS. The browser demo is important because it runs as a static web page, without backend connectivity. A user can inspect CAD data in the browser without sending the model to a server.
For many CAD processes, this is more than a technical detail. Engineering data is often sensitive, and a useful browser tool should allow local inspection without requiring the model to leave the user's machine. We also plan a local backend mode where heavier calculations run on the user's PC while the browser remains the visual interface for model inspection, selection, and review.
The current focus of CascadeScope is topology and model inspection. The format direction includes STEP, IGES, BREP, XBF, VRML, PLY, OBJ, and trial support for DXF 2D/3D, SAT/SAB, Parasolid, and JT. The deeper goal is to inspect model structure: faces, edges, graph relationships, mesh state, presentation state, and connected data.
The next step is a direct Model Context Protocol (MCP) layer for local work. A browser or desktop CAD tool should be able to connect to backend activities running on the user's own machine. An assistant or tool can request organized model information, while the CAD application and local backend remain the owner of the model and the checker of changes.
flowchart LR A["CAD File"] --> B["CascadeScope"] B --> C["Browser static demo"] B --> D["Desktop app"] C --> E["No remote backend"] D --> F["Local tools"] B --> G["Local backend on PC"] G --> H["Calculations on PC"] G --> I["Local MCP layer"] I --> J["Automation / AI assistant"]OBE and ODE as exchange formats with stable IDs
The third part is a new exchange layer. OBE means OpenCascade BRep Exchange, and ODE means OpenCascade Data Exchange. OBE is focused on compact BRep graph exchange with stable UIDs. It makes the topology graph clear, small, and fast to read.
Early results show at least 5x smaller size than binary BREP and around 10x faster reading. The exact number will always depend on the model, but the direction is clear: when the model is stored as a graph, it becomes easier to load, index, inspect, compare, and reference.
ODE extends the idea from BRep exchange to data exchange. It is intended to organize BRep data together with assembly structure, connected attributes, and external documents. That makes it a base for PLM-oriented work, where geometry is only one part of the engineering record.
The key idea is stable IDs. If a face, edge, solid, instance, attribute, or document reference has a stable UID, then another tool can talk about it exactly. A stable ID turns "this face" or "that edge" into a reliable reference. For human users this is useful; for scripts and tools it is essential.
OBP and ODP as patch formats
Exchange is only part of the story. The next part is patching. OBP means OpenCascade BRep Patch, and ODP means OpenCascade Data Patch. These patch formats are designed around readable JSON formats, so the action layer can be read by people and used by tools.
The idea is that a local tool or AI assistant can ask for information about a specific item by UID. It can request the local data around a face, edge, shell, solid, mesh node, or assembly item, inspect connected attributes, and then propose a partial edit using a clear JSON format. The OCCT application still checks the action and decides whether the edit is legal. Text generation proposes an action; OCCT checks the result.
This is closer to how source-code tools work. A tool reads the relevant data, proposes a patch, and the developer or the system checks it. CAD needs a similar pattern: inspect by UID, dump focused model data, propose a small patch, check it in OCCT, and apply only the valid change.
sequenceDiagram participant Tool as MCP / AI Tool participant App as OCCT Application participant Model as CAD Model Tool->>App: Request item data by UID App->>Model: Read topology, geometry, mesh, attributes Model-->>App: Organized local data App-->>Tool: JSON dump Tool->>App: JSON patch proposal App->>App: Check action App->>Model: Apply partial edit App-->>Tool: Result and diagnosticsWhy this matters for AI-assisted CAD
AI-assisted CAD needs more than prompts and screenshots. For engineering work, tools need organized model access, stable IDs, checks, and a way to make small edits safely. Stable IDs let an assistant say which face or edge it is changing. Organized exchange avoids repeated reverse engineering of file-level behavior. A patch format keeps small changes from becoming full file rewrites. Local application connection keeps sensitive engineering data closer to the user's machine when a remote service is unnecessary.
The direction we are working on combines these parts. OCCT-Light provides the compact SDK for many languages. CascadeScope provides browser and desktop inspection. OBE and ODE provide compact exchange with stable IDs. OBP and ODB provide readable patch actions for partial edits. Model Context Protocol can become the local connection layer between applications, tools, and assistants. For us, the important part is giving CAD applications a better interface for scripts, tools, and AI-assisted work.
Training, consulting, and custom development
This work is also connected to practical support for teams building on OCCT. OCCT3D offers e-trainings with learning materials for mastering OCCT, as well as online and on-site training directly with OpenCascade developers. These trainings are useful for teams that want to understand the modeling kernel, data exchange, topology, visualization, and application-level connection in a clear way.
For companies building CAD, CAM, CAE, PLM, inspection, or engineering applications, we provide custom OCCT-based development, architecture and implementation consulting, connection support, maintenance of OCCT-based products, and help with performance, data exchange, visualization, and modeling work. More information is available at OCCT3D, and you can also contact us by email: contact.us.occt3d@capgemini.com
Looking forward
The key idea is structure. If CAD data has stable IDs, compact exchange, readable patches, and local application connection, then scripts and tools become much more practical. Developers can build tools around exact model items. Applications can expose only the relevant data. AI assistants can work with clear actions instead of vague file-level changes.
This is the direction behind OCCT-Light, CascadeScope, OBE, ODE, OBP, and ODB. It is still active work. Some parts are early prototypes, some APIs will change, and some ideas will become simpler as we check them on real models and real use cases. The goal is clear: make OCCT-based CAD data easier to access, easier to organize, and more useful for the next generation of engineering tools.
Links:
Beta Was this translation helpful? Give feedback.
All reactions