pipelines/CRAFT_TOPOLOGY_DEFORMATION.md
Status: PROPOSAL TIER, 2026-08-08. Not ratified canon. Citation-verified 2026-08-08 — every source
was checked by direct fetch or DOI resolution, and seven rules were rewritten where the original
draft attributed a claim to a source that does not make it. See the citation verification note at
the end of SOURCES. This doc researches the AAA practice for
character topology and skin deformation, maps it onto our named stack under build/3d/best_a14/rig,
and ends with GAP NOTES the audit phase consumes.
The presenting symptom this was commissioned against: our shoulders look wrong in motion and the
legs shred under flexion. We hand-rolled harmonic-field and inverse-distance weights. The research
below says the symptom has at least four independent causes stacked on top of each other, and that
weight painting is the LAST of them, not the first.
Meshes," Proceedings of the 12th ACM SIGGRAPH/Eurographics Symposium on Computer Animation (SCA),
2013. DOI 10.1145/2485895.2485919 — https://dl.acm.org/doi/10.1145/2485895.2485919
Interpolation and Skeleton-Driven Deformation," Proceedings of SIGGRAPH 2000.
DOI 10.1145/344779.344862 — https://dl.acm.org/doi/10.1145/344779.344862
ACM SIGGRAPH Symposium on Interactive 3D Graphics and Games (I3D) 2007.
https://users.cs.utah.edu/~ladislav/kavan07skinning/kavan07skinning.pdf
Approximate Dual Quaternion Blending," ACM Transactions on Graphics, 2008.
https://users.cs.utah.edu/~ladislav/kavan08geometric/kavan08geometric.pdf
Deformations While Preserving Detail," Proceedings of the Fourth Symposium on Digital Production
(DigiPro '14), 2014. DOI 10.1145/2633374.2633376 —
https://dl.acm.org/doi/10.1145/2633374.2633376 — presentation video: https://vimeo.com/103666815
ACM Transactions on Graphics (SIGGRAPH) 2019. DOI 10.1145/3306346.3322982 —
https://dl.acm.org/doi/abs/10.1145/3306346.3322982
with Continuous Examples," ACM Transactions on Graphics, 2021. DOI 10.1145/3450626.3459779 —
https://dl.acm.org/doi/10.1145/3450626.3459779
Dual Quaternion Skinning for Production Use," Walt Disney Animation Studios.
https://media.disneyanimation.com/uploads/production/publication_asset/98/asset/dualQ.pdf
Direct Skinning Methods and Deformation Primitives. https://skinning.org/direct-methods.pdf
— course hub: https://skinning.org/
animation," degree thesis, Luleå University of Technology, Department of Arts, Communication and
Education, 2018. https://www.diva-portal.org/smash/get/diva2:1218697/FULLTEXT01.pdf
— record: https://www.diva-portal.org/smash/record.jsf?pid=diva2%3A1218697
https://dev.epicgames.com/documentation/unreal-engine/skeletal-mesh-rendering-paths-in-unreal-engine
https://dev.epicgames.com/documentation/metahuman/metahuman-dna-rig-definition-and-rig-operation
https://dev.epicgames.com/documentation/metahuman/metahuman-creator-from-template-tool-in-unreal-engine
https://dev.epicgames.com/documentation/metahuman/metahuman-creator-from-custom-mesh-tool-in-unreal-engine
https://dev.epicgames.com/documentation/metahuman/body-conform-controls
https://dev.epicgames.com/documentation/en-us/unreal-engine/skeleton-editing-in-unreal-engine
https://help.autodesk.com/cloudhelp/2027/ENU/Maya-Modeling/files/GUID-A66E942B-D757-42FF-A36B-F366E31047C2.htm
— deformer overview: https://help.autodesk.com/cloudhelp/2023/ENU/Maya-CharacterAnimation/files/GUID-139B703C-28E7-4787-8FD4-C2991BD6C990.htm
Corrective), Blender Manual.
https://docs.blender.org/manual/en/latest/modeling/modifiers/deform/corrective_smooth.html
— Python API: https://docs.blender.org/api/current/bpy.types.CorrectiveSmoothModifier.html
outside Maya). The vendor page offers a free version on GitHub alongside a paid marketplace
version. https://www.mesh-online.net/voxel.html
optimisation setting; it does not itself tabulate limits across DCCs).
https://docs.instalod.io/Products/InstaLOD_Studio/Workflows/Optimizing_Skeletal_Meshes
https://gist.github.com/donmccurdy/4cad2039360fbd7cd55d18b3f0428581
at the Creation of U2's Characters," GDC 2010, Visual Arts track, GDC Vault.
https://gdcvault.com/play/1012552/Uncharted-2-Character-Pipeline-An
https://www.youtube.com/watch?v=myZcUvU8YWc
material, notably the three-skeleton split (motion-capture skeleton, animation/keyframe skeleton,
game deformation skeleton). Treat as secondary, not primary.
https://cassbennett.wordpress.com/2014/09/30/character-rigging-in-games/
https://studio.blender.org/tools/pipeline-overview/asset-creation/animation-testing
https://sol-g-brennan.medium.com/rigging-tips-methods-for-extra-character-deformation-in-game-dev-e4c0e89e7b00
https://sol-g-brennan.medium.com/rigging-tip-driving-your-deformations-primarily-for-games-9265a38492b5
https://www.3dfiggins.com/writeups/forearmTwist/
https://caveacademy.com/wiki/post-production-assets/rigging/rigging-training/introduction-to-rigging-course/11-corrective-blendshapes/
https://cgtyphoon.com/topology/human-knee-topology/
https://cgtyphoon.com/topology/elbow-topology-explained-for-character-modeling/
https://mocaponline.com/blogs/mocap-news/character-rigging-game-dev-guide
https://mocaponline.com/blogs/mocap-news/character-rigging-basics-guide
https://polycount.com/discussion/87716/forearm-twist and
https://polycount.com/discussion/210412/trying-to-fix-arm-twist-for-a-ue4-rig
NOT VERIFIED: both URLs return HTTP 403 behind Polycount's bot protection, so no claim in this doc
rests on them. Retained as leads only.
https://medium.com/@Jamesroha/metahuman-5-6-5-7-pipeline-reference-170d302b078e
https://forums.autodesk.com/t5/maya-programming-forum/using-geodesic-voxel-skin-binding-in-maya-standalone/td-p/11871400
NOT VERIFIED: returns HTTP 403 to automated fetch. No claim in this doc rests on it.
https://lesterbanks.com/2014/06/geodesic-voxel-binding-maya/
Every source above was checked on 2026-08-08 by direct fetch, DOI resolution through the Crossref
and OpenAlex APIs, or both. Four sources are marked NOT VERIFIED in place because the host blocks
automated fetch; nothing in ACTIONABLE RULES or WHAT WE ADOPT depends on them. Where an earlier
draft of this doc attributed a claim to a source that does not in fact make it, the claim has been
rewritten against what the source actually says — see A2, A6, B1, B2, B4, E2 and H3.
Each rule states the practice, cites where it comes from, and names the file in our stack that owns
it or would have to own it.
predictably; triangles and n-gons produce pinching, uneven smoothing and shading artifacts under
deformation (CGTyphoon knee and elbow guides; DiVA thesis). This is a property of the MESH, and no
weighting method recovers it. Our owner would be a retopology stage that does not currently exist;
the mesh that reaches bl_skin_to_mannequin_BOUNDED.py is whatever the generative chain emitted.
line and loops on either side of it. The knee guide states that most character models use at least
three to five loops around the knee for stable deformation. The elbow guide scales the count by
asset tier rather than giving one number: three to four loops for a mobile character, four to six
for a standard game character, six to eight for a hero character, eight or more for a cinematic
character — and cautions that more geometry does not automatically improve deformation, clean edge
flow usually mattering more than polygon count (CGTyphoon knee and elbow guides). Below the floor
the silhouette breaks and a sharp fold appears. Our characters are hero-tier, so the elbow and knee
budget to design against is six to eight loops, not three.
the elbow) takes more geometry; the compressing side takes less (CGTyphoon knee guide).
the bend produces visible pinching and unstable shading (CGTyphoon knee guide).
elbow and forearm, so tension distributes along the limb instead of concentrating at one ring
(CGTyphoon and general practitioner consensus in the topology sources).
From Custom Mesh tool exists to "Generate a fully rigged MetaHuman from a mesh with custom
topology, including sculpts, 3D scans, and AI-generated meshes," and Epic states that "the result
is always standard MetaHuman topology in the MetaHuman A pose" (Epic, MetaHuman Creator From
Custom Mesh Tool). The From Template tool's compatibility requirements are stated the other way
round — they apply to a source mesh already in the system: "The source head or body mesh uses
standard MetaHuman topology" (Epic, MetaHuman Creator From Template Tool). So the industrial answer
to "our generated mesh has no loops" is not to demand loop-correct input; it is to CONFORM an
authored, loop-correct base topology onto the generated shape and ship that, which is precisely the
case our chain matches — an AI-generated mesh — and precisely the structural decision our chain has
never taken.
Correction of record: an earlier draft of this doc quoted a sentence requiring "all inputs" to use
standard MetaHuman topology and the joint hierarchy to follow MetaHuman standards. That sentence
does not appear on the cited Epic pages, and the Custom Mesh page states close to the opposite
about inputs. The rule survives the correction and is in fact strengthened, because Epic names
AI-generated meshes as a supported input class.
helper joints in its Replace workflow, and states that "All body joints, body RBFs, and skin
weights are generated automatically to best fit the source mesh" — so the helper layer and its RBF
drivers are generated rig machinery, not animator-facing controls (Epic, MetaHuman Creator From
Template Tool). Naughty Dog's published split is stronger still: separate motion-capture,
animation/keyframe and GAME DEFORMATION skeletons — "their rigging pipeline consists of referencing
these rigs into the animation scene" (Cass Bennett's summary of the ND GDC material; treat as
secondary). The deformation skeleton is allowed to have joints the animator never touches.
Scope note: the MetaHuman DNA / Rig Definition page does not use the core-versus-helper vocabulary
and does not describe RigLogic's solver internals, so no claim about RigLogic is made here.
says to "Add 1-3 twist bones between the elbow and wrist and weight the mesh accordingly." Kiel
Figgins uses three forearm joints spaced evenly between elbow and wrist, weighted "Elbow >
Forearm1 > Forearm2 > Forearm 3 > Wrist. All weighted 1 to 1, with slight fading to ease the
transitions between joints," and reports that "With a 3 Joint twist, higher volume is retained,
based on joint rotation and weighting, over other solutions." The shared principle is that weights
ramp along the segment so the roll distributes rather than pinching at a single joint. Our target
skeleton
ALREADY HAS these: upperarm_twist_01/02, lowerarm_twist_01/02, thigh_twist_01/02 and
calf_twist_01/02 per side are present in the census emitted by bl_weight_census.py.
ROLL; the primary joint still carries flexion and abduction and must hold the majority weight in
its own zone (Figgins; Brennan; MoCap Online). See GAP-2 — this is where our bind inverts the
practice.
set-driven keys ("a way to have an arbitrary value control another value/s with an animation
curve"), RBF — which he calls "the big daddy itself of driving deformations and an industry
standard" — cone readers that "give you the angle of a cone, with a given angle where a value will
start to fade from 0 to 1," maths nodes, and expressions, which he notes suit "simple, linear types
of behaviour — like a twist joint setup" (Brennan, "Driving your Deformations"). Figgins'
corrective-joint writeup gives the general rig for this — a Constrain_Grp > SDK_Grp > Offset_Grp >
CTRL > Joint hierarchy with set-driven keys automating the corrective joint off the primary bend
joint — and for the shoulder specifically defers to Peter Shipkov's shoulder rig
(petershipkov.com/development/shoulderrig/shoulderrig.htm) rather than specifying a mechanism.
Scope note: an earlier draft asserted a specific shoulder recipe here (a helper reading the
upper-arm angle at a fraction of it, plus a twist-damping counter-joint) and attributed it to
Figgins, a Blender Artists thread and the CAVE Academy wiki. Figgins' page does not state it, the
CAVE page does not state it, and no Blender Artists thread is cited anywhere in this doc. The
recipe is withdrawn; sourcing a specific shoulder-helper construction is open work, and Shipkov's
rig is the lead to run down.
watertight, single-component surface. It fails outright on the meshes production actually
produces. That failure is the stated motivation for geodesic voxel binding.
and is explicitly designed for "production meshes that may contain non-manifold geometry, be
non-watertight, have intersecting triangles, or comprise of multiple connected components." The
method: voxelize the rest-pose geometry; compute geodesic distance THROUGH THE VOXEL GRID from the
voxels a bone occupies to every non-exterior voxel; derive weights from those distances. It
produces smooth weights at interactive rates with no time constants, no iteration parameters and
no optimisation step, and it decouples weight assignment from distance computation so falloff can
be retuned at pose time without recomputing anything (Dionne and de Lasa 2013).
the mesh's edge graph, it does not need the surface to be connected, and it still cannot leak
between two limbs that are separated by empty space — the voxel path has to go around. That is
exactly the property our harmonic-field edge-graph solve was hand-rolled to obtain, obtained
correctly and without depending on mesh connectivity.
combines Blender's heat-map approach with a voxel grid. The vendor states the case exactly:
"Traditional heat map diffuse skinning algorithm can only deal with watertight meshes, but artists
create character components in their own way, then group them together to a character, usually the
character is not seamless," and the addon "converts the non-seamless character into a solid statue,
heat diffuses in the solid statue, so we can get the most natural vertex weights." A free version
is published on GitHub and a paid version is sold on the Blender marketplace. This is the drop-in
for bl_skin_to_mannequin_BOUNDED.py's fallback path.
auto-bind output as previz-tier and follows it with correctives, smoothing and hand paint. Our own
binder header already says this ("HONEST TIER OF THE WEIGHTS: PREVIZ-AUTOSKIN"); the research
confirms the label is accurate and that no amount of tuning inside that class reaches AAA.
candy-wrapper collapse under twist, elbow (and knee) collapse under flexion, and general volume
loss in high-curvature regions (Kavan, SIGGRAPH 2014 course, Part I — the course's whole
progression through spherical blend skinning, dual quaternion blending and linearised nonlinear
skinning is organised around them). Disney's production paper names the same headline defect from
the other side: DQS "avoids the undesirable candy-wrapper effect and effectively simulates volume
preservation" (Lee et al.).
wrapper class of artifact (Kavan et al. 2007, 2008). LBS and DQS are jointly described as the de
facto standards for skeleton-based deformation.
(Kavan 2014 course notes reference bulging-free DQS). Disney's paper exists specifically to harden
DQS for production and is blunt that it is "not a simple drop-in replacement for LBS" — on Frozen
they configured "DQS with LBS to handle non-rigid transformations, hierarchies of differing joints,
and arbitrary support joints" (Lee et al.). The practical production posture is DQS or blended
LBS/DQS on
limbs, LBS elsewhere, with correctives on top either way.
in Blender or Maya does not survive export unless it is baked into correctives or the engine path
is changed. Any DQS decision in our stack is therefore a DCC-side authoring decision that must be
BAKED, not a runtime one.
specific pose, store the per-vertex displacement in the local coordinate frame, and interpolate it
back with radial basis functions as a function of the driving joint angles (Lewis, Cordner and
Fong, SIGGRAPH 2000). The paper states the technique unifies shape interpolation and skeleton-
driven deformation, and it is the method behind essentially every production shoulder in the
twenty-six years since.
non-linear behaviour of skin, fat and muscle. CAVE Academy puts the practical case plainly: "Blend
shapes will allow us to push deformation much further than can be achieved through skinning alone."
The mechanism is the one Lewis, Cordner and Fong define in E1 — the stored quantity is a per-vertex
DISPLACEMENT in a local frame, that is, a correction applied on top of the skinned result rather
than a replacement shape measured from neutral.
Scope note: an earlier draft stated the relative-to-applied-deformation definition as a quotation
from the CAVE Academy wiki. That page does not contain it. The claim is retained because it is what
the pose space deformation paper's displacement formulation says, and it is now cited there.
where adding more joints would blow the per-vertex influence budget. Helper joints earn their cost
where the correction is broad and rotational (Brennan, "Methods for Extra Character Deformation").
The shoulder usually wants both.
together, because the two move as a unit and the balance between them is the deformation. Stated
honestly: this is a design position of ours, not a sourced rule. It follows from E1 (pose space
deformation interpolates as a function of the driving joint angles, and the shoulder has two of
them) but no source sampled for this doc states it, so it carries no citation weight and should be
re-grounded before it hardens into a contract.
own sculpted detail: it smooths the deformed result, then re-applies per-vertex deltas captured in
the rest pose in a local frame. Mancewicz, Derksen, Rijpkema and Wilson describe it as a Voodoo
deformer developed at Rhythm and Hues that "smooths arbitrary deformation of polygonal mesh without
smoothing the original detail of model," report that it "has been used in all character rigs at R&H
since it was developed in 2010," and state the workflow consequence directly: "By making bad
deformations good, Delta Mush helps facilitate an efficient character workflow: riggers can use
simpler binds and coarser deformers; animators have access to interactive, realtime rigs" (DigiPro
2014).
weights, because its explicit purpose is making bad deformations good. That is the paper's own
phrase, and it is why the paper claims simpler binds: it lowers the weight-quality floor required.
smoothing, slower), Distance Weight (default 0.0; the documentation says it "lets you account for
the distance between vertices when calculating the 'mush'", and raising it toward 1.0 gives nearby
vertices more influence, which helps meshes with varied face sizes), and Inward and Outward
constraints, which "retain the contour of the deformed mesh shape just before the delta mush
deformer" by moving vertices tangentially (Autodesk Maya documentation).
as Smooth Corrective. The manual describes it as reducing highly distorted areas of a mesh by
smoothing the deformations, and names the Armature modifier as the typical upstream cause, since
distortion around joints is hard to avoid even with careful weight painting. Parameters are Rest
Source (original coordinates, or bind coordinates), Factor, Iterations, and Smooth Type (Simple, or
Length Weighted). It is free and already in our DCC.
Verification status: the Blender manual page is real and linked from the manual's modifier index,
but docs.blender.org returns HTTP 403 to automated fetch, so the parameter list above was NOT
re-verified against the live page on 2026-08-08. Confirm it in the DCC before writing it into a
build contract — the parameter names are the thing a script will break on.
filter is used at AUTHORING time and then baked — either into corrected skin weights (the
dm2skin-style approach: a Maya Python script that "allows you to convert the results of a
delta-mush deformer to standard skin weights" by optimising weights against the delta-mushed vertex
positions over a set of keyframed poses; original repo https://github.com/IlgarLunin/dm2skin) or
into corrective shapes. Direct Delta
Mush (Le and Lewis 2019) exists precisely to make the operation direct rather than iterative and
therefore bakeable into a weight-blending form, and its 2021 follow-up compresses it further.
and pads unused slots with zero weights that still cost skinning computation (Epic, Skeletal Mesh
Rendering Paths).
influences is capped to 12 because of the way Skeletal Mesh source data is stored" (same source).
Influences (requires editor restart), Unlimited Bone Influences Threshold, and Default Bone
Influences Limits. Per-mesh override is the Bone Influence Limit under LOD Build Settings. Epic's
own recommendation: "Set the Unlimited Bone Influences Threshold to 8. Skeletal Meshes with bone
influences between 9 and 12 are rendered with the Unlimited Bone Influences path, and bone
influences between 0 to 8 are rendered with the fixed 4 / 8 bone influences path."
pushed to 8" (Brennan). Mobile and LOD assets go lower.
influences and renormalising (Kavan 2014 course; standard across the tool references).
LODs. The reduced joint count when descending LODs is done by exclusion, where each subsequent LOD
excludes some of the joints from the whole subset." Weights are per LOD because geometry is:
"Each LOD has its own geometry set, with no meshes shared across LODs, therefore all geometry
related attributes are per LOD (for example, skinning weight assignments)" (Epic, MetaHuman DNA /
Rig Definition).
the ROM pass is a rigging deliverable, not an afterthought. Blender Studio's pipeline names the
same step — "simple transformations on the controllers to see if they behave how we expect" — and
makes the loop explicit: "Test the rig weight painting and deformations, having feedback sessions
with rigging and modeling until it moves correctly." MoCap Online sets the pass condition: "full
rotation at each joint should produce natural deformation, not collapse or intersect."
applying motion capture data. Mocap pushes rigs through the full range of human body movement,
exposing problems that hand-keyed poses miss," specifically "deformation artifacts, IK
instabilities, and weight painting failures at the shoulders and hips." The recommended clip set is
walks, runs, jumps, sitting, reaching and combat (MoCap Online).
supplies one. Stated honestly: an earlier draft attributed a five-item visual checklist
(silhouette, contacts, deformation, pops, camera readability) to MoCap Online and Blender Studio.
Neither states it. What the sources do give is the pass condition in H1 and the failure classes in
H2 — collapse, intersection, deformation artifacts, IK instability, and weight failure
concentrated at shoulders and hips. Build our checklist from those, and treat the extra items as
ours to justify rather than as inherited practice.
TWIST artifact, so the ROM has to include forearm pronation and supination and upper-arm roll, or
it cannot see the defect the twist chain exists to fix (implied directly by Kavan's artifact
taxonomy plus the twist-joint literature; see GAP-10).
Ranked by expected quality gain per unit of work against the presenting symptom. Every item names
the file that owns it.
1. Replace the fallback binder class outright. bl_skin_to_mannequin_BOUNDED.py's
geodesic_bounded_inverse_distance path is a hand-rolled approximation of geodesic voxel binding
that still resolves weights by distance to a bone SEGMENT. Adopt a true voxel-geodesic bind —
either the Voxel Heat Diffuse Skinning addon inside our existing Blender step, or a first-party
implementation of Dionne and de Lasa's grid walk. This removes the segment-direction defect, the
cross-midline leak and the bone-heat refusal in one move, because none of the three is a property
of the weights: all three are properties of the distance metric.
2. Insert a smoothing filter and bake it. Add Blender's Smooth Corrective modifier (Rest Source
BIND, Length Weighted) between the armature and export inside the binder, then bake it into
weights or into a corrective shape before FBX export. Delta Mush's stated purpose is to make
auto-skinned weights presentable; that is precisely our situation, and it is the cheapest
large win on the board.
3. Fix the weight distribution between primary and twist joints before anything else is tuned.
upperarm_l, upperarm_r, thigh_l, thigh_r and spine_05 currently hold ZERO weight (GAP-2). No
corrective, filter or algebra change matters while the joints the animation actually rotates
are not attached to the skin.
4. Add a corrective layer at the shoulder, elbow, hip and knee. Sculpt the corrected shape at the
ROM pose we already photograph, store it as a shape key driven by the joint angle, per Lewis,
Cordner and Fong. Our ROM set already defines the exact poses to sculpt at — 01_shoulder_abduct,
02_shoulder_raise_fwd, 03_elbow_flex, 06_hip_flex, 07_knee_flex in bl_rom_render.py — so the
corrective program is already scoped by an artifact we own.
5. Arm the ROM. Extend bl_rom_render.py with the missing twist axes and extreme and combined poses,
and give ROM_RESULT.json a real deformation SCORE (per-region volume change against bind,
self-intersection count, normal-flip count) so a red shoulder can fail a gate instead of sitting
in a PNG nobody consumes.
6. Declare the influence contract end to end. Reconcile the binder's --max-influences default (4)
with the delivered asset (8) and write the matching Unreal setting — Unlimited Bone Influences
Threshold 8, per-LOD Bone Influence Limit — into the build contract so the engine cannot silently
re-prune and change the deformation from what we photographed.
7. Board the topology question as a structural decision, not a tuning one. Rules A1 to A6 cannot be
satisfied by any weighting method. The industry route is to conform an authored, loop-correct base
mesh onto the generated shape (the MetaHuman conform pattern, which Epic documents as accepting
"sculpts, 3D scans, and AI-generated meshes" and always emitting standard MetaHuman topology)
rather than to skin the generated triangle soup. Note that the intermediate step is already
half-built and unshipped: a quad remesh
exists at build/3d/finish_a14/retopo/QUAD_A14_V3B.obj and the ship path bypasses it (GAP-1).
Promoting it would satisfy A1 but not A2 to A5, because a field-based remesh gives isotropic quads
rather than placed loop rings — so the decision to board is between promoting the existing quad
branch as an interim and adopting a conform-a-fixed-topology base, and that is a pipeline-shape
decision above this doc's authority. It belongs in the character-model pipe dossier.
8. Treat dual-quaternion skinning as an authoring-side option only, baked to correctives. Unreal
skins linearly; a DQS look must be baked or it does not ship. Low priority until items 1 to 5 land,
because twist joints plus correctives already address most of the candy-wrapper class.
Deviations already visible between our named stack and the practice above. Each carries its evidence
so the audit phase can score it rather than re-derive it.
actually skin is a pure triangle mesh with ZERO quads. Counted directly on the shipped surface,
build/3d/finish_a14/retopo/FINAL_A14_V3B.obj is 151,928 verts, 303,860 tris, 0 quads, 0 ngons; the
rigged LOD0 that reaches the binder reads 241,374 tris over 144,662 verts welding to 137,440
(build/3d/best_a14/rig/v21/SKIN_ASSEMBLY_V21.json), which is one vertex per triangle corner and the
signature of an unstructured surface. bl_skin_to_mannequin_BOUNDED.py's own header names the
condition ("The delivered LOD0 is a triangle soup"). Violates A1 outright, and A2 through A5
vacuously — there are no concentric loops at the knee, elbow or shoulder because there are no loops
at all. This is a structural cause of leg shredding that is independent of every weighting decision
downstream.
The sharper finding: a quad retopology branch WAS built and was then not consumed.
build/3d/finish_a14/retopo/QUAD_A14_V3B.obj is 10,749 verts, 10,530 quads, 30 tris, 125 ngons, and
build/3d/eval/likeness/ladder_stages.py's own chain derivation records that this branch "is REAL on
disk and is NOT the ship path; QUAD_A14_V3B was measured into retopo/_scratch_quad.obj and never
consumed." So the pipeline reached the right question and dropped the answer.
The honest caveat, which the audit must carry: adopting that branch as-is would NOT satisfy A2
through A5. AUTOREMESHER_REPORT_V3B.txt shows it is a field-based automatic remesh, which yields
ISOTROPIC quads — quads everywhere, loops nowhere in particular. The practice in section A wants
anatomically PLACED loop rings at each joint, which a field remesher does not author and which
MetaHuman obtains by conforming a fixed, hand-built topology (A6). The gap is therefore two-layered:
we ship triangles when we already have quads, and even the quads we have are not loop-correct.
build/3d/best_a14/rig/v21/CENSUS_V21_BARE3.json reads upperarm_l, upperarm_r, thigh_l, thigh_r and
spine_05 at verts_over_bar = 0 and max_weight = 0.0. All shoulder-region weight sits on
upperarm_twist_01_l at max 0.961 (8,262 verts) and upperarm_twist_02_l at 0.487; all hip weight on
thigh_twist_01_l at max 1.0 (11,634 verts) and thigh_twist_02_l at 0.498. On the UE5 Manny skeleton
the twist bones are partial-rotation children driven by the animation blueprint's twist correction,
so the deltoid and the glute are currently being deformed by a CORRECTION CHANNEL rather than by
the joint whose rotation the animation authors. Violates B3 directly. This alone is sufficient to
explain a shoulder that reads wrong in motion while every numeric bind check passes.
weight 0.236 on 2,232 vertices more than 5 cm past the midline, and clavicle_r 0.253 on 2,106. The
census script's own doctrine (bl_weight_census.py header) states that a midline crossing cannot be
right for a limb bone. The geodesic bound in bl_skin_to_mannequin_BOUNDED.py reduced this class but
did not close it on the clavicles.
0.0000 of vertices ... falling back to the geometric distance-to-bone-segment solve" and
bone_heat_weighted_fraction = 0.0. A mesh that heat diffusion refuses entirely is the exact case
Dionne and de Lasa built geodesic voxel binding for (C2). We answered it with a hand-rolled
edge-graph geodesic ball wrapping an inverse-distance-to-segment law, which (a) cannot bridge
disconnected components, since there is no edge there, (b) is unreliable on a triangle soup whose
corners are split, and (c) still uses distance to a straight segment through space as the weight
law inside the ball. GVB's voxel walk has none of those three properties. Violates C2 and C3.
bl_skin_to_mannequin_BOUNDED.py's header documents that bone tails kept whatever axis the FBX
import gave them rather than pointing at their children, making thigh_l's weighting segment run
22 cm HORIZONTALLY at joint height, and that the --segment-mode child flag corrects the weighting
proxy while deliberately leaving the armature untouched. The proxy is now better but the whole
method still stands on a synthesised segment. Every method in section C that studios actually ship
is segment-free: heat diffusion and voxel geodesics both work from the bone's occupied volume, not
from a line. Our defect class is therefore structural to the chosen solver, not a tuning residue.
blendshape, no shape-key driver and no RBF-driven helper joint anywhere under
build/3d/best_a14/rig. The shoulder fix that has been standard practice since Lewis, Cordner and
Fong in 2000 is simply absent from the stack. Violates E1 through E4.
no baked equivalent appears in bl_skin_to_mannequin_BOUNDED.py, bl_unpose_and_export.py or
prep_assembly.py. The technique whose published purpose is to make auto-skinned weights acceptable
(F1, F2) is not being used by the one project in this comparison whose weights are entirely
auto-solved. Violates F1 through F5.
and no adjudication on record choosing LBS deliberately. bl_rom_render.py's header names
candy-wrapper as the failure mode it is looking for, but nothing in the stack can act on that
finding beyond the twist bones — which per GAP-2 are currently carrying the primary rotation rather
than distributing roll. Violates D2 and D3 by omission; note D4 constrains the fix to a baked one.
bl_skin_to_mannequin_BOUNDED.py declares MAX_INFL default 4 (argval "--max-influences", "4") while
the delivered asset reports influence_budget 8, max_influences_before_prune 8 and
max_influences_after_prune 8 (SKIN_ASSEMBLY_V21.json). No repo artifact declares the matching
Unreal-side setting. Per G1 to G3, if the project's Default Bone Influences Limit is 4 the engine
re-prunes and renormalises on import, and the deformation the engine shows is NOT the deformation
bl_rom_render.py photographed. That is a silent, checkable divergence between our evidence and the
shipped result.
dictionary contains nine poses and NOT ONE of them rolls a limb about its own axis: 09_wrist_both
is ("hand_l", "X", -55), a flexion; 08_spine_twist twists the SPINE. There is no forearm pronation
or supination and no upper-arm roll. Candy-wrapper is a twist artifact (D1), and the twist bones
that currently carry nearly all our limb weight (GAP-2) are therefore never exercised by our own
test. Additionally: no pose exceeds roughly 90 degrees, there are no COMBINED poses (abduct plus
flex plus roll together, which is where shoulders actually fail), no hyperextension, and no
motion-capture clip — the test H2 names as the strongest one available.
verts_moved_frac and max_displacement_over_stature per pose — quantities that measure that the pose
MOVED something, not that it moved it WELL. There is no volume-loss, self-intersection or
normal-flip metric, and no consumer returns a verdict: emit_rig_record.py and emit_route_a_record.py
read the JSON into records, montage_rom.py sheets the PNGs, and emit_a14_v2_manifest.py points at
the file. Nothing gates on it. This reproduces exactly the RC1 finding in
docs/pipeline_review/POSTMORTEM_LIKENESS_2026-08-08.md — "no stage and no lens owns the whole read"
— at the deformation layer, and it is why a shoulder Josh can see is wrong passes every check we
have.
SKIN_ASSEMBLY_V21.json, 72 vertex groups on the bare body per CENSUS_V21_BARE3.json), used
unmodified as both the animation skeleton and the deformation skeleton. B1 says the deformation
skeleton is allowed extra driven joints the animator never touches, and B4 says the shoulder
specifically wants one. We have taken the constraint without taking the freedom it comes with.
exclusion-per-LOD, weights-encoded-per-LOD scheme. Our chain carries a LOD1 mesh flag in
bl_skin_to_mannequin_BOUNDED.py's usage string but the v21 records cover LOD0 only, and no artifact
states the per-LOD joint or influence policy. Lower severity than the above, but it will become a
defect the moment LODs are generated from a bind whose influence contract is already undeclared
(GAP-9).
(A14_BODY_APOSE_CANONFRAME, A14_ASSEMBLY_APOSE_CANONFRAME), which matches MetaHuman practice:
during Mesh Fit "The character is reposed to the standard MetaHuman A pose," and the Custom Mesh
tool's result "is always standard MetaHuman topology in the MetaHuman A pose" (Epic,
Creator-From-Template and Creator-From-Custom-Mesh). The bind-pose choice is aligned with the
reference practice; the deviations are all downstream of it.