Building a 3D World with Playable Characters

Building a 3D World with Playable Characters

September to October 2026 · The first step toward 3D worlds people can walk through: how we built a playable third-person
game on Three.js and Electron, and what it took to make its characters and its world hold up.

This is the engineering journal of TPS Arena. It covers what we built, what broke, which routes we weighed, what we
picked and what it cost. Each chapter is written as problems, causes and solutions. Where our first diagnosis was
wrong, the chapter says so and gives the real cause.

The short version is that getting a shooter to run is not the hard part. The first playable build came quickly. Everything
after that is the distance between a build that runs and a game that feels right. That distance is made of problems like
a jump that only worked one frame in three, hair bound to a character's hands, a sword that took twenty iterations to
sit in a fist, and a frame-rate meter that reported the wrong number.

Why a game first

A game is the hardest everyday test of a 3D world. Its characters have to move, collide, be lit and hold a frame rate
while real people use them. Everything in this journal, from making a generated model fit for real time to keeping a
five-a-side match above 100 fps, is groundwork for the worlds we want to build next: digital buildings that mirror real
landmarks, places to walk through and shop in, and previews that let a property developer show a project before it is
built, in time in VR and AR as well as on a screen.

TPS Arena is the case study. This journal is the record of what it took, problem by problem.

The tools, in the order they joined

Chapters

The chapters are in build order, grouped into five parts. Page 00 sets out what we built and the tools behind it. Part V
holds the two reference pages, and the roadmap is always the last chapter.

About this journal

What this journal is, what we built, and the tools behind it.

What it is

This is the engineering journal of TPS Arena, a third-person shooter built on Three.js and Electron. It covers the build
from the first playable version to v0.38. It is a record of problem solving. Each chapter takes a stretch of the build and
explains what we made, what went wrong, why it went wrong and how we fixed it.

Every figure in it was measured. Frame times, triangle counts, joint angles and damage numbers come from our own
test harness, our benchmark and the patch notes.

What we built

The busiest series by far is v0.32, with 63 entries. It covers Agent S's grip, Agent L, the clones and the camera.

The kind of work changed part way through. The early chapters are code, with many small commits. The later chapters
are art in Blender, with few commits and long stretches of modelling.

The stack and the tools

Generated mesh to rigged game character

September 2026 · v0.06 to v0.14 · Meshy, a rig, and hair bound to her hands.

1. The turning point

Problem. After another round on Agent E's painted face, it still did not read as a character.

Cause. It was not a tuning problem. Eyes painted on a sphere with capsule hair will never read as a sculpted
character.

The pipeline we weighed against it was: concept art, then an image-to-3D generator, then Mixamo for the skeleton,
then a GLB file into Three.js.

Solution. We made the engine load a rigged GLB. We tested it on a free placeholder model, which is still in the
roster as the character "Proto". This is the first tool added to the workflow, and the first of the jumps in speed
described in chapter 13.

2. Getting a usable model out of Meshy

The first model came back white, with no texture. It was in an action pose with the sword fused to the body. We
regenerated it in an A-pose with empty hands.

Problem. The model was 2.3 million triangles. Meshy's limit for rigging is 300k. A higher count is not automatically
better. It has to be reduced without damaging the texture.

Why our 72k model looked worse than a 30k Overwatch model. An Overwatch model is built by hand,
with every triangle placed on purpose. A generated one is not. Chapter 13 covers this in full.

Result. Agent E was rigged and running in the game at 245k triangles and 17 MB. That build is v0.10, the first with a
3D model.

3. Heights

Problem. Agent E looked tiny next to the other characters.

Our rule. Characters range from 1.55 m to 1.95 m. Each has a true stature that drives the rig, the hitbox and the
camera.

Our first fix was wrong. The old code-built characters drew at about 1.19 times their stated height. We enlarged
Agent E to match them, which put her at 1.96 m in world height.

Solution. Agent E is 1.65 m, as specified. Everyone else was made proportionally smaller.

4. Animation: 5 out of 100

Problem. With a real model on screen, the hand-written animation looked worse, not better. On our own scale, where
80 out of 100 is smooth and realistic animation, the ability animations sat at about 5. They needed a major rework.

Cause. Joint rotations had been guessed axis by axis. Knees and elbows bent the wrong way.

Solution. We rebuilt the arms and legs on proper two-bone inverse kinematics. We wired the loader so that real
animation clips take over wherever one exists. That was v0.12. It was still nowhere near 80.

The walk that reset

5. The hair, first time round

Problem. In Mixamo's preview, Agent E's long hair was stuck to her hands.

Cause. The automatic rig had bound the hair to whatever bone was nearest. We measured the weights.

What we tried.

Stepping back. We stopped iterating and looked at how Fortnite handles hair. We also saw that we had been fixing
something the game did not show. The hair stuck to the arms in Mixamo's preview, and that is not our game
environment.

Solution. Hair is a stiff, bunched mass that barely moves, the way Fortnite does it at gameplay distance. Free-
flowing motion is kept for a cape.

That decision held until Agent C (chapter 12). It is the compromise that chapter 13 takes apart. The hair is stiff because
it is welded to the body, and it cannot move further without tearing.

What this gave us

A real character in the game, a loader that every later character uses, a height rule, and a first understanding of what a
generated model is: one fused shell that has to be repaired before it can move.

Weapon grip in hand and a fake Mixamo rig

September 2026 · v0.15 to v0.16 · Agent S, a grip tuned by numbers, and a rig that was not what its bone names said.

1. A second character, and what the generator copies

Agent S's specification: humanity's strongest gladiator, 185 cm, an athletic mesomorph build but not a bodybuilder.

Problem. Meshy's first results were slim and flat-shaded. We are building characters in the style of Overwatch and
Fortnite, not 2D anime characters.

Cause. Meshy copies what it sees. The lesson was about the input picture, not the text description.

Solution. The concept picture itself has to look like a 3D render.

2. The cape: use the right tool

Problem. Meshy kept modelling his cloak folded open. We built the cape in code. It came out as a flat 2D piece that
looked like a cardboard cutout.

Cause. Code was the wrong tool for a sculpted garment.

Solution. We generated the cloak as its own model. The engine gave it a chain of bones and physics.

It still took corrections.

• The clasp side had been read as the front. It is the back.
• The top flared out like wings.
• The collar height took three tries. It sat above the collar and must sit below it.

His kit is rage mode, an air dash, a wall run, and a greatsword that splits into twin blades. The mechanics were the
easy part.

3. The grip

Problem. The hard part was his hand. The wrist twisted the wrong way and the elbow distorted.

What we tried. Two rebuilds of the hand logic. Both were reverted. What was left was one number, the roll of the
right hand, tuned by eye.

It took about twelve iterations in all. Our own measurement of "palm toward body" turned out to be inverted. After
that, the direction was set by eye in the game, not by the measurement.

The twin blades

Problem. In dual-sword mode Agent S held two full greatswords. Each hand should hold one half of the greatsword,
cut down the centre.

Our first cut was wrong. It went through the blade the flat way. That halved its thickness and looked identical
from the camera.

Solution. The second cut went across the profile (tools/splitsword.mjs).

4. A method that does not scale

We stepped back and assessed where we stood.

• Against a proper Overwatch-lite goal, we were about 5% there in appearance.
• It was taking twenty iterations to seat one sword in one character's hand. That does not scale.

The suggested missing step was a bridge between our code tooling and Blender, through Higgsfield.

Cause. The missing step was not any one product. Art was being authored as numbers in code and reviewed by
screenshot. That is the wrong tool for art.

Solution. Author in Blender, where a sword is placed by dragging it once. We wrote this into DEVELOPER_GUIDE.md.
Blender joined the workflow in chapter 06.

The guide also ranked where the visual gap really was.

5. A "Mixamo rig" that was not Mixamo's

Problem. The first real Mixamo animation clip went onto Agent S. The clip played, but his legs looked broken.

What we measured. Agent S's skeleton from Meshy had 28 bones against Mixamo's 65. The bones carried
Mixamo's names, but they pointed in different directions. The arms were 95 and 103 degrees off. A clip recorded on
Mixamo's skeleton cannot play correctly on that.

Solution. We wrote a small tool that strips the model down to a bare mesh that Mixamo will accept
(tools/glb2objzip.mjs). We rigged him there.

From then on his combo was real clips: three slashes at 42 / 42 / 57 damage and a fourth at 84.

One route we tried and removed. We converted those clips onto Agent E's old Meshy rig. It did not hold up in
game and we removed it. She would have to be re-rigged on Mixamo too (chapter 04).

6. Version numbers

Problem. The patch notes had grown as "v0.1, v0.2, Patch 0.2.1". We wanted one uniform scheme with no confusion.

What we tried. Splitting the notes into several files. We reverted it, because the point was to reduce clutter.

Solution. One file, one scheme. We also checked the early history for padding. The prototype had been listed as nine
versions. We collapsed it to six honest ones, v0.01 to v0.06.

What this gave us

A second character on a skeleton that every Mixamo clip fits, and the diagnosis that shaped the rest of the project:
place art by hand in an art tool, and let the game play it back.

Mixamo clips: fingers, feet, sword flips

September 2026 · v0.17 to v0.18 · Agent E, Agent Zero and Agent B move onto real clips, and the asset library gets a contract.

1. Open fingers and an upside-down sword

