Adom Step2GLB - STEP to GLB converter
Public Made by Adomby adom
Color-preserving STEP (.step/.stp) to GLB converter. Thin Rust CLI shelling to a shared OCCT XCAF service. Formerly 'step2glb'.
Draco on chip-sized GLBs is a net loss: ~40% BIGGER than quantized, and undecodable in the wiki readme sandbox
Summary
Every GLB the service emits is Draco-compressed (KHR_draco_mesh_compression in extensionsRequired). On chip-sized models this is a double loss:
- It makes the files bigger. Re-encoding the same geometry decoder-free with
KHR_mesh_quantizationis ~40% smaller than the Draco output. - It makes them unloadable in the wiki's readme sandbox — the one place our component pages actually show 3D. Because the extension is in
extensionsRequired, this is a hard failure, not a degraded render.
Measured today on two real parts:
| model | Draco (today) | quantized, decoder-free | delta |
|---|---|---|---|
bq7692003pwr.glb |
225,080 B | 139,400 B | −38% |
stm32f103c8t6.glb (adom/stm32f103c8t6) |
516,264 B | 307,676 B | −40% |
Both report generator: glTF-Transform v4.4.0, so the service is already running glTF-Transform — this is a flag change, not new tooling.
Why Draco can never work on a wiki page
The wiki serves /readme/... under this CSP (verified with curl -I):
script-src 'unsafe-inline' https:; ... connect-src 'none'
Babylon's Draco decoder is fetched from a CDN at load time. connect-src 'none' blocks that fetch, so the model never decodes. Measured in headless Chrome under that exact CSP, loading bq7692003pwr.glb:
[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
The identical page with the identical model, de-Draco'd, loads clean: LOADED meshes=328 withVerts=327. Nothing else changed.
This isn't fixable downstream. connect-src 'none' blocks every fetch, so the decoder can't be pulled from the wiki either, and inlining it as a data: URI doesn't help (data: is not in connect-src). Bundling the WASM is also out — the CSP has no wasm-unsafe-eval. The only fix is to not require a decoder. John reached the same conclusion independently from the viewer side (adom/wiki#180, "quantize+KHR_mesh_quantization works everywhere, decoder-free").
Ask
Emit decoder-free GLBs for these parts — KHR_mesh_quantization instead of Draco. Either as the default (recommended: it's smaller and portable, so there's no trade being made here) or behind a --compress quantize|draco|none flag on convert / from-library if some consumer depends on Draco today.
Draco earns its keep on large scanned/organic meshes. These are 3.4k-vertex chip bodies, where the container overhead and the decoder dependency cost more than the compression returns.
One gotcha if you route this through gltf-transform's optimize: its default turns on EXT_mesh_gpu_instancing, which the babylon9 bundle renders as one giant mis-scaled instance (also adom/wiki#180). Pass --instance false.
Context
Found while fixing adom/adom-lbr#4 (Ray: the adom-lbr embed 3D column is a static PNG). adom-lbr now transcodes Draco→quantized at embed time as a bridge, so it can render live 3D from the GLBs that already exist. That workaround costs a node + gltf-transform dependency in a lean Rust CLI, and every future consumer of these GLBs inherits the same problem. If the service stops requiring a decoder, the bridge can eventually come out and existing pages just need a regenerate.
Repro for the sizes above is gltf-transform-equivalent: drop KHR_draco_mesh_compression, apply quantize(), re-write binary.