Proposal: metric-mm measurement system (millimetre labels) #509

Activity

1. Aymericr commented on Jul 19, 2026

   

   Aymericr

   on Jul 19, 2026

   Contributor

   More actions

   Millimetre labels are a valid direction, but the current implementation boundary is broader than formatMeasurement: the persisted useViewer.unit value also drives numeric editor inputs, floor-plan export/calibration, area and volume formatting, and the public registry GeometryContext.unit contract. Adding a third union member without an explicit semantic decision would leave some controls in metres while their in-world pills switch to millimetres.

   For a production-ready change, please define one choice first:

   1. Label-only format: keep metric editor inputs and m²/m³ unchanged, add a separate linear-label format used by measurement pills/guides/exports. This is the narrower and safer first PR.
   2. Full metric-mm unit system: convert every linear input/control to millimetres too, while explicitly defining area/volume behavior and migrating the persisted preference.

   I recommend option 1 for the first slice. Acceptance should cover 0.2 m → 200 mm, 18.4 m → 18400 mm, negative values, the 0.5 mm rounding boundary, preference persistence, and the 2D/3D measurement label paths. Keeping the issue open for that scoped implementation.
2. Aymericr commented on Aug 4, 2026

   

   Aymericr

   on Aug 4, 2026

   Contributor

   More actions

   Progress update. #540 implements the label half of this and I have rebased and extended it — it now threads millimetre notation through every 3D/2D live readout: wall and fence draft labels, wall measurement annotations, site edge labels, elevation guides, terrain brush, placement boxes, zone quantities, and the ceiling panel. The most visible gap in the first pass was the wall length label itself.

   One design note that came out of the implementation, since it affects how you would embed this: the notation is a separate store field (useViewer.metricNotation), not a third value on unit. That was deliberate. unit is load-bearing beyond labels — it drives numeric editor inputs, floorplan export and calibration, area/volume formatting, and the public GeometryContext.unit contract that registry plugins read. Adding a metric-mm member to unit would force every one of those consumers to handle a third case or silently fall through to a wrong branch. Keeping notation orthogonal means unit === 'metric' stays true for mm users and only the formatter changes behavior.

   For embedders: the 2D floorplan path already respects an override via GeometryContext.extensions[FLOORPLAN_CONTEXT_EXTENSION_KEY].metricNotation, so you can drive mm rendering without waiting on the settings surface.

   Still open after #540 merges:

   • Numeric inputs — typing a value into an inspector control. This is the same underlying gap as unit toggle only affects the display of dimensions, not the input #308, which is about imperial rather than mm but is the identical display-vs-input split.
   • Area and volume formatters — mm² and mm³ are rarely what anyone wants; m² is conventional even on mm-dimensioned drawings. Worth confirming against Korean practice before implementing, and I would rather leave these in m² than guess.
   • Panel controls — the audit in Track imperial unit support for remaining measurement panels #374 covers the same panels for imperial. Whatever pattern lands there should carry mm rather than growing a second mechanism.

   Cross-linking the measurement cluster so these do not diverge: #374 (panel audit), #308 (display vs input).
3. Aymericr

   added

   enhancementNew feature or requestNew feature or request

   on Aug 4, 2026
4. Aymericr

   closed this as completedin #540on Aug 4, 2026
5. pascalorg

   deleted a comment from on Aug 4, 2026