Hakan SevenandClaude Opus 4.8 1f89b78a7e fix(precision): keep typed hatch boundaries exact in f64 (#311) ...

The HATCH/GRADIENT/BOUNDARY commands built the persisted hatch through
the render-side boundary (f32 offsets from world_origin), and with a
zero world_origin that meant absolute f32 - so a typed boundary vertex
of 2000.8 was stored as 2000.8020, and at UTM scale the fill landed far
from its boundary.

HatchModel.boundary stays f32 (the GPU render contract). Added
HatchModel.boundary_wcs: Option<Arc<Vec<[f64;2]>>>, an exact absolute-WCS
boundary set only by the draw commands. Scene::add_hatch persists from
boundary_wcs when present (exact f64 -> DxfHatch), else falls back to the
f32 + world_origin reconstruction used by DXF-rebuilt hatches. manual_pts
is now Vec<DVec3>; make_hatch takes the f64 boundary, stores the exact
copy and derives the RTE render rep. The committed render model is
rebuilt from the DXF entity, so nothing renders the command model's f32
boundary. This also fixes command hatches mis-placing at large
coordinates (world_origin was [0,0]).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-07-11 21:55:10 +03:00

..

block_hatch_export.rs

fix(precision): keep typed hatch boundaries exact in f64 (#311)

2026-07-11 21:55:10 +03:00

dim_copy_check.rs

fix(copy): duplicate a dimension's baked block so COPY copies it (#161)

2026-06-25 22:30:45 +03:00

text_font_rendering.rs

fix(text): keep inline \C colours through block colour inheritance (SDF)

2026-07-07 22:17:27 +03:00

zoom_extents_xline.rs

fix(view): exclude XLine/Ray display segments from ZOOM Extents (#284)

2026-07-05 14:08:43 -07:00