Once Agent S's clips worked, we moved Agent E onto Mixamo's skeleton too, with her own greatsword clips. Her hair
had to be rebuilt again. It took two tries. The first mask swept in tanned skin, which made the top read as short hair
and split the lower half of the long hair away from it.

Problem. Her fingers stayed open around the hilt. The sword sat off her back hand. Sometimes it flipped upside
down.

First approach, wrong. We tried to curl the fingers in code. It took about six rounds and never looked like a
closed hand. The better instinct was to use the original animation as recorded, and ask why it was not arriving.

Cause. The fault was in our own engine code, not the animation. Three.js only writes a bone when its value has
changed. Our rig reset the fingers to their rest pose every frame. The idle clip holds the fists perfectly still. So from the
library's point of view nothing had changed, and the fists were never written.

Solution. We invalidate that cache each frame.

A test run showed 0 flips. The fists sit 0.3 to 4.7 cm from the handle.

2. One comment, two broken characters

Problem. Agent E's primary fire dropped back to its fallback mode.

Cause. A // comment had been added in the middle of her settings line. Everything after it on that line was silently
switched off: her clip combo, its speed-up, its hit timings. The same mistake later broke Agent Zero.

Solution. Comments go at the end of a line and never in the middle. We wrote it down as a rule because it happened
twice.

3. Twelve rounds on one ability

Critical X is a leap, a spin and a beam. Agent E and Agent Zero share the same clip. His is mirrored. We tuned its feel by
play. Jump height went 1.5 m, then 1.0, 0.5, 0.8 and finally 1.2. Hang time and fall speed changed six times or more.

Two measurement errors we corrected. We first measured the blade's sweep through our own grip code and
not the skeleton. That led to a wrong 9% speed-up, which we removed. We also recorded the slash as running to 1.65
s. Watching it showed the slash ends in the air, almost at the moment the beam leaves. 1.65 s was the time slot, not
the motion.

An accident that became a feature. Pressing Space and then E sent the character to 1.88 m, against 1.20 m for
the cast alone. It happens because the cast raises upward speed to a minimum and does not replace it. It was already
useful in play, so we kept it and logged it as an official mechanic. It is in the v0.17 notes as leap stacking.

4. Agent Zero: twelve generations, then the feet

Agent Zero's look took twelve generations on Meshy. The versions with the correct look came out with short legs. We
tried stretching his legs in the file. At 48% the legs were too long in preview, and we reverted it. Then the import
problems came one after another.

5. A clean library, built for fifty characters

After Agent Zero we reorganised the project for fifty characters and not four. Our bar was to patch in the cleanest way
possible. We planned it in phases and approved them one at a time.

The result is a contract a character file must pass (tools/herocheck.mjs, 13 rules) and one tool that prepares a
model for Mixamo and brings it back (tools/heroprep.mjs).

The standing rule. A character's quirk is an asset or pipeline problem. Fix the file or the tool. Never add a per-
character flag in the engine plus a paragraph explaining it.

6. Agent B is not Agent E

Problem. Agent B was a placeholder on Agent E's body. We copied too much and gave her Agent E's whole move
set, where only the body was meant to be shared.

Solution. She is a female swordsman, but she is her own character. We restored her own walk, jump and abilities.
Only the three-hit combo is shared.

Rule. Character changes stay on the character they were made for.

What this gave us

Three characters running on real clips with closed fists and a stable sword. A measured, engine-level foot correction
that needs no per-character data. And a library where a new character is checked by a tool against 13 rules, not
explained by a paragraph.

Lag fixes, and NPCs built on player code

September 2026 · v0.19 to v0.30 · Lag, invisible walls, knockback, and the decision that an NPC is the character code.

1. One default speed for everyone

We wanted melee characters to outpace gunners. The default walk dropped from 6.2 to 4.0 m/s, and melee characters
kept 6.2 by name. Bots had their own speeds per difficulty. We removed them. Bots scale down to the defaults and
have no special speeds. That change is the seed of the biggest architectural decision in the project.

2. Lag, cause one: lights

Problem. Versus mode arrived in v0.19, with up to five NPCs a side. With it came freezes, worst when shooters were
in the match.

What we measured. We added a slow-frame logger to find where the time went. It found two separate causes.

Cause. Every muzzle flash, health-pack glow and projectile added its own light to the scene. In Three.js the number
of lights is part of every material's shader. Each time the count changed, every material was rebuilt.

Solution. A fixed pool of lights that effects borrow from. The light count never changes.

3. Lag, cause two: bullets against bodies

What we measured. Of 260 slow frames, 256 were game logic, not drawing. The cost was in the hit test.

Cause. Bullets were raycast against each character's rigged body. No shipping game does that.

Solution. Every character now carries an invisible capsule and a head sphere. Bullets test those.

4. Forty-eight walls made of air

Problem. Characters ran into obstacles that were not there. The map had invisible walls.

Cause. It had been in the game since the first build. The decoration groups were being added to themselves instead
of to the world. Every pillar, barrel, lamp, tree and sign was built, given a collider, and never drawn. Forty-eight colliders
with nothing to see.

Solution. We attached the groups to the world. That also let us merge 650 small meshes into a handful (v0.20).

With the props finally visible, we judged the map honestly. The target was a map like Overwatch. What we had looked
like Minecraft. The Practice map went bare again, and Central Park was rebuilt as a plaza.

5. The decision: an NPC is the character code

Problem. The NPCs kept cheating in small ways. They moved at their own speeds and swung at their own rate. NPC
Agent E had grown a leap ability no player had. And Agent Zero, with 500 HP including armour, died in a few bullets.

Cause. An audit confirmed it. NPC bullets left the eye horizontally at about 1.6 m. Against a 1.80 m character, every
shot landed in the head zone. Four bullets at 39 each was 156 damage.

Solution. We went further than a patch and made the rule structural.

The rule in our engineering rules reads: if a player cannot do it, an NPC cannot either. We made it for fairness, since
this is meant to be a PvP game one day. It also turned out to matter for networking (chapter 13). A remote player is the
same body driven by a third kind of keyboard.

The same work gave the project its vocabulary rule. A "jump attack" is Space plus left click, whatever animation plays.
We had been naming moves after their clips. Moves are now named by their input.

6. Scoreboard and assists

v0.24 added the post-match table: kills, deaths, assists, damage, healing, mitigation. We wrote our own assist rules.

We also took a cost lesson here. A simple question, how other games count assists, deserves a simple search and not
a deep research pass.

7. Immortal Fury: sixteen passes on one ability

Problem. Agent S's spin was supposed to drag enemies in and finish with a cut. Between v0.26.2 and v0.28.4 it was
a shove, then a vacuum, then a vortex, then a radial pull with a sideways swirl. The finisher's timing alone took eight
releases (v0.27.7 to v0.27.14). It played choppy, and it felt like two abilities and not one connected move set.

Solution. Two playback rates. Slow into the hit and fast out of it.

In the middle of the tuning, a change to his dash and pull strength went in without sign-off. We laid out the options
afterwards.

The same failure later, with a clip instead of a number, produced Rule Zero (chapter 06).

8. Knockback on the ground and in the air

Problem. A shove that sent an airborne enemy 2 to 3 m moved a grounded one about 0.35 m.

Cause. Ground friction (16 per second) ate the push in roughly 0.05 s.

Requirement. Ground and air should match.

There is one door for all knockback now, Player.shove. Immortal Fury was deliberately left out of the drag. A more
rugged feel suits it better.

What this gave us

Freezes traced to two measured causes and removed, a map where every collider can be seen, and NPCs that are the
character code with a different input source. That last decision later carried straight into networking.

Clone abilities, aim offset, hand-keyed draw

September 2026 · v0.32.45 to v0.33.12 · Agent L's clones, the third-person camera, and a sword draw authored frame by
frame.

1. A clone that did no damage

Problem. Agent L's Q made a copy of him that repeats his moves. In the Practice Range, Giga Slash dealt 240
damage with the clone and 240 without it, even though six waves flew instead of three. The mirage was there but it
was not dealing the doubled damage.

We followed Rule Zero. No code changed until the design was approved.

Decision. We chose A, and corrected the design underneath it. Our first build made the clone a separate character
with its own ability charges. That was wrong. Clones are not characters. They are an ability, derived from Agent L. A
clone is a mimic with no ID, not a twin.

We could already see where the idea ran out, so we did not argue the mirror version on paper. We built it as a second
ability on F so both could be tested side by side. Q is Shadow Mirage. F is Phantom Mirror, a lighter body that can be
hit but has no brain of its own.

2. Swings that land beside the crosshair

Problem. We put a Marvel Rivals screenshot next to ours. Our character stood far to the left of the crosshair: 351
pixels, 18% of the screen width. Many sword hits looked like they did not land where they should. It felt mildly off.

It took eight versions (v0.32.51 to v0.32.58) to settle.

Two rules we kept. The turn never goes past 12 degrees, or the walk reads as a crab-walk. And the lower the head
sits from the crosshair, the smaller the character feels. We treat that as law for framing.

A side effect we had not tested for. Both clones aimed from Agent L's eye, which no longer pointed where the
camera did. They stood at the old angle while Agent L stood at the new one. Their aim now starts at the camera.

3. Credits and approvals

We bought 1,000 Higgsfield credits to make Agent L's scabbard and nodachi.

Problem. The scabbard job was priced at 25 credits and submitted in the same step.

Rule. Show the job and the cost, and wait for a yes. Pricing and submitting are separate steps.

