Module widgets 

In-scene overlay widgets: the engine-side registry that hosts the brep-gizmos gizmos natively. It owns the widget STATE (fed as plain JSON over the R3 boundary — datum planes/axes/frames, curve display, feature dimensions, the transform gizmo, the always-on ViewCube), constructs a GizmoCamera from the engine’s live ViewCamera each frame, and emits the brep-gizmos Overlay geometry the render core converts into overlay GPU buffers. It also answers pointer hit-tests (ViewCube snap target, datum pick, transform-gizmo hover/pick) and computes transform drag deltas.

No renderer, no GPU: pure geometry + hit-testing, exactly like the gizmo crate. The host UI keeps the drag→feature-commit logic and the dimension text labels; the engine supplies the geometry and the frame-space deltas / label anchors.

Overlay-feed API surface (the contract the Rust UI programs against)

Five feeds set overlay geometry. Each is wasm Engine.* → EngineState.* → the WidgetRegistry method named below. Four are SPECIALIZED (they carry structured state their own pick/anchor/interaction reads); one is GENERAL (arbitrary geometry, no interaction). The general channel is the ONE uniform feed; the specialized feeds stay specialized (see “Why not one feed”).

Feed (wasm)	Registry setter	Geometry it carries	Screen-constant?	Specialized query / interaction
set_datums	set_datums_json	datum planes (world- or screen-sized), axes, frames, curves	frames + screen-sized planes: yes	datum_pick → hit plane/axis name
set_dimensions	set_dimensions_json	linear / angular / radial dimension leaders + arrows	yes	dimension_anchors → (id, world label anchor) (the host projects to place text)
set_overlay	set_overlay_json	GENERAL named groups of raw tris / lines / points	no (points billboard)	none — pure display geometry
set_transform_gizmo	set_transform_json	the move+rotate gizmo at a feature frame	yes	transform_hover / transform_pick / transform_drag / transform_drag_end
set_viewcube_enabled	set_viewcube_enabled	the always-on ViewCube (own mini-camera + corner rect)	yes	viewcube_rect / viewcube_hover / viewcube_clear_hover / viewcube_click

Draw path

build_main_overlay merges datums + dimensions + transform + the general set_overlay groups into ONE full-viewport Overlay drawn in the render core’s depth-cleared overlay pass, in a fixed order: planes, axes, frames, curves, dimensions, transform gizmo, then the general groups sorted by their renderOrder. The ViewCube alone draws in its own pass (build_viewcube), with a mini-camera in a scissored corner rect.

Why not one uniform feed (rewrite-time note)

The general set_overlay groups pre-expand their tris/lines into GPU-ready vertices AT FEED TIME (only point billboards are rebuilt per frame). The specialized widgets can’t: dimension leaders, datum_frames, screen-sized datum_planes, the transform gizmo, and the ViewCube are all SCREEN-CONSTANT — sized from world_per_pixel against the LIVE camera every frame — so they must be rebuilt in build_main_overlay, not stored pre-expanded. They also carry structured state their interaction needs (datum names for datum_pick, dimension ids+types for dimension_anchors, the feature frame for transform_drag, region handles for the ViewCube). Routing any of them through the flat set_overlay group buffers would drop either the zoom-invariant sizing or that interaction, so it is NOT done here. The one genuinely static subset (world-sized planes, axes, curves) is left on set_datums rather than fragmenting a single feed across two paths. Any deeper unification is deferred to the engine-native UI rewrite.

Structs

ViewCubeFrame

The ViewCube render frame: its overlay drawn with a mini-camera in a scissored corner sub-rect.

WidgetOverlay

A whole frame’s worth of overlay-widget geometry, ready for the render core’s overlay pass: the main overlay (datums / dimensions / curves / transform gizmo, full-viewport) + the optional ViewCube (own mini-camera + corner rect).

WidgetRegistry

The engine-side widget registry (one per engine).

Functions

gizmo_camera

Build the gizmo camera the widgets consume from the engine’s live camera. The view_proj is byte-identical to the render core’s Camera::view_proj (both from ViewCamera::resolve), so widgets project to exactly the view the engine renders solids with. viewport is CSS pixels (what the gizmo screen-constant sizing keys off).