The proxy has twenty-two bones. Named mixamorig:Hips, mixamorig:Spine, mixamorig:LeftArm. The full Mixamo convention, nothing abbreviated. The mesh is capsule parts: torso as a subdivided cylinder, limbs as tapered capsules, head as a UV sphere. It looks like a crash-test dummy rendered in a student project. Behind it the stage is fully live: toon shaders running, amplitude bands bouncing to the beat, a Sky3D clock ticking at the top of the frame. Everything that will eventually drive the real Cj avatar is already wired. Against this.
That was P4. The Meshy API call came at P5.
The project
The EVA Music 24/7 stream visualiser (youtube-music-visualiser-ent) is a Godot 4 build: one persistent World3D, a 2.5D toon avatar of Cj, audio-reactive environment, continuous stream. The avatar pipeline plan was image-to-3D → Blender → Mixamo → Godot. That pipeline has two gates: Meshy charges per generation, and Mixamo adds an external rig-processing dependency. Both gates are deferrable. The question is how long.
The build order
The sequence that emerged delays both gates as long as possible:
- P0: Godot project, toolchain, Blender pipeline scaffold, MCP wiring
- P1: environment. Procedural studio kit before any imported asset.
- P2: audio. Playlist manifest, beat clock, amplitude bands, stage reactivity.
- P3/P4: proxy rig. Mixamo-compatible humanoid stand-in, full system proven.
- P5: Meshy API, real mesh, swap
Nothing in P0–P4 touches either external service.
P1: the set before the character
blender/tools/kit.py generates eleven studio assets from bmesh primitives. Deterministic, licence-free, no imports. build_set.py instances them from sets/studio/spec.json. The toon look is locked here: flat-shaded ink outlines, no PBR. Nothing about the environment shader depends on what the avatar looks like.
The Sky3D clock wires in at P1 too, a live-stream signal in the top of frame. The resting shot was locked at P1, before any avatar existed. Locking it early establishes a fixed visual reference: every subsequent lighting decision, shader tweak, and audio-reactive geometry change gets evaluated against a known composition, not a moving one. Building procedurally means no import state that can silently break. Change the spec, rerun build_set.py, the set regenerates.
P2: build against the interface, not the mesh
tools/manifest_from_remotion.py (Python, not the originally-planned .mjs, one test stack instead of two) converts the Remotion manifest into data/stream-manifest.json, joining NAPA masters by TRACK_NN number. Beat clock and amplitude bands derive from this at runtime. Stage reactivity (lights, geometry response, environment parameters) ties to amplitude.
All of P2 runs against a placeholder character. The stage doesn’t know what the avatar looks like; it knows bone positions and amplitude values only. Build against those two signals and the character becomes a plug-in.
This is the critical decision in the sequence. If P2 had waited for a real mesh, the audio-reactive stage would have been written around specific geometry. Written against an abstract interface, it works with any mesh that speaks the same convention.
P3/P4: the proxy rig
blender/cj/proxy_rig.py generates a Mixamo-named humanoid stand-in: twenty-two core mixamorig: bones at human proportions, skinned capsule parts, five VRM-named face shape keys. The naming convention is exact. The Godot animation controller consumes mixamorig: names directly. If the proxy drives the controller, any mesh with the same naming drives it.
The proof at the end of P4: proxy hosts, beat drops, stage reacts, face shape keys change. Everything the real avatar will do, the proxy does first. Not a unit test. A rendered proof. Full pipeline, wrong mesh.
Mixamo as a processing step dropped out here. The proxy uses Mixamo naming so downstream tooling is compatible, but the Meshy API returned a rig in the same convention directly. The naming was forward-compatible; the processing step wasn’t needed.
P5: the swap
tools/meshy.py wraps the Meshy API. Stdlib-only, 7 tests. The key lives in Keychain under meshy-api-key; balance at creation was 3,105 credits. The call generates a Cj mesh from reference images, rigged in Mixamo-compatible convention, exported into the Blender pipeline.
The swap: replace the proxy mesh with the Meshy output. Every other file unchanged. Animations, stage reactivity, toon shader, the Godot bone controller: none of it references the mesh directly. The mesh is the only variable.
One commit. Because the interface was defined and proven at P4, not at P5.
The proxy phase also clarifies the Meshy requirements before the credit leaves the account. By the time the call fires, the spec is exact: Mixamo-compatible rig, named bones matching the controller, five face shape keys. No ambiguity to resolve mid-generation. The proxy defined the contract; the API call satisfies it.
The cost
There’s a real cost to this sequence: time before the product looks like itself. P4 is visually flat. Capsule limbs, blank face, crash-test dummy silhouette against a live toon set and working audio. The pull towards collapsing P4 and P5 together is genuine. Prove stage and real mesh simultaneously, skip the proxy phase entirely.
The problem: if something breaks after the swap, diagnosis is open-ended, with mesh geometry, rig output convention, stage interaction, and naming mismatch all in play. The P4 proof narrows scope fast. The proxy ran clean. The break lives in the Meshy output or its rig.
That narrowing is the actual value of the proxy phase. Not the capsule geometry. The clean diagnostic boundary between “everything before the mesh” and “the mesh itself.”
What this isn’t
This sequence doesn’t suit every avatar build. Cutscenes and character-driven work need the real mesh early. Expression and timing can’t be reviewed against capsule parts. The proxy-first approach fits continuous-loop environments where stage, audio, and environment matter as much as the character. If the character IS the product, prove the character first.
Out of scope: Remotion manifest format details, Meshy API call parameters, the Godot animation controller wiring. Each warrants its own entry.
The general pattern: prove the interface on cheap geometry before committing to the final asset. The proxy is the test harness. The Meshy call is the deployment.
