3D field viewer: annotations, cut plane, picking, time plots, stats (#1859 items B–E)

[jcschaff]

Implements items B and C of #1859: the two annotation actors and the orthogonal cut plane. Stacked on #1860 (base = feat/field-viewer-labels); when that merges, GitHub retargets this to master. All changes are in webapp-viewer/ — no Java.

Color bar (vtkScalarBarActor)

Slim strip on the right edge, titled with the variable name, with a checkbox to hide it.

The load-bearing detail: the scalar bar labels the lookup table's range, which mapper.setScalarRange never reaches — with the mapper's implicit LUT the bar would read [0,1] under a correctly colored surface. The viewer now owns one vtkLookupTable shared by mapper and bar (useLookupTableScalarRangeOn), re-ranged and rebuilt on every field change, so the two cannot disagree. Hue range flipped to blue-low → red-high to match the desktop results viewer (VTK's default rainbow runs the other way).

Axes box with ticks (vtkCubeAxesActor)

Bounds from the raw grid (the smoothed surface shrinks slightly), camera-attached so tick labels track rotation — the thing an HTML overlay could not fake, per the issue discussion. Checkbox to hide, default on.

Both actors enter the scene via renderer.addViewProp — the standalone session's invoker refuses addActor2D (probed earlier, recorded in webapp-viewer/README.md; this PR adds the LUT-range gotcha to those notes).

Verification (live, headless harness against a mock field server)

• Monotonic ramp field: surface sweeps blue (x-min) → red (x-max) and the bar's direction and labels match the served range — proof mapper and bar share the LUT.
• Time scrubbing: bar re-labels (0.251–0.997 at t=1 → 5.75e-5–0.969 at t=0) and the t=0 all-blue boundary is physically correct for the mock's interior gaussian.
• Toggles: each checkbox hides its actor and re-renders cleanly (visibilityOn/Off).
• Console watched for the invoker's silent is not permitted refusals throughout — none.

annotated scene	ramp verification

On merge, tick items (2), (3) and (4) in #1859.

🤖 Generated with Claude Code

https://claude.ai/code/session_01FYqrC3BiB4JRsJoz7BXJF4

---

Orthogonal cut plane — a CROP, not a floating slice (vtkPlane + vtkCutter + mapper clipping) — item C

Axis dropdown (Off/X/Y/Z) + position slider with a coordinate readout. Axis-aligned only, per the issue's guidance — an interactive plane widget needs interactor infrastructure the standalone session does not have.

• The volume is genuinely cropped: the surface mapper carries a GPU clipping plane that discards the half above the cut, and the cutter's cross-section caps the exposed face. The surface stays opaque — the first iteration's 25%-opacity ghost shell (review feedback: "the cropped portion isn't really cropped") is gone.
• mapper.addClippingPlane works in this wasm build even though WebGL2 has no gl_ClipDistance — VTK emulates clipping in-shader. It is also a quiet API (accepted with nothing logged either way), so it was verified by same-camera on/off renders orbited toward the removed side.
• The cap is cut from the raw grid — the cutter passes cell data through, so each cut polygon carries its source voxel's exact value, colored through the same shared lookup table as the surface and the bar.
• Live re-cut while dragging, with the same in-flight guard as orbiting; a domain switch re-feeds the cutter and remaps the slider onto the new bounds. The slider insets slightly from the axis ends, where a plane on the outermost faces cuts a degenerate sliver; cuts landing exactly on interior voxel faces render fine.

face-on Z crop (cap where the front half was)	X crop, orbited toward the cut	same camera, crop off

Cap rim follows the smoothing slider (review feedback)

The order is smooth-then-cut: the cut face stays flat and sharp (the cap is planar by construction), while its in-plane outline is trimmed to the smoothed silhouette via vtkClipPolyData + vtkImplicitPolyDataDistance built from the sinc output. At slider 0 the rim is the raw staircase — consistent with the raw shell — and it smooths with the slider like every other view. Clip-the-grid-then-smooth would have rounded the cut edge off, and is unavailable anyway: vtkClipDataSet and both siblings have no registered constructor in this bundle (probed; recorded in the README along with probe.html, the scratch probe page).

smoothing 0 — staircase rim	nominal — trimmed	heavy (48 iters) — elliptical rim

---

Value under the mouse + time-series at a picked point — item D (#1859 items 6 and 8)

(6) Hover readout — plain JS, no VTK picker, as the issue recommends: the browser holds the whole grid and field, so the pick is an occupancy map (built once per geometry) plus an Amanatides–Woo 3D-DDA walk along the mouse ray — a few dozen lattice steps per hover regardless of cell count, no round trip, no serialization-registry dependence. The walk applies the renderer's crop keep-rule, so hovering the exposed cut face reads the cap voxel, not the invisible removed half. Blanked (NaN) cells read "no data".

(8) Click → time course via a new /timeseries endpoint. The reduction happens server-side next to the reader, per the issue's explicit design point: the endpoint maps the viewer's cell index to the solver's global volume index through the served grid and goes through the same VCDataManager.getTimeSeriesValues path the desktop's own time plots use — one code path for local and remote runs, data travels once, already reduced. Client renders a framework-free inline-SVG polyline with min/max + time-range labels. A press that moves < 4 px is a pick; more is an orbit.

Verified in the mock harness: hover center reads the front-most voxel with correct value/coords, background hover clears, click produces the 5-point curve, and with the Z-crop active the same mouse position resolves to the cap voxel (9.5, 8.5, 8.5) instead of the removed half. The Java endpoint compiles; it exercises the same time-series path as the desktop plots (not exercised live in the harness, which mocks the server).

On merge, tick items (2), (3), (4), (6) and (8) in #1859.

---

Spatial min/mean/max over time — item E (#1859 item 9)

The strongest server-side-reduction case in the issue: computing these client-side would pull every timestep of every variable. New /stats?sim&job[&var=a,b,c] endpoint (default: all volume variables) runs one space-stats TimeSeriesJobSpec carrying all the variables — each reduced over its own domain's cells, since one run's variables can live on different geometry — through the same getTimeSeriesValues path as /timeseries. Weighted mean when the reader provides it, unweighted otherwise (identical on a uniform Cartesian grid).

Client: a Stats button renders every variable (capped at the palette size) into the shared plot panel — solid mean curve + translucent min-to-max envelope per variable on one common scale, with a color-swatch legend. Verified in the harness: the diffusing variable's mean rises as its envelope widens while the time-constant test field draws a flat mean with a constant band — physically correct on sight.

Bundle bumped to vcell-vtk-wasm v1.1.0

virtualcell/vcell-vtk-wasm#1 (merged, built, released) marshals vtkClipDataSet / vtkTableBasedClipDataSet; the fetch script now pins v1.1.0. Probed against the released bundle: both clip filters construct (+setClipFunction +insideOutOn), no invoker refusals, and the full viewer pipeline renders unchanged. probe.html now covers them for future bumps.

On merge, tick items (2), (3), (4), (6), (8) and (9) in #1859 — leaving only (5) movie export and (7)/(1), which are already in #1860.