Skip to content

CAD SDK Evaluation Report

Source files: cad_sdk_evaluation_report.docx, current NX live-control architecture and Techstack tracking Last synthesized: April 2026

Executive Summary

This evaluation compares CAD multiformat exchange SDKs for use in the TextCAD pipeline (DFM analysis, feature extraction, geometry simplification). The goal is to find a solution that reliably parses STEP, IGES, and optionally NX native files, and supports robust geometry operations.

Recommendation: OpenCASCADE (OCCT) via pythonOCC for primary geometry parsing and analysis; FreeCAD headless as secondary option for higher-level CAD modeling.

This report answers the headless geometry question. It does not replace the separate NX live-control question, which is now handled through an in-session NX Open host when the workflow must stay inside the real NX drafting session. See NX Live Control Architecture. For the companion operational matrix that maps common exchange formats between major CAD tools, plus the AICAD feature-value breakdown, see CAD Format Interoperability and AICAD.

Evaluation Criteria

Criterion Weight Notes
Format support High STEP, IGES, BREP; ideally NX/Parasolid
Geometry robustness High Feature detection, topology operations, healing
Python integration High Must have clean Python API for backend
Headless operation High Must run without GUI in production
Cost/licensing Medium Open-source preferred; commercial acceptable if cost justified
Documentation Medium API docs, examples, community support
Performance Medium Parsing speed, memory footprint for large models
Maintenance Medium Active development, security updates

Evaluated Options

Description: Industry-standard open-source geometric modeling kernel

Strengths: - ✅ Excellent STEP/IGES parsing - ✅ Robust B-Rep geometry operations - ✅ Clean Python bindings (pythonOCC) - ✅ Runs headless (no GUI dependency) - ✅ Free and BSD-licensed - ✅ Used in FreeCAD, Salome, many commercial tools - ✅ Strong community and documentation

Limitations: - ❌ No native NX format support (workaround: export to STEP) - ❌ Edge case handling can require custom healing logic - ❌ Moderate learning curve for advanced operations - ⚠️ C++ core (bindings are good but not all features exposed)

Best for: Core geometry parsing, feature extraction, rule-based DFM analysis

Cost: Free (open-source)

Integration: pythonOCC (pip install OCP or conda install -c conda-forge pythonocc-core)

2. FreeCAD (Open-Source Alternative)

Description: Full CAD suite built on OCCT with higher-level Python API

Strengths: - ✅ Built on OCCT (same solid foundation) - ✅ Higher-level Python API (easier to use than raw OCCT) - ✅ Includes CAM/DFM workbenches - ✅ Can run headless with Python scripting - ✅ Free and open-source (LGPL) - ✅ Large community, extensive documentation

Limitations: - ❌ Heavier footprint (full CAD app, not just kernel) - ⚠️ Performance slower than raw OCCT for batch processing - ⚠️ Version stability; rapid changes to Python API across releases - ❌ No native NX format support

Best for: Higher-level operations (feature modeling, assembly manipulation); prototyping before moving to OCCT

Cost: Free (open-source)

Integration: pip install FreeCAD or Docker image

3. Parasolid (Commercial, Siemens)

Description: Industry-standard commercial kernel; used in NX, Creo, Solid Edge

Strengths: - ✅ Exceptional robustness (Siemens invests heavily) - ✅ Native NX format support (Parasolid XT, X_T) - ✅ Excellent feature recognition - ✅ Superior topology healing - ✅ Widely used in aerospace/automotive

Limitations: - ❌ Expensive: $5K-50K/year (depending on usage tier) - ❌ License management (seat-locked, OEM licensing required) - ⚠️ Fewer Python bindings; mostly C/C++ APIs - ⚠️ Proprietary; limited code access for customization

Best for: Commercial products requiring maximum robustness; when NX native format is critical

Cost: License cost + implementation effort

4. ACIS (Commercial, 3D Systems)

Description: Another industry-standard commercial kernel; used in SolidWorks, AutoCAD

Strengths: - ✅ Very robust topology operations - ✅ Good feature recognition - ✅ Widely used in manufacturing

Limitations: - ❌ Expensive (similar to Parasolid) - ❌ Poor Python support (C/C++ focused) - ❌ No NX native format support

Best for: If you're embedding in a product that already licenses ACIS

Cost: $5K-50K/year

5. Shapely / PyGEOS (Python-Only)

Description: Lightweight Python geometry library built on GEOS (topological operations)

