Skip to main content

Module constraint_overlays

Module constraint_overlays 

Source
Expand description

Assembly-constraint VIEWPORT overlays (build-spec §8.4) — the CONSTRAINT twin of crate::feature_dimensions.

Pure builders: the kernel’s assembly_overlay_json rows (per-constraint world anchors / directions / status / measured value) + the assembly_state_json constraint list (for inputParams — expression detection + element refs) fold into ConstraintOverlay records, which bake into the SAME leader/arrow/arc triangle buffers the feature-dimension gizmo draws (via crate::feature_dimensions::leaders_buffers — nothing re-rolled, per the UI-consistency directive):

  • distance → a LINEAR dimension annotation — the silver rod + orange cone arrow + orange origin sphere, GRABBABLE (drag edits inputParams.distance, commit auto-solves). Plane-based pairings draw the TRUE dimension perpendicular to the BASE face (the perpendicular-foot construction on [build_distance_annotation], matching the kernel’s signed d = (P_other − P_base)·n̂_base convention); plane-less pairings keep the plain anchor-to-anchor leader.
  • angle → an ANGULAR annotation (the screen-constant arc + orange sweep-end handle + red dashed zero reference + green axis), GRABBABLE (drag edits inputParams.angle).
  • center → two plain leaders drawn BY ROLE from the row’s groups (the kernel mapper’s inferred [width pair, tab] element-index groups): the width span between its two faces, and a leader from that span’s midpoint (which lies on the mid-plane) to the tab’s anchor centroid; the label sits at the width midpoint. Pick order never shapes the drawing.
  • everything else (coincident / parallel / perpendicular / concentric / tangent / touch_align / fixed) → a plain anchor-to-anchor leader line + label anchor only — never a handle.

Dragging is DISABLED for a distance/angle whose param is a non-numeric EXPRESSION string (matches how feature dimensions treat expression-driven params); the engine consults ConstraintOverlay::draggable.

The interactive state machine (hit regions, drag preview, the assembly_update_constraint_json commit) lives in engine_state/assembly_overlay.rs; this module stays camera-free and pure so the geometry is unit-testable from canned JSON payloads.

Structs§

ConstraintOverlay
One constraint’s overlay record: identity + status for the label, the resolved world geometry, and (for the dimensional kinds) the annotation the shared leader renderer draws + the drag machinery grabs.

Enums§

ConstraintOverlayKind
Which overlay family a constraint renders as.

Functions§

build_constraint_overlays
Build the overlay records from the kernel payloads: overlay_rows is the parsed assembly_overlay_json array; state_constraints is the parsed assembly_state_json’s constraints array (may be Null — the builder then has no inputParams, so dimensional rows fall back to draggable-with-empty params). Rows without resolved anchors yield status-only records (no geometry, no label anchor); a fixed constraint’s single anchor yields a label anchor but no leader.
constraint_overlay_buffers
Bake the whole overlay set into flat world-space triangle (positions, colors) buffers (the tris shape the overlay group consumes): the dimensional annotations through leaders_buffers (identical arrow/arc styling), the non-dimensional rows as plain silver leaders (append_plain_leader). Rows without geometry contribute nothing.
status_color
The requirements-doc §5 status → color vocabulary as display-sRGB [r,g,b] (0..1, hex/255 like the leader palette — the overlay shader writes ~directly).