Every line was drawn 1px regardless of its CAD lineweight. Two causes:
the dwg-wasm parseResult never carried the field (acadrust reads
EntityCommon::line_weight but it was dropped in serialization), and the
renderer merged all segments into one LineSegments whose
LineBasicMaterial.linewidth WebGL ignores.
Resolve ByLayer/ByBlock/Default per entity and bucket segments by
dash|lineweight. Weighted buckets get their own LineSegments2 +
LineMaterial with worldUnits:false, so width stays constant in pixels
while zooming - AutoCAD LWDISPLAY semantics - at 8 px/mm (0.25mm = 2px).
Anything at or below the 0.25mm default stays in the hairline batch so
drawings that never assigned a weight render exactly as before.
Fat batches are instanced, so layer masking compacts the instance buffer
and lowers instanceCount instead of rewriting an index; slotOf tracks
where each segment moved so the selection highlight still finds its
vertices. Per-entity color spans (meta.spans) let the highlight repaint
across the hairline batch and every bucket it touched. Buckets past
400k segments fall back to hairline to bound GPU/heap cost.
Display follows the drawing's LWDISPLAY and can be forced from the
toolbar; the property panel now shows the entity lineweight.
Verified headless at a fixed camera on the 65k-entity road drawing:
cyan road edge 2px -> 5px, layer hide/restore returns the exact baseline
pixel counts, and a 0.35mm LWPOLYLINE selects and highlights.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The road-surface drawing (대산당진 2공구_노면) rendered nothing for its
노면/부체도로면 geometry. The cause was not the renderer: the parseResult
contained zero MESH entities.
Two faults, both in the wasm parser, fixed upstream in hmwebviewer 35f5b1c:
1. dwg-wasm never serialized MESH. acadrust reads the entity in full; only the
JSON arm was missing.
2. acadrust's read_mesh clamped its array counts with the blanket 100_000-item
corrupt-data guard. This drawing's road mesh has 105_497 vertices, so the
count was truncated, the remaining vertex bits were never consumed, and the
face/edge/crease lists after them decoded from the wrong bit offset —
producing a plausible-looking vertex count next to a nonsense 14-face list.
Counts are now bounded by the bits actually left in the object stream.
before verts=100000 faces=14 face sizes [64, 0, 64, 23, 0, 0, 0, 15]
after verts=105497 faces=185444 face sizes [3, 3, 3, ...]
This commit carries the vendored side of that work:
- the rebuilt wasm, which now emits MESH as flat arrays (vertices [x,y,z,...],
faceList in DXF group-93 layout, deduplicated edges). The sample drawing goes
from 116 MB to 130 MB of parseResult with parse time unchanged at ~3.2 s.
- a MESH case in the property inspector (vertex/face/edge counts, subdivision
level, bbox and elevation range)
- docs/subdmesh-rendering.md, plus README pointers
- the acadrust licence notice, which can no longer say "consumed unmodified" —
read_mesh now carries a local patch. MPL-2.0 is file-level copyleft, so the
patched file stays under MPL and its source ships in hmwebviewer.
Verified: 9 MESH entities parsed from the drawing; entity histograms over six
other sample drawings are byte-identical to the previous wasm, so nothing else
moved.
Two deliberate omissions, both because a lineweight/fat-line refactor is in
flight in this working tree:
- Viewer2D.js is not included. Its _meshSegs helper and three MESH dispatch
sites share hunks with that refactor and cannot be separated; the same
renderer code is committed upstream in hmwebviewer 35f5b1c and will land here
with the refactor. docs/subdmesh-rendering.md records this.
- dist2/ is not rebuilt here. The current build embeds the half-wired
lineweight button and progress-bar markup; deploy per
docs/deploy-dist2-static-build.md once that work lands.
The wasm binary also carries the new lineweight parser fields (lwdisplay,
celweight, layer and entity lineWeight), since it was built from a tree that
already had them. They are additive JSON keys with no consumer in this commit.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This repository has no deploy script or CI: package.json only builds to
dist/ (gitignored), yet dist2/ is committed and is what actually gets
served. The procedure was folklore reconstructed from commit history each
time someone deployed.
Write it down, including the two traps found while deploying fb8f7ca:
- vite's emptyOutDir defaults to true when outDir sits inside the project
root, so a bare `vite build --outDir dist2` deletes the hand-placed test
assets in dist2/samples (configBak/, dwg_18.3mb.dwg). Always pass
--emptyOutDir false.
- npx vite can fail here with `Missing script: "vite"`; call
./node_modules/.bin/vite directly.
Also notes the open issues: no build:dist2 script, old hashed bundles
accumulating in dist2/assets, and test fixtures living inside the build
output directory.
Link it from the README issue table.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