Strengths: - ✅ Easy to use, pure Python - ✅ No external dependencies (mostly) - ✅ Good for 2D operations and mesh cleanup

Limitations: - ❌ 2D-focused (not suitable for solid modeling) - ❌ Cannot parse STEP/IGES natively - ❌ Limited to topological operations, not B-Rep modeling - ❌ Not designed for CAD geometry

Best for: 2D geometry processing, mesh repair, post-processing (not primary CAD parsing)

Cost: Free (open-source)

Comparison Matrix

Criterion OCCT FreeCAD Parasolid ACIS Shapely
STEP support ✅ Excellent ✅ Excellent ✅ Excellent ✅ Good ❌ None
IGES support ✅ Excellent ✅ Excellent ✅ Excellent ✅ Good ❌ None
NX native format ❌ No ❌ No ✅ Yes ❌ No ❌ No
Python API ✅ Good ✅ Excellent ⚠️ Limited ⚠️ Limited ✅ Excellent
Headless operation ✅ Yes ✅ Yes ✅ Yes ✅ Yes ✅ Yes
Open-source ✅ Yes ✅ Yes ❌ No ❌ No ✅ Yes
Cost ✅ Free ✅ Free ❌ $5K-50K ❌ $5K-50K ✅ Free
Geometry robustness ✅ Strong ✅ Strong ✅ Excellent ✅ Excellent ⚠️ Limited
Feature recognition ✅ Good ✅ Good ✅ Excellent ✅ Excellent ❌ None
Community/docs ✅ Strong ✅ Excellent ⚠️ Limited ⚠️ Limited ✅ Strong

Recommendation

For TextCAD (DFM + Autonomous CAE)

Primary: OpenCASCADE (OCCT) via pythonOCC

Rationale: - ✅ Industry-proven geometry kernel - ✅ Excellent STEP/IGES support (covers 95% of use cases) - ✅ Clean Python API for production use - ✅ Free and open-source (no licensing costs) - ✅ Runs headless in Docker/cloud - ✅ Used in similar products (FreeCAD, Salome, commercial CAD tools)

For NX native format: If you need to directly read NX files without exporting to STEP first: - Option A (Recommended): Require users to export STEP from NX (standard workflow anyway) - Option B (Future): License Parasolid if NX integration becomes critical

Secondary tool: FreeCAD headless for prototyping and higher-level CAD modeling (assembly operations, feature modeling)

Where NX Open Fits

The current RapidDraft stack now has a clearer split than this original report assumed.

For headless geometry, this report still stands: OCCT remains the right default choice because it is strong on STEP/IGES, practical in Python, and suitable for production services.

For live NX drafting workflows, the product now uses a different architectural layer:

  • an NX Open host loaded into the real NX session
  • live session targeting rather than detached helper execution
  • review-sheet creation, layout iteration, and PDF export inside NX
  • a migration path from the current managed host to a native NX Open C++ host for deeper drafting control and Open C / UFUNC fallback

So the revised interpretation is:

  • OCCT / translators are still the right answer for general geometry infrastructure
  • NX Open live control is the right answer when the workflow must remain inside NX

Implementation Strategy

Phase 1: OCCT/pythonOCC (Production)

from OCP.STEPControl import STEPControl_Reader
from OCP.TopExp import TopExp_Explorer
from OCP.TopAbs import TopAbs_FACE, TopAbs_EDGE

# Load STEP file
reader = STEPControl_Reader()
reader.ReadFile("part.step")
reader.TransferRoots()
shape = reader.OneShape()

# Extract faces, edges, compute properties
explorer = TopExp_Explorer(shape, TopAbs_FACE)
while explorer.More():
    face = explorer.Current()
    # Analyze face properties, detect features
    explorer.Next()

Dependencies: 

pip install OCP  # or use conda-forge

Performance: - STEP parsing: <1 second for typical parts (<10K faces) - Geometry operations: <5 seconds for feature detection - Memory: ~200MB per loaded model

Phase 2: Commercial Option (If Needed)

If user feedback indicates NX native format is critical: 1. Evaluate Parasolid licensing terms 2. Prototype dual-path: OCCT for STEP + Parasolid for NX 3. Make NX import optional (cost/complexity trade-off)

Risks & Mitigation

Risk Severity Mitigation
OCCT doesn't handle malformed CAD Medium Implement healing + validation layer; fall back to manual intervention
STEP files are incomplete (missing solids) Medium Detect and warn user; log for support
Performance for very large models (100K+ faces) Low Profile and optimize; consider mesh-based fallback for CAE
Maintenance if OCCT API changes Low Stay on stable LTS releases; monitor GitHub

