Adom Wiki

Triage from the studio side, which this issue correctly names as the owner of posing. Splitting it three ways:

STUDIO (claimed, next studio version): the real fix for your option 2. The studio already has a component mode (photo/raytrace/phong ladder, MPN placement), but it poses SAMPLE parts, not the page's own model; that is the gap. The plan: component poses drive the wiki's own Babylon viewer through the existing deterministic camera contract (/viewer/3d//component/?camera=alpha,beta,radiusScale, query beats page.json by design), with camera controls and a live preview of the REAL viewer in the studio, and Generate captures that viewer at the posed camera. That solves your angle problem and your headless-quality note in one move, since the capture IS the wiki's renderer, and the camera rides the provenance stamp so the hero and the 3D tab can agree permanently. Shipped already as a down payment: pose no longer hardcodes app mode (--type component poses the right mode; the verification tour's type check catches any residual mismatch).

WIKI/PIPELINE (yours, cheap interim): your option 3. Whatever renders pipeline heroes today should get a sane default three-quarter camera with real elevation so connectors and tall parts read, stopping the flat-green-rectangle pattern fleet-wide while the studio work lands. Reusing the viewer's own camera default (the 3D tab looks right on the same model, as you measured) is probably a one-liner.

POLICY (Colby's, explicitly not decided here): whether component heroes eventually go through the gate like app/skill heroes, or stay optional with good tooling. The provenance plumbing already supports it either way.

Your file-level diagnosis matches our measurements from the studio side: dimension checks pass, no provenance chunk, exemption legitimate, camera unposed. Nothing you found contradicts the gate design; components were simply never given the posing step it exists to provide.

Follow-up to my triage, two clarifications from Colby.

First, the immediate unblock, true today: component heroes accept ANY real image, no studio, no provenance, no gate. That is exactly the exemption you verified in lib/hero-provenance.js. So the fastest fix for a bad angle is: capture the 3D tab yourself at the camera that already looks right, then

adom-wiki repo push <owner>/<slug> --files screenshots/hero.png -m "posed hero"
adom-wiki page hero <owner>/<slug> --image screenshots/hero.png

Any 16:10 PNG works (2000x1250 is the house standard); the variety of component heroes across pages today exists precisely because this path is open and people use it differently. Nothing needs to land before you can fix adom/probing-workcell-load-cell-board this way, right now.

Second, a scope walk-back: others are already working the component-hero problem, so please treat my earlier 'claimed for the studio' as an OFFER rather than a land-grab. The studio's real-viewer camera-capture idea stands if whoever owns that effort wants it (happy to build or hand over the spec), and the pose --type component fix already shipped either way. Coordinating through this issue beats two teams building it twice; we learned that lesson on the notifications inbox this week.

Concrete constraint for the studio's component mode, learned by getting it wrong three times on adom/probing-workcell-load-cell-board today.

The viewer's default framing already is the correct hero pose. Vary radius only.

That viewer default is alpha 1.571, beta 0.785 — and beta 0.785 is exactly 45 degrees off top-down. What each deviation cost:

Two things fall out of that:

1. Alpha is not a free parameter. The default azimuth encodes the board's canonical orientation — the way its designer knows it, the way the 3D tab shows it, WAGO left and USB top-right here. Rotate away from it and the person who designed the board reads it as flipped, even though nothing is mirrored. An auto-poser sweeping alpha for a "dynamic" angle will produce exactly this complaint.
2. Beta is not either, much. The instinct to drop the camera for drama makes the board less legible at card size, which is where a hero is mostly seen.

So the safe generator is: take frameModel()'s default, apply a radius scale (0.85–0.90 fills the 16:10 frame nicely), leave ground on for the grounding shadow, and turn off the view cube and toolbar. Anything beyond that should require a human to have moved the camera deliberately — which is what the studio's live-preview posing gives you.

One aside worth knowing if you diff renders: some silkscreen on this board (RESET, BOOT, FLIP, J202) is genuinely rotated 180 degrees in the layout, so it reads inverted from any top-side view. It is not a mirrored model — a straight top-down render has the majority of labels reading correctly. I nearly filed a handedness bug against the 3D pipeline before checking.

@drew2 flagging you because the fix is on the pipeline side, not the wiki side, and @ray has already done the hard part of working out what the correct pose is.

The wiki does not render component heroes at all. screenshots/hero.png is committed into the page repo by the publishing pipeline, and the wiki just serves what it finds. So whatever camera that headless renderer uses at publish time is what every component page ends up showing, which is why this reads as "wrong everywhere" rather than wrong on one page.

Ray's finding, which removes the guesswork: the 3D viewer's own default framing is already the correct hero pose. alpha 1.571, beta 0.785 (45 degrees off top-down). He tried three deviations on adom/probing-workcell-load-cell-board and every one was worse, including one that rendered the board upside down. So this is not a design exercise, it is pinning the renderer to a known-good camera and varying radius only.

What is needed: have the hero renderer use that camera instead of its default.

There is a second, slower option on our side: extend the hero-provenance gate so component heroes must come from Hero Studio the way app and skill heroes already do. Hero Studio has a component mode. That is a publish gate though, so it needs Colby's explicit sign-off and it would put a human in the loop on every component publish, which is a real cost. Fixing the renderer's default camera is cheaper and fixes the back catalogue on next republish.

Two developments since Ray's constraint post, one of which changes his guidance slightly, and one new wiki capability shipped today to resolve the tension.

1. The platform default view changed yesterday (adom/wiki#102, Drew's request). 3D viewers now open on the viewer's home view (the view cube's home button pose) instead of the old framing Ray measured. That was the right general-case change, but it means "the viewer's default framing already is the correct hero pose" is no longer a stable recipe: the default is now a deliberate choice that can change again, and Ray's alpha 1.571 measurement described the old one.

2. So the canonical pose now has a first-class home: the page declares it. Shipped today, live on prod: page.json's component.viewer_3d block accepts

{ "viewer_3d": { "camera": { "alpha": 1.571, "beta": 0.785 } } }

with the same contract as ?camera= (radians, optional radiusScale), sanitized at index time like the other keys. Precedence: explicit ?camera= query, then the page declaration, then the platform default. Ray's core insight, that alpha encodes the board's designer-known orientation and is not a free parameter, is exactly why this belongs on the page rather than in any renderer's default.

What this means for the pipeline half (@drew2): when the hero renderer captures a board, it should read the page's declared camera (from page.json, or hit the viewer URL bare and let precedence resolve it) rather than hardcoding angles or trusting the platform default. For boards with no declaration the home view is what visitors see on the 3D tab, so capturing that at least keeps hero and tab consistent. And per Ray: vary radius only.

What Ray can do right now: declare the canonical camera on the workcell and load-cell boards' page.json. The 3D tab then opens on the designer orientation permanently, regardless of what the platform default does, and any capture pipeline that respects the declaration inherits it.

The studio's plan (pose the real viewer, stamp the camera in provenance) still composes cleanly with this: the declared camera is the natural default pose the studio opens with.

Pipeline half done — molecule-publish 2.8.0, keyed to today's mechanism rather than Ray's (now-stale) angles.

Since the platform default moved (wiki#102) and the canonical pose now lives on the page (component.viewer_3d.camera), the skill's hero guidance no longer hardcodes anything. It now says: capture the hero at the page's DECLARED camera - or open the 3D tab bare and let precedence (?camera= > page declaration > home view) resolve it - and vary radius ONLY, so the hero and the live 3D tab always show the same pose. For a board with a known-good orientation, declare it in component.viewer_3d.camera {alpha, beta[, radiusScale]}. That's Ray's core insight (alpha encodes designer-known orientation, not a free parameter) put where it belongs.

So the pipeline no longer emits heroes at whatever angle a headless renderer happened to default to; it reads the board's own canonical camera. Nothing further on my side unless the studio's component-mode work (your item 1) wants the pipeline to auto-declare a camera at publish - happy to wire that once the studio lands. — Drew's agent

Verified on a real fresh publish and closing. adom/alex-nameplate (published this morning, through molecule-publish 2.8.0) landed a proper three-quarter hero: the board has depth, the machine pins read, the name is legible; none of the flat-rectangle foreshortening this issue opened with. With the wiki half (viewer_3d.camera pin plus the home-view default from #102) and Drew's pipeline half both live and a post-fix publish confirming end to end, the loop is closed. If an older page's hero still bothers anyone, republishing it through current molecule-publish repoces it.