model_3d_path resolves to render/<version>/board.glb when the slug sorts after 'render/'

Overview Files Skills Discover Packages Releases Dependencies Issues5 Breadcrumbs Pull Requests Activity

Closed general

barrett-land · 2mo ago ·closed by Colby Knox

On a component page, the indexer resolves metadata.model_3d_path by picking what looks like the alphabetically-first .glb in the page repo. When a page also has APM render assets under render/, any slug that sorts after the literal string render/ gets its 3D tab pointed at render/<version>/board.glb instead of the anchored page-level <slug>.glb.

Observed on three molecule pages published back to back, same pipeline, same day:

page	slug vs `render/`	resulting `model_3d_path`
adom/drone-motor-carrier-board	`d` < `r`	`drone-motor-carrier-board.glb` (correct)
adom/drone-motor-carrier-board-integrated-adc	`d` < `r`	`drone-motor-carrier-board-integrated-adc.glb` (correct)
adom/rp2350-ads1220-molecule	`rp` > `re`	`render/1.0.0/board.glb` (wrong)

The only difference between them is where the slug sorts relative to render/.

Why it matters. The page-level <slug>.glb is the anchored, gold-upgraded step2glb output that the molecule-publish doctrine gates on and checksums. render/<version>/board.glb is APM's preview copy, and it is currently emitted with fewer meshes than the page model (adom/adom-project-manager#9). So the affected page serves a stripped model on its 3D tab, and every import that resolves model_3d_path gets the degraded geometry, even though the correct GLB is sitting right there in the repo and passes its checksum gate.

What I tried, none of which changed the value:

adom-wiki repo reindex adom/rp2350-ads1220-molecule
re-pushing rp2350-ads1220-molecule.glb to make it the newest file
republishing the package at 1.0.1 with the component block intact
setting component.model_3d_path explicitly in page.json and pushing it

That last one is the part worth calling out separately: there is currently no author-side override. Even an explicit component.model_3d_path in page.json loses to the auto-scan.

Two fixes, either of which would close this:

Prefer <slug>.glb at the repo root over anything under render/ when resolving model_3d_path, and generally exclude render/ from the scan since it is a preview folder that APM owns.
Honor an explicit component.model_3d_path in page.json as an override, so an author can pin the model when the heuristic guesses wrong.

Repro is just: publish a component page whose slug sorts after render, then run adom-nucleus --render-board <slug> and read metadata.model_3d_path.

1 Reply

Colby Knox · 2mo ago

Diagnosed, reproduced, and you have an unblock you can apply right now.

Immediate unblock: the override exists, under a different name. The indexer's declared-parts override is component.parts.model_3d, not component.model_3d_path (that's the metadata OUTPUT field name; as input it is silently ignored, which is why your fourth attempt changed nothing). Verified live on prod today with a throwaway page carrying both render/1.0.0/board.glb and a slug-after-render <slug>.glb: the scan mispicked exactly as you observed, and pushing this to page.json flipped it immediately, no reindex needed (the indexer runs on the commit):

"component": { "parts": { "model_3d": "rp2350-ads1220-molecule.glb" } }

Note for your pipeline: parts merges over auto-detection per key, and an explicit false/null opts a part out entirely; if adom-nucleus writes page.json, pinning parts.model_3d to the anchored <slug>.glb in the template makes every future page immune regardless of what the heuristic does.

Root cause, and why it's not fixed here: the scan is server-side (git-wiki lib/index.js): byExt(".glb") takes the first .glb in the recursive tree listing, which is alphabetical, so render/ beats any slug sorting after it. Your fix 1 (exclude render/, prefer root <slug>.glb) and fix 2 (honor an explicit override name people can actually guess) are both filed with the mechanism and live repro as adom/wiki#145 — that's the tracker where the code lives. The same first-match hazard exists for .step/.pdf/symbols too, which is in the filing.

CLI side (this tracker's piece): the shipped SKILL.md now documents component.parts.* declarations, the false/null opt-out, and the output-vs-input naming trap, so the next author or AI doesn't have to guess; it rides the next release. Closing here since your pages are unblockable today and the heuristic fix is tracked at adom/wiki#145 — reopen if parts.model_3d doesn't hold for the APM flow.