Common API: one interface, every format
This demo shows the unified entry point of MCAD SDK — the same API calls open files from different CAD systems and expose their structure consistently.
Loading multiple formats
We open files from several formats in sequence — SOLIDWORKS (.sldprt, .sldasm), Inventor (.iam), STEP (.stp), JT, and 3DM — through a single function call. The SDK detects the format from the file header, routes the request to the appropriate native reader, and returns a unified document object regardless of the source format. The Common Data Access (CDA) tree on the left renders identically across formats: assembly hierarchy at the top, parts and sub-parts below.
Switching between geometry representations
Many native CAD formats store more than one geometry representation per file — for example, precise B-Rep alongside tessellated mesh, or simplified representations for visualization performance. The SDK exposes these as primary and alternative representations — selecting between them updates the viewport without re-parsing the file. This is part of preserving full fidelity: nothing in the source file is dropped at read time.
Switching between PMI views
PMI (Product Manufacturing Information) is not just baked into geometry — it is organized into named views. Each view corresponds to a specific orientation and a specific set of annotations relevant to a manufacturing or inspection step. The SDK exposes these views explicitly, allowing the application to switch between them programmatically or in response to user selection.
Multi-format conversion to STEP
From the same Common API, any supported format can be exported to STEP. We trigger conversion on the open SOLIDWORKS, Inventor, and JT files — each produces a STEP file usable in any STEP-compatible tool. The conversion path is built into the API itself: any format that complies with the Common API contract gets STEP export automatically, with no per-format conversion code.
SOLIDWORKS: complex assembly access
This demo walks through structural and metadata access on a complex turbine assembly, showing how the SDK maps native SOLIDWORKS data into a navigable application model.
Assembly hierarchy through the CDA tree
As we navigate the 3D model, the Common Data Access (CDA) tree on the left indexes every component, sub-assembly, and individual fastener. Each entry corresponds to a component instance in the SOLIDWORKS database, including its file reference, position in the assembly, and configuration link. For complex assemblies with hundreds or thousands of components, this structured tree is what makes navigation tractable in a custom application.
Component-level metadata
Selecting a component — for example, the rear casing — exposes its metadata directly from the underlying database: source file path, document type (part or sub-assembly), unit system, creation and last-modified timestamps, and custom properties. Custom properties are read from the document's three levels — Document, Configuration, and Component — and exposed through a unified API.
Suppression and display state control
SOLIDWORKS components have suppression states that control whether they participate in the active configuration. The SDK exposes these states for read and modification — toggling between Resolved and Suppressed lets the application isolate specific internal geometry for inspection or simulation. This is part of write-back support, currently available for SOLIDWORKS.
Click-to-select synchronization
Selecting a part in the 3D view highlights its corresponding entry in the CDA tree, and vice versa. This bidirectional binding is essential for any UI that needs to keep visual and structural representations in sync — viewers, BOM editors, inspection tools, configurators.
Transformation accuracy in nested assemblies
Even within deeply nested sub-assemblies, the SDK preserves full 4×4 transformation matrices end-to-end. Components are positioned exactly as the original SOLIDWORKS database defines them, with no accumulated drift through the hierarchy. This matters for any workflow where geometric position is consumed downstream — manufacturing, simulation, collision detection.
Inventor: V10 engine assembly
This demo opens an Inventor V10 engine assembly in the ODA Visualize viewer and shows document property extraction through a sample application.
Assembly file structure
The .iam (assembly) file references multiple .ipt (part) files and other .iam sub-assemblies. The SDK traverses this reference graph and presents a complete tree, with all components resolved and positioned. Inventor uses .iam for assemblies and .ipt for parts — the SDK handles both file types and their internal references through a single unified document model.
Document properties
Inventor stores file metadata across three property streams: Summary Info, Design Tracking, and User Defined. The InvDocumentProperties sample application reads all three through the SDK and presents them in a single list — including Material, Mass, Last Saved By, Last Saved Date, Part Number, and any custom properties added by the user. These are the same properties Inventor's own UI exposes; the SDK reads them directly from the file with no Inventor installation required.
Read-only at this stage
Inventor support in the SDK is currently read-only. Write-back capabilities — modifying properties, updating component references, changing display states — are on the roadmap but not yet shipped. For workflows that need round-trip editing of Inventor data today, see the SOLIDWORKS demo above.
JT: visualization and PMI
This demo shows JT file visualization and PMI rendering — the two core capabilities required for using JT in PLM and downstream MBD workflows.
JT visualization
JT (ISO 14306) is the lightweight format widely used in PLM systems like Siemens Teamcenter. Its primary purpose is fast visualization of large assemblies — parts can carry multiple levels of detail (LOD) for performance scaling. The SDK loads JT files and renders them through the ODA Visualize SDK on desktop, web, and mobile, with appropriate LOD selection based on the application's needs.
PMI rendering
JT files commonly carry PMI (Product Manufacturing Information) — dimensions, GD&T frames, surface finish, datum references. The SDK renders this PMI according to the ASME Y14.5 standard, using the correct symbol library so manufacturing inspectors and downstream tools see the same annotations the source CAD system produced. Both the visual representation and the underlying semantic data are accessible through the API.
Conversions: STEP, DWG, Common API
This demo shows three conversion paths the SDK supports — bidirectional STEP↔DWG and unified Common API → STEP from any supported format.
DWG to STEP
We take a DWG file containing 3D geometry and convert it to STEP. The bridge transfers 2D and 3D B-Rep geometry, view definitions, and the geometric representation of PMI. The output is a valid STEP file consumable in any STEP-compatible tool — a common requirement when DWG-based design data needs to flow into MCAD systems that prefer STEP for exchange.
STEP to DWG
The reverse direction. STEP geometry, including B-Rep solids and PMI, is converted into DWG. Note that PMI in this direction is transferred as geometric representation — lines, arcs, text — rather than as semantic annotation. DWG does not have a native equivalent of STEP's semantic GD&T model, so this is a known boundary for round-trip workflows.
Common API to STEP — multi-format
Any supported MCAD format can be exported to STEP through the same Common API. We trigger conversion across SOLIDWORKS, Inventor, JT, and other open files in turn — each produces a valid STEP output without per-format conversion code on the application side. This is the universal pipeline: integrate the Common API once, get STEP export for every format that ships in the SDK.
