BODY_ASSEMBLY_ARCHITECTURE_BRIEF_2026-08-06.md

pipelines/BODY_ASSEMBLY_ARCHITECTURE_BRIEF_2026-08-06.md

THE BODY-ASSEMBLY ARCHITECTURE BRIEF — 2026-08-06

What this is. Josh's charter, verbatim: *"i dont know if chunks is a good idea or needs to be

created after or created first, merging might get messy, but please do your research on this for the

best route forward. we need to get this factory down so we can produce every asset"*

[docs/spine/DECISIONS_PENDING_JOSH.md L4481-4496]. The conditional body-chunks approval of the same

night is SUSPENDED pending this brief. This document answers the question the whole character factory

stamps from: how does a generated character body get assembled and dressed — across 12 protagonist

ages, companions, supporting cast, NPCs, and humanoid creatures.

Authority. PROPOSAL-TIER. This brief rules nothing. Canon, the CVD and Josh's rulings bind every

line of it. It is a decision brief built to the standing decision protocol — options, deep-dive,

adversarial review, a RECOMMENDATION and the strongest objection — and it goes to the director for the

eye-pass and then to Josh to ratify.

The honest register, held throughout. Nothing here upgrades any asset's tier. Every generated

character asset in this project is GREYBOX until its plates pass Josh's graded floor; the count of

Josh-graded-acceptable generated plates remains 0

[docs/pipeline_review/AAA_WORKFLOW_CORRESPONDENCE_2026-08-06.md L15-21] *(superseded 2026-08-10,

director-rows wave: the V4 body plates postdate this brief and are generated and Josh-approved —

"Yeah v4 is approved", BODY_V4_CARRY_SEVEN_AGE.json; the GREYBOX register above is unchanged)*.

---

DERIVATION

