Confirmed and fixed locally — the 3D column is now a real orbitable Babylon scene. Build verified in headless Chrome under the readme's exact CSP: 328 meshes, orbit works, no console errors. One correction to the plan though, because the obvious version of this fix cannot work.
Your report is right, and slightly understates it
The PNG-with-pan is exactly as you describe. Worse: when a directory has a .glb but no -3d-iso*.png, cmd_embed emits nothing at all — <div class="ph">no 3D render in this directory</div> — while the model sits right there unused. The candidate list is PNG-only (-3d-iso-named.png, -3d-iso.png, -3d-iso-lg.png); .glb was never consulted.
Also: the pin→pad table now reads 20 pins for BQ7692003PWR, so your #3 is genuinely fixed in 2.6.1+ — the "0 pins" I hit first was my stale binary.
The correction: Draco cannot decode in the readme sandbox
Note: step2glb output GLBs are Draco-compressed — the viewer must decode Draco (Babylon does natively...)
Babylon does natively — but not there. The wiki serves /readme/... with connect-src 'none':
script-src 'unsafe-inline' https:; style-src 'unsafe-inline' https:;
img-src data: https:; ... connect-src 'none'
Babylon fetches its Draco decoder from a CDN at load time, and connect-src 'none' blocks that fetch. This matters for your page specifically: adom-lbr embed's output IS readme.html on adom/stm32f103c8t6 (349 KB, one inlined data:image/png, zero .glb), so the readme sandbox is the deployment target, not an edge case.
Measured in headless Chrome under that exact CSP, loading bq7692003pwr.glb (which is extensionsRequired: ["KHR_draco_mesh_compression"], so it's a hard fail, not a degraded render):
[console.error] Connecting to 'https://cdn.babylonjs.com/v9.5.0/draco_decoder_gltf.wasm'
violates the following Content Security Policy directive: "connect-src 'none'".
THREW: Unable to load from file:m.glb: /meshes/0/primitives/0: Error status: 0
- Unable to load https://cdn.babylonjs.com/v9.5.0/draco_decoder_gltf.wasm
Same page, same model, de-Draco'd first: LOADED meshes=328 withVerts=327, clean. There's no way around it downstream — connect-src 'none' blocks fetching the decoder from the wiki too, data: URIs aren't in connect-src either, and bundling the WASM fails because the CSP has no wasm-unsafe-eval. John hit the same wall from the viewer side (adom/wiki#180).
So the viewer can't decode Draco. The GLB has to arrive decoder-free.
What it does now
embed prefers a real .glb over any render, and transcodes Draco→KHR_mesh_quantization at build time (node + gltf-transform, fetched once into ~/.cache/adom-lbr/gltf). The transcode is a bonus, not a cost — quantized is smaller than Draco on these models:
| model |
Draco |
quantized |
delta |
| bq7692003pwr |
225,080 B |
139,400 B |
−38% |
| stm32f103c8t6 |
516,264 B |
307,676 B |
−40% |
Then the model rides inline as base64 and is decoded to a File in-page, so nothing is ever fetched and connect-src 'none' never applies. The Babylon bundle loads from the wiki's own /static/vendor/adom-3d-viewer-babylon9/... as a <script> import — that's script-src https:, not connect-src, which is why it's allowed (same trick John's BQ readme uses).
Details worth knowing:
- Symbol/footprint keep pan/zoom; only 3D opts out. The 3D column gets an ArcRotate camera framed on the model's world bbox, and the pan/zoom loop skips it — panning a projection was the bug, so it shouldn't survive the fix.
- Z-up. These GLBs come out of STEP Z-up while glTF is Y-up, so the scene root gets a −90° X correction, matching what the wiki's own component viewer assumes. Verified visually: the TSSOP-20 sits flat with the leads on the sides, not standing on end.
- Fallbacks are honest. No
.glb → the old static render, unchanged, and the 13 MB bundle is never loaded. Offline → poster stays up with "3D needs a connection; showing the static render", and the pin table still renders. Draco present but node unavailable → static render plus a printed reason, rather than shipping a 3D column that can't load.
--instance false matters if anyone reaches for gltf-transform's optimize: its default enables EXT_mesh_gpu_instancing, which the babylon9 bundle renders as one giant mis-scaled instance (adom/wiki#180).
Upstream
Filed adom/adom-step2glb#3: Draco shouldn't be applied to these at all — it's ~40% bigger and it's what breaks the sandbox. If the service emits quantized GLBs, adom-lbr's transcode step can eventually be deleted and existing pages just need a regenerate. The transcode is a bridge for the Draco GLBs already on the wiki (including yours).
Not published yet — sitting at 2.6.3, and Barrett is checking with John before cutting 2.6.4, since he owns the merge. Once it lands, re-running adom-lbr embed --dir on the STM32 dir and re-publishing readme.html should give you a live 3D column.