fix(assembly): classify datum planes from all class hierarchies in Distance joints #318

forbes · 2026-02-23T00:55:58Z

forbes commented

2026-02-23 00:55:58 +00:00

Problem

The datum plane detection in getDistanceType() only checked isDerivedFrom<App::Plane>(), which catches origin planes (XY/XZ/YZ) and Part::DatumPlane. This missed two other class hierarchies:

PartDesign::Plane — inherits Part::Datum → Part::Feature, NOT App::Plane
Part::Plane primitive — inherits Part::Primitive → Part::Feature, referenced bare (no Face element)

Both produce empty element types (sub-name ends with .) but failed the type check, falling through to DistanceType::Other → Planar fallback. This produced incorrect constraint geometry, causing conflicting constraints and solver failures.

Symptoms

Joints referencing PartDesign::Plane datums logged: unhandled DistanceType Other, falling back to Planar
Solver diagnostics: Constraint N is conflicting (redundant and unsatisfied)
Newton-Raphson + BFGS both failed

Solution

Add shape-based isDatumPlane(), isDatumLine(), isDatumPoint() helper functions that cover all three class hierarchies by inspecting the actual OCCT geometry:

App::Plane / App::Line / App::Point — fast isDerivedFrom check
Part::Datum subclasses — check shape has a planar face / linear edge / vertex
Part::Feature fallback — single planar face = datum plane (catches Part::Plane primitive bare refs)

Extends getDistanceType() to use these helpers for all datum-vs-datum and datum-vs-element combinations (planes, lines, points).

Tests

Adds TestDatumClassification.py with tests for:

PartDesign::Plane + box Face → PlanePlane
PartDesign::Plane + box Vertex → PointPlane
PartDesign::Plane + PartDesign::Plane → PlanePlane
Part::Plane bare ref + box Face → PlanePlane
Part::Plane with Face1 element (normal path)
Origin App::Plane + PartDesign::Plane cross-hierarchy

## Problem The datum plane detection in `getDistanceType()` only checked `isDerivedFrom<App::Plane>()`, which catches origin planes (XY/XZ/YZ) and `Part::DatumPlane`. This missed two other class hierarchies: - **`PartDesign::Plane`** — inherits `Part::Datum → Part::Feature`, NOT `App::Plane` - **`Part::Plane` primitive** — inherits `Part::Primitive → Part::Feature`, referenced bare (no Face element) Both produce empty element types (sub-name ends with `.`) but failed the type check, falling through to `DistanceType::Other` → Planar fallback. This produced incorrect constraint geometry, causing conflicting constraints and solver failures. ### Symptoms - Joints referencing `PartDesign::Plane` datums logged: `unhandled DistanceType Other, falling back to Planar` - Solver diagnostics: `Constraint N is conflicting (redundant and unsatisfied)` - Newton-Raphson + BFGS both failed ## Solution Add shape-based `isDatumPlane()`, `isDatumLine()`, `isDatumPoint()` helper functions that cover **all three class hierarchies** by inspecting the actual OCCT geometry: 1. `App::Plane` / `App::Line` / `App::Point` — fast `isDerivedFrom` check 2. `Part::Datum` subclasses — check shape has a planar face / linear edge / vertex 3. `Part::Feature` fallback — single planar face = datum plane (catches `Part::Plane` primitive bare refs) Extends `getDistanceType()` to use these helpers for all datum-vs-datum and datum-vs-element combinations (planes, lines, points). ## Tests Adds `TestDatumClassification.py` with tests for: - `PartDesign::Plane` + box Face → PlanePlane - `PartDesign::Plane` + box Vertex → PointPlane - `PartDesign::Plane` + `PartDesign::Plane` → PlanePlane - `Part::Plane` bare ref + box Face → PlanePlane - `Part::Plane` with Face1 element (normal path) - Origin `App::Plane` + `PartDesign::Plane` cross-hierarchy

forbes added 1 commit 2026-02-23 00:55:59 +00:00

fix(assembly): classify datum planes from all class hierarchies in Distance joints

Build and Test / build (pull_request) Successful in 30m13s

Details

962b521f5c

The datum plane detection in getDistanceType() only checked for
App::Plane (origin planes). This missed two other class hierarchies:

  - PartDesign::Plane (inherits Part::Datum, NOT App::Plane)
  - Part::Plane primitive referenced bare (no Face element)

Both produce empty element types (sub-name ends with ".") but failed
the isDerivedFrom<App::Plane>() check, falling through to
DistanceType::Other and the Planar fallback. This caused incorrect
constraint geometry, leading to conflicting/unsatisfiable constraints
and solver failures.

Add shape-based isDatumPlane/Line/Point helpers that cover all three
hierarchies by inspecting the actual OCCT geometry rather than relying
on class identity alone. Extend getDistanceType() to use these helpers
for all datum-vs-datum and datum-vs-element combinations.

Adds TestDatumClassification.py with tests for PartDesign::Plane,
Part::Plane (bare ref), and cross-hierarchy datum combinations.

forbes merged commit a6a5db11f8 into main

2026-02-23 00:56:22 +00:00

forbes deleted branch fix/datum-plane-classification-all-hierarchies

2026-02-23 00:56:22 +00:00

forbes referenced this issue from a commit

2026-02-23 00:56:23 +00:00

Merge pull request 'fix(assembly): classify datum planes from all class hierarchies in Distance joints' (#318) from fix/datum-plane-classification-all-hierarchies into main

forbes referenced this pull request

2026-02-23 03:07:12 +00:00

fix(assembly): handle non-standard datum element types in Distance joint classification #319

Sign in to join this conversation.