DERIVED FROM (canon and ruling):
  - docs/spine/DECISIONS_PENDING_JOSH.md, the ruling named "BODY CHUNKS SUSPENDED PENDING RESEARCH"
    (the charter), and the ruling named "IF-MODULAR CONDITIONS" (the five binding conditions any
    modular route must meet). NOTE ON POINTER FORM: DECISIONS is an append-only living file, so
    the rulings below are cited BY NAME -- the insertion-invariant pointer -- and the L-numbers
    that appear in this brief are read-aids at this commit, never the citation of record. That is
    gate 46's option A applied rather than another line-range citation minted.
  - DECISIONS L4518-4539 -- THE UNEQUIP FLOOR: the minimal underwear layer is the paper doll's
    lowest reachable state, "the anatomically-correct bare base is a FACTORY artifact
    (generation, fitting, physics, ROM) and never a player-visible state" -- with its
    equal-force CULTURAL COUNTERWEIGHT (the floor never sanitizes historical dress)
  - DECISIONS L4540-4562 -- BARE-IS-DEV-ONLY + THE SWAP SEMANTICS + EVERY-PASS-IMAGED
    ("the base bare layers are dev only ... the equipment will actually swap to the
    minimalistic underwear layer instead of the actual bare model. make sure every pass is
    being recorded and landing in our disk as an image as well so you can review the seams
    and proportions to make sure everything will join together as a 3D asset properly, then
    the layers can add ontop")
  - DECISIONS L4166-4181 -- THE EQUIPMENT-SCREEN MODEL ("Base body doesnt have garments or
    equipment. That layers on top. Also base body is fully textured. Think equipment screen.
    Think Diablo 4 and Witcher 3 and FF7R and baldurs gate 3 etc")
  - DECISIONS L4182-4204 -- THE UNDERWEAR RULING, which already names the mechanism:
    underwear "SUPPRESSES under gear (the engine-standard per-region body/underlayer masking)"
  - DECISIONS L4134-4149 -- THE BASE-PLUS-LAYERS PRINCIPLE ("ONE base body model; equipment =
    separate per-slot skeletal meshes layered on the same skeleton ... AGING = altering the base
    model via morph targets - the 12 age states live on one shared-topology mesh")
  - DECISIONS L4112-4133 -- THE AGING MODEL RATIFIED: 12 discrete age states, 7 through 18
  - DECISIONS L4422-4452 -- THE KEYSTONE AGING METHOD (7/11/14/18 first, largest jumps first)
    and L4453-4480 -- BARE-FIRST GENERATION
  - DECISIONS L4380-4421 -- JOSH GRADES THE 3D LIFT: the bare-base violation ruling
  - registries/T0_Equip_Slot_Registry [DRAFT v0.1]/Sheet1.csv -- THE RULED 16 paper-doll slots

DERIVED FROM (our own measured records):
  - Source/Humanity/Public/Core/HumanityGarmentComponent.h L10-26 (GAME repo) -- the shipped
    assembly mechanism and its own named gap: "NO HIDDEN-FACE APPLICATION ... UE has no cheap
    per-face hiding on a skeletal mesh at runtime"
  - build/3d/characters/CHAR_0001_LAYERED_STAGING_IMPORT_MANIFEST.json -- the merged-underwear
    architecture as built (later superseded), the stand-off table, and the 8,317-face hide list
  - build/3d/characters/build_bare_base.py + audit_bare_base_lineage.py -- the de-merge, and
    the luck it depended on
  - build/3d/characters/repair_recombine_winding.py -- the merge-introduced winding inversion
  - GAME:QA/bench/garment/recombine_seam_20260806T142936Z.json -- the 0.40 mm neck-seam bar
  - build/3d/characters/CHAR_0001_HEAD_AUTHORED_RECORD.json -- the seam silhouette ruler
  - build/3d/V2_ROUTING_RATIFIED.json L961 -- "two age states generated independently CANNOT be
    blended -- there is no vertex correspondence to blend along"
  - docs/pipeline_review/AAA_WORKFLOW_CORRESPONDENCE_2026-08-06.md section 3.4 -- the wrap cage
    as the binding constraint, with the AAA public record behind it
  - docs/pipeline_review/AAAAA_IMPROVEMENT_REGISTER_2026-08-06.md rows 19, 22, 34, 44, 57
  - docs/pipeline_review/tech_research/PIPE_CHARACTER_MODELS_2026-08-06.md sections 7 and 10 --
    the parametric-template landscape and the three-layer routing recommendation
  - build/3d/schema/anatomy_reference/HUMANOID.json -- the joint/ROM table the assembly is
    judged against; build/3d/schema/material_defaults.json -- the physical-property schema
  - GAME:QA/bench/creature_archetype_census.json -- the 187-row, 8-archetype creature census

FIRST-PARTY ENGINE EVIDENCE (read directly from the installed engine, not from the web):
  - UE 5.8.0, C:/Program Files/Epic Games/UE_5.8 -- SkinnedMeshComponent.h L2153-2190
    (HideBoneByName, ShowMaterialSection), SkinnedMeshComponent.cpp L4035-4083 (the hidden-
    material path), SkeletalMeshSceneProxy.cpp L217, L610, L701, L1139 (hidden section = skipped
    draw, no shadow), SkeletalMergingLibrary.h (the merge API surface),
    SkeletalMeshMerge.cpp (1,205 lines, ZERO occurrences of "morph" or "cloth")

NOT DERIVED (authored engineering judgment, and why it had no canon home):
  - The three-questions reframe in section 1, and OPTION E in section 3. Canon rules the base +
    layers + morph model and the 16 slots; it does not rule the GENERATION granularity of the
    bare body, which is the gap this brief fills. Every recommendation below is grounded in a
    measured record or a first-party API, never asserted.

---

0. THE HEADLINE — seven findings, and the first one dissolves most of the argument

1. "Chunks" is not one question, it is three, and they have different answers. *Generation*

granularity (is the bare body generated as separate parts?), *asset/runtime* granularity (is the

shipped body one skinned mesh or several components?), and *suppression* granularity (how is body

geometry hidden under gear?). The AAA titles Josh named answer them NO / ONE-ISH / PER-REGION —

they split the body into regions for hiding and swapping, and they never merge independently

authored geometry to make a body. Section 1. And the vocabulary is already on our side: in

Cyberpunk 2077's own format a *chunk* IS a submesh of one authored mesh with its own material,

hidden by chunkMask — *"You can only use chunkMasks to hide submeshes"* — which is exactly the

thing this brief recommends and the opposite of the thing Josh was worried about. Section 2.1.

2. Josh's merge-mess worry is not a hunch — we have already paid for it twice, measured. The

merged-underwear base had to be *de-merged*, and the de-merge only worked because a pre-garment

pass with byte-identical topology happened to still be on disk

[build_bare_base.py; audit_bare_base_lineage.py]. And our one real geometric recombine

introduced a winding inversion on 947 of 1,040 components, which baked a black AO atlas

(mean 0.030, 0.551 after the flip) before anyone noticed

[repair_recombine_winding.py]. Both defects were invisible until a downstream stage failed.

And the comparators pay it too: CDPR ships a dedicated mesh, t0_000_pma_base__full_seamfix,

whose only job is covering the joins between the body's component meshes; and Rockstar's own peds

ship with neck, leg and wrist seam defects that the community patches. Sections 2.1 and 2.3.

3. The masking model is not a proposal — Josh already ruled it, and half of it is already built.

The underwear ruling names *"the engine-standard per-region body/underlayer masking"*

[DECISIONS L4192-4196]; the garment lane already emits a per-face hide list owned by the layer

(8,317 of 21,154 base faces at cover ≥ 0.85, applied at equip and dropped at unequip)

[CHAR_0001_LAYERED_STAGING_IMPORT_MANIFEST.json /asset_2.../hidden_base_faces]; and the engine

already runs the leader-pose modular assembly [HumanityGarmentComponent.h L10-14].

The only missing link is the engine-side application of that list, and the component's own

header already names the two shipping forms [L17-21].

4. UE 5.8 gives us the suppression primitive for free, and it is per-region, not per-face —

ShowMaterialSection sets a per-component, per-LOD hidden-material flag, and the scene proxy then

*skips the draw and casts no shadow* for that section (verified in the installed engine source:

SkeletalMeshSceneProxy.cpp L217, L610, L701, L1139). Hiding is keyed on the material index,

so the base body must be authored as a partition into body-region sections. That partition is

the honest, shippable form of "body chunks". **And the engine's production-grade version of the

same idea is already on disk:** the Mutable plugin ships RemoveMeshBlocks, which removes body

geometry by UV layout block with an explicit face-cull strategy — so the partition must be

expressed in the cage's UV layout, not only in material slots. That is the one line of the spec

this research changed, and it costs nothing to do now and cannot be retrofitted cheaply. §4.4.

5. Runtime skeletal-mesh merging would destroy the ruled aging model. SkeletalMeshMerge.cpp is

1,205 lines and contains zero occurrences of "morph" or "cloth". Josh ruled that the 12 age

states *"live on one shared-topology mesh"* via morph targets [DECISIONS L4145-4148]. A route that

merges meshes at runtime or at cook throws the morph targets away — so merging is not merely messy,

it is incompatible with a ratified canon requirement.

6. The EVERY-PASS-IMAGED law re-prices the two routes, and it re-prices them apart. Every

generation, build and finishing pass on every body, chunk and layer must land on disk **as an

image beside its data**, so the director reviews seams and proportions on renders *before* parts

join as 3D — *"a pass without its image is un-DONE"* [DECISIONS L4540-4562]. Under a partition

the imaged-pass count is one per stage per age state. Under chunk-first it is **one per part

per stage, plus one per seam per revision, plus a joined-assembly render to prove the join** —

the law makes the modular column multiply rather than add, and it makes every seam revision a

*review* event and not just a compute event. Priced in section 3.2 and section 5.2b.

7. The binding constraint is unchanged and this brief does not move it. The shared-topology cage

still does not exist — the stack's one quad-retopo tool returned out_quads: 0

[AAA_WORKFLOW_CORRESPONDENCE §3.4; AAAAA_IMPROVEMENT_REGISTER row 34]. Every option below,

including chunk-first, needs correspondence to deliver 12 ages across 167 cast rows. **Chunk-first

does not route around the cage; it multiplies the number of cages needed.**

The one-line answer to Josh's question: chunks YES, merging NO. Ratify body chunks as a

partition of one mesh — real, separately-measurable, separately-hideable, separately-valued

anatomical regions that were never separate geometry — and ban geometric merging of independently

generated parts from the character factory. That keeps every one of his five if-modular conditions and

pays for none of the seam engineering, because a partition creates zero new seams.

---

1. THE THREE QUESTIONS HIDING INSIDE "CHUNKS"

The charter, the if-modular conditions, and the AAA comparators are all answering different questions.

Separating them is most of the work.

Josh's worry — *"merging might get messy"* — is entirely a Q1 worry, and it is correct. The

appeal of chunks — separately correct proportions, separate physical values, per-region damage — is

entirely a Q3 appeal, and it is also correct. The two are separable, and separating them is

the recommendation.

The distinction that carries the whole brief: a PARTITION is not an ASSEMBLY.

A partition takes one authored mesh and labels its faces into regions. The vertices at a region

boundary were already shared; nothing is welded, no normal is averaged across a join, no skin weight is

transferred, no UV island is stitched. The seam count of a partition is zero. An assembly takes

geometry that was generated independently and joins it — and every one of those five problems becomes

a per-asset engineering task. Every real cost Josh is worried about lives on the assembly side of that

line, and every benefit he is asking for lives on the partition side.

---

2. HOW THE NAMED TITLES ACTUALLY DO IT

Method and its limits, stated first. The public technical record for shipped character systems is

thin — studios publish art talks, not data models. The strongest available evidence is

reverse-engineered modding documentation, which is written by people who had to make the real

format work and is therefore precise about mechanism while being second-hand about intent. Every claim

below carries its source; where the evidence is community-derived rather than first-party it is marked

[MODDING-DERIVED] and its confidence is stated. Where the record is genuinely thin, this section

says so rather than filling the gap.

2.1 Cyberpunk 2077 — and the finding that reframes the whole question

In REDengine 4, the word "chunk" already means exactly what this brief recommends. CDPR's mesh

format calls a submesh a chunk: *"A mesh consists out of multiple parts"* and *"each submesh can have a

different material assigned"*; chunkMask is a per-appearance visibility control where *"unchecking an

entry will hide it, regardless of the assigned materials"*; and the constraint is explicit —

*"You can only use chunkMasks to hide submeshes."*

(https://wiki.redmodding.org/cyberpunk-2077-modding/for-mod-creators-theory/files-and-what-they-do/file-formats/3d-objects-.mesh-files/submeshes-materials-and-chunks)

[MODDING-DERIVED, high confidence — this is the format documentation the tooling is built from.]

And the body is a genuine hybrid, which is the second finding and the more useful one. CP2077's

player body is *both* split into separate component meshes and internally chunk-masked: torso

t0_000_pma_base__full / t0_000_pwa_base__full, separate left and right arms

(a0_000_pma_base_hq__l.mesh, a0_000_pma_base_hq__r.mesh), separate feet

(l0_000_pwa_base__cs_flat.mesh) — **plus a purpose-built seam-patch mesh shipped by CDPR,

t0_000_pma_base__full_seamfix.mesh, whose entire job is covering the joins at the arm and shoulder

junctions**

(https://wiki.redmodding.org/cyberpunk-2077-modding/for-mod-creators-theory/references-lists-and-overviews/cheat-sheet-body).

[MODDING-DERIVED, high confidence — these are asset paths, verifiable by extraction.]

That seamfix asset is the single most instructive artifact found in this whole research pass. A

CDPR-scale team, splitting a body across components, had to ship an *extra mesh whose only purpose is

hiding the joins*. It is Josh's *"merging might get messy"* worry, confirmed by the most technically

sophisticated comparator on the list, and paid for in shipped content.

Body-part visibility is driven from those meshes — *"you can use this information to show/hide parts

of the player body via chunkmasks"* (ibid.) — and clothing suppression is declared with **visual tags

in the .app file**: *"any visual tags that hide parts of the mesh must go into the .app file to take

effect"*, and *"with visual tags, you can force-show hair, hide an item in first person, or turn body

parts on and off"*, the mechanism being *"how e.g. your sunglasses disappear when you put on a

helmet"*

(https://wiki.redmodding.org/cyberpunk-2077-modding/modding-guides/items-equipment/influencing-other-items).

The tag family is anatomical and maps onto chunk indices — base-game hide_H1 (head), hide_F1

(eyes), hide_T1 (chest), hide_T2 (torso), hide_L1 (legs), hide_S1 (feet), hide_Hair,

hide_Genitals, with ArchiveXL adding hide_CollarBone, hide_UpperAbdomen, hide_LowerAbdomen,

hide_Torso (documented as chunks 0, 1, 2), hide_Arms, hide_Thighs, hide_Calves, hide_Ankles,

hide_Feet, hide_Legs (chunks 4, 5, 6, 7)

(https://github.com/CDPR-Modding-Documentation/Cyberpunk-Modding-Docs/blob/main/for-mod-creators/core-mods-explained/archivexl/archivexl-tags.md).

**So the base body carries roughly eight anatomical region submeshes and hiding a region clears those

bits** — which is, to within naming, the region partition this brief recommends.

Layering is handled by Garment Support, and its mechanism is worth recording because it is a

*third* answer beside hiding and merging: the garment mesh carries a blend shape literally named

GarmentSupport beside Basis — Basis is the natural silhouette, GarmentSupport a shrink-wrapped

version conformed to the body — and at runtime the engine morphs toward the support shape so an

under-layer tucks under an over-layer instead of clipping through it. Components are scored by

name prefix (s0=0, l0=10, t0=30, h0=40, s1=50, l1=60, t1=70, h1=100, h2=110,

t2=120) and higher scores squish lower ones

(https://wiki.redmodding.org/cyberpunk-2077-modding/for-mod-creators-theory/3d-modelling/garment-support-how-does-it-work).

Correction to a premise this lane was given: no source was found attributing garment support to

patch 2.0 — 2.0's clothing rework is documented as a *stats* change (armour moved to cyberware). Treat

"the 2.0 garment support system" as unverified.

The finding: the largest, most technically documented comparator uses "chunks" to mean *submeshes

of one authored mesh, each with its own material, hidden by a visibility mask*. It does not mean

independently generated parts joined together. Josh's instinct to call them chunks is right; the danger

he sensed is in the *other* meaning of the word — and where CP2077 *does* split across components, it

pays for it with a shipped seamfix mesh.

2.2 Baldur's Gate 3 — the shared cage and the mask slots, from Larian's own docs

Two mechanisms, and both map onto rulings we already have.

• Shared topology is an authoring RULE, not an optimisation. Larian's modding documentation states

that armour *"should have the same topology as the naked body, especially in regions that deform a

lot"*, with more leeway only where body parts will be hidden, and no leeway at all on skin-tight

armour *"where the body mesh cannot be hidden"*

(https://docs.baldursgate3.game/Creating_Armour, summarised via

https://bg3.wiki/wiki/Modding:Creating_Armor_Mods). That is the cage, stated as a content rule.

• Suppression is per-region and finer than per-section. BG3 uses Vertex Color Mask Slots —

tags added to meshes *"so the system understands what it needs to hide on other meshes"* — with

shaders carrying VertCut in their name using vertex colours to mask parts of a mesh. The published

examples are exactly our cases: *sleeves hidden when gloves are equipped*, *trousers hidden when

boots are equipped*, a boot cutting the part of the trouser it overlays — and, decisively for the

underwear ruling, *"VertexColorMaskSlots can be added to resources to hide specific body parts like

the panties and bra"* (same sources).

• And they measure garment stand-off the way we do. The docs give trouser and sleeve meshes a

thickness limit — always thinner than an *orange* limit, never sticking out *"unless marked with

green vertex color which will be hidden"* (ibid.) — which is a colour-coded version of our own

signed-clearance measurement (char_cloth_thickness.py).

• The mask slots are named body regions with fixed vertex-colour codes, declared in merged.lsf

as VertexColorMaskSlots nodes: Torso #013201 (used by most body armour), upperarm #014101,

hands #015F01, down to per-segment codes for the legs and feet, plus **Bra #01A001, Panties

#01AA01, Private_Parts #022902** and a Never Hide Hair slot for headwear; values are

case-sensitive (https://bg3.wiki/wiki/Modding:VertexColorMaskSlots). [MODDING-DERIVED, high

confidence.] **The underwear layer and the anatomy floor are literally named mask slots in a

shipped AAA RPG.**

• And the cost is named too, in the place we will pay it. BG3 has four body types crossed

with the playable races, and armour is authored per body type — which is why mods enumerate

which body types they support and why so many ship body-type-1 only

(https://bg3.wiki/wiki/Modding:Body_Models; https://www.nexusmods.com/baldursgate3/mods/23978).

Larian's own workflow also requires modders to import the matching **nude body as an in-scene

reference, fit against it, and match seams carefully against it to prevent gaps** — the bare

body as development substrate, stated as a rule (2.7).

The finding: BG3 ships the exact architecture this brief recommends, including the underwear layer

as a *maskable resource* rather than as merged base geometry — which is Josh's underwear ruling,

already shipped by the title he named. **Its dominant cost is the N-bodies × M-garments authoring

multiplier, which for us is not four body types but twelve age states** — the reason the age axis

must be a morph on one cage rather than twelve bodies.

2.3 GTA V / RAGE — the one genuine chunk-first shipping case, and why it works

RAGE does split the body. A ped is built from 12 component "drawable" slots — head, beard,

hair, torso, legs, hands, feet, accessories, undershirt, armour, decals and tops — each carrying

multiple drawable variations with their own textures, driven at runtime by

SET_PED_COMPONENT_VARIATION

(https://docs.fivem.net/docs/game-references/ped-models/;

http://gtaxscripting.blogspot.com/2016/04/gta-v-peds-component-and-props.html;

https://wiki.rage.mp/index.php?title=Player%3A%3AsetComponentVariation).

[MODDING-DERIVED, high confidence on the slot roster; the runtime natives are first-party-documented.]

**Steelmanned honestly: this is a shipped, enormous-scale, chunk-first character system, and it

works.** But the conditions under which it works are the ones we do not have:

• Every drawable is hand-authored against one fixed template and skeleton, so boundary rings match

by construction. The seams are *authored*, never *solved*. **[INDUSTRY-GENERAL — I could not find a

first-party statement of RAGE's boundary-matching discipline, and this inference is stated as an

inference.]**

• The split is at clothing boundaries, not through deforming anatomy — torso/legs/feet are also

where garments end, which is why the seams sit under cloth.

• No morph-based aging. GTA peds do not need twelve age states of one identity blending along a

shared vertex order, which is the requirement that makes correspondence non-negotiable for us

[DECISIONS L4145-4148].

And it visibly does not fully work, in the shipped game. The widely-used community "Ped Fixes"

packs exist specifically to correct neck-seam normals, leg/foot-seam normals, wrist gaps

and waist weighting on Rockstar's own assets

(https://www.gta5-mods.com/player/ped-fix-pack). That is direct, shipped evidence that a split-body

slot system without runtime seam correction ships with seam defects — from the studio with the

largest character-content budget in the industry.

Its costs are also documented and they are the costs of *content*, not of frames: three LODs per

drawable, ~3,600 verts typical per component, hard slot ceilings (128 items per drawable type per

gender as the compatible norm, 255 the format wall), and metadata scarcity — roughly 100 .ymt slots

per gender total, with recent builds reporting three or four free

(https://docs.gta.clothing/game-mechanics/game-limits-and-crashes;

https://github.com/Sollumz/wiki/blob/main/tutorials/basic-clothes-editing.md).

The finding: chunk-first is viable when parts are authored to a template by hand. It is a

different proposition when parts are generated by a model that emits an unstructured surface with

no correspondence between runs [V2_ROUTING_RATIFIED.json L961]. GTA is evidence *for* split bodies

and *not* evidence for merging generated parts — and even done by hand, at Rockstar's budget, the

seams are a known, community-patched defect.

2.4 The Witcher 3 — same lineage, thinner record

REDengine 3 uses the same submesh-chunk vocabulary — character-editing guides work from a per-mesh

*"chunk list"* whose numbering shifts between game versions — and a head is itself several meshes

(head.w2mesh, an optional eye/lash/teeth/tongue mesh, an optional beard/brow haircard mesh), with

armour swapped by pointing appearances at .w2ent entities rather than at meshes

(https://www.nexusmods.com/witcher3/mods/5458; https://www.nexusmods.com/witcher3/mods/5363).

[MODDING-DERIVED, medium confidence — forum-grade rather than format documentation.] The shape of the

system matches 2.1: one body, submesh chunks with materials, gear as separate entities.

2.5 Diablo 4 — thin public record, stated as thin

D4 exposes five armour slots (helm, chest, gloves, legs, boots) which together cover head to toe,

plus a wardrobe/transmog layer over them

(https://diablo4.wiki.fextralife.com/Armor; https://diablo4.wiki.fextralife.com/Wardrobe). The one

technically-worded primary source is Blizzard's June 2021 quarterly update, which describes the system

as built for *"hundreds of componentized armor sets, different body types, dozens of unique

personas"*, states that every armour set is authored for two body types, and describes per-part

dyeing driven by material-type metadata (leather/fabric/metal)

(https://news.blizzard.com/en-gb/article/23665024/diablo-iv-quarterly-updatejune-2021).

No public technical account of D4's body-suppression mechanism was found — no GDC talk, no

developer blog, no reverse-engineering documentation of the appearance data model — and this brief

does not infer one. D4 is cited in Josh's ruling as a *player-facing* reference (the equipment

screen's empty state) and that is the claim it supports.

The documented Blizzard-lineage comparator, offered in its place and marked as a substitution:

World of Warcraft's M2 format is the canonical, fully documented *"one model containing every variant,

with a visibility bitfield"* design. A character model carries every hairstyle and armour-bulk variant

as geosets (submeshes), and rendering a look means enabling or disabling geosets; item display

data drives it via geosetGroup entries — gloves address the 401 group, boots 501, cape 1501 — and

some geoset IDs are explicitly marked *does not exist* so the game can select nothing in a group,

which is the explicit "hide this body region" state (https://wowdev.wiki/M2/.skin;

https://wowdev.wiki/DB/ItemDisplayInfo). **That is the partition model, twenty years old, at the

largest content scale in the genre.**

2.6 What is common across all of them

Not one of them merges independently produced geometry to make a body. Every one suppresses or

swaps at a boundary decided at authoring time. That is the industry answer to Josh's question and it

is unanimous on the only point he was worried about — and the two comparators that *do* split the body

across separate meshes are also the two with documented seam defects in the shipped product.

2.7 The bare body: dev-only, verified — and one honest divergence

Josh's ruling asks this section to verify that dev-time bare bodies with player-facing floors is *"the

standard for dev for games like baldurs gate 3 and diablo 4 and witcher 3 and cyberpunk 2077"*

[DECISIONS L4540-4552]. **The dev half verifies. The ship half diverges, and reporting that honestly

makes our position stronger rather than weaker.**

• DEV SIDE — verified, and it is unanimous. Every comparator with a published data model builds on

a complete base body and dresses it in layers: BG3 requires armour to share the *naked body's*

topology and marks which body regions a piece hides (2.2); CP2077 names the base body meshes and

hides parts of them under garments (2.1). A complete, correct, dev-time bare body is exactly the

substrate the masking model requires — you cannot mask what you did not build. This is the

clause Josh's cultural counterweight depends on: minimal-coverage historical dress leaves the

substrate visible, so it has to be right everywhere [DECISIONS L4197-4201].

• SHIP SIDE — divergent, and two of the four go further than we will. BG3 equips undergarments by

default but they are ordinary equippable items the player can remove, and the community's standing

advice for a nude playthrough is simply to unequip them

(https://steamcommunity.com/sharedfiles/filedetails/?id=3017138707). Cyberpunk 2077 ships genital

customisation at character creation and a Nudity Censor option in the gameplay settings; with the

censor on, *the character wears clothes in the customizer* and private areas are covered

(https://www.thegamer.com/cyberpunk-2077-nudity-toggle/;

https://screenrant.com/turn-off-nudity-cyberpunk-2077/). D4 and W3 expose no nude player state in

normal play.

• THE HONEST READ. *"Players never reach the bare base"* is our house rule, ruled by Josh

[DECISIONS L4522-4530], and it sits above BG3's and CP2077's floor rather than copying it. It

should be presented that way. What the comparators do verify is the two things the ruling actually

depends on: (a) the bare complete body is a development substrate in every one of them, and

(b) the floor, where a title has one, is implemented by covering, not by deleting geometry —

CP2077's censor puts clothing on the character rather than editing the mesh, which is precisely the

swap semantics Josh ruled [DECISIONS L4553-4556].

One consequence worth naming. Because our floor is stricter than two comparators', the underwear

layer is not an optional cosmetic — it is a **shipping-critical asset in every slot configuration and

at every one of the 12 ages**, and it must itself be suppressible under tight gear (the underwear

ruling's own reason for existing). BG3 already proves that is doable with the same mask mechanism

(2.2), which is why stage 11a is half a tooling-day rather than a new subsystem.

---

3. THE OPTION SPACE

Five options, each steelmanned, each with the place it breaks named on evidence rather than on

preference.

3.1 OPTION A — UNIFIED MESH + PER-REGION SUPPRESSION (the CP2077 / BG3 / WoW standard)

*Named for the three comparators where the mechanism is documented. D4 and W3 are consistent with it

and neither is evidence for it — see 2.4 and 2.5.*

How it works. One complete bare body mesh per character (per age state, or one mesh with 12 morph

targets). Gear is a set of separately skinned meshes bound to the same skeleton, following the body's

pose via SetLeaderPoseComponent. Under gear, body geometry is not deleted or merged away — it is

suppressed, by hiding the body regions the garment fully covers.

What it costs per asset at factory scale. One geometry lift, one retopo/cage conform, one UV set,

one texture set, one skin bind per character; one mesh + one fit measurement per garment. Gear

authoring is decoupled from body authoring, which is what makes a 16-slot paper doll tractable.

Seams. Zero new seams on the body. The only seam in the pipeline is the head↔body join, which we

already own and already measure (section 4.3).

Skinning. One bind, on the whole body, where the facing control is well-posed. Our own record

proves the value of that: binding a *partial* mesh alone hard-failed the facing control on the

chest piece — derived yaw 0, best measured yaw 180 — because a torso-only mesh has no legs, head or

feet to constrain the fit [bl_split_skinned_pieces.py docstring]. That control is the one guard

against a silently mirrored character; a route that has to disable it for partial meshes is a route

that ships mirrored characters.

LOD. Section boundaries must survive decimation, because the hide granularity is the material

index per LOD. This is a real requirement and we do not meet it today (section 6, stage 8).

Aging morphs. Perfect fit: 12 morph targets on one cage is exactly the ruled model

[DECISIONS L4145-4148].

Where it breaks. (a) It needs the cage, which does not exist. (b) Suppression granularity is

limited by how finely the body is partitioned — a garment that covers 60% of a region either leaves

the region visible (poke-through risk) or hides it (a hole). The mitigation is the same as every

shipped title's: partition finely enough, and keep a stand-off band at every hem — which our hide list

already does deliberately, thresholding at cover ≥ 0.85 rather than 0.5 precisely so *"the

two-millimetre band under each hem keeps its skin"*

[CHAR_0001_LAYERED_STAGING_IMPORT_MANIFEST.json hidden_base_faces._why_085_and_not_05].

(c) Each hideable region is its own material slot, therefore its own draw call.

3.2 OPTION B — CHUNK-FIRST (parts generated separately, then merged)

Steelman, and it is a real one. Three genuine advantages, none of them imaginary:

• Detail budget. A plate that has to show a whole body at 1344² spends most of its pixels on

nothing. Generating a head from a head plate and a hand from a hand plate puts every pixel where the

detail is. This is the strongest argument for chunks and it should not be waved away — it is exactly

why our own face lane pivoted to a head-only lift in the first place.

• Parallelism. Parts generate independently across GPU slots.
• Per-region truth. Each part is separately proportioned, separately valued, separately judged —

which is precisely what Josh's if-modular conditions ask for.

What it costs per asset at factory scale, honestly. Per character *per age state*: N part lifts +

N part finishes + (N−1) seam constructions + (N−1) seam verifications + one whole-assembly ROM pass +

one re-UV of the assembly. With the ruled 12 ages and even a modest 6-part split, that is **12 × 5 = 60

seam constructions per character**, each of which is a named engineering target under the if-modular

conditions. Against 167 cast rows [AAAAA_IMPROVEMENT_REGISTER row 44] the arithmetic stops being

about quality and starts being about whether the factory can run at all.

And under EVERY-PASS-IMAGED the cost is not the compute, it is the REVIEW. Every pass on every

body, chunk and layer lands as an image and a pass without its image is un-DONE

[DECISIONS L4540-4562]. So chunk-first's imaged-pass count per character per age is

*(parts × stages) + (seams × 1 seam-render) + 1 joined-assembly render*, against a partition's

*stages + 1*. At a 6-part split and the twelve stages of section 6, that is roughly **72 + 5 + 1 = 78

imaged passes per age state, ×12 ages = ~936 per character, against a partition's ~13 per age

state, ×12 = ~156**. Six times the renders is six times the director's eye, and the director eye-pass

is the scarcest resource in this project by the DIRECTOR EYE-PASS LAW [DECISIONS L4413-4418]. **That

is the honest headline cost of chunk-first, and it is a throughput cost, not a quality cost** — which

matters because throughput is the reason the charter was written.

Where it breaks — and this is measured on our own assets, not argued.

1. The parts have no correspondence, so the boundary rings cannot match. Our geometry route emits

an unstructured iso-surface with no landmark correspondence between runs

[V2_ROUTING_RATIFIED.json L961]. Two independently generated parts therefore share no boundary

vertices, no vertex order, no UV frame and no skin weights. Every join is a bespoke weld.

2. We have already measured what a single merge costs. The one geometric recombine in this

project introduced an inward winding inversion on 947 of 1,040 components, detected only when an

AO bake of an unoccluded group returned a black atlas (mean 0.030; 0.551 after the flip); the bare

base going in was wound outward (+0.037376 m³) and the recombine's output came out inward

(−0.030967 m³) [repair_recombine_winding.py docstring]. **The merge introduced the defect; it was

not inherited.** One seam, one silent corruption, caught by a second instrument by luck.

3. The seam we DO have passes only because it is CONSTRUCTED, not merged. The neck join works

because the sleeve is *derived from the body's own densely sampled neck surface* and its last two

rings turn inward and terminate inside the body, so the transition is a surface crossing and

never a rim [CHAR_0001_HEAD_AUTHORED_RECORD.json /geometry/seam/method]. That is a

purpose-built join between a generated part and a body that was already there — it is not a

general part-to-part merge, and it does not generalise to shoulder, hip, wrist and knee joins

between two parts that are both generated.

4. The verification does not survive re-authoring. When the head topology changed, the record's

own read 3 (did the recombine re-author the face?) became NOT APPLICABLE — *"the two assemblies

are not vertex-comparable: (95855, 3) vs (110840, 3)"*

[GAME:QA/bench/garment/recombine_seam_20260806T142936Z.json read_3_head_to_head]. Chunk-first

makes that class of un-answerable question the normal case: every part revision invalidates every

seam claim that touched it.

5. The de-merge lesson. When the merged-underwear base had to be un-merged, it was only possible

because a pre-garment pass with an exactly shared topology still existed on disk — pass1 and pass2

at 359,742 verts / 120,000 tris each, differing on 43.04% of vertices at a median 6.47 mm — so

the recovery was a *substitution* rather than a rebuild [audit_bare_base_lineage.py;

build_bare_base.py]. The first audit of the same question got it wrong, measured the wrong

candidate, and concluded no de-merge was available. **A merge is a one-way door unless the parts

survive with their correspondence intact** — which is exactly Josh's third if-modular condition,

and it is the condition that makes chunk-first expensive rather than the condition that makes it

safe.

6. It multiplies the binding constraint. Chunk-first still needs correspondence for the ruled 12

ages. It does not need *one* cage — it needs one per part, plus a rule that keeps the parts'

boundary rings in correspondence across all 12 age morphs. That is strictly harder than the

single-cage problem, not a way around it.

Verdict on B: the advantages are real and the costs are measured, and the costs are not close.

Every advantage of B is obtainable inside A (section 3.5) without a single new seam.

3.3 OPTION C — THE HYBRID WE PARTIALLY RUN (authored body + generated head at a constructed seam)

How it works, because it is what ships today. An authored/parametric base body, a plate-conditioned

generated head, recombined at the neck via a constructed sleeve, plus fitted garment meshes. This is

the shipped default: with no cvars supplied the engine assembles

/Game/Meshes/Characters/SK_CHAR_0001_CHILD carrying the arrival outfit

[CHAR_0001_HEAD_AUTHORED_RECORD.json /body_half].

It works, and its numbers are good. The seam's silhouette ruler reads a maximum scanline width step

of 0.0771 cm across the crossing band against the body's own worst step over the same band of

0.0771 cm — the assembly exceeds the body by 0.0 cm, with a positive control at the waist reading

10.8388 mm so the ruler is demonstrably not reading zeros

[CHAR_0001_HEAD_AUTHORED_RECORD.json /check_render/seam_silhouette_ruler]. The 0.40 mm figure the

charter names is the cut-plane displacement: max 0.3993 mm claimed, re-derived at mean 0.5067 mm,

median 0.4814 mm, p95 0.859 mm over 33,419 points in the 104-108 cm band

[GAME:QA/bench/garment/recombine_seam_20260806T142936Z.json].

Where it breaks. It gives no correspondence, so it cannot deliver the ruled 12-age morph model; it

requires a fresh recombine per age state; and its verification is fragile to re-authoring (3.2 point

4). It is the right bridge and the wrong destination — and this brief keeps it alive as the

bridge (section 6.1).

3.4 OPTION D — WHAT THE FIELD DOES BETTER

Three real off-the-shelf answers were checked, and each is partially adoptable:

• MetaHuman "Creator From Custom Mesh" takes sculpts, scans or AI-generated meshes *"of any

topology"* and returns standard MetaHuman topology in the A pose — *"which is precisely the conform

operation our route is missing, offered as a product"* [AAA_WORKFLOW_CORRESPONDENCE §3.4]. It is

blocked for the child band: 0 of 30 live constraints is age, all 18 archetypes are adult, and

proportion misses the canon child (6.62-7.35 head-units measured against the canon 6.567)

[docs/proposals/METAHUMAN_ROUTE_EVIDENCE.md §3]. Register row 19 already takes it for the ADULT

and ADOLESCENT bands and leaves the child on our own solve — that split stands and this brief adopts

it unchanged.

• **MetaHuman ALSO ships a body-region hiding mechanism, and it is worth copying even where the rest

of MetaHuman is blocked. The Body Hidden Face Map** is a greyscale texture painted on the

MetaHuman body's UV map — *white = show, black = hide* — assigned on the wardrobe asset, and at

assembly time the mapped faces are removed from the body mesh, which Epic says reduces clipping

and *"also makes the MetaHuman more efficient"*

(https://dev.epicgames.com/documentation/unreal-engine/testing-and-setup-in-metahuman-creator).

Two things follow: (a) it is another vote for expressing the region partition in UV space

(§4.4), and (b) it is bake-time only, with the documented limitation *"we are unable to hide

faces on the head mesh at this time"* — so a runtime equip/unequip still needs

ShowMaterialSection or Mutable. Plan for both paths, as §4.4 says.

• R3DS / Faceform Wrap is the industry's cage mechanism and its framing is the one to copy: the

wrap is a recipe applied to an unlimited number of subsequent subjects, and identically-topologised

wraps *"naturally become blendshapes of each other"* [AAA_WORKFLOW_CORRESPONDENCE §3.4]. **And it

is genuinely batchable:** WrapCmd.exe / WrapCmd.sh takes `compute <project.wrap> -s -e -f

"1,5,10-20" -m <threads>`, returns pipeline-usable exit codes (0 success, 1 bad args, 2 compute

failure, 3 licence failure, 4 project load failure), supports #-token output sequences and

distributed execution via R3DS Rush/Node, at Indie $570 perpetual under $100K revenue

(https://docs.faceform.com/Wrap/CommandLineInterface/CommandLineInterface.html;

https://docs.faceform.com/Wrap/BatchProcessing/BatchProcessing.html; https://faceform.com/wraporiginal/).

The honest ceiling, and it lands squarely on our case: non-rigid ICP is proximity-driven, so the

fix for large proportion deltas is user-supplied landmarks and Control Points Weight — and Faceform's

own automatic facial detector is documented as *"usually not very accurate."* **Child-versus-adult

proportion is precisely the delta where wrap-without-landmarks breaks.** Hands, eye and mouth

interiors (Wrap ships Free Polygons to exclude them), hair and clothing are the other named

failure classes.

• The Apache/CC0 parametric bodies — and the numbers are now corroborated. Anny (NAVER Labs

Europe, arXiv 2511.03589, https://github.com/naver/anny) is **13,380 vertices / 13,378 quad faces —

exactly the MakeHuman basemesh — with a 163-bone** default rig, Mixamo-style rig support, an

interpretable phenotype parameter space (age, gender, height, weight, muscle) rather than PCA betas,

an age axis calibrated to WHO population statistics with a bijective map to chronological years,

and measured fit of 2.4 mm on adult scans and 2.7 mm on children. Licence: **Apache-2.0 for code

and model, MakeHuman/MPFB2 assets CC0**, with the SMPL-X topology variant flagged

non-commercial — avoid that one leg and it is clean.

This closes an item PIPE_CHARACTER_MODELS §11 recorded as owed, and corrects it: that survey

carried a lane-reported, uncorroborated *"13,718 v / 13,710 quads / 163 bones"*. The bone count

holds; the vertex and quad counts were wrong and the corrected figures are 13,380 / 13,378.

A parametric body is a cage that arrives pre-built, which is the cheapest possible answer to the

binding constraint — and the research's own cross-cutting conclusion is the same one: **production

increasingly avoids retopo-to-cage by generating in cage space** (MetaHuman, CC4, Daz, SMPL, Anny

are all "every character is already the same topology by construction"), and treats wrap as the

ingestion path for external or scanned assets, not the primary authoring path.

One hard confirmation from the same pass, because it closes the door on the alternative:

image-to-3D generators categorically cannot produce consistent topology across generations — vertex

count, ordering and connectivity are emergent properties of the extracted isosurface, and TRELLIS

(FlexiCubes) and Hunyuan3D (octree resolution 16-512 and a separate target face count) both expose

that directly. The one exception found is TOPOS, heads only, on a fixed 24,049-vertex MetaHuman

reference topology with cross-generation vertex correspondence — and its licence is unstated

(https://arxiv.org/html/2605.14594). You cannot build a morph cage out of generated meshes; that

is not a tuning problem, it is what the output shape is.

3.5 OPTION E — ONE CAGE, PARTITIONED ◀ THE RECOMMENDATION

How it works. Option A, with "chunks" ratified in the only form that costs nothing and delivers

everything Josh asked for:

• ONE bare body mesh per character, on a shared-topology cage, carrying the 12 age states as morph

targets. Never merged from independently generated parts.

• PARTITIONED into anatomical body regions — a face-set labelling of that one mesh, each region a

real anatomical unit, each with its own material slot so ShowMaterialSection can hide it

per-instance, per-LOD.

• Each region carries its own record: measured proportions against the anatomy reference, its own

physical values (density, mass, hardness, fragility, flexibility, failure semantics), its own texel

budget, its own hide-mask membership. These are the "chunks" — separately correct, separately

valued, separately damageable, separately hideable.

• Gear is separate skinned meshes on the same skeleton via leader pose (already shipping), each

piece declaring the regions it suppresses.

• Detail is bought per region by targeted plates and bakes onto the cage, not by generating parts

separately. That is how B's one real advantage is captured without B's seams.

What it costs. The cage stage (which every option needs) plus a region-partition stage (a labelling

pass, cheap) plus a region-record emitter (cheap) plus LOD section preservation (a constraint on an

existing stage) plus the engine-side suppression call (small, and the header already specifies it).

What it does NOT cost. Zero seam constructions. Zero seam verifications. Zero weld repairs. Zero

winding-inversion classes. Zero per-part re-UV. Zero facing-control disablement.

---

4. OUR OWN RECORDS — what is already built, and what merging already cost us

4.1 Already built, and it is more than the discussion assumes

4.2 What merging already cost us — twice, measured

Cost one: the merged-underwear base had to be un-merged. Josh's ruling that the base body is the

bare body [DECISIONS L4189-4204] made the shipped merged base a legacy asset. Recovery was possible

only because pass1 and pass2 existed on disk sharing an exact topology (359,742 verts / 120,000 tris

each, differing on 43.04% of vertices at median 6.47 mm, max 24.53 mm), which let each low-poly vertex

be re-evaluated on pass1 through the same triangle and barycentrics — *"pass1 is this body without its

cloth, vertex for vertex"* [build_bare_base.py docstring]. **The first audit of the same question got

the answer wrong**, compared the shipped base against base_high.glb (a different build entirely —

97.6% of its vertices moved, median 27.0 mm), and concluded no de-merge was available

[audit_bare_base_lineage.py docstring]. Two lessons, both directly on Josh's question: a merge is

reversible only when the pre-merge parts survive with correspondence intact, and a merge's

reversibility is easy to mis-measure.

Cost two: the one geometric recombine silently inverted its winding. 947 of 1,040 components wound

inward; an AO bake of the body group with nothing to occlude it returned a black atlas (mean 0.030,

0.551 after the flip); the input bare base measured +0.037376 m³ and the recombine's output −0.030967

m³, so *"the inversion is introduced by the recombine, not inherited from the body"*

[repair_recombine_winding.py docstring]. The repair had to run per group across eleven groups (body,

head, two ears, two eyes, two corneas, scalp, hair, lashes) because a cornea legitimately reads

negative and open surfaces have no signed volume at all — **which is itself the point: a merged

assembly's correctness is not a single number, it is a per-part audit that has to be re-derived every

time the assembly changes.**

4.3 The seam bar, stated precisely, because the charter names it

The 0.40 mm precedent is a displacement claim, not a gap claim: *"the body the head attaches to

moves by 0.40 mm at the cut plane"* (max_abs_delta 0.3993 mm), re-derived on the artifacts as mean

0.5067 / median 0.4814 / p95 0.859 / max 1.6984 mm over 33,419 points in the 104-108 cm band, with a

positive control at the waist reading max 10.8388 mm against a 3.0 mm floor so a zero cannot be a

broken instrument [recombine_seam_20260806T142936Z.json]. The visible-quality claim is separate and

stronger: the assembly's silhouette step exceeds the body's own worst step over the same band by

0.0 cm [CHAR_0001_HEAD_AUTHORED_RECORD.json /check_render/seam_silhouette_ruler].

**That is the bar class for any seam this factory ships, and it is the reason to have as few seams as

possible.** It took a purpose-built sleeve derived from the body's own surface, a dense 2.5 M-point

sample, an angle-weighted ring integral, a silhouette ruler, a positive control, and a withheld read

to clear ONE seam. Multiplying that by (parts − 1) × 12 ages × 167 cast rows is the honest cost model

for chunk-first.

4.4 THE ENGINE MENU IN UE 5.8 — read out of the installed engine, not off the web

Every claim in this subsection was verified against C:/Program Files/Epic Games/UE_5.8, the engine

this project ships on (5.8.0, BuildId 55116800). Where a research lane's web-sourced claim disagreed

with the install, the install wins and the disagreement is recorded.

The Mutable finding, and the correction that comes with it. Epic's own modular-character

documentation still describes only Leader Pose / Copy Pose / Merge and never mentions Mutable, so a

lane reading the canonical page gets legacy guidance. Mutable's Remove Mesh Blocks node removes body

geometry by UV layout block at instance-build time, with an explicit face-cull strategy — first-party

verified in the header above. That changes one line of our spec: the region partition must be

expressed in the cage's UV layout, not only as material slots, because the UV-block partition is

the input Mutable's removal path consumes and it is an authoring-time decision that cannot be

retrofitted cheaply. Doing it that way costs nothing extra now and keeps both suppression paths open:

ShowMaterialSection for the cheap per-instance hide today, Mutable's block removal for

build-time geometry removal and its mesh/texture merging later.

**AND THE CORRECTION, recorded because it is exactly the class of claim this repo does not take on

trust:** a research lane reported, from Epic's 5.8 release notes, that Mutable *"reached production

status in UE 5.8."* Our installed 5.8.0 disagrees. Mutable.uplugin reads `"VersionName":

"1.8.0", "IsExperimentalVersion": false, "IsBetaVersion": true, **"EnabledByDefault":

false`**. So on the engine we actually ship on, Mutable is a beta plugin that is off by default. That

does not disqualify it — beta plugins are adoptable and the nodes are real — but any plan that treats

it as production must say so against the install, and the plugin has to be enabled deliberately.

Two more engine-side cautions worth carrying, both material to a multi-component character:

• Leader pose saves animation evaluation, not draw calls. Epic's own worked example is 50

characters × 3 components = 150 draw calls unmerged against 50 merged

(https://dev.epicgames.com/documentation/en-us/unreal-engine/working-with-modular-characters-in-unreal-engine).

Our assembly is already multi-component for gear; the partition adds sections to the body on top of

that. This is the arithmetic behind the second objection in 5.4.

• Multi-component characters desync at LOD borders. Known engine issues UE-87501 and UE-191796

cover bone caches not updating when bone counts differ between LODs, with distance-based follower

desync reported in the field. The mitigation is ULODSyncComponent, which forces every component to

switch LOD together — and MetaHuman ships it by default across face, hair, torso, legs and feet

(https://dev.epicgames.com/documentation/metahuman/lodsync-component-for-unreal-engine). Our

assembly has no LOD sync today. That is a real, named, currently-unowned defect and it is added

to section 8.

---

5. THE RECOMMENDATION

**RATIFY OPTION E — ONE CAGE, PARTITIONED. Body chunks are approved as a PARTITION of one bare body

mesh, never as an assembly of independently generated parts. Geometric merging is banned from the

character factory, with one named exception (5.3).**

5.1 Why this and not the alternatives

1. It is the only option that satisfies a ruling we already have. The 12 age states *"live on one

shared-topology mesh"* [DECISIONS L4145-4148]. Independently generated parts have no correspondence

[V2_ROUTING_RATIFIED.json L961], and runtime merging discards morph targets entirely

(SkeletalMeshMerge.cpp, zero morph references). Chunk-first and merge-at-runtime are both

*incompatible with ratified canon*, not merely more expensive.

2. It is the mechanism Josh already named. *"the engine-standard per-region body/underlayer

masking"* [DECISIONS L4192-4196] is per-region section hiding. This brief is largely a

specification of a ruling that already exists.

3. It keeps every if-modular condition and pays for almost none of them (section 5.2).

4. The engine primitive is already there and costs less than nothing at runtime — a hidden section

skips its draw and casts no shadow (SkeletalMeshSceneProxy.cpp L217, L610, L701, L1139), so

suppression *reduces* cost exactly where gear covers the body.

5. It preserves the one control that stops a mirrored character shipping. The whole-body facing

control is well-posed only on a whole body [bl_split_skinned_pieces.py].

6. It matches how the named titles ship (section 2), and it matches the AAA cage finding this repo

reached independently twice [AAA_WORKFLOW_CORRESPONDENCE §3.4; AAAAA_IMPROVEMENT_REGISTER row 34].

5.2 Josh's five if-modular conditions, mapped

Recorded per the charter addendum. Under Option E four of the five are satisfied *by construction*,

and the fifth is genuinely new work that this spec schedules.

The honest line on cost: meeting these conditions under chunk-first would cost the same five

items PLUS (parts − 1) seam constructions and verifications per character per age, PLUS a

correspondence rule holding the boundary rings stable across 12 morphs, PLUS the re-derivation of

every seam claim whenever any part is re-authored. Under Option E the same five conditions cost

three tooling-days and a pass that was already chartered.

5.2b The three later rulings, mapped — bare-is-dev-only, the swap, and every-pass-imaged

One honest note on the imaging law's own trap, carried from our records so it is not re-learned:

an A/B is only an A/B when both arms are re-rendered by the instrument doing the comparing —

inheriting one arm's frames from another lane's evidence directory is a confound, not a shortcut

[PIPE_CHARACTER_MODELS_2026-08-06.md §2.1] — and a flat-albedo instrument cannot read an untextured

mesh at all, which once produced four blank frames that looked like a broken mesh [ibid.]. Under

EVERY-PASS-IMAGED those become factory-scale rules: the images are now the review surface, so a stage

that emits its picture on a different instrument than the stage before it has emitted **a comparison

nobody can make**. Each stage's image output below therefore names the instrument, not just the

picture.

5.3 The one exception, named so it is not a loophole

The head↔body recombine stays live as the bridge while the cage is built, because the age-7

keystone and the slice must not stall behind a new stage. It keeps its full instrument, its positive

control and the 0.40 mm bar class. It retires the moment the cage covers the head, and no second

seam class is opened in the meantime.

5.4 THE STRONGEST OBJECTION

**This recommendation makes the entire character factory wait on the one stage that has never produced

a single output.** AutoRemesher returned remesh_used: false, out_quads: 0, and the finished asset

fell back to a cleaned triangle mesh [CHAR_0001_FACE_finish.json]. Option E is a specification whose

first stage is the project's measured, twice-independently-confirmed binding constraint — while

chunk-first, whatever its seam costs, could stamp bodies next week on tools that already run today

and have already produced a shipped default. A brief that recommends the elegant architecture and

thereby idles the factory has chosen badly, and Josh's charter explicitly names throughput as the

reason for the question: *"we need to get this factory down so we can produce every asset."*

The answer, and it is a real answer rather than a reassurance, in three parts.

1. Chunk-first does not actually route around the constraint — it multiplies it. The ruled 12-age

model needs vertex correspondence [V2_ROUTING_RATIFIED.json L961]. Chunk-first needs that

correspondence *per part*, plus boundary-ring stability across all 12 morphs. There is no version of

this factory that ships the ruled aging model without the cage. Choosing chunk-first buys weeks and

pays for them with a harder cage problem later, on 167 assets instead of one.

2. The bridge stays live, so nothing idles. Section 5.3: the current route continues producing

keystone ages while the cage is built. The slice does not wait.

3. The cage may be nearly free. The survey's own recommendation is a **parametric body that

arrives with clean quad topology, UVs and a rig already** — Anny (Apache-2.0 code, CC0-descended

assets), whose parameter space natively spans *"infants to elders"*, the exact band MetaHuman was

measured unable to reach [PIPE_CHARACTER_MODELS_2026-08-06.md §7.1, §10]. If that lands, the

"missing stage" is an adoption, not an invention, and the objection's premise weakens sharply.

It is still an objection with teeth until that is measured — the survey itself flags Anny's

topology numbers as uncorroborated and names an Anny-vs-MHR bake-off as the fork it could not

settle [ibid. §11]. That bake-off is the highest-value thing this brief can point at, and it is

scheduled as stage 2 of the factory spec.

A second objection, recorded because it is the cheapest way to overturn this brief. The

suppression primitive is keyed on the material index (SkinnedMeshComponent.cpp L4058-4068), so

every independently hideable region is a separate material slot and therefore a separate draw call and

a separate section that must survive LOD decimation. A body partitioned into ~10 regions is ~10 draws

at LOD0 instead of one, on every character on screen — on top of the gear components, where Epic's

own arithmetic is 50 characters × 3 components = 150 draw calls unmerged against 50 merged (§4.4).

It has two fallbacks, both inside the same architecture rather than outside it. The header's own

named option — a pre-hidden body variant baked per outfit [HumanityGarmentComponent.h L19-20] —

trades memory and build time for draws. And Mutable does exactly this natively: it removes the

covered geometry by UV block *and* merges meshes and textures to reduce draw calls, at instance-build

time (§4.4). So the objection resolves to *"the cheap path may not scale, and the engine ships the

expensive path we would migrate to"* — which is a sequencing question, not an architecture question.

It is still unmeasured, and it is named in section 8 as owed.

---

6. THE FACTORY SPEC — the stage list every humanoid is stamped from

Written so a lane can execute it without a conversation. EXISTS = a proven tool with a record on

disk. BUILD = named, specified, not yet built. Each stage names its gate.

6.0 The invariants that bind every stage

• NEVER merge independently generated geometry. The only join in the humanoid factory is the

head↔body bridge of 5.3, and it retires.

• BARE-FIRST. Every exemplar plate generates as the bare base (M-17 tasteful-minimal); clothed

states are derived compositions [DECISIONS L4453-4468]. The geometry lift never runs on a clothed

plate [DECISIONS L4388-4398].

• THE BASE BODY CARRIES NO GARMENT AND NO EQUIPMENT, and is fully textured [DECISIONS L4166-4181].
• BARE IS DEV-ONLY. The bare textured base is the development substrate — the flexibility that

makes every cultural apparel class dressable — and it ships **only as the substrate under masking,

never as a reachable player state** [DECISIONS L4540-4552]. The unequip path bottoms at the minimal

underwear layer via swap semantics [DECISIONS L4518-4539, L4553-4556].

• EVERY PASS IS IMAGED. Every generation, build and finishing pass on every body, chunk and layer

lands on disk as an image beside its data, on a named instrument, so seams and proportions are

director-reviewed on renders before anything joins as 3D. A pass without its image is un-DONE

[DECISIONS L4557-4562].

• IDENTITY IS JUDGED AGAINST THE PICK AT EVERY AGE, never chained through intermediates

[DECISIONS L4413-4418], and no gradeable reaches Josh without the director's own per-tile sighted

audit [ibid.].

6.1 The stages

6.2 The critical path, and what can run in parallel

Serial: 2 → 4 → 5 → 6 → 6b → 7. Everything downstream of the cage is blocked on the cage; that is

the honest read and it is why stage 2 is the highest-value item on the whole register.

Parallel, starting now, on tools that already run: stage 1 (keystone plates), stage 3 (the lift),

stage 9 (the body texture batch — the shipped body is still a flat cream constant sampling zero

textures [register row 2]), stage 10's decimation defect (the chest LOD0 is 6.34× its own base body

and 5.59× the Steam-Deck floor [register row 22]), stage 11's suppression call, which needs no cage at

all — it can be built and proven against the current base body and the existing hide list by

partitioning that body's 21,154 faces into regions today — and stage 11a, which needs nothing but

the floor piece and the component surface that already exists.

That last point is worth naming as the cheapest real win in this brief: the suppression mechanism

and the unequip floor can be built, proven and shipped on the asset we already have, before the cage

exists, and suppression is the one named gap the shipped engine component documents against itself.

Stages 11 and 11a together are roughly a tooling-day and a half, and they close the two rulings

(per-region masking, and the swap floor) that currently have no engine implementation at all.

---

7. CREATURES AND NON-HUMANOIDS — where the answer transfers and where it does not

The census is 187 rows across eight archetypes plus HUMANOID

[GAME:QA/bench/creature_archetype_census.json]: QUADRUPED 62, NEEDS_CANON_BODY_PLAN 42, WINGED 32,

AQUATIC 20, LIMBLESS 13, ARBOREAL_PRIMATE 11, SPRAWLING_QUADRUPED 4, MULTI_LEGGED 3.

What transfers unchanged:

• The merge ban. The winding-inversion and de-merge lessons are geometry lessons, not anatomy

lessons. They apply to a dragon exactly as they apply to a child.

• The region partition and its physical values. A per-region physical table is arguably *more*

valuable on creatures than on humanoids — severance, armoured plates versus soft flanks, wing

membrane versus wing bone — and it is the same mechanism.

• Region suppression wherever a creature is barded, saddled, armoured or equipped.
• Bind on the whole, ROM against the archetype's own reference table (the eight archetype JSONs

already exist alongside HUMANOID.json).

• Auto-rigging at archetype scale is buyable or self-hostable, which the creature line needs.

UniRig (VAST-AI/Tsinghua, SIGGRAPH 2025, MIT) runs headless — generate_skeleton.sh,

generate_skin.sh, merge.sh with --input_dir/--output_dir — and is topology-adaptive rather

than fixed-template (https://github.com/VAST-AI-Research/UniRig). Tripo's rig API is the only

surface found with real non-humanoid coverage: rig_type ∈ biped, **quadruped, hexapod, octopod,

avian, serpentine, aquatic**, with Mixamo-compatible naming and a rig-check pre-validation call

(https://developers.tripo3d.ai/en/docs/animations-rig). Both map onto the census's archetypes far

better than Mixamo, which is biped-only, has no API, and shows real availability risk.

• The ROM finding, and it is the one that makes the cage pay twice. No product takes a rigged

character and emits validated joint limits; the published research is about *pose-conditioned*

limits (Akhter & Black CVPR 2015 — elbow ROM depends on shoulder orientation; Jiang & Liu ICRA 2018

— a learned implicit boundary of the valid configuration set). The workable shape is therefore the

one our anatomy tables already assume: **hand-author one ROM/constraint profile per archetype

against a biomechanical reference, and let a shared cage transfer it to every character by

construction**, with a learned pose prior used only as a QA gate. The same argument applies to

rigging itself — with a fixed cage, fitting a Rigify metarig collapses from a per-character

authoring task into a vertex-index lookup.

What does NOT transfer:

• One cage per archetype, not one cage per project. A cage is a topology with a fixed vertex order;

a quadruped and a serpent cannot share one. The correspondence *benefit* transfers within an

archetype (62 quadrupeds sharing a cage is the same multiplier Guerrilla got across 100+ heads) and

not across archetypes.

• Age morphs mostly do not apply. The 12-age model is a protagonist-and-companion requirement

[DECISIONS L4451-4452]; most creature rows need one state.

• The equipment slot model mostly does not apply. The 16-slot paper doll is humanoid canon.
• The 42 NEEDS_CANON_BODY_PLAN rows are blocked on canon, not on this decision — a folklore

being's body plan is a design decision and the census refuses to guess it

[anatomy_reference/HUMANOID.json scope]. This brief does not unblock them and must not be read

as doing so.

• Coat and groom have no stage at all for the 62 QUADRUPED and 11 ARBOREAL_PRIMATE rows

[AAAAA_IMPROVEMENT_REGISTER §1.4]. That is a different gap and it is not this brief's.

The one creature-side caution. The creature line's own honest NO-GO is a measured deformation

ceiling with the bind seam deliberately held [docs/boards/SLICE_COMPLETION_BOARD.md]. Nothing in this

brief claims to move it; the partition model gives creatures the same suppression and physical-values

machinery, and their deformation problem stays where it is.

---

8. WHAT THIS BRIEF LEAVES OWED

• The draw-call measurement for a ~10-region partitioned body under a crowd, against the

pre-hidden-variant fallback. Named in 5.4 and unmeasured.

• Diablo 4's body-suppression mechanism is unknown to us (2.5). It is cited in Josh's ruling as a

player-facing reference and this brief uses it only as that. If the ruling ever needs D4 as

*technical* evidence, that evidence does not currently exist in our records — WoW's geoset system is

the documented Blizzard-lineage substitute, and it is named as a substitute.

• The RAGE boundary-matching inference in 2.3 is an inference, marked as one. If a first-party

account contradicts it, the steelman of chunk-first gets stronger and section 5 should be re-read.

• ULODSyncComponent is missing from our assembly (§4.4). Multi-component characters desync at

LOD borders (UE-87501, UE-191796) and MetaHuman ships LOD sync by default. Ours does not. **This is

a live defect in the shipping assembly, found by this brief and not owned by any lane.**

• Mutable is BETA and off by default in our installed 5.8.0, against a research lane's

release-notes claim of production status (§4.4). Any plan that leans on it must re-verify against

the engine build the game actually ships on, and must enable the plugin deliberately.

• Licence items to chase before anything is adopted: whether WrapCmd / Rush / Node are covered

by the base Wrap licence or need separate compute-node licences (undocumented, and it changes the

cost model); Anny's missing glTF/FBX exporter (trivial to write on a fixed topology, but it does not

exist); the SOMA and TOPOS licences; and the MakeHuman CC0 carve-out, which is documented for

GUI-export use and may not survive programmatic/batch generation — Anny sidesteps it, which is

another reason to prefer Anny over MakeHuman directly.

• The Anny-vs-MHR bake-off (stage 2). The survey's own unsettled fork

[PIPE_CHARACTER_MODELS §11], and now the factory's critical path.

• The region roster itself — how many regions, drawn where. It should be derived from the ruled 16

slots' actual coverage plus the anatomy reference's joint boundaries, not typed from taste, and it

needs a canon pass for the physical values.

• Section preservation through decimation is asserted as a requirement here and has never been

tested on our LOD chain.

• The suppression call's reversibility under LOD transitions (hidden materials are stored per LOD;

a piece equipped at LOD0 must hide the same region at LOD3).

• The imaged-pass instruments do not all exist yet. Six of the twelve stages name an image this

project has never emitted — the cage deviation heat-map, the region-colour map, the region

value-ramp, the per-rung silhouette strip, the garment penetration heat-map, and the in-engine

unequip-floor frame. EVERY-PASS-IMAGED makes each of them a blocking deliverable of its stage,

not a nicety, and that is a real addition to the spec's cost that this brief does not hide.

• Nothing here is enrolled in a blind join. This is an architecture brief grounded in records and

first-party APIs; it makes no quality claim about any asset.

---

9. THE ONE-PARAGRAPH VERSION FOR THE RULING

Chunks are a good idea and merging is a bad one, and they are separable. Ratify body chunks as a

partition of one bare body mesh — real anatomical regions, each with its own proportions, its own

physical values, its own record, and its own material slot so gear can suppress it — and ban geometric

merging of independently generated parts from the character factory. That is what Cyberpunk, BG3,

Witcher 3 and GTA actually ship (in Cyberpunk's own format the word *chunk* already means a submesh of

one mesh hidden by a mask, and BG3 requires armour to share the naked body's topology and hides *"body

parts like the panties and bra"* through the same mask system), it is the mechanism Josh's own

underwear ruling already named, half of it is already built and shipping in our engine, and it

satisfies four of the five if-modular conditions by construction rather than by engineering. It also

makes the unequip floor cheap — the floor layer is just another maskable layer, and the swap is half a

tooling-day on a component surface that already exists — and it keeps the EVERY-PASS-IMAGED law

affordable, because a partition costs roughly 156 imaged passes per character where a six-part

chunk-first split costs roughly 936, and the scarce resource being spent there is the director's eye.

The cost is that everything waits on the shared-topology cage — which every route needs anyway, which

the ruled 12-age model cannot be delivered without, and which may be an adoption rather than an

invention if the parametric-body bake-off goes our way.

Generated by harness/site/structure_site.py — the URL path is the repo path. review root