Skip to content

Releases: SecondMouseAU/OCCTSwiftScripts

v1.4.2 — cap OCCTSwiftIO to 1.0.x (fixes lean-consumer resolution)

Choose a tag to compare

@gsdali gsdali released this 01 Jul 20:48
6ed14de

Dependency-constraint patch. No API changes.

Fix (#69, PR #70): OCCTSwiftScripts declared occtDep("OCCTSwiftIO", from: "1.0.0"), which is only bounded by the major version. Once OCCTSwiftIO v1.5.0 was published, any consumer depending on OCCTSwiftScripts without its own root-level OCCTSwiftIO override resolved OCCTSwiftIO to 1.5.0, dragging in the heavy mesh-IO stack (SwiftX / SwiftDXF / SwiftJWW / SwiftPMX / ThreeMF / SwiftGLTF / Nodal / Zip) and making the dependency graph unsolvable (exhausted attempts to resolve the dependencies graph). This broke OCCTMCP's execute_script, whose cached SPM workspace depends on ScriptHarness alone.

Change:

  • New occtDepUpToNextMinor helper; OCCTSwiftIO is now pinned with .upToNextMinor(from: "1.0.0") (the 1.0.x line — the narrow surface used by the GraphML / graphml verbs, which has no need for 1.1.0+).
  • Also fixes a sibling-detection false-positive in the local-clone occtDep path (a .build/checkouts/OCCTSwiftIO was wrongly treated as a dev sibling and used via .package(path:) transitively — the deeper mechanism behind #69).

Lean/transitive consumers (OCCTMCP execute_script, PadCAM, PartsAgent) now resolve without needing their own OCCTSwiftIO cap.

🤖 Generated with Claude Code

v1.4.0 — load-brep / import --allow-invalid

Choose a tag to compare

@gsdali gsdali released this 20 Jun 00:09
4859b27

load-brep and import gain --allow-invalid (JSON: allowInvalid), threaded to OCCTSwift 1.8.0's Exporter.writeBREP(allowInvalid:). Lets an in-progress reconstruction — a compound of loose analytic faces, possibly invalid — be persisted into a scene manifest and reloaded for measurement (metrics, measure-deviation, graph-validate), instead of being refused by the shape.isValid write gate. Default off preserves the gate. OCCTSwift floor → 1.8.0.

Enables OCCTMCP #41. PR #60.

v1.3.0 — occtkit measure-deviation verb + metrics boundingBoxOptimal

Choose a tag to compare

@gsdali gsdali released this 19 Jun 23:28
5aa3b06

Two introspection capabilities, bringing occtkit (and the OCCTMCP Node server that wraps it) to parity with OCCTMCP's Swift in-process tools.

measure-deviation <a.brep> <b.brep> [--deflection D] [--max-samples N]

Directed + symmetric surface deviation (one-sided / symmetric Hausdorff). Unlike measure-distance (minimum gap, ≈0 for overlapping bodies), it samples each shape's tessellated surface and projects onto the other's triangles — the metric for certifying a mesh→analytic reconstruction. Reports {max, rms, mean, worstPoint, samples} per direction + symmetricHausdorff. Exact point-to-triangle; fidelity scales with --deflection (default 0.5% of the a-shape bbox diagonal).

metrics --metrics …,boundingBoxOptimal

Opt-in tight extent (BRepBndLib::AddOptimal); the default Bnd_Box over-reports curved B-spline faces (control-point hull). Default-all set unchanged.

Refs: OCCTMCP #41, #44. PR #59.

v1.2.0 — graph-select verb + convexity in graph-ml

Choose a tag to compare

@gsdali gsdali released this 18 Jun 23:00
d95999b

Adds the BRepGraph selection primitives (on the 1.7.1 floor).

  • graph-select verb (closes #54): local adjacency/selection queries — face-neighbors (+ convexity + shared-edge count via the kernel AAG), edge-faces, vertex-edges, face-adjacency (full gAAG), edges-class (boundary|non-manifold|seam|degenerate) — without dumping the whole graph.
  • graph-ml now emits a convexity-attributed faceAdjacency block (closes #55), the gAAG edge attribute B-rep GNNs key on.

Built + smoke-tested against OCCTSwift 1.7.1; the rewrap preserved the AAG/adjacency reads. (#56)

v1.1.0 — OCCTSwift 1.7.1 / OCCT 8.0.0p1

Choose a tag to compare

@gsdali gsdali released this 18 Jun 23:00
cb2513b

Bumps the OCCTSwift floor 1.3.1 → 1.7.1 (= OCCT 8.0.0p1). OCCTSwift 1.7.0 realigned the BRepGraph wrapper to OCCT's redesigned graph model; 1.7.1 made the derived graph reads real again (adjacentFaces/faces(of:)/edges(of:)/sharedEdges, faceSameDomain, faceIsNaturalRestriction) + durable UID/RefUID/ItemUID identity.

The graph verbs (graph-validate/compact/dedup/ml, query-topology) build and run unchanged; smoke-tested on recipes/01. Behaviour changes are confined to the BRepGraph domain (edgeMaxContinuity/setEdgeRegularity now no-ops → Shape.maxContinuity; degenerated/closed/sameParameter/sameRange setters no-op, getters live-derived). Cohort resolves unchanged at existing floors. (#58)

v1.0.5 — iOS platform support

Choose a tag to compare

@gsdali gsdali released this 15 Jun 23:12
5228e7c

iOS platform support (closes #52)

Declares .iOS(.v18) in the package so the library products — DrawingComposer and ScriptHarness — link into downstream iOS apps (e.g. a SwiftUI app deploying to iPhone). Previously SPM assumed iOS 12 for these targets, so any iOS app pulling them failed resolution against OCCTSwift's iOS-15 floor. v18 matches the sibling cohort (Viewport/Tools/AIS are .iOS(.v18)).

Also in this release

  • ScriptContext output-directory selection is now platform-guarded. macOS behaviour is unchanged (iCloud Drive if present, else ~/.occtswift-scripts/output); iOS writes into the app sandbox's Documents directory, since homeDirectoryForCurrentUser and the ~/Library/Mobile Documents iCloud path are unavailable in the iOS sandbox.

Scope

Library products only. The executable targets (occtkit, Script, legacy Graph*) shell out via Foundation.Process and remain macOS-only — SPM never pulls them into an iOS app that links a library product.

Verified

  • xcodebuild -destination 'generic/platform=iOS' builds both DrawingComposer and ScriptHarness (arm64-apple-ios18.0).
  • swift build on macOS still links all executables.

Downstream consumers can now move their pin to from: "1.0.5".

v1.0.4 — Assembly general-arrangement drawings

Choose a tag to compare

@gsdali gsdali released this 13 Jun 22:53
2c3f813

General-arrangement / assembly drawings (#50)

DrawingComposer.Composer.render only took a single Shape. Two new overloads produce one GA sheet that lays out multiple parts together with per-component identity:

  • render(spec:components:) — lays out [DrawingComponent] in shared views (one scale + placement frame → parts sit in assembled positions), draws a numbered balloon per part, and renders a parts-list (BOM) table. Same partNumber/name merge into one BOM row with summed quantity; every instance is still drawn. Optional per-component transform (12-elt row-major 3×4) positions a part before projection.
  • render(spec:document:) — flattens an XCAF Document to its positioned leaf parts and delegates; leaf names drive the parts list.

Reuses upstream OCCTSwift v0.150 BillOfMaterials + Sheet.renderBOM + DXFWriter primitives. DrawingComposerResult gains componentCount + partsList (both defaulted → source-compatible; the single-shape path and the occtkit CLI are unchanged).

Scope: per-view sections/detailViews/dimensions/manual annotations key to one drawing per named view and are not carried into the GA path; auto centrelines/centermarks are applied per component. No cross-component hidden-line removal (each part's HLR is independent).

Tests

First tests for the DrawingComposer module — new DrawingComposerTests target (3): multi-component BOM merge, empty-throws, placement transform.

🤖 Generated with Claude Code

v1.0.3 — align cohort floors to crash-fixed Viewport 1.0.4

Choose a tag to compare

@gsdali gsdali released this 26 May 06:30
6d790b2

Aligns Scripts to the crash-fixed cohort: OCCTSwiftViewport 1.0.1 → 1.0.4, OCCTSwiftTools 1.0.2 → 1.1.1, OCCTSwiftAIS 1.0.0 → 1.0.2. Render-preview now hard-requires the fixed Viewport (uncatchable quantize() crash #30 + the Viewport↔Tools cycle fix). Pure dep-floor alignment; the occtkit CLI builds and runs.

🤖 Generated with Claude Code

v1.0.2 — bump cohort floors (cosmetic)

Choose a tag to compare

@gsdali gsdali released this 09 May 09:21
be3c89d

Cosmetic floor bumps. OCCTSwift 1.0.1 → 1.0.3, Viewport 1.0.0 → 1.0.1, Tools 1.0.0 → 1.0.2. All three resolved forward to these versions under SemVer's from: semantics already; this matches declared intent to actual cohort. No public API changes. Pin: from: "1.0.2".

v1.0.1 — bump OCCTSwiftViewport floor to 1.0.0

Choose a tag to compare

@gsdali gsdali released this 09 May 08:39

Highlights

Viewport floor bump completing the v1.0 cohort alignment.

Changes

  • Bump OCCTSwiftViewport floor to from: "1.0.0" (closes #45). Viewport graduated to v1.0.0 on 2026-05-08, one day after the rest of the cohort, and v1.0.1 followed the next day. The bump was blocked on OCCTSwiftTools v1.0.2, which widened its own Viewport constraint; that release unblocked this one.
  • Documentation refresh: README Requirements and CLAUDE.md Dependencies entries updated for the v1.0 cohort. Adds the previously-missing OCCTSwiftAIS and OCCTSwiftIO requirements to the README, and trims pre-1.0 dep narrative from CLAUDE.md (still consultable in git log if you need to support an older floor).

Resolved cohort

Package Floor Resolves to
OCCTSwift 1.0.1 1.0.3
OCCTSwiftViewport 1.0.0 1.0.1
OCCTSwiftTools 1.0.0 1.0.2
OCCTSwiftAIS 1.0.0 1.0.0
OCCTSwiftMesh 1.0.0 1.0.0
OCCTSwiftIO 1.0.0 1.0.0

Verbs

No new or removed verbs in this release — same 26-verb surface as v1.0.0.