v1.2.0 — tunable wireframe edge deflection (#24)

Wireframe edge polyline extraction is now tunable, closing #24.

Edge polylines were extracted at a hardcoded 0.005 linear deflection (independent of the triangle-mesh deflection), so an edge following a long fine curve — e.g. a helical thread — became thousands of points: a slow-to-render, illegibly dense wireframe with no knob to coarsen it.

New (defaults preserve historical behaviour exactly):

• CADFileLoader.shapeToBodyAndMetadata(..., edgeDeflection: Double = 0.005, maxPointsPerEdge: Int = 1000, ...)
• WireConverter.wireToBody(..., maxPointsPerEdge: Int = 10000, edgeDeflection: Double = 0.005)
• Public default constants on both types.

Consumers can now coarsen edges at the source and drop the post-hoc ViewportBody.edges decimation hack — which also restores edge-picking.

MINOR per the cohort SemVer policy: new opt-in functionality, backward compatible. 28 tests green.

v1.1.2 — re-pin OCCT 8.0.0p1 cohort

Re-pin to the OCCT 8.0.0p1 cohort: OCCTSwift 1.7.1, OCCTSwiftViewport 1.1.20, OCCTSwiftIO 1.0.1. No API changes; 25 tests pass.

v1.1.1 — raise Viewport floor to 1.0.4

Raises the OCCTSwiftViewport floor 1.0.2 → 1.0.4, making the uncatchable quantize() crash fix (Viewport #30) and the Viewport↔Tools cycle fix (Viewport v1.0.4) hard minimums for Tools consumers. Pure dep-floor bump; no API change. 25 tests pass.

🤖 Generated with Claude Code

v1.1.0 — wire pointRadius / perPointColors through to ViewportBody

OCCTSwiftViewport v1.0.2 (issue #28) added the point-cloud rendering pipeline. PointConverter.pointsToBody now wires its pointRadius and perPointColors parameters through to the new ViewportBody.pointRadius / vertexColors fields, and stamps primitiveKind = .point.

Swift signature unchanged. Consumers passing those params now get the behaviour they always intended; consumers ignoring them keep the soft-amber fallback color and 0.05-world-unit default radius.

Dep bump: OCCTSwiftViewport from: "1.0.1" → from: "1.0.2".

Bumped MINOR per the cohort SemVer policy. Pin: from: "1.1.0".

Closes the renderer-side gap noted in #18. Downstream consumers (OCCTMCP's add_scene_primitive(pointCloud)) can now drop the 256-point sphere-compound workaround.

v1.0.2 — bump OCCTSwiftViewport to 1.0.1, OCCTSwift to 1.0.3

Pure dep bump.

• OCCTSwiftViewport 0.55.0 → v1.0.1 (graduates onto the SemVer-stable Viewport line)
• OCCTSwift 1.0.1 → v1.0.3 (picks up boolean-history Tier 1 and Tier 2/3 surfaces from OCCTSwift#165)

No public API changes in this package. Pin: from: "1.0.2".

v1.0.1 — PointConverter (issue #18)

Adds PointConverter.pointsToBody(_:id:color:pointRadius:perPointColors:) — sibling to CurveConverter / SurfaceConverter / WireConverter. Produces a ViewportBody whose vertices carry the cloud points and whose vertexData / indices / edges are empty; the renderer is expected to interpret the body as a point list.

OCCTMCP's add_scene_primitive(pointCloud) is the immediate consumer. Today (OCCTMCP v0.9) it caps at ~256 points and synthesises a sphere compound (~50k tris); switching to PointConverter lifts the cap because the body avoids triangulation entirely.

pointRadius and perPointColors are accepted as parameters for forward compatibility but the current ViewportBody has no fields to carry them. Renderer-side support for drawing those vertices as on-screen point primitives is tracked separately on the OCCTSwiftViewport side; until that lands, the body shape is correct but the points won't be visible.

Pure additive — no API surface removed or changed. Closes #18.

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

Dep bump to graduate alongside OCCTSwift v1.0.0 and OCCTSwiftIO v1.0.0. OCCTSwiftViewport stays at 0.55.0 (no v1.0 yet). SemVer-stable from this tag. Pin: from: "1.0.0". Closes #16.

v0.6.0 — split file-I/O concerns into OCCTSwiftIO

Splits file-I/O concerns into a new sibling package: OCCTSwiftIO v0.1.0 — depends on OCCTSwift only, no OCCTSwiftViewport. Closes #12.

Headless consumers (Scripts, PadCAM CLI, batch pipelines, server-side workflows) can now load CAD files without dragging in the Metal renderer transitively. Source compatibility preserved for existing Tools consumers via @_exported import OCCTSwiftIO.

What moved to OCCTSwiftIO

• enum CADFileFormat
• enum ExportManager + enum ExportFormat
• struct ScriptManifest
• final class ImportProgressClosure
• struct CADBodyMetadata (pure-data picking metadata; no Viewport dep)
• New: enum ShapeLoader — load(from:format:progress:), loadRobust(...), loadFromManifest(at:) returning ShapeLoadResult { shapesWithColors, dimensions, geomTolerances, datums, manifest }. No ViewportBody.

What stays here

• CADFileLoader.shapeToBodyAndMetadata(...) — the bridge. Unchanged.
• CADFileLoader.load(...) — now a thin façade over OCCTSwiftIO.ShapeLoader.load(...) plus per-shape bridge. Same return type (CADLoadResult with bodies: [ViewportBody]), same signature.
• CADFileLoader.loadFromManifest(...) — same façade pattern.
• CADLoadResult — couldn't move (has bodies: [ViewportBody]).
• Mesh parameter presets, CurveConverter, SurfaceConverter, WireConverter, BodyUtilities.
• STL/IGES robust-loader fallback path — bridge-aware (triggered by per-shape mesh-bridge failure), so it lives here.

Consumer migration

• Bridge users (AIS, CADKit, custom Metal viewers): no change. import OCCTSwiftTools works as before; @_exported re-exports IO so even direct OCCTSwiftTools.ExportManager etc. references still resolve.
• Headless users (Scripts, PadCAM CLI, batch tools): switch import OCCTSwiftTools → import OCCTSwiftIO to drop the transitive Viewport dep. ShapeLoader.load(...) is the headless analogue of CADFileLoader.load(...). CADLoadResult has no IO equivalent (it carries [ViewportBody]); use ShapeLoadResult.shapesWithColors instead.

Dependencies

• New: OCCTSwiftIO ≥ 0.1.0.
• OCCTSwift ≥ 0.170.1 — unchanged.
• OCCTSwiftViewport ≥ 0.55.0 — unchanged.

Stats

15 tests / 5 suites in this repo (was 29/8) — the moved test suites live in OCCTSwiftIO now (18/4 there, all green).

Sequencing toward 1.0.0

The issue's acceptance pins both packages at 1.0.0 against OCCT 8.0.0 GA (targeted 2026-05-07). Today's xcframework is OCCT 8.0.0-beta2. Tag both Tools and IO at 1.0.0 when OCCT 8.0.0 GA + OCCTSwift 1.0.0 land.

v0.5.1 — remove duplicate ShapeMeasurements after OCCTSwift kernel hoist

Removes the duplicate ShapeMeasurements type after the OCCTSwift kernel hoist landed in OCCTSwift v0.170.1 (PR gsdali/OCCTSwift#163). Closes #13.

No public API change

ShapeMeasurements and Shape.measure(linearTolerance:) still resolve at every existing call site — they now come from OCCTSwift instead of OCCTSwiftTools. CADFileLoader.shapeToBodyAndMetadata(includeMeasurements: true) continues to populate CADBodyMetadata.measurements exactly as before; the field's type is now the kernel-side ShapeMeasurements, identical in shape and behaviour to the previous Tools-side type.

What changed

• Deleted Sources/OCCTSwiftTools/ShapeMeasurements.swift (84 lines).
• Trimmed Tests/OCCTSwiftToolsTests/ShapeMeasurementsTests.swift to the single Tools-specific case (t_metadataIncludesMeasurementsWhenRequested, which exercises CADFileLoader.shapeToBodyAndMetadata). The 5 numeric correctness cases (box totals, centroids, cap-on-axis) live in the OCCTSwift kernel suite as of #163.
• Refreshed SPEC.md and docs/CHANGELOG.md.

Net: 5 files changed, +20 / −211.

Dependencies

• OCCTSwift ≥ 0.170.1 (was 0.168.0) — required for the kernel-side ShapeMeasurements type. The xcframework binary is unchanged from v0.170.0, so SPM consumers don't re-download.
• OCCTSwiftViewport ≥ 0.55.0 — unchanged.

Consumer migration (optional)

Consumers (e.g. OCCTSwiftAIS) can drop the OCCTSwiftTools import for ShapeMeasurements and import it directly from OCCTSwift instead — no longer pulling in the Tools+Viewport graph just for the measurement type. Existing code that already imports both keeps working unchanged.

v0.5.0 — Source-shape vertex convention (closes #10)

Pre-1.0 behaviour change. Closes #10.

Converges ViewportBody.vertices / vertexIndices / CADBodyMetadata.vertices on the source-shape convention so AIS' Selection.vertices (and any other consumer) can round-trip a picked primitiveIndex back to a TopoDS_Vertex via shape.vertex(at: primitiveIndex). v0.4.1's polyline-endpoint convention rendered the same number of points for typical solids but in a different order, breaking that round-trip.

What changed at runtime

• body.vertices is now shape.vertices() Float-converted (was: deduplicated polyline endpoints).
• body.vertexIndices is now the explicit identity array [0, 1, …, n-1] (was: empty, treated as identity by the renderer). Belt-and-braces against future renderer changes that drop the empty-as-identity interpretation.
• CADBodyMetadata.vertices aligned to the same source — single source of truth.

No public API signature changes. The init shapes are unchanged; what's different is what populates them.

AIS coordination

No breakage window. AIS v0.6.1 currently overrides body.vertices and body.vertexIndices itself in InteractiveContext.display(_:) to fix the round-trip. Once consumers upgrade to OCCTSwiftTools v0.5.0, AIS can drop that override — both sides will be writing identical data, so the transition is non-breaking.

Internal cleanup

Dropped the private deduplicateVertices(from:) helper (dead code post-convergence).

Dependencies (unchanged)

• OCCTSwift ≥ 0.168.0
• OCCTSwiftViewport ≥ 0.55.0

Test invocation

OCCT_SERIAL=1 swift test --parallel --num-workers 1

35 tests across 8 suites, all green.

Installation

.package(url: "https://github.com/gsdali/OCCTSwiftTools.git", from: "0.5.0"),