OCCTSwiftIO v1.1.0

Adds the MeshIO product: pure-Swift 3D mesh I/O (no OCCT) — STL/OBJ/PLY native + PMX/.x via SwiftPMX/SwiftX. The OCCT-free home for mesh formats.

v1.0.1 — re-pin OCCTSwift 1.7.1

Re-pin OCCTSwift floor to 1.7.1 (OCCT 8.0.0p1, redesigned BRepGraph/TopologyGraph). No API changes; 22 tests pass.

v1.0.0 — graduate alongside OCCTSwift 1.0.x (OCCT 8.0.0 GA)

Pure dep bump to graduate alongside OCCTSwift v1.0.0 (OCCT 8.0.0 GA pin). No public API changes in this package. SemVer-stable from this tag.

Pin: from: "1.0.0"

Closes #3.

v0.2.0 — ML-export hoist from OCCTSwift kernel

v0.2.0 — ML-export hoist from OCCTSwift kernel

ML-export hoist from OCCTSwift per #1 (supersedes OCCTSwift#71). The consumption-side ML repacking layer added to OCCTSwift in v0.136.0 — pure batch / headless workflow, no Viewport — fits this package's charter, so it lives here now.

New public API

OCCTSwift.TopologyGraph extension:

• struct GraphExport — flat vertex positions + per-edge boundary/manifold flags + COO-format face/edge/vertex incidence + face-to-face adjacency.
• func exportForML() -> GraphExport — build the export from a TopologyGraph.
• func exportJSON() -> Data? — JSON serialization for ML pipelines.

What did not move (and why)

• FaceGridSample / sampleFaceUVGrid(faceIndex:uSamples:vSamples:) stay in OCCTSwift. Their implementation calls OCCTBRepGraphSampleFaceUVGrid on TopologyGraph.handle, which is internal to the OCCTSwift module — lifting them would require widening kernel visibility, which the partial-lift decision on issue #1 rules out as out-of-scope.
• sampleEdgeCurve(edgeIndex:count:) similarly stays — same handle constraint.

Breaking change for OCCTSwift consumers

TopologyGraph.exportForML / exportJSON have been deleted from OCCTSwift v0.171.0. Direct callers must now import OCCTSwiftIO in addition to import OCCTSwift. Symbol resolution otherwise unchanged. Known callers swept: OCCTSwiftScripts/Sources/occtkit/Commands/GraphML.swift, OCCTSwiftScripts/Sources/GraphML/main.swift.

Dependencies

OCCTSwift ≥ 0.171.0 (the kernel release that ships the matching deletion).

v0.1.0 — headless CAD file I/O for OCCTSwift

Initial release. Spin-out of file-I/O concerns from OCCTSwiftTools per OCCTSwiftTools#12 so headless consumers (Scripts, PadCAM CLI, batch pipelines) don't drag in OCCTSwiftViewport transitively just to load a STEP file.

What's in this package

• enum ShapeLoader — load(from:format:progress:), loadRobust(...), loadFromManifest(at:). Returns ShapeLoadResult { shapesWithColors, dimensions, geomTolerances, datums, manifest }.
• enum CADFileFormat — .step, .stl, .obj, .brep, .iges (lifted from OCCTSwiftTools).
• enum ExportManager + enum ExportFormat — OBJ / PLY / STEP / BREP / glTF / GLB writers (lifted from OCCTSwiftTools).
• struct CADBodyMetadata — pure-data per-body picking metadata (face / edge / vertex indices). Produced by OCCTSwiftTools.CADFileLoader.shapeToBodyAndMetadata; lives here so the type itself doesn't carry a Viewport dep.
• struct ScriptManifest — Codable manifest format for the script harness (lifted from OCCTSwiftTools).
• final class ImportProgressClosure — closure-backed OCCTSwift.ImportProgress adapter (lifted from OCCTSwiftTools).

What's NOT here

• ViewportBody production. That's OCCTSwiftTools.CADFileLoader.shapeToBodyAndMetadata — one floor up — and is the entire reason this package exists separately.
• CADLoadResult { bodies: [ViewportBody], ... }. Stays in OCCTSwiftTools where the Viewport dep already lives.

Architecture position

OCCTSwiftAIS          (depends on Tools)
       ↑
OCCTSwiftTools        (bridge: Shape ↔ ViewportBody — depends on IO + Viewport)
   ↑       ↑
   |   OCCTSwiftViewport  (Metal renderer)
   |
OCCTSwiftIO           ← this repo
       ↑
OCCTSwift             (B-Rep kernel)

Installation

.package(url: "https://github.com/gsdali/OCCTSwiftIO.git", from: "0.1.0"),

Dependencies

• OCCTSwift ≥ 0.170.1. No transitive Viewport.

Stats

18 tests / 4 suites — all green on macOS arm64 with OCCT_SERIAL=1 swift test --parallel --num-workers 1.