The nodachi needed two generations. The first came out with a scimitar's curve. We then narrowed the blade and
guard when the right first move was to scale the whole sword down without touching its proportions. For the second
generation we priced the options first.

Fitting the hilt into the sheath took many small corrections in Blender. The pattern of them is the lesson. Unrequested
changes made it worse: too much cut off the collar, a ring flattened until it looked broken and wrinkled, parts scaled
that were not in scope, such as the grip. In art tuning, one person leads by eye. Each step is one named change, then a
check.

4. T-pose clips on an A-pose body

Problem. A clip copied straight across put Agent L's hands inside his body.

First diagnosis, wrong. We first assumed the wrong Blender window was being viewed. It was the right window.
The transfer was what was wrong.

Cause. Mixamo records its clips on a skeleton standing with arms straight out. Agent L rests with his arms down at an
angle. The difference at the arms is 53 degrees.

Solution. Match the rest poses before transferring. Once matched, every checked bone agreed to 0.0 degrees. The
same correction went into the game's loader. The same trap caught Agent J's clips later (chapter 11).

5. Drawing the sword

The draw is the first animation in the project authored by hand, frame by frame. We measured three Mixamo clips for
how close the palm comes to the grip.

Our principles. Move the prop, not the body. The first thing to try in any instance is to reposition the sheath. And
the sheath should swing, because it does in real life: it goes up violently as a result of momentum.

Decision. Use V1, the first clip. Then came the per-frame work.

• The wrist bend at frame 11 went from the clip's 22 degrees up to 62.8 and back to 58. A later note took a wrist
  bend from 15 degrees back to 10.
• The sheath's resting spot was raised twice.
• Three frames were pushed out by an inch or half an inch.

The intent for each frame is written in our draw notes file, so later work does not have to guess.

The draw itself is his first hit.

6. Bugs the sheath caused

On Olympus, Agent L's abilities stopped working after the sheath shipped. We suspected the new code. That was right
for one of two causes.

What this gave us

A clear model for clones as abilities. A camera rule that makes melee read correctly for every character. A rest-pose
correction built into the loader. And a working method for hand-authored animation, with the intent of each frame
written down.

Reaching 120 fps and measuring frames right

September 2026 · v0.33.4 to v0.35.2 · A frame-rate target, a frame counter that over-reported, and one repeatable benchmark.

1. The requirement

Problem. Five-a-side matches lagged, even on a greybox map. If an empty map could not hold a frame rate, a fully
modelled and textured one had no chance.

Our bar. 120 fps as the target and 80 to 100 fps as the floor, on a mid-range PC (Ryzen 7 3700X, RTX 2060), at Low
and Medium. Below that, a shooter stops feeling like a shooter.

2. Measure first

We changed nothing until it was measured. The game had no frame counter, so we added one before anything else.

Solution. v0.33.4 shipped four changes.

• Clones are built once during loading and pooled.
• Every world mesh got a bounding-volume tree, so ray tests never walk triangles.
• On Medium and Low the map's shadows are baked once at load and characters get blob shadows. Only High
  redraws shadows live.
• An FPS overlay and a frame limit setting.

That is roughly a 5x improvement in play.

3. Shader stutter at match start

Problem. The first seconds of a match still stuttered.

Cause. Shaders were compiling the first time each effect appeared on screen.

Solution. The loading screen now stays up for at least four seconds and runs a short hidden fight to warm
everything. Our rule: up to ten seconds of loading is acceptable if nothing is built mid-match.

4. The meter that lied

Problem. On High, the in-game meter showed 80 to 100+ fps. The experience on screen was closer to 10 fps.

Cause. The meter was counting how often the game loop asked for a frame. With vsync and the frame cap removed
in v0.33.4, the loop kept ticking while the graphics card fell behind. Timed directly, the meter read 60 while the real
rate was 42. High had also been rendering at up to twice the screen's pixels on high-DPI displays.

Solution. The meter now measures finished frames on the GPU. We then listed the costs on High as numbered items
and re-cut the presets from that list. Items 1, 2 and 4 became a new Ultra preset. Items 1 to 5 became High. Medium
and Low were left alone, since they are the presets our target is set on.

5. One honest benchmark

Problem. The first set of real surface textures on Olympus cost about 20% of the frame rate at once. Nothing had
compared that step against the previous build.

Solution. One command, npm run bench (tools/bench.cjs). It runs the same scene from the same camera at
2560×1440, times the GPU, then runs a ten-second bot fight. Its first numbers were High 72 fps (limited by the GPU)
and Medium 137 fps. Every art step is now compared against the last release with it.

The texture cost was brought back from about 20% to about 6% by merging pieces and dropping normal maps where
nobody would see them.

6. The performance budget

What this gave us

The game's own code runs on one CPU core. So the budget is draw calls and script time per frame, not triangle counts
or memory. That is the opposite of what one would guess, and it is why a dense map is acceptable as long as it is
merged. We also have a meter we can trust and a benchmark that catches a regression at the step that caused it.

Map pipeline: greybox, then a modelled kit

September 2026 · v0.33 to v0.35.3 · The first map built to look like a place, and what its art pipeline taught us.

1. Layout first, because credits are money

Problem. Olympus was the first map meant to look like a place and not a test room. The first estimate for its art was
about 390 credits for a 22-piece kit. An art budget of 390 to 450 credits is roughly half of a $50 plan.

Solution. We built the layout in code first, the same way as the earlier maps, and generated nothing. Olympus
shipped as a playable greybox in v0.33. The layout could be judged before any art was paid for.

Problem. On the first try, NPCs walked off the edges and froze at the jumps.

Solution. We fixed navigation until none fell in a 60-second run.

A 1.5x version followed, with a Stairway to Heaven and a Garden of Eden. We kept both. The original is Olympus V1 and
the larger one is Olympus V2. Both are playable, for A/B testing.

2. What must come before any 3D asset

Before any art, we settled the non-negotiables. They became the art strategy in docs/MAPS.md, written down as part
of the master plan and the map plan.

For the style lock we made two concept pictures, one per image model, for 8.5 credits together. Concept A won
clearly. Its sky was the deciding element.

3. Why not the whole arena as one 3D model?

Which generator to use was settled by looking at the result. The first temple island from Hunyuan3D (15 credits) came
out waxy and rounded. So Meshy 7 (38 credits) became the rule for anything seen close, and Hunyuan3D is used for
far background only.

4. Every reference picture is reviewed before it goes to 3D

Problem. One island was submitted to 3D on an earlier approval, without a review of the picture itself. A 3D job costs
credits whether or not the picture was right.

Solution. A fixed gate. No 3D job is submitted until its reference picture has been looked at and approved for that
job. The gate works: one distant island was rejected four times in a row (white, white, too brown, too grey) and never
went to 3D.

To make review easy, we reorganised the Blender scene into four tabs: the playground, pending references, other
references, and modelling. Every finished model goes straight into the playground.

5. The sky, piece by piece

Problem. The painted sky had a hard bottom edge. The cut-off broke the immersion of the scene.

Fixing it took several passes. Each one exposed the next fault.

Solution. Match colours on the rendered output. The cloud colour ended at #f7ca88 against the picture's horizon at
#fbcc8c.

6. The finding: we had been using generation for too much

Problem. We looked into how the popular "whole scene from one text description" Blender demos are made. The
answer was uncomfortable. No whole-scene generator exists. Those scenes are scripted Blender Python for the
architecture, plus PBR materials, plus an HDRI sky. AI 3D is used only for props. Higgsfield's own free Blender
instructions already said so: blocking is 0 credits, generation is for showcase props only.

Cause. We had not read those instructions before spending.

Solution. We proved the new route at once with a plinth modelled in Blender: 3.5k triangles, a gold Greek key on a
marble band, 155 KB, 0 credits.

We also decided to document every mistake, so we grow from each one. That file is docs/LESSONS.md.

7. Smaller lessons from the same work

8. Reviewing the whole pipeline

We then reviewed the whole body of map work end to end, looking for where it went wrong and how to build more
efficiently. The finding was the one above: credits were spent before the free instructions were read.

The credit balance tells the story in one line. It went from 912 to 297.5 across this stretch of work.

What this gave us

Two playable versions of Olympus, a style lock, and a pipeline with the costs in the right places. Architecture and
simple props are modelled in Blender for 0 credits. Generation is reserved for organic and showcase pieces, and only
after the reference picture is approved. Every mistake on the way is written in docs/LESSONS.md.

High-to-low baking and local AI on 6 GB

October 2026 · v0.35.5 to v0.36 · Statues that survive a close look, and generation that costs no credits.

1. Decimate is not a pipeline

Problem. Olympus V2 needed its gods on their plinths. Ares came first. Before spending, we weighed two routes:
generate at high resolution and scale down, or generate his sword and shield separately. Ares came back from Meshy
7 (ultra, 44 credits) at 306k triangles. Straight decimation to 15k shattered his blade into shards.

Cause. Decimating the raw generated mesh throws away fine geometry with nothing to carry the detail. It is the same
shortcut that had produced the "playdough" shield on Zeus and Athena.

Solution. We re-baked Athena through the new route and left Zeus alone, so the two could be compared side by
side. Then we re-baked Zeus too.

2. Facing the right way

Problem. Ares was not looking at the colosseum. His facing did not match the side his nameplate was on.

Solution. Every statue now faces the plinth side that looks at the altar.

