Skip to content

Releases: axiolid/kernel

v0.11.0 — Exact curve inversion and Cartesian trim resolution

Choose a tag to compare

@GeneralPawz GeneralPawz released this 05 Sep 16:19

Exact curve inversion, so a trim stated as a point resolves.

Added

  • axiolid_evaluate::curve::invert2 / invert3, re-exported as axiolid_reference::curve::{invert2, invert3}. The exact point-to-parameter map for lines, circles and ellipses. Curves already had evaluate, derivative and jet; inversion was the missing direction.

Fixed

  • CurveRelation::Trimmed with TrimmingPreference::Cartesian now resolves. Point selectors were validated and stored but never read, so every point-trimmed curve passed graph validation and then failed to compile with trimmed directrix start needs a finite parameter selector. Formats that can only state a trim as its endpoints -- a three-point arc knows its endpoints, not their parameters -- were representable but not usable.

Exactness policy

Families with no closed-form inversion are refused by name rather than iterated. Newton in trim resolution would put a tolerance and a convergence failure mode into every consumer of a point trim, and would collapse the three-valued verdict certified inversion produces (unique / ambiguous / off-surface) into a bare Scalar, discarding the evidence that makes it trustworthy. axiolid-nurbs stays out of the compile path; certified iteration remains available to callers that can carry its certificate.

A point off the curve is refused with its residual rather than projected onto the nearest parameter. The conic path needs this specifically: the arctangent yields a plausible angle at any radius, so only re-evaluating and measuring catches a point at the right bearing and the wrong distance.

A basis that is itself a curve relation has no analytic curve to invert against. A parameter selector still resolves there; a point selector is refused by a message that says why.

v0.10.0 — Frame contracts and surface-curve pairing

Choose a tag to compare

@GeneralPawz GeneralPawz released this 05 Sep 13:39

Frame contracts, and the surface-curve pairing that unblocks IFC surface curves.

Breaking

  • CurveRelation::SurfaceCurve replaces associated_geometry: Vec<NodeId> with sides: SurfaceSides, which pairs each p-curve with the surface it lies on. Construct with SurfaceSides::single(surface, pcurve) or SurfaceSides::two(s1, p1, s2, p2).
  • MasterRepresentation::ParameterCurve splits into ParameterCurveS1 and ParameterCurveS2.
  • ExpectedReference::CurveOrSurface is removed; it had no remaining constructor once each side is checked against its own node kind.

Added

  • PlaneFrame and SpaceFrame in axiolid-core: validated in-plane and 3D orthonormal frames with private fields, so an invalid basis is unrepresentable rather than merely rejected. Both own their mappings (project/lift, to_local/to_world).
  • bounded_half_space_in_frame in axiolid-construct, taking an explicitly authored in-plane boundary frame.

Fixed

  • axiolid-project decided plane orthonormality with the LINEAR tolerance. Orthonormality is a dot product of unit vectors and so is dimensionless; deciding it with a length tolerance made the same 0.5 mrad skewed basis valid in millimetres and invalid in metres, silently producing wrong coordinates for every projected point.
  • Surface evaluation accepted a LEFT-handed frame. invert checked unit length and perpendicularity but never handedness, and a mirrored basis satisfies both -- returning reflected parameters that round-trip through their own bad frame and look correct. It also validated against a hardcoded 1e-9 while already receiving a caller tolerance.
  • SolidOperation::BoundedHalfSpace.placement now orients the boundary profile rather than only the finished mesh, so a source format that places the boundary independently of the base surface round-trips.

Notes

Three call sites previously carried their own frame validity rules under three different tolerance policies, and only two of the three checked handedness. All now delegate to SpaceFrame; no hand-rolled orthonormality checks remain in production code.

Closes #90, #93, #94, #95.

v0.9.1 — Transverse crossing fix

Choose a tag to compare

@GeneralPawz GeneralPawz released this 05 Sep 09:22

Patch release for a correctness fix in axiolid-measure.

mesh_distance and proximity_components reported a nonzero separation for two meshes whose triangles genuinely interpenetrate, contradicting the documented contract that crossing surfaces report zero. The pairwise scan sampled vertex/triangle and edge/edge candidates only; a transverse crossing is realised where an edge passes through a face, so every family missed it.

Fail-open for clash detection: a real interpenetration was indistinguishable from a real gap. Coplanar overlap was already handled, which is why existing tests did not catch it.

Fixes #91.

v0.9.0 — Capability breadth through solid modelling

Choose a tag to compare

@GeneralPawz GeneralPawz released this 05 Sep 08:38

Five capability milestones (v0.5 through v0.9) closed after the 0.4.0 tag without a release being cut. This release closes that gap: the tag lagged the tree by 60 commits, so consumers pinning v0.4.0 could not reach planar offset, region algebra, projection, routing, or mesh/mesh proximity at all.

Milestones included

  • v0.5 Trustworthy discrete geometry
  • v0.6 Compiled geometry and plans
  • v0.7 Measurement and validity
  • v0.8 Mesh processing breadth
  • v0.9 Solid modelling breadth
  • partial v0.10 (mesh queries, decompose/compose)

Newly reachable for consumers

These shipped on main but were unreachable from the previous tag:

  • axiolid-overlay planar offset and stroke offset
  • axiolid-overlay persistent region with set ops and morphology
  • axiolid-project planar projection and vertical prism clipping
  • axiolid-route exact planar shortest path with typed unreachable reasons
  • axiolid-measure mesh/mesh distance and proximity components

The facade also now re-exports project and route behind additive features.

See the changelog for the full list.

v0.4.0 — Downstream integration

Choose a tag to compare

@GeneralPawz GeneralPawz released this 03 Sep 15:15

v0.4.0 — Downstream integration

This release establishes executable, verified downstream consumption paths for Axiolid: an external Rust or C/C++ application can now depend on an immutable released Axiolid without checking out this workspace, importing implementation-private crates, or reverse-engineering capability and refusal semantics.

Milestone: https://github.com/axiolid/kernel/milestone/8

Downstream integration surface (v0.4 scope)

  • Downstream integration profiles and a capability handshake (#50)
  • A supported Rust application facade and provider path (#51)
  • A versioned, memory-safe C ABI for native consumers (#52)
  • CMake integration and cross-platform native artifacts, Linux/macOS/Windows (#53)
  • Black-box downstream consumer probes and compatibility CI (#54)
  • A machine-checked, mutation-tested 2D-only dependency closure for narrow consumers such as ifc-geometry (#1)
  • Release automation: version bump and changelog rollover, wired into the standard gate (#10)
  • Executable downstream integration quickstart guides for narrow Rust crates, the Rust facade, plain C, and C++/CMake (#55)

Full details: see docs/CHANGELOG.md under ## [0.4.0], and the per-feature ADRs it links to.

Consuming this release

  • Rust: pin a git dependency to this tag or its commit, or to the corresponding axiolid-* versions once published to crates.io (publication itself remains a manually-dispatched, verify-then-execute workflow — see scripts/publish-workspace.py and docs/adr/0043-release-version-changelog-rollover-is-a-checked-reviewed-script.md).
  • C/C++: fetch the native release archive attached to this GitHub Release, or use the Axiolid::axiolid CMake integration to build from this immutable source tag.
  • Start here: docs/guide/downstream-integration.md.