Testing & Validation

Test Coverage

  1. Format parsing: STEP, IGES files from major CAD tools (Autodesk, Siemens, etc.)
  2. Feature detection: Holes, pockets, bosses, ribs, bends on representative parts
  3. Geometry operations: Face suppression, edge healing, topology validation
  4. Performance: Batch processing 100 models; measure parsing time and memory
  5. Edge cases: Degenerate faces, missing solids, self-intersections

Success Criteria

  • ✅ Parse 95%+ of real STEP files from customers
  • ✅ Detect features with >80% accuracy
  • ✅ Handle edge cases gracefully (log, warn, don't crash)
  • ✅ Process typical part in <5 seconds

Deployment Considerations

Python Environment

FROM python:3.10
RUN pip install OCP PyQt5  # PyQt5 optional for FreeCAD headless
RUN apt-get install -y libocct-*  # If using system OCCT

API Wrapper

Recommend creating a wrapper library to abstract OCCT: 

# src/geometry/shape_loader.py
class ShapeLoader:
    def load_step(self, filepath: str) -> GeometryFacts
    def extract_features(self, shape) -> FeatureCandidates
    def compute_measurements(self, shape) -> Measurements

This isolates OCCT calls and allows future SDK swaps without rewriting code.

Conclusion

OpenCASCADE (OCCT) via pythonOCC is the right choice for TextCAD. It provides: - Production-ready geometry parsing - Excellent cost (free) - Community support - Flexibility to extend with custom healing/feature recognition - Clear upgrade path (Parasolid) if commercial requirements emerge later

Next steps: 1. Prototype feature extraction on 5-10 real customer parts 2. Build geometry healing layer for malformed CAD 3. Integrate into DFM pipeline 4. Monitor performance; optimize if needed

Commercial Translator SDKs — Deep Evaluation

Source: CAD multiformat exchange sdk research/Research from CHATGPT.docx — product/ops evaluation of commercial CAD translator SDKs for RapidDraft Studio Focus: Licensing for cloud SaaS, behaviour on real-world assemblies, and new-version support cadence

Context

If the product goal is "drop in a SolidWorks/CATIA/NX file and RapidDraft just works," the translator SDK becomes a core product dependency, not a side feature. The differences between SDKs show up less in happy-path demos, and more in: 1. Licensing in a cloud SaaS (autoscaling, multi-tenant) 2. Behaviour on ugly real-world assemblies (external refs, configurations, suppressed components) 3. What happens when CAD vendors ship new yearly versions

SDK Comparisons

Strengths: - Explicit support for "massive assembly" workflows (load/unload components), assembly instances/external refs/configurations - B-Rep, PMI (visual + semantic), and tessellation in one SDK - Access to persistent face IDs — essential for revision-stable workflows and geometry anchor stability - Format-version update cadence: CAD readers updated to latest authoring versions within ~90 days - Current version coverage documented for SolidWorks, CATIA V5, and NX

Cloud/SaaS risks: - Enterprise pricing — published indicative figures: ~$33k/yr partnership fee + $20k/yr minimum. Must negotiate SaaS-specific terms (how cores/containers are counted) - Trial licenses include telemetry (sends CPU info, MAC addresses to Tech Soft endpoint) — can complicate pilots in restricted IT environments

Best fit for RapidDraft: When roadmap includes enterprise assemblies, semantic PMI, stable IDs for revision workflows, and you want a premium SDK with strong documentation of those exact problems

3D InterOp (Spatial / Dassault Systèmes)

Strengths: - Selective import of product data (structure, graphics, geometry, manufacturing info) — useful to avoid processing entire assemblies when only one sub-tree matters - Works across major modellers (ACIS, CGM, Parasolid) - "Data Prep" add-on: reduce model complexity and mask IP during import — useful for "share-safe" derivatives (simplified models for suppliers) - Emphasises "manufacturing-grade geometry fidelity"

Cloud/SaaS risks: - Pricing is quote-driven (less transparent) - Must clarify server-side multi-tenant SaaS licensing explicitly - Kernel/ecosystem bias can influence topology consistency quality in edge cases

Best fit: When vision leans toward "manufacturing-grade" geometry fidelity, selective import workflows, and potential IP masking for supplier sharing

3D_Kernel_IO (CoreTechnologie)

Strengths: - "Complete technical extraction": assembly structure, attributes, B-Rep + tessellated models, PMI, and feature/history access - Automatic healing modules - Windows/Linux/Mac support - "Flexible annual fee or per-license cost" with CodeMeter-based locking

Cloud/SaaS risks: - Higher customer expectations if you advertise feature/history accuracy — requires stronger regression testing - Must confirm how they count servers/cores/containers in autoscaling environments

Best fit: When the product vision is heading beyond "drawings from geometry" into manufacturing intelligence (features/PMI-driven automation) and you want that capability on the table early

Datakit CrossCad/Ware

Strengths: - Very broad format surface area — dimensions/tolerances/annotations, features, assemblies, B-Rep, mesh/tessellation - Open CASCADE (OCC) output option — strategically relevant since RapidDraft's stack is OCC-based - glTF/GLB I/O supported - Modular format licensing — buy exactly what you need - Frequent releases and regular updates

Cloud/SaaS risks: - Module sprawl — different enterprise customers demanding different format modules and version support - Assembly edge cases: breadth of format doesn't automatically mean painless assembly import

Best fit: When you want broad format coverage and flexibility, and like the OCC-friendly output option without betting on the most expensive premium tier vendor first. Validate assembly edge cases early with real customer datasets.

CAD Exchanger SDK

Strengths: - Transparent, modular licensing: formats licensed individually or in a bundle; "development fee + distribution fee" model - Supports SolidWorks/CATIA/NX import and STEP/JT/glTF export - Preserves structure/metadata/appearances

Cloud/SaaS risks — this is the critical concern: - Distribution fee is "per end-user's machine" with differences for desktop vs server - Generates licence keys per host-id with quarterly reporting/fees - In a SaaS with autoscaling containers where instances come and go, host-id licensing can become a severe operational constraint - Cost can scale with number of servers (not revenue or customer seats)

Best fit: Only if they offer a cloud-friendly licensing agreement that won't fight your autoscaling/cloud deployment model. Do not assume this is available — negotiate explicitly before committing.

Recurring "Gotchas" for RapidDraft's SaaS Model

Risk Detail
Drawings magnify geometry defects Tiny topology gaps that look fine in a shaded viewer create ugly HLR artefacts (extra edges, broken silhouettes, noisy section lines). Prioritise SDKs with strong B-Rep healing.
Assemblies are the real workload External references, configurations, instances, partial loading — this is where 80% of pain lives. Not the single part.
SaaS licensing can make autoscaling impossible The biggest strategic risk is not technical — it is getting locked into a licence model that assumes fixed machines. CAD Exchanger's public licensing text is the clearest example.
PMI — decide now whether it's core If you ever want "auto-annotate drawings from model PMI," pick a toolkit with semantic PMI, not only visual. HOOPS, CoreTechnologie, and Datakit all explicitly support semantic PMI extraction. 
Native CAD file (SolidWorks/CATIA/NX)
        ↓  Commercial translator SDK
STEP AP242 (truth geometry)  +  GLB (viewer)  +  Assembly manifest
        ↓
Existing RapidDraft pipeline (OCC/FreeCAD)
        ↓
DFM checks  +  Drawing generation  +  Report

Key lever for cost control: Cache identical uploads aggressively. Cached conversions don't consume paid translation quota — this is a major margin lever at scale.

Licence negotiation priority: Confirm how the SDK counts in your environment: per conversion? per concurrent job? per host-id? per core? Get SaaS-friendly concurrency terms in writing before signing.

Short Recommendation by Customer Type

Customer type Recommended SDK
Enterprise assemblies (automotive/aero suppliers) HOOPS Exchange — lowest product risk
Manufacturing-grade geometry + IP masking 3D InterOp + Data Prep
Feature/history-driven automation in roadmap 3D_Kernel_IO
Broad format coverage + OCC compatibility Datakit CrossCad/Ware
Cost-sensitive with modular needs CAD Exchanger — only if cloud-friendly licence is confirmed

Sources

  • cad_sdk_evaluation_report.docx
  • D:\02_Code\47_NXconnection\README.md
  • D:\02_Code\47_NXconnection\NATIVE_CPP_HOST_ARCHITECTURE.md
  • C:\Users\adeel\OneDrive\100_Knowledge\203_TextCAD\01_Product_Project_Management\00_Project_Management_n_skills\01_tracks\techstack\TRACKING.md
  • C:\Users\adeel\OneDrive\100_Knowledge\203_TextCAD\01_Product_Project_Management\00_Project_Management_n_skills\03_decision_log\DL-006_nx-live-control-should-converge-on-native-cpp-host.md