Poseidon, Hades, Artemis, Apollo and Hermes followed. Each reference picture was revised until approved before it
went to 3D. Each model cost 44 credits. v0.36 is the release where all eight gods stand on Olympus V2.

3. Records show the final design only

Getting a design right takes many pictures. That iteration is internal. Once a design is ready, it is the design, and we
stick with it. Documents, patch notes and commits record the final approved design only. A local commit and tag that
said more were removed and redone before the push. This journal follows the same rule.

4. A wrong assumption about credits

We had assumed that a job rejected by the generator still costs credits. We checked the balances. A rejected job costs
nothing.

5. The first local generator

Problem. Credits were the constraint on all of the map art. The next tool had to cost none. It also had to be
scriptable end to end, with no manual steps in a tool's interface.

Solution. ComfyUI went onto the RTX 2060 with an SDXL model and a ControlNet.

Getting it to start was its own small fight.

• Launching it from the terminal failed.
• A stuck process ran into a 30-minute limit.
• The card needed a different CUDA build.

In the end it is started by double-clicking a batch file.

What it bought: picture edits and texture close-ups at no credit cost. An approved face is kept pixel-identical by
repainting only a masked area.

6. Local image-to-3D

Hunyuan3D, running inside ComfyUI, produced a full body from one picture in about five minutes for 0 credits. The
shape was plausible. The face was poor.

We then pushed for maximum quality with no limit on generation time.

The body and the head are merged in Blender.

The limit is the hardware. One job ran 14 minutes because the game was using the same GPU. Generation and
play-testing cannot share the card. A bigger card is under consideration. The setup is also written down so that a new
machine knows exactly what it needs to download.

What this gave us

A statue pipeline that holds up close: generate high, bake to about 20k triangles, keep the detail in lossless maps. And
a second generation route that costs time, not credits. Paid generation is now reserved for the pieces where its quality
is needed.

Fused-shell hair: why it tears when it moves

October 2026 · her own branch in its own worktree, v0.37.2, not merged · Our first healer, and a limit of generated character

models.

1. The kit was the quick part

Agent C is our sixth character and the first healer. The requirement was a placeholder at no credit cost: Agent E's body
with pink hair and a wand made in code.

Her kit:

• Light bolts that heal or hurt for 25.
• A heavy orb.
• A cleanse.
• A launch.
• A 20 m healing circle.

The kit was built and measured quickly. Every number that the design had not specified was listed out for review. The
kit checker passed 49 abilities with 0 mismatches.

That is the pattern of this whole project in one character. The mechanics were the quick part. Her hair took far longer
and is still not right.

2. A borrowed walk

Constraints. No greatsword walk on Agent C. No new Mixamo downloads onto her skeleton.

Problem. We gave her the shared girl's walk. Her legs were fine below the knee and twisted at the hip.

Cause. That walk had been recorded on Agent E's older rig. Its thigh bones sit about half a turn round their own
length from Agent C's skeleton.

Solution. We retargeted the clip onto her own skeleton, the route Agent B already uses. The motion came through
clean.

3. The hollow back

Problem. Her hair was to be shorter than Agent E's. After the cut the hair looked good, but her upper back was
hollow.

Cause. Something nobody had measured. On the generated model, the long hair was the surface of her upper back.
There was no back underneath.

We ranked the options and tried them in order.

We measured the result by counting see-through pixels on her back.

Two rules came out of this. Measure an asset before editing it. And a visual fix is judged in a live match, never claimed
from a static view.

4. Hair that follows the head, or the body

Problem. On a turn, the lower half of her hair rode her back like a backpack.

Cause. The hair on her skull followed the head and the hair below followed the chest. The chest twists 32 degrees in
her run and the head 5. That is 27 degrees of disagreement in one piece of hair.

How we compared them. The variants were played side by side in Blender, on a recording of a real walk and sprint
captured from the game.

Options 2e, 2d and 2c on the recorded run, from behind: the view that decided the hair, and the one that sent us back to Agent E's
own model first (chapter 14).

A process mistake. Two of the variants (2d and 2e) were put straight into the game. That became a rule. Options
are compared in Blender first. Nothing goes into the game until one has been picked. A test never swaps the live files.

We stopped there on purpose. Variant 2e stays for now, and everything was committed as v0.37.2.

5. Over-scoped

Problem. Finishing Agent C meant one thing: swapping in her character model. We treated the whole open list in our
notes as the job, and started building a test suite, an NPC healer and a benchmark switch.

Solution. We stopped that work. She was committed to her branch as she stood. One real bug did come out of it: a
match crashed when Agent Zero marked an NPC Agent C. But the scope was wrong. The lesson is to confirm the size
of a task before starting it.

6. Why this is a wall and not a bug

Six variants of weights did not fix Agent C's hair, because the weights were never the problem. Her hair is part of one
fused shell with nothing beneath it.

This is the same compromise we made for Agent E (chapter 02), reached again from the other side.

What this gave us

A working healer kit, a clean retargeting route for borrowed clips, and a precise statement of the limit. A generated
character whose hair and body are one shell cannot have hair that both moves and stays closed. Chapter 13 takes on
that question.

Character quality gap: cause and four routes

October 2026 · Why our characters are not production-grade yet, and the routes that could close the gap.

1. The pace problem

Problem. The schedule for a production-grade shooter is three months. At the current pace it would take one to two
years. That is not acceptable.

What we observed. Every jump in speed so far came from adding a tool, not from working harder. Each new tool
made the workflow many times quicker. So the question became which tool, or which method, comes next.

2. What was wrong with the characters

The complaint was specific.

Hair was the clearest symptom. Our hair physics are a patch over a deeper fault. They are fine for now. They are not
fine for production-grade material.

3. A route we rejected: another game's extracted assets

The modding community makes very good custom Fortnite characters. The method uses FortnitePorting, UModel and
Blender. It pulls the official character models, skeletons and textures out of the game files, loads them into Blender,
and modifies them. We evaluated it as a route to better characters. It fails on three counts.

A correction to our own guide. DEVELOPER_GUIDE.md section 1 says the Meshy characters are already close to
the right tier. That holds at gameplay distance. It does not hold on the character select screen, or for anything that has
to move, like hair and cloth.

4. The root cause: how the model is constructed

The evaluation did point at the real difference. It is the construction of the model.

Problem. Hair barely moves, and it cannot be made to move more.

Cause. The 4-12° limit is the patch. We capped the swing because a fused shell tears if it moves more.

Solution. No physics tuning fixes that. The hair has to be a separate object over an intact head.

5. Options we considered

Cascadeur is installed and not yet used. It stays the right tool for motion. It does nothing for model quality.

6. What the remaining time can and cannot buy

Overwatch polish is roughly 3-6 artist-months per character. No tool closes that gap in 70 days. What is reachable is a
vertical slice: six characters whose look and physics read as intentional, one finished map, playable on LAN.

Characters are not even the biggest schedule risk. There is no netcode at all, and LAN play needs roughly 2-3 weeks
of it. The architecture helps here. An NPC is already a Player driven by a fake keyboard (chapter 05). So a remote
player is a Player driven by a network one. After that, map art is still the largest visual gap.

7. The plan

The plan is a recommendation. Nothing has been built from it, and the route is not yet chosen.

What this gave us

A precise diagnosis. Our characters fall short because each one is a single fused shell, not because of the renderer or
the engine. That turns a vague quality complaint into a construction problem with four priced routes, a test to choose
between them, and a scope that fits the schedule.

Faceting: weld before decimating

5 and 6 October · The question that started the rebuild, the sources we gathered to answer it, and the three facts that shaped

everything after: weld before reducing, bake after reducing, and give the face its own budget.

1. The face, measured

The game model as it was: a face with no detail, flat eyes.

Problem. The Streetwear model in the game had a faceted face, painted-on eyes, fringe colour smeared onto the
forehead and wedges on her cheeks and belly. We started with a baseline in headless Blender under neutral light.

The face itself was 1,345 triangles and about 62,000 texels, scattered across the sheet. The dark patch over her nose
and mouth was not in the texture: flat-lit, the skin there is one clean colour. It was geometry. 1,315 corner points of the
face were duplicated, and neighbouring face triangles met at 33 degrees.

A first, cheap pass changed shading only:

It helped, and it was a stopgap. The real question was why a sculpt that looks smooth in Meshy's viewer comes out
faceted in ours.

2. The cause: the wedges were ours, not Meshy's

Cause. At full resolution (605,392 triangles) the sculpt is smooth everywhere. Meshy exports every vertex split along
its UV seams, and our original reduction had decimated that unwelded mesh by more than 90 percent. Each seam was
an open edge: the decimate protected the edges and chewed the surfaces between them. The wedges, and the holes
the base model had, were the seams. The face had also been given only 3 percent of the triangles, because a single
decimate hands out triangles by surface area.

Solution. Weld first (remove_doubles: 327,905 vertices to 302,642), then reduce. A welded leg at 1,424 triangles
came out flawless; the old one at 2,900 had cracked. That one fact moved everything else in this part.

3. Separable parts: Meshy's split-parts download

The tool scan we ran first found nothing that turns a picture into a rigged, part-separated character. It did find that
Meshy can return a model as separate pieces. Re-rendering the original with "split parts" instead of "texture" gave us
this:

No colour, and nothing under the hair. We measured what is behind it:

