Crate brep_gizmos 

In-scene gizmos and overlay widgets — the shared CONTRACT every gizmo builds against, plus the math it needs and a CPU rasterizer for headless demos.

Design: a gizmo is pure geometry + hit-testing. It consumes a GizmoCamera (the render engine’s view state, mirrored here with no wgpu/kernel dep) and emits an Overlay of colored line segments and triangles in WORLD space, which the render engine’s overlay pass draws over the shaded solids. Where a gizmo is interactive it also answers Gizmo::hit (which handle is under a screen point) and, for draggables, a drag lifecycle in its own frame.

The crate has no renderer or kernel dependency. The render engine converts Overlay geometry into its overlay vertex buffers.

Conventions (shared with the engine):

• Right-handed world space, +Z up (the app convention).
• Column-major 4x4 matrices, world → wgpu clip (z in 0..1) — byte-identical to brep-render’s Camera::view_proj.
• Screen: origin top-left, x right, y DOWN, in CSS pixels (device-pixel ratio handled by the caller when it forwards viewport size).
• Screen-constant gizmo sizing uses GizmoCamera::world_per_pixel.

Re-exports

pub use math::Ray;

pub use math::Vec3;

Modules

curve_display

Curve DISPLAY builders (R30): spline / helix editor visuals for the render engine’s overlay pass.

datum

Datum / plane / axis / coordinate-frame display builders — the engine overlay geometry that replaces the retired editorDisplay bodies for datum features (PlaneFeature, DatiumFeature) and the world-axis helper (axisHelpers).

dimension

Feature-dimension LEADER geometry (R29) for the render engine’s overlay pass.

hit_region

Screen-space pickable regions — the SINGLE source of truth a gizmo’s hit-test AND its debug outline both consume, so “what you see (the red outline) is exactly what you can click/drag.”

math

Minimal vector/ray math for gizmos (no external math dep — keeps the crate light and the compile fast).

raster

A tiny CPU rasterizer for headless gizmo demos: projects an Overlay’s triangles (z-buffered, flat-lit) and lines (screen-space width) through a GizmoCamera and writes a PNG. NOT the production render path — the engine draws overlays on the GPU — this exists only so a gizmo can be eyeballed in isolation during development.

transform

Stateless transform gizmo: three axis arrows, three planar translation handles, three rotation rings, and an optional free-move handle.

view_cube

ViewCube navigation gizmo — a small orientation cube that mirrors the main camera and, when a face / edge / corner is clicked, hands back the standard view the engine’s camera animation should snap to.

Structs

GizmoCamera

The engine camera state a gizmo needs, mirrored with no engine dependency. Construct from the engine’s live camera each frame at integration time.

LineVertex

One line-segment vertex in the overlay (world position + linear-space RGBA).

Overlay

Accumulated overlay geometry a gizmo emits for the engine’s overlay pass. lines are screen-constant-width segments (pairs); tris are shaded/flat triangles (triples). Both are WORLD space.

TriVertex

One triangle vertex in the overlay (world position, normal, linear RGBA).

Traits

Gizmo

The contract every gizmo implements.

Functions

mat_inverse

General 4x4 inverse (column-major), via cofactors. Adequate for camera matrices (well-conditioned); returns identity on a singular matrix.

mat_mul_point

m * [p.x, p.y, p.z, 1] → [x, y, z, w] (column-major m).

Type Aliases

HandleId

A gizmo handle id — an opaque token a gizmo returns from hit and the host interaction layer echoes back to start a drag. 0 conventionally means “the body / no specific handle”.