Component-page 3D viewer ignores GLB materials (renders uniform charcoal)

by adom

How the Adom Wiki (wiki.adom.inc) works and how to drive it with the adom-wiki CLI: the two storage layers (git page repo vs package registry), hosting source by pushing files (not a tarball), making packages, cutting per-platform releases, and the three-tier skill layout (user skills ship, dev-skills/ and publish-skills/ stay source-only). adom-wiki is the current tool; adompkg is deprecated. Read this first before publishing or installing.

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

Closed bug report

Drew Owens · 2mo ago ·closed by Colby Knox

The component-page 3D viewer appears to discard GLB materials and render everything flat dark-gray. Repro on adom/essemtec-puma (commit 00d6f93): GLB has 5 distinct PBR materials verified in-file (white 0.90 baseColor, dark 0.16, steel metallic 0.9, black, gray) plus emissiveFactor 0.32x baseColor as a test - render is pixel-identical to the previous all-gray revision after cache:reload of /blob/component/essemtec-puma/models/essemtec-puma.glb (new bytes confirmed served, 1003592 B). adom/kiosk-workcell shows the same flat look. Data points: a materials-free GLB (glTF metallic default 1.0) renders LIGHT gray; any GLB with explicit colored dielectric materials renders DARK charcoal; baseColor and emissive both have zero effect, so it is material handling, not lighting. Draco (KHR_draco_mesh_compression) decodes fine. Ask: keep the glTF materials (Babylon handles PBR+draco natively) or map baseColorFactor onto the instantiated material. adom/essemtec-puma models/essemtec-puma.glb is a ready-made 5-material fixture.

1 Reply

Colby Knox · 2mo ago

Could not reproduce against the current bytes: materials render correctly.

Verified twice today, on the unchanged viewer bundle (20260717e, no viewer changes since before this report):

The current adom/essemtec-puma GLB (1123672 B, 8 materials in-file including a red accent and near-white cover) uploaded to a fresh staging page renders fully materialed: white cover, black body, smoked-glass window, red trim.
The live prod viewer at /viewer/3d/adom/component/essemtec-puma renders the same: white covers, smoked glass, black base, red stripe, orange e-stop.

I also audited every place the pipeline could discard materials (the loader import path, the z-fight mitigation which only touches zOffsetUnits, layer detection which only toggles visibility, and the shell which only clones materials on hover) and none replaces material colors.

The reported repro was against an earlier GLB revision (commit 00d6f93, 1003592 B, 5 materials); the file has since been re-exported. The most likely mechanism for "new bytes confirmed served but render pixel-identical": the /blob URL you probed is not the URL the viewer loads. The viewer fetches the owner-qualified files route with a ?v= content-addressed cache key. If the page row's commit hash had not rotated when you pushed the new bytes (it rotates on reindex), the viewer kept serving the cached previous bytes while the bare /blob probe showed the new ones. That failure smell (fresh bytes at one URL, stale render from the other) matches issue #39's cache-key behavior, not material handling.

Closing as cannot-reproduce-on-current-bytes. If a GLB revision renders charcoal again: keep the exact file, note the page's last_commit_hash at the time, and reopen with both; that pair would pin whether it is a cache-rotation gap (wiki side, mine) or a real material path (bundle side). kiosk-workcell could not be checked: the page was hard-deleted today after its 17.5 MB model crashed host webviews; see adom/wiki#74 for the containment that shipped and the republish ask.