The honest part first, same as I put in the README: as a sculpting toy it loses to any realtime WebGL viewer. ComfyUI renders on Queue Prompt, not continuous drag, so even at ~0.15s a render you get discrete updates, not a smooth morph. The clay head was never the point.

The point is that GNM becomes a deterministic control signal. The head renders to depth and normal maps, those maps drive a depth ControlNet, and out comes a photoreal face at an exact pose, proportion and framing — control a random reference photo can't give you. A slider moves, the depth map changes, the generated face follows. Same identity vector, same skull, every time.

Two caveats I didn't bury: depth control nails pose and proportion, but subtle expressions transfer weakly through a 512px map, and depth alone doesn't lock identity across angles — you still want a reference adapter for that. That's the real ceiling of geometry-as-control, and it's why this is a control input, not a finished-face generator.

The actual work was the environment. GNM pulls in TensorFlow, which upgrades protobuf and breaks onnx / insightface / ReActor in a normal ComfyUI env. So the heavy stuff runs in an isolated venv with a warm render server over localhost, and rendering goes through nvdiffrast instead of GNM's TF/pyrender path. Your main ComfyUI never gets touched. That isolation is the whole trick.

There's also a client-side web app that sculpts a head and exports depth/normal maps entirely in the browser, on your own GPU — no Python, no backend. The GNM deformations are precomputed as a linear blend-shape model (6.6MB, verified 0.00% error against the real model), so the browser just does neutral + Σ slider×delta. The exported maps drop straight into the ComfyUI graphs above.

The whole guide collapses to one move: mint a single product master first — one file, the product from a few angles with its real label — then attach it to every image you generate afterward. The world changes, the product stays. That's what stops variation #47 from looking like a different brand than #1.

I also ran a fair tier bake-off — Pro vs 2 vs Lite, same prompt, same seed, master attached to all of them — instead of the usual test where each model invents its own label from scratch. Once there's a reference attached, all four hold the brand, and the difference collapses to render quality, speed and price. Nano Banana 2 came out the value pick: richest result at 2K for half of Pro's cost. And 'Lite' is misnamed — it's faster (~7s), but at $1/unit it isn't cheaper, so it's a sketchpad, not a volume play.

Everything in the guide was generated by a Claude skill that ships in the repo, so the images are reproducible rather than cherry-picked. The site runs beginner-to-advanced; the skill is the part I'd actually keep.

The ratchet is the whole idea: hold a best-so-far, keep a change only if it beats it, otherwise revert. Before this, that lived in the model's head — which means one context compaction wipes it and the agent quietly starts handing back regressions. Now the best graph and the decision ledger sit in a file. A revert is a tool call, not an act of recall.

Proof matters more than the claim, so there's a run in the repo where the ratchet caught the model lying about its own work. Pass 3 of a tiling texture read as "better" to the model; the objective seam score said otherwise, and it reverted to pass 2 on its own. An agent that wants to be finished will call a regression an improvement — the gate is what stops it.

The unglamorous half was correctness. Every one of the MCP tools now has a passing test — the ones that install nodes, the ones that look at the rendered image, the ratchet itself. Two bugs fell out of writing them: restart_comfyui was reporting success even when the restart failed, and the litegraph→API converter dropped connections that passed through Reroute nodes instead of resolving them. Both are the kind of thing that only shows up when you run the tool and read what it returns, not when you eyeball the code.

loop_report also landed: a finished run renders to one self-contained HTML page — every pass, what moved, what got kept or reverted — so the loop leaves a trail you can read after the fact.

The pipeline is four models in a trench coat. HunyuanWorld-1.0 does the true-360 extrapolation — one plate in, a 1920×960 equirectangular panorama out — running as a subprocess in its own venv (torch 2.5 / diffusers 0.34) so its FLUX-Fill dependency never collides with the rest of the stack. A ComfyUI pass then wrap-pads and upscales it 2× (4x-UltraSharp + TiledDiffusion, cropped back), and a second ComfyUI pass heals the wrap seam by rolling the pano 50%, inpainting the centre strip, and rolling it back. The result lands at 3840×1920. A BLIP caption of the plate steers the extrapolation when no prompt is given, so the invented half of the sphere stays on-theme instead of wandering off into a different scene.

The interesting part is the light, not the picture. A panorama is just pixels; an HDRI has to know what actually emits. Naive exposure lifts every bright region at once and the whole frame glows — white flowers, a pale wall, an overcast sky — so the scene ends up lit by a daisy. An emitter gate (DINO + SegFormer) classifies the scene first and only lets real sources — sky, sun, windows, practicals — cross 1.0. It treats interiors and exteriors differently, and it deliberately doesn't blow out an overcast sky into a fake sun.

The output is more than one file. The stage writes a scene-linear EXR, an LDR preview, and a six-face cube map with a PolyHaven-style cross — in both EXR and Radiance .hdr, so it drops into UE5 or GIMP as easily as Nuke or Houdini. An optional first step removes people: stills go through FLUX-Fill, moving clips through VOID clean-plate, so the light of the location stays but the crew doesn't.

The genuinely hard part was memory. FLUX-Fill wants ~34GB of RAM and won't share a GPU politely with a loaded ComfyUI, so the orchestration restarts ComfyUI lean right before the FLUX step and frees VRAM around it. A 128GB unified box eases that pressure, though the aarch64 model stack has to be built first. None of that is glamorous, and all of it is the gap between a pipeline that survives a real shot and a demo that only runs on the developer's machine.

The whole thing sits behind a modal in my VFX Tools front end — auto-caption the plate, adjust the prompt, submit — because an artist should get an IBL back, not a pipeline to operate.

The trick is one shared shape. Every tracker MCP emits the same normalized snapshot — project_summary — so an agent reads a project out of ShotGrid and recreates it in Kitsu without knowing either SDK. Five standalone servers, published and credited separately, all speaking one contract. A sixth tracker is just one more MCP that emits the same shape; everything downstream then works on it for free.

The hub is where that uniform contract pays off. It does five things no single tracker can: verify (diff two snapshots), audit (one source of truth against many mirrors), rollup (totals across every production), snapshot (a portable versioned archive), and migrate (an orchestrated read → write → verify that ends with proof). Most of it is pure — verify, audit, rollup and snapshot never touch a tracker SDK, they just operate on the normalized JSON. Only migrate does any writing.

The hub found real drift on its own the first time I aimed it at one project copied into all three original trackers. The ftrack copy came back short 8 tasks, carrying 615 status mismatches and 357 casting mismatches, plus name-collision assets ftrack had silently created. Every one of those is a documented cross-tracker incompatibility, surfaced by diffing snapshots instead of by hand. And an orchestrated migrate of a slice ended with VERIFY: PASS — every count matched.

Write safety was non-negotiable, since these point at real production databases. Every create, update, delete and status change takes a two-level dry run — a client-side plan, or a preflight that resolves references against live data, validates statuses against the schema, and returns a before→after diff while writing nothing. The whole thing is v0.1 and honest about its edges: the migrate reference copies structure, statuses and casting, and reports any media gap rather than pretending to move the heavy publish bytes.