So we used the split model as a label, not a mesh: it says which triangle of the painted model belongs to which part.
Where the hair comes off, a scalp liner in hair colour closes the gap.

4. Colour: three projections that failed

Problem. The first rebuild (R, 53,410 triangles, 6,000 on the face, about 17 texels per cm instead of 11) showed that
the geometry was now right: the abs, legs and lower face came out perfect. The colour was not. Carried over from the
old game model, it made her look alien: smudged eyes, a speckled neck, pale hems.

Cause. The two surfaces were 3.4 mm apart at the legs and 13.5 mm at the arms. Projecting colour across that gap
reads the wrong texel. We added a safety check (no bake if the surfaces are more than 3 mm apart). When it stopped
the next bake at 5.9 mm, we first said Meshy had regenerated the geometry. That was wrong: with a proper fit the gap
was 0.07 mm.

Solution. Stop moving colour between models. Build the game model out of the painted model itself, reduce it part
by part, and bake each part from its own source. The gap is then zero by construction.

5. The sources: twelve paints and three remeshes

A Meshy retexture at full resolution: a better face, the eyes still odd.

Meshy can repaint a model without touching its geometry, and the rerolls were free. We had the Streetwear sculpt
repainted twelve times. Every T has the same 605,392 triangles in the same order; only the paint differs. Ranked by
eye, face first, then hair from behind, in a window sorted 2K / 4K / 8K so nobody had to memorise numbers.

The decision: face and body from T8 (R8) or T10 (R10), hair paint from T3. A bigger texture did not mean a better paint:
the 4K and 8K hair was worse than the 2K, and the game ships 2048 anyway.

What a Meshy-painted face is up close, hair hidden: the fringe was painted into the forehead skin, brows and all. No retexture
escapes this; it is how an image-to-3D painter sees a fringe.

Hair paint smeared onto the face, on Meshy's flagship model.

We also had Meshy remesh T8 three ways. Its own retopology, one fused shell each:

Reading the files themselves explained why M8 looked worse in Blender than in Meshy's viewer: the remesh drops the
normal map (two images in the file, not three), and Meshy's viewer lights it more kindly. We concluded that with a
normal map the remeshes would have been the obvious choice. Without one, our own rebuilds still won where it
mattered most for a body: they kept her roundness and had none of the veins and ridges the remeshes left on her
legs. What the remeshes did very well was the clothing and the hair, so that is what we took from them.

The window at its widest: the retextures, the old game model, the rebuilds and the masters. A clone army, assembled only to pick
one face, one hair and one hoodie.

6. Two ways to put colour on a reduced mesh

This is the fact behind both the fused eyes and the black teeth at the hoodie hem that come up in chapter 17, and it
took a day to see that they were the same fact.

The rule: reduce, then bake. Keep the original texels only at full resolution.

7. Where the triangles should go

A single decimate hands out triangles by surface area, and Meshy painted her whole face into 3 percent of the mesh.
The counts, measured with the same part test on each file:

Two things the table says. Legs and belly at 1,100 to 1,500 are flawless once welded; the old 2,900 bought nothing.
And the face needs a budget of its own, around a third of its full detail, or the eyes fuse. We also decided not to aim
for the 60,000 ceiling: most characters sit well below it, and every triangle we do not need is one less that can make
the game lag.

What this gave us

A diagnosis that held for the next four days: the generated sculpt was fine, our reduction was not. A source for each
part (T8's face, T3's hair paint, M8x's clothes and hair shape). And three rules that every later build followed: weld
before reducing, bake after reducing, and decide the face's budget before anything else.

Seam gaps and a capped collar

6 and 7 October · From the first part-by-part rebuild (R8) to R8fix v6, on par with the old model · The longest single fight of the
remake was one junction: where the hoodie meets the neck. It took eleven builds, and the answer was not another rule.

1. R8 and R10: the right face, and holes at every seam

The first row: a 2K retexture (T1), the game model (A), and the first two rebuilds (R8, R10). A's shine is the old game material; the
rebuilds already carry the retextures' paint.

R8 and R10 were built straight from the painted model: T8 (or T10) cut into eleven parts by the split-parts test, each
part reduced to its own budget, unwrapped fresh, and T8's paint (T3's for the hair) baked onto it.

They looked much better than the game model, because the face and colour now came straight from the painted
model instead of being carried across from another mesh. What they still lacked was closure: holes on her inner shin,
at the hip and around the shorts.

First attempts. Pinning the cut edges (R8b) took the model from 53,799 to 76,678 triangles, doubled the hair and
made black needle triangles. Overlapping the parts by 2.5 mm (R8c) still left black slivers.

Cause. Found by looking at the baked textures, not at renders. The unwrap had made thousands of tiny islands (most
of the 2048 sheet was black gaps), and Meshy exports every vertex split at its UV seams, so each part was reduced
as thousands of loose scraps.

Solution. Weld each part before reducing it, and pack a few large islands per part with a 16-pixel margin, every texel
pushed 24 pixels out over the black. That was R8fix.

2. R8fix, step by step

With v3 (55,931 triangles) we judged the clothes, skin and smoothness done: all of them looked much better, so every
later build left them alone. What was left was the collar.

A leftover of the hole problem: a slit on the belly after one reduction, a fold in an overlap strip. It went when the strips went.

3. The collar, eleven times

The gap: where the trimmed hoodie no longer met the neck, with the torn cap edge showing black.

Problem. From v3 on, the hoodie either left a gap at the neck or wrapped it.

Cause. R8 never had the problem because its hoodie was cut out of the painted model: one continuous shell, hoodie
rim to inner collar to neck skin. The voxel route made the hoodie a separate closed object, and Meshy closes each split
piece with a cap that follows the body underneath. Every trim rule drew the line between cap and hoodie somewhere
wrong. We wrote four rules before asking what R8 had done right.

The diagnostic that ended it: colour every face of the remeshed hoodie by what a rule would do to it.

The builds in order, and why each one failed:

The options we weighed before v6:

The narrowing that made it work: the voxel-smoothed clothes were already good everywhere except the neckline, so
swapping all of them for M8x's would have thrown away work that was right to fix a problem that lived in one place.
Only the hoodie came from M8x. The neck part extends two rings under it.

4. What a build costs, and why it took eight minutes

A build took eight minutes, and with eleven collar builds in a row we needed to know why it was not instant, and
whether the GPU or the memory was the limit. Where the time went, stage by stage:

The GPU was off limits: three open Blender windows owned the RTX 2060's 6 GB.

5. The process mistakes, and the rules they left

What this gave us

R8fix v6, the first rebuild that matched the old model's look without its wedges. And the pattern that came back on 8
and 9 October: a junction between two separately made pieces is an invented edge, and the cure is a source in which
the edge does not exist.

Master first, then reduce

7 October · Masters F8 and F10, the R8x family, and the two routes on record · The plan had been to put T3's hair on T8 and
keep the full model. What came back was a game-size build. Going back for the full model we had skipped taught us more
than any build before it.

1. The question

Problem. When R8 and R10 were first made, the plan was to put T3's hair on T8. The expected result was a full
model with no other change, to be reduced afterwards. What came back was a game-size build, chopped, reduced and
baked in one go. We realised the order we had always meant to follow was merge the T variants → get one perfect
variant → repaint minor flaws and downscale to game size. The shortcut had quietly become a whole other route, so
we now had two, and no master behind either.

So we built the step we had skipped. Since every T is the same mesh in the same face order (face centres differ by 0.0
mm), the merge is a second UV map: F8 is T8 with T3's hair paint read through T3's own layout on the 243,871 hair
faces. F10 is the same on T10. 37 MB each. Both looked right, which confirmed the merge costs nothing in quality: it is
only a second UV map, so every texel stays original.

Which of R8's reasons for chopping into parts still apply once the master exists:

2. A whole model reduced at once: R8x

The first R8x was F8 welded and decimated in one go to R8's count. R8x and R10x came out surprisingly good: no
flaws and no holes in the body, where R8 and R10 had both. That made the one weakness stand out: the eyes looked
fused.

We also noticed that their legs had half the triangles of R8 and R10, yet looked flawless and without holes. That told
us that welding, not triangle count, decided smoothness, and that a uniform decimate starves the face: 18,840 face
triangles are 3 percent of the model, so a uniform cut leaves 1,716.

The parts version took budgets per part instead, set by eye:

3. Eyes that warped, and teeth at the hem

Problem. Even at 7,000 triangles the eyes still looked warped, and a thin slit appeared on the belly with black teeth
running down from the hoodie hem.

We offered five options for the head:

The answer was none of them. The head had already been fixed once, on R8fix, so it made more sense to study how
than to invent a new technique, and going back through every R8fix variant closely showed it. R8fix's head was
welded, decimated plainly to 6,000, unwrapped fresh and baked from T8. The bake, not a geometry trick, had fixed the
face, so the five options had been solving the wrong problem. Applied at 7,000: the face was good and the slit was
gone.

The hem teeth followed the same path. We tried overlap strips (they made a shelf: 215 belly faces facing inward
against 28 before), snapped borders, then shared border anchors every 6 mm. Then the comparison that settled it:

Solution. Bake every part that carries skin or a face: head at 2048, belly and legs at 1024, hands at 512, fresh
unwraps from T8. Cloth and hair keep Meshy's texels. R8x final: 39,344 triangles. Everything that went through a bake
behaved; everything that kept Meshy's texels through a reduction bit us.

4. Two routes, and how each family is achieved

