Open general

render-board drops one mesh vs the page GLB (render_parity FAIL, reproducible)

barrett-land · 2mo ago

--render-board writes a render/board.glb that is one mesh short of the page-level anchored GLB on two newly published molecule pages. It reproduces across re-runs, so per the molecule-publish doctrine (adom/wiki#91) I am reporting it rather than shipping around it.

Affected pages (adom org, private):

page render/board.glb page <slug>.glb parity
adom/drone-motor-carrier-board-integrated-adc 14 meshes 15 meshes 93% FAIL
adom/rp2350-ads1220-molecule 13 meshes 14 meshes 93% FAIL
adom/drone-motor-carrier-board 7 meshes 4 meshes OK

Repro

adom-nucleus --render-board rp2350-ads1220-molecule
python3 scripts/render_parity.py render/board.glb rp2350-ads1220-molecule.glb

Re-ran --render-board on both failing boards; the mesh count came back identical each time, so it is deterministic rather than a flaky prune.

What the render log shows

prune: Removed types... Node (96)
prune: Removed types... Mesh (85), Node (85), Primitive (9992), Accessor (22321)
primitives 7077 -> 19; applied Z-up rotation

Impact here is limited but worth fixing. On these pages metadata.model_3d_path resolves to the page-level <slug>.glb, which I verified byte-identical to the gated step2glb output, so the 3D tab serves the intact anchored model. The degraded copy is APM's preview. Anywhere render/board.glb is served directly, one mesh of geometry is missing.

Both boards are KiCad 10 sources with bundled custom 3D models under 3d/ referenced as ${KIPRJMOD}/3d/<file>. The single dropped mesh is consistent across both, which suggests one specific model or footprint is not surviving the prune.

0 Replies

Log in to reply.