NODESMITH PIPELINE

Seven diagrams tracing nodeSmith end to end — a written brief through a language model and SDXL, two paid calls out to GPT Images and Tripo, FrameBridge's frame correction, SkinTokens' auto-rig, SkinBridge's cleanup and FBX export, and a manual hand-off into Unreal Engine 5. This is a staged toolkit, not a shipped, automated pipeline — every diagram below shows where a human approves, and where the graph refuses rather than guessing.

7 DIAGRAMS 76 WORKFLOW NODES 146 DIAGRAM NODES / 61 WITH DETAIL 3 PAID STEPS 3 GATES THAT REFUSE

Every diagram on this page is drawn from one embedded data object — the same object drives the SVG layout below, the hover/tap detail popups, and the plain-text <details> list under each diagram. Nothing is typed twice.

Reading the color families — consistent across all seven diagrams:

solid — a real graph link dashed — not a socket connection (drives / writes / cross-reference) ● amber dot in a box's corner — hover, focus, or tap for more detail
Where the money goes. The pipeline spends at three points, all marked amber: the language-model payload call that turns the written brief into a schema-validated prompt (Node 69 — metered API tokens), the GPT Images call that produces the orthographic views, and the Tripo generation that turns them into a mesh. Everything else runs locally.

The approval gate guards two of those three. It sits between the hero render and GPT Images, so it stops you spending on the orthographic views and on the mesh. The payload call runs upstream of it and has already spent by the time you approve — a single text-model call, far smaller than an image or a mesh generation, but not free.

Where the refusals are. Rose boxes are the three controls that refuse: hero-shot approval, facing verification (Node 126), and the 90% coverage gate. Dark red boxes are the failures those controls exist to prevent — left/right silently swapped, and the skeleton landing inside the body. They are outcomes, not gates; no arrow leaves them. Grey dashed boxes are neither: an open question, or a measured caveat.

00 — The pipeline at a glance

One brief in, one rigged FBX out. Every box here is expanded in its own diagram below; this one exists to show the shape of the pipeline and, more usefully, where it costs money and where it can refuse you.

GateRefuses whenWhat it prevents
Approve the hero shotyou have not approvedspending on a concept you do not want
Facing verifiedthe rigged mesh faces wrongshipping a reversed rig — SkinTokens has already named _l/_r off the wrong facing
Coverage above 90%mesh and skeleton do not corresponda skeleton landing inside the body

"Amber is money. Two nodes only... Pink is the refusal path. Three controls refuse... The other two pink boxes — Left/right silently swapped and Skeleton lands inside the body — are outcomes, not controls, and have no arrow leaving them... The dotted lines are not data. The Cockpit drives stages rather than passing values through them, and the project tree is written to rather than being a step." — 00-overview.md

64 of the 76 nodes are muted at any moment, and that is the design working. The pipeline arms one stage at a time; a saved workflow shows the stage last worked on, not the whole thing live. Nothing here is disused — it is waiting to be armed. See the control plane, below.

01 — From a written brief to an approved hero concept

Ten settings nodes assemble a brief, an optional language-model call turns it into a structured payload, SDXL renders the concept locally, and a snapshot tree holds every iteration until one is approved and the "GPT Orthos" gate is armed to spend on the next stage.

"The IPAdapter node's wiring is exactly what the ground truth shows, not simplified for the diagram. Node 8 loads a MODEL from the checkpoint but has no outputs read by anything else in the saved graph — KSampler takes its model input directly from the checkpoint, not through Node 8... drawn as a dead end deliberately." — 01-concept.md

02 — Two routes to four approved orthographic views

The approved hero render becomes four orthographic views one of two ways — one paid GPT call producing a single sheet that gets measured and split, or four independent paid GPT calls, one per view. Both are currently muted in the saved graph; only whichever one is armed actually runs.

Open question — Kris's call, not resolved here. "The wiring is settled; the intent is not. GPTsheet (Node 97 → 98 → 132 → 133 → four SaveImages) is one connected chain costing a single paid call. GPTimages (Nodes 89–96, 24/34/44/64) is four independent paid calls wired into nothing downstream. Both write the same pipeline_<view>_*.png filenames... so which route Kris actually uses cannot be read off the graph." Both routes are drawn below with equal visual weight, on purpose — this diagram does not pick a side.

03 — Mesh: Tripo generation through FrameBridge correction

Four approved orthographic views leave ComfyUI and become a textured 3D mesh through Tripo, then FrameBridge corrects the mesh's frame before anything downstream can rig it. This stage also covers the TRIPO PROXY branch — a separate, lighter retopologised mesh with its own frame correction — and draws two structural facts exactly as the saved graph has them: the Draft/Convert chain currently ends in a dead end, and the correction step below it runs on a hand-pasted path, not a live link.

yaw_degrees is per-generation, never a constant. Two real generations once needed opposite corrections, 180 degrees apart. A wrong yaw rigs the character left/right swapped and raises no error — the single most consequential fact in this pair of diagrams.

04 — Rig: SkinTokens, SkinBridge, and the coverage gate to UE5

Picking up from the FrameBridge-corrected mesh: SkinTokens auto-rigs it, SkinBridge cleans the rig up in an iframe-hosted editor, and — on the route that reuses a saved skeleton instead of a fresh SkinTokens run — a 90% coverage gate decides whether the reuse is trusted or refused. This is the step that does the FBX export: an embedded Blender (bpy) backend, not a separate external DCC tool.

Coverage figureResult
Correct pair100.0% — passes
Same character, frame-corrected100.0% — passes
Same character, raw / uncorrected40.0% — refused
Different character34.8% — refused

"Known measurement gap — coverage is measured against the SAVED asset's own bounding box, not the target's. A much larger asset on a much smaller mesh can read near 100% without truly corresponding." — 04-rig.details.json. UE5 import stays manual: set Update Skeleton Reference Pose ON when re-importing over an existing skeleton, and confirm facing and that _l bones sit on the actual left.

05 — Control plane: arming and driving a stage

This diagram does not re-draw the linear pipeline above — it shows the machinery that decides, at any given moment, which one stage is actually live. 64 of the graph's 76 nodes sit muted at any given save; that is the mute-gated stage architecture working as designed, a cycle the operator drives forward, not decay.

As saved, the Tripo stage is armed — 7 of its 8 nodes — while 64 of the graph's 76 sit muted, waiting their turn. Which stage is armed rotates as Kris works; a saved workflow shows the stage last worked on. The preflight gate (bottom of this diagram) pauses on a warning and offers Run anyway — it never refuses outright, and the whole feature fails open.

06 — Asset plane: where files actually land

One project root fans out to seven sibling folders, each filled by a different pipeline stage at a different time. This diagram covers the trap an operator loses real time to: ComfyUI's own flat output folder and the per-character project tree are different places, and only some files ever cross from one to the other — always copied, never moved.

"The project tree holds keepers, not scratch. Every iteration — every raw Tripo draft, every SkinTokens rig attempt — stays in ComfyUI's own folders. Only an approved hero render, a corrected mesh, or a verified rig is ever copied across." — 06-assets.md