They converge. R8fix's bake already reads two donors; reading from a merged master changes one line. The difference
is where the paint fixes live: on the master, once, or in the recipe, every time. For every character after Agent E the
order is master first.

5. Three routes for every character after her

We set the three final approaches side by side to decide which one every future character should follow.

The order for the next character: generate retextures → rank faces and hair in the window → merge the winners into
the master → cut, weld, reduce (the face never below a third of its detail) → re-bake the skin only → paint file → rig.

What this gave us

A master to paint on, a reduced model whose body was flawless at fewer triangles than any build before it, and a
written order of work. It also fixed what a merge means for us: putting one variant's part on another produces the full
model first, not a shortcut to the game.

Fixing AI paint errors by hand

7 October · Red paint on her collarbones, three automatic fixes that looked like burn marks, and the brush that replaced them ·
The day colour stopped being a rule in a script and became a stroke made by a person.

1. Red where it does not belong

The red: T8's inner-collar paint running onto the skin, on faces the part test rightly calls neck.

Problem. T8 paints the inside of the collar and the hood lining hair-red, and ran that red about a centimetre past the
fabric onto the collarbone skin. T1 to T5 go straight from skin to black.

Cause. Meshy's painter, not our build: the red is in T8's own texture, on the master too.

Since every T is the same mesh, the hoodie could read its paint from any of them. The choice of hoodie source:

2. Three automatic fixes, three burn marks

Fixes made straight away had been costing us builds, so we decided that from here on every fix starts as a diagnosis
with ranked recommendations, and nothing changes until one is chosen. We set out four options (rule inpaint, collar
skin from T3, hand paint, black) and the rule inpaint was chosen first.

Cause. Colour on a face is a judgement. A script sees texels; where a region borders two colours, any automatic fill
mixes them, and the eye reads the mix as a bruise. Agent J's hair had been fixed the same week by hand painting
(chapter 11). And we realised the split parts gave us the order a painter would use: the body can be painted on its own
first, before the jacket goes on, so a fix on the skin never touches the cloth.

3. The brush

Solution. A paint file for R8x, where every part is its own object with its own map: one-click buttons per part (paint
skin, paint jacket, paint belly, paint shorts, paint hair, show all, look at face) that hide what is in the way and put the
right map under the brush; a black brush and a skin brush; and a SAVE button. The workflow:

The paint file. A marker stroke on the jacket (any colour will do), the texture it lands on at the right, and the one-click panel.
Whatever is marked becomes what we say it is.

What the passes did, in order:

Two things had to be learned on the way. The brush projects through the mesh's active UV map, so the jacket strokes
landed at random on T12's 8K map until that layer was switched. And Blender's brush colours are linear, not display
colours, so a brush set to black first painted grey.

The verdict: of the three fixes, the brush was the best. The eye put each colour exactly where it belonged,
which no rule had managed. R8x, hand-painted, became the branch for Agent E Streetwear.

4. What a brush cannot fix: the face under the fringe

Problem. Meshy painted hair colour into the forehead and brow texels. Painting it out by hand failed: the hair colour
sat in the same texels as the brows and forehead, so there was no clean skin underneath to bring back. That made us
ask how a studio artist avoids the problem in the first place:

We parked it: with her hair on, it blends in at this level of quality. Two days later the whole question went away,
because her head was replaced (chapter 22).

What this gave us

A working division of labour that every visual task since has used: the eye marks, the script converts exactly what was
marked, and nothing else changes. And a rule we had been circling since chapter 12: colour is decided by a person
looking at it, in the light the game will use.

Texture atlas, first rig, source holes

7 and 8 October · Getting the hand-painted R8x to 50 MB-class size, rigging it, and finding out that the hole in her shoulder
had been in the source all along · The first time the game, not Blender, was the judge.

1. How heavy is a character?

We noticed that Agent L, Agent J and Agent Zero looked the best in the game at the time while having the fewest
vertices, which told us that the method used to bake and reduce matters more than the count. The current Agent E
looked a tenth of Agent L's quality while using more. The game was already starting to lag and was unplayable on a
Mac, so we set the end goal of bringing every character down to the 50 MB range, not 100 MB+.

Problem. The painted R8x carried 27 maps, three of them whole-body Meshy atlases (T12 at 8K, T8 at 4K, T3 at 2K)
of which the hoodie, shorts, shoes and hair used slivers: 698 MB on the GPU. We had picked 8K out of habit, not for a
reason: the extra resolution had never protected a build through reduction, where something went wrong every time.

Solution. A bake: for every texel of one new 2048 map, a ray reads what is painted on the part surface underneath,
whatever map that part was using. The body became one object with one fresh unwrap and one 2048 set; the hair its
own object on a 1024 set. Nothing geometric moved.

What it cost: texel density. The hoodie went from a fifth of an 8K atlas to a quarter of a 2048; the head from its own
2048 to a fifth of one; the hair from 2048 to 1024. We judged the loss acceptable for the memory it saved, with one
bake miss, a single dot filled from its neighbours. Below 50 MB is not a modelling job: every route ends at one 2048
set. GPU-compressed textures would be the next floor (chapter 23).

The three game-size options as they then stood:

The verdict: R8x for every character that matters, R8fix as the batch route, M8 as a donor when a part tears under
reduction. On credits, a 44-credit remesh is small next to the budget we set: 500 Meshy credits per character without
review, and 1,000 at the cap. We still decided not to force a remesh on every character, because it takes time and is
clunky; it earns its place as an option to try when a part is not working.

2. The first rig: copied, not solved

The atlas went into the game on her existing skeleton (52 bones plus a 5-bone hair chain), with weights copied by
nearest surface from the old Streetwear mesh. The file contract passed: 13 rules, 0 failures. The game showed what
Blender had not.

The first three fixes worked: hair weights only from the old mesh's hair, the hoodie rim rebuilt with its dense border, the
shoes baked into their own maps. Then a smoothing pass on every weight, and she came out looking cracked, skin
and clothes both broken. That taught us the lesson that set the rule for the rest of the week: all three models had
started with few problems, about 90% there, and each round of fixes took them down to 80%, 70% and lower, because
every fix created new problems to mend. So we look for the root cause and prevent it in the first place, instead of
mending problems one by one. We reverted to the 90% state.

3. The hole in her shoulder

Problem. In the game her left shoulder had a hole. Three rig passes chased it (a plain transfer, hair from the old hair
only, a per-side transfer with smoothing). Then two geometry guesses: hair winning the tie in the part test (a rule
returned 7,552 faces from hair to body), and the thin double layer of the hood collapsing in the decimate.

Cause. Found by a different test: we put a bald Agent E in Blender, from behind at 45 degrees, three sources side by
side. With the hair out of the way, the F8 master clearly had holes in it.

The painted master with the hair hidden. Under the hair, the hair was the only surface Meshy ever painted.

The split-parts mould, bald. The shoulders exist here: as a flat plate stuck on the hoodie piece.

We had earlier ruled out holes in F8 from a thumbnail, and a thumbnail with the hair on could never have shown them.
Every build cut from the painted shell inherited the hollow.

Solution. Hoodie and both arms from the sculpt pieces: a 2 mm voxel remesh first (the raw solid is double-layered at
the hood and a plain decimate tears it), then three ray tests per face. Paint above within 8 cm: keep. No paint above
and more than 4 mm from any paint: the closing cap, dropped (3,837 hoodie faces). Paint above is hair: keep and fill
flat, hoodie black or arm skin.

The rebuilt shoulder in the game, before the brush: no hole, but a blotch of red and black.

Better than a hole, but still not passable. The design had always been a backless top with a hoodie attached to the
neck, so the rebuilt shoulder had to read as skin above the sleeves and as black only on the hood. So the last step
was the brush again: the strip above each sleeve marked as skin (11,072 texels), the hood back as black (122,840
texels, the reddish ones refilled from genuine black), and a live slider on the skin patch to set the tone by eye.

That passed, and we moved on: this version of Agent E was the only one that was game ready and not broken. In the
game on 8 October: 46,709 triangles, six maps (body 2048, hair 1024), 63 MB on the GPU, 16.5 MB file, 0 contract
failures.

4. The order that worked

What this gave us

A 50 MB-class target for every character, the first rebuilt Agent E in the game (Streetwear X), and two rules that held
from then on: a rig is judged in motion, and a hole is looked for in the source before it is blamed on the stage that
revealed it.

Voxel remesh fills: the monster neck

8 October · A jagged collar, the day we wrote Rule One, two whole new routes (B and C) built and rejected in an afternoon, and
Meshy's own remesh made into the final figure · About forty named builds in one day.

1. A sticker and a jagged lip

Streetwear X on the character select screen: the shoulder hole gone, the front collar lip jagged.

The sticker: a flat patch on the black jacket at the shoulder.

Problem. The shoulder hole was fixed, but looking at the model we could still see a flat patch on her hoodie (the
sticker), the front of the hoodie near her neck looked like botched black remnants scattered over it, and the front
hoodie lip was jagged.

Cause. The hoodie swapped in from the sculpt kept its inside hood walls: 564 faces, about 50 cm², standing 1 to 2 cm
off Meshy's painted surface, and a second collar lip about 2 cm outside the neck piece's own. We had checked the
swap only from behind.

2. The day we wrote Rule One

We then spent half an hour hunting the sticker with renders, ray tests and 24-angle grids. A person looking at the
model found it in seconds. That set a different way of working for anything visual: the eye finds the problem and marks
it, and the scripts measure and fix exactly what was marked.

It went to the top of our working rules the same minute, above Rule Zero (chapter 06). From then on a visual problem
starts with a scene: the model loaded, framed and lit, with a red marker brush and pins, and the spot is marked by the
person who can see it.

3. The collar, welded

With the marks to aim at, the collar took seven versions in four hours.

It had never been welded, and that was an architectural choice. Eleven parts, each welded only within itself; the
seams were held by 6 mm border anchors, which gives two matching edges, never one joined edge. The anchors had
then been switched off for the hem, and the mould's hoodie came from separate sculpt geometry that shared no seam
at all. A weld belongs at the step where the parts merge.

4. Route B: everything in one shell

The joins we expected, since this was a multi-part build, but we counted far more flaws than the joins could explain.
The causes: Meshy's shell has nothing under the hair; a 13x cut (605,000 to about 46,000 triangles) tears thin areas;
parts from mixed sources were never made to meet; and fixes by rules, made without seeing. We concluded that
colour was the easy part, because Agent E's colours are quite straightforward, and that the flaw was the geometry, so
the next route had to rebuild the geometry rather than keep repainting it.

The optimistic estimate held. B1 was the sculpt pieces fused into 36,000 triangles with 0 open edges. B2 baked
colour from A (only 242 of 36,000 faces had no source within 1.5 cm). B3 took its surface detail from a 494,000-face
clean shell and its face from the original 4K head. B5 and B7 pulled the neck back onto the painted original (110 points,
then 13). So far the voxel remesh had done well: we found B superior to A in many ways, including the texture on her
jacket from behind, which told us the route was worth finishing.

B7, about 50,000 triangles, rigged: a body we judged perfect except for one fault, the neck. It had
swollen into a monster neck that no hand work could fix and no number of revisions would
save, so we stopped revising it and went after the cause.

First diagnoses. The fused shell; then the hoodie collar filling the space. B8 (the hoodie as its own shell) came
back with a black face; B9 (B7 with A's head and neck) with a face badly damaged by many large triangles.

Cause. Meshy's hoodie piece is a closed solid whose neck hole is sealed with a flat cap. The voxel remesh fused that
cap into the body and turned it into neck: her neck came out at the diameter of the hood's opening, 54 to 70 mm
against A's 30 mm, two to three times the original diameter.

Route C was the other way round: A without its head, the whole body fused, A's head put back. Its neck was 35 mm,
close, but A's open parts became 2 mm double-walled slabs that a reduction cannot collapse: about 150,000
triangles, a mess of shards.

Three builds (B8's black face, B9's torn face, C3's shards) had been shown without being checked first, and each one
wasted a review on a fault a basic check would have caught. The rule since: every build is checked before it is shown,
and a failed build is deleted, not displayed.

The lineup at the end of the afternoon, every iteration on display:

B and C were dropped except one: we kept B7 as our benchmark for a perfect body with a failed head and neck, with
the method that made it, so that later bodies have a clean one to be measured against.

5. Meshy's remesh as the final figure

That pointed us to a simpler option: use M8x, M8u or M8 as the end figure. Meshy's remeshes had none of the flaws
we had spent the day chasing, so the only repair we expected was their hollow shoulder. Three steps made it work.

The hair split, without fills. Every face of the remesh goes to its nearest sculpt piece; where hair and body
overlap within 1.5 mm, the body keeps the face. The first version filled the hollows under the removed hair from the
fused shell, and pasted pieces of B's monster neck in front of her neck.

The see-through spots came from the fill piece itself, a step our own rules had added, and it was also what carried B's
monster neck into the remesh. Without it the spots fell from over 300 to under 70 on every model, so we dropped it
for good: no fill pieces.

B7's back. We wanted the remeshes' backs to match the B variant's, because B7's back was the cleanest torso we
had; only the torso back, though, not the head or neck, which were exactly where B had failed. B7's faces from the
waist to the shoulder tops replace the remesh's, grown 18 mm so they tuck under its edge, and welded. Seen from
behind, the graft showed no seams. Open points left on the back: M8 43, M8u 38, M8x 26.

New hair. A fresh 2K remesh of T3 (M3, 10,121 triangles), fitted to the sculpt within 0.17 mm. Next to the old hair the
difference was night and day: redder, fresher and far less distorted, so we put it on every model.

We checked B7's back and shoulders and the M8 and A bodies and found no holes or cracks in any of them, so we
kept them as parts for later builds instead of discarding them with the routes they came from.

6. The hair in the game

Problem. In the game the hair looked glued to her shoulders and clipped into them when she looked up.

Cause. Measured: the hair over the neck and shoulders was 38% bound to the head bone, so it turned rigidly with the
head; and Agent E used the shared hair settings, which tie the lower hair 70 to 85% to the spine with 4 to 12 degrees
of swing.

Solution. Weights by height down the chain (root 1.39 m, then 1.22, 1.05, 0.89, 0.73), the front locks on the chest, and
her own hair settings: spine follow 8 to 50%, swing 6 to 26 degrees, more fall, a wider body capsule. Clipping in a
sprint was left for a later patch.

That night the hood's blood-red stain was painted black, a dark pimple on M8x's nose was found by hand-painted skin
dabs where our scan of 433 texels had found nothing and overwritten with a 231-texel disc of surrounding skin, and
5,589 peach texels in her hair went red. A face paint that wiped her brows made her look like a different person, so we
undid it: keeping her likeness mattered more than an even skin. M8x went into the game as a skin (43,563 triangles,
contract 0 failures).

What this gave us

Rule One. A benchmark body (B7) and the method that made it. The cause of the monster neck, which shaped every
voxel step after it. And the realisation that closed the day: M8x's mesh had too many scars to be the end, and a clean
finish would have to start from more detail, not from a reduced remesh. The next morning we went back to the full-
resolution sculpt (chapter 21).

Full-res body: hood, shoulders, normals

9 October, morning · The T8 sculpt at full detail as the body, B7's back grafted on, a hood top that had never been visible, and a
shoulder that took eleven attempts · The first day much of the shaping was done by hand in Blender, with tools built for the

job.

1. Why go back up

We had meant to use the T8 mesh entirely. M8x's mesh had too many scars to finish from, and we wanted a proper
high-definition weld between the head and body made before anything was reduced to game size, while there was
still full detail to weld. The plan, in four steps: the T8 body; B7's back for the shoulders; the paint (shoulders, hood,
inner collar); then a new high-resolution head fused on. From then on we welded at full resolution only: every join is
made at full detail, and reduced once, at the end.

The look of the hoodie was a choice too. Next to A's, B7's hoodie looked glossy and high-resolution, and we traced the
difference to its settings:

We chose B7's surface. After step 3 the body stood at 319,000 triangles with B7's back welded on (51 points), the
hood stain painted out (61,898 texels) and the collar repainted (13,039). Everything looked as good as it once had, but
the new lighting showed us flaws the old lighting had hidden: the shoulder skin geometry needed some smoothing.

Step 3 from behind, in the new lighting: the hood and the rear shoulder where B7's back meets T8's skin.

2. Step 4: the smoothing failure

Problem. Step 4 put a new head on (the full-resolution head from a second Meshy generation of Agent E, with its
hair) and smoothed the shoulders on the way. We saw the same crusty look this smoothing method had produced
every time before: parts of the model botched, with holes everywhere. That told us the step had done more than it
said, so we stopped and traced exactly what it had changed before going any further.

Cause. Step 4 moved 105 shoulder points halfway toward their neighbours, eight times, with no blend into the fixed
edge; and its neck cut deleted every face within about 6.5 cm of the neck centre above the slice without checking
what it hit, which could bite the hood and collar.

Solution. Back to step 3. The rule went into our lessons the same minute: never smooth or delete by a region rule
without saying so first.

3. A hood top nobody had ever seen

We could see jagged lines along the top of the hood. We wanted it smooth, so that the hood would read as intact and
in shape even with no head inside it. We had no reference to work from: none of our prior models had shown that area,
because hair had always covered it.

The first diagnosis blamed the old hair cut. Measured by angle, the T8 hood rim was level; the ragged edge was the
top border of B7's graft, about 1.5 cm above and 3 cm below the rim. Two options:

Option 2 won by far visually, so we took it. Option 1 had a practical case, since a lower hood minimises clipping, but it
left visible gaps and holes; we kept the method for places where clipping matters more than looks. Option 2 was
almost acceptable: a few bumps were left on the sealed hoodie, and judging those by eye called for an eraser rather
than another script.

Option 2's hood top: an even voxel mesh, with a few stray spikes along the edge that had to be pressed down, not deleted.

4. Tools for the hands

From here much of the work was done by hand, with tools built for the job inside the same window:

Of the brushes, flatten was the one that fixed the hoodie. Red remnants on the inner hoodie were marked with the heal
brush as a selection and only the red texels inside the strokes turned black: 2,384 of 19,016, then 1,262 of 36,047,
everything else put back exactly. The shorts hem glued between the legs was deleted by hand, and the microscopic
holes it left were closed with one face per hole in flat denim colour, after a first patch in skin and red was rejected (we
wanted it blue and white like the jeans, so the patch would disappear into the denim) and a second used too many
triangles.

One bug cost paint before it was found: the SAVE button wrote the new PNG but packed the old texture into the
.blend, so every reopen lost the latest strokes.

5. The right shoulder, eleven attempts

Where B7's graft (left, coarse) meets T8's skin (right, dense): about 10 mm triangles against 2 to 3 mm.

Problem. The back of her right shoulder looked lumpy next to the left, even after hand sculpting.

Cause. Not the geometry. Our first three diagnoses were the voxel band, a hidden second layer, and a shadow
artefact. The real ones were three: stored custom normals that never update after sculpting, a normal map baked for
B7 still plugged into the graft, and a skin tone a few values off.

Hand sculpting had helped too, with a cost the numbers explained: flatten and smooth shrink convex shapes, so the
shoulder lost some roundness. The mirror kept the left shoulder's roundness on both sides.

6. Working safely on someone else's hands

What this gave us

Option 2: the full-resolution body, 318,734 faces, with an intact hood top, closed shorts and two matching shoulders,
on which every later build stands. And a different kind of collaboration from the one this part started with: by the
afternoon of 9 October the hands in Blender were doing the shaping, and the scripts were doing what hands cannot
(measuring, mirroring, matching tones to the value).

Welding a new head onto a body

8 and 9 October · A new head for Agent E, welded to the body so that face and neck read as one person · More than a dozen
named welds on two models, scored out of ten along the way, until W7 became the new benchmark for Agent E.

1. Why a new head

The face under the fringe could not be repainted (chapter 18): Meshy had painted the fringe into the forehead skin. A
second Meshy generation of Agent E came with a cleaner head, its own hair, and its own maps. Rather than repaint a
face, we transplanted one: her head and all her hair as one piece onto our body, cut at mid-neck. The hard part was
never the head. It was the 2 cm of neck where two different models have to become one surface.

2. First attempts, on the reduced model

The first transplants went onto M8x at game size. Each failure taught a constraint:

A bridged neck before recolouring: each new face reads its texture from wherever its corners landed. The fix was one neck-skin
texel for every bridge face.

The same method at full resolution (474,578 triangles) was so clearly better than the reduced versions that there was
nothing to compare, and we deleted them. That was the moment the rule became: welds are made at full resolution,
and reduced once, at the end. Two more full-resolution welds built on the step-4 body (n5a, n5b) were rejected, and
we set a rule that has held since: a failed model is deleted and cleared, never put on show.

3. W1 to W7

The real welds were made on Option 2 (chapter 21). Each was scored.

W6's wrinkles, measured. The head's neck was more wrinkled in the band just above the join, and we measured
why. The body's ring is jagged and slightly oval and off-centre; the head's is rounder. Stretching each point to its
partner gave neighbours different stretches.

Better, and still not right. A hand fix on W6 was tried and abandoned: nothing good came of it. The better route came
from the cause itself. The stretch only existed because the head's neck had been sized down and then stretched back
up, so it made more sense to compute the neck width that sizes it properly in the first place than to keep smoothing
the stretch. The neck width was solved, not tuned.

W7s became W7. Methods we considered and declined, for the record: matching vertex counts then bridging (the
bridge already joins 214 to 164), merge-by-distance everywhere (her fringe touches her chest, and merging everything
would glue the two together, where they must stay separate), a Boolean union (needs watertight shapes), and a
normals transfer (kept as a last polish only).

4. One skin tone

Her body was too pale beside her face, so we set the target for one skin tone: somewhere between the two, or the
face's own colour.

We moved the body toward the face, because the face carries identity (a face paint the night before had made her
look like a different person): a multiplier on 3.16 million body texels and 1.44 million graft texels. The tone came out a
95% match, close enough to call the tone itself solved. But the fix made a new fault: a dark band at her neck that read
as a choker. The fade across the join had left the seam row darker than both sides.

That table is after the fix. The rule it left: after any colour fade, measure the colour by height in 2 mm steps.

The final W7 took the other direction, the one later chosen for the choker variant: the body keeps its own tone, and the
head goes halfway toward it with a soft ceiling, so the face's bright channels do not clip.

W7 became the new benchmark for Agent E: the model the later builds are measured against.

5. The choker variant, and a blotch that was not paint

W7C is W7 with a black choker band from the new head. Its first versions moved the choker (24.5 mm higher; then
25% wider, 98% of it outside the neck), and then three faults came back at once: a face paler than the body (its red
channel had to rise 10.5% and clipped), 92 hair-red patches on the neck, and a choker top standing 11.5 mm off the
neck. Those three were fixed. The fourth was not: the neck between the choker and the head stayed blotchy, and we
wanted it one even colour.

The neck above the choker, lit: two tones in patches.

We flattened the colour (30,842 texels to one tone, then 37,653), replaced the stored normals on 4,035 faces,
smoothed the choker's top edge (spikes 19.6 mm to 0.6 mm). None of it changed how the neck looked, which was the
first sign that the fault was not in the colour at all. Then the screenshot that settled it:

The same neck with no colour at all, solid view: the marking is still there. Not paint, not roughness, not UVs. The mesh.

Fix after fix had missed, so we stopped fixing and stepped back. If the fault was in the mesh, more colour work would
never reach it, and the answer might be a different weld altogether. We set out the options:

The final band: cut from the original head on two fitted planes, sitting 2.5 mm outside the neck with its edges folded
in, moved 1 cm higher, with its own black material (painting it into the shared head texture would have blackened 119 of
W7's own neck faces).

What this gave us

W7, the benchmark. A neck join method that is now written down step by step (cut by shape, mask the chin, solve the
width, fade the tone, measure by height). And the strongest case yet for Rule One: the blotch that five fixes could not
find was obvious the moment a person looked at it with the colour switched off.

Game budget, KTX2 and skinning spikes

9 October, afternoon to midnight · W7 at 475,573 triangles taken to 47,557 without touching her face, rigged, compressed for
the graphics card and put in the game as v0.38 · The last reduction was done by hand.

1. The brief

The brief: a game-ready W7, with the face preserved and no holes in the body, allowed to run up to 50% over the usual
game budget for a first pass. We gave the first pass that headroom on purpose: it was better to see that nothing went
wrong at a generous size, and tighten afterwards, than to break her face or open holes chasing the final number at
once.

It was almost there: the hair held up apart from one or two skin-coloured blobs. We decided the next pass should give
slightly less to the face and less again to the hair. Hair does not need fine geometry to read well: even AAA games
render hair as a mass, and what sells it is the physics, so its triangles were better spent elsewhere.

2. Budgets by part, and a mask nobody intended

A second build cut the model in three passes, part by part:

Problem. The new build was botched: the bottom half of her face had turned dark red, so she looked as if she were
wearing a mask. A face is the one part that cannot regress, so rather than patch the new build we went back to the
previous W7 game, pixel for pixel.

Cause. The step that fixed skin-coloured blobs in the hair decided what was hair by position: head material, outside a
face box that ended at 1.50 m. The lower half of her face sat below 1.50 m, so it counted as hair and was recoloured.

Solution. The previous build was restored byte for byte. The rule: hair is defined by its texels, never as the head
minus a box, and every recolour step counts how many faces it touched inside the face and refuses to save unless
that count is zero.

3. The budget, set by eye

Measured on the restored build, then set part by part:

The hair blobs. In the reduced hair, big triangles stretch across skin-coloured texels while their centre still lands on
red. Three attempts: judging each face by its centre texel only; searching only near earlier strokes; and a skin test so
loose that hair highlights passed as skin. The fourth sampled each face at seven points and used a strict peach test.

The blobs: skin-coloured texels showing through where reduced hair triangles stretch across the paint.

Then a paint job by hand, in marker colours: red strokes where hair showed skin, black on the hoodie, skin on a leg
patch. The red strokes were reverted to the original hair pixels (6,340 texels) and the 211 hair faces under them given
real hair texture; 52 within 2 mm of the face skin were left alone. An apparent hole on her right shin, which no
measurement could find, turned out on a closer look to be not a hole at all but a black marking on one of the big
triangles; that is why the hole checks never saw it, and it was painted out by hand.

4. The last 7,854 triangles, by hand

A REDUCE SELECTED button with a ratio slider was added to the panel: select a region, reduce only that, and nothing
outside the selection or its border row changes. The reduction itself was made by hand, part by part:

The cuts went where nobody looks. Her back had never been strong in the original T8 body, because it was meant to
be covered, so it made sense to reduce it most rather than spend triangles on a surface that was not built to be seen;
the back hidden inside her hoodie lost many points for the same reason. Face, hair, hoodie, hands and shoulders were
untouched. No new holes: 1,990 open edges before and after. The two last saves, one with a repainted back, were
compared side by side under seven lighting setups (preview, studio, noon sun, back light, evening, night, flat game
light). Both held up in every light, and we chose the 22:57 save as the one to rig for the game.

5. The rig, and her shorter hair

W7 game went onto her existing Mixamo skeleton, with body weights copied from M8x's body side by side (her left
from the left half, her right from the right). Her new hair is much shorter than the old: it runs from 1.18 m (the upper
back) to her crown, where the old hair reached her waist. So only the top two links of the hair chain carry it: the crown
follows the head, the lower hair swings on the chain, and the front locks, which now end at her chin, follow the head
instead of the chest.

The first rig run put her 6 m from her skeleton and gave most of her body a finger bone: the saved file carried the
preview window's row offset on the object, and our script baked it into the mesh. The weight report caught it before
anything shipped (every point unweighted), and the rule since is to print an object's transform and bounds before
rigging it.