V's body: resources, rig and the Studio's body render

Maturity: Draft. Consolidated on 26 September 2026 from the installed 2.31 game (the Phantom Liberty creator resources, the player body .app, .mesh and .morphtarget resources, the decompiled game scripts), the generic resolver's output for the default V, a new-game save and a V with body choices set, WolvenKit 9.0.1 exports of the body parts, ArchiveXL 1.27.3 source and the Modding Docs. Nothing on this page has runtime evidence yet. Evidence grades follow the knowledge rules: source engine/framework/tool source or decompiled scripts, resource extracted game or mod resources, wiki Modding Docs text or image, runtime running game, hypothesis not yet established. Provenance (hashes, commits, the resolver runs and the joint comparison) is in the body render evidence.

This page answers, for the V without clothing: which resources make up the player's body per body gender, how the creator's choices select them, how the body shares skin with the head, what the game's censorship rules do, how the body is rigged and animated, and how the Studio draws it. Clothing, which builds on it, is in worn clothing; the head's options are in head CC rendering and the option catalogue in the CC file chain.

1. Which parts make the third-person body

The creator resource has three parts, head, body and arms, each with options and consumer groups resource (file chain §2). A save stores every group's resolved appearances, and the default V's rule R5 activates every group too, so a V lists the first-person body, every arm-cyberware holster state and both feet states at once resource. Which of them the third-person V draws is decided by the consumers:

Female V's parts, as the resolver finds them on the base game (paths abbreviate base\characters\common\player_base_bodies\ as …\) resource:

Male differences resource: the body is a plain mesh, player_man_average\t0_000_pma_base__full.mesh (no breast morph); the arms' groups are not split per perspective; there are no feet groups; nipples have their own two-choice option, without a censorship rule.

A masculine V's body is drawn by the same plan, consumer groups and censorship rules [offline, 27 September, the default masculine V on one MO2 profile]: t0_000_pma_base__full, both nails, the arms (a0_000_ma_base__full_ag_hq, two components), the personal link (a0_001__personal_link_default_holstered) and the underwear cover i0_000_pma_base_full_censored. Without clothes he shows a bare chest and the underwear bottom, and the body mesh draws the feet: there is no feet component to add, as the missing feet groups and feet controller suggest. The creator idle is the feminine V's, so his body and head hold still until his own clips are prepared (masculine V plan, phase 2). That this matches the game's censored gameplay look is still a hypothesis for the in-game check.

Arm cyberware changes the arms. Each holster state is two creator options that fill the same component names with different mesh appearances and chunk masks: h_<state>_arms_colors_base_tpp (the skin-tone half: the arms' skin chunks) and h_<state>_arms_colors_cyberware01_tpp (the cyberware half) [resource: the reference save's resolved groups]. The cyberware halves mix skin.mt with multilayered.mt, mesh_decal.mt, metal_base.remt and glass_onesided.mt chunks: per arm, Gorilla Arms (holstered_strong_tpp) carry multilayered.mt ×2–3, mesh_decal.mt ×7, metal_base.remt ×2 and glass_onesided.mt ×1; Mantis Blades metal_base.remt ×2; Monowire and the Projectile Launch System mesh_decal.mt and multilayered.mt. Every state carries the personal link; the nails option lists every state but Gorilla Arms resource. Since 30 September the preview draws the state the save equips source: the loadout reader reads the ArmsCW item (SavedLoadout.arms), the request carries it (xfs/character-request-9 arms), and the host follows §1.1's chain (src/arm-cyberware.ts) to the group the body plan reads, so both halves of the state draw in place of the default arms. The default V, a save without arm cyberware, and every step that can't be followed (the TweakDB unreadable, a TweakXL item, a state the creator resource has no group for) draw the default state, the last three with a line in the record's notes. metal_base.remt alpha-tests the decal and logo chunks whose instance sets enableMask (PREV-117), and glass_onesided.mt draws its transmission pass (the tint; the Gorilla Arms pane reflects nothing) (metal and glass reference §7). Offline on the reference machine's saves the chain names holstered_strong_tpp for Gorilla Arms and holstered_nanowire_tpp for Monowire [offline] (experiment 034 §4); how the game draws them is unproven until capture C6 (render gap plans §8).

1.1 How equipped arm cyberware picks the holster state

The chain from the equipped item to the arms' creator group, read offline from the 2.31 TweakDB (tweakdb.bin; tweakdb_ep1.bin holds the same values) and the decompiled scripts (evidence):

1. Each arms weapon names a holstered item resource. The arm-cyberware weapon records (Items.StrongArms, Items.MantisBlades, Items.NanoWires, Items.ProjectileLauncher; the legendary variants point to the same item) and the base fists (Items.w_melee_004__fists_a) each have a holsteredItem. Every holstered item has entityName holstered_arms, equip area RightArm and the single placement slot AttachmentSlots.RightArm.
2. The holstered item's appearanceName is the creator group's name resource. Items.HolsteredFists → holstered_default; the Gorilla Arms item → holstered_strong; Mantis Blades → holstered_mantis; Monowire → holstered_nanowire; the Projectile Launch System → holstered_launcher. These are exactly the name fields of the creator resource's perspectiveInfo entries, whose tpp and fpp halves are the _tpp and _fpp groups.
3. The scripts keep one holstered item in the right-arm slot source. EquipmentSystemPlayerData.UpdateArmSlot equips the holsteredItem of the item in the ArmsCW area, or of the base fists when that area is empty. Drawing the weapon puts the weapon item itself in AttachmentSlots.WeaponRight and unequips the holstered item, except for the base fists (tag base_fists). HandleArmsCWUnequip and RetrofixHolsteredArms restore the fists' holstered item.
4. The engine turns the item into a group hypothesis. The step from "an item with appearance holstered_strong in the right-arm slot" to "draw the holstered_strong_tpp group" is native. A gameuiCharacterCustomizationArmCyberwareController class (fields defaultGroupName, additionalCyberArmAppearances) exists for it [source: WolvenKit RED4 types], but no instance was found in the local caches. The unholstered_* groups have no _tpp/_fpp split and belong to the drawn weapon; the weapon records' appearanceName is None, so how the drawn state selects them is not read.

For the preview (built 30 September): read the equipped ArmsCW item's TweakDB ID from the save, follow holsteredItem → appearanceName, and draw that name's tpp group from perspectiveInfo (a resource that doesn't split the state per perspective, the masculine one, names its group after the state); with no ArmsCW item, holstered_default_tpp. TweakXL-added records are not read yet, as for worn clothing, so a mod's arm cyberware defined only in TweakXL YAML draws the default state with a note. The preview shows V holstered. The rule is data-driven: a mod that adds an arm cyberware with its own holstered item and creator group needs no special case. The wiki states the same one-group-per-cyberware link wiki (switchers, icxrus). ArchiveXL's garment arm states follow a different, drawn-weapon rule: the item in WeaponRight or WeaponLeft and its TweakDB cyberwareType (MantisBlades, NanoWires, ProjectileLauncher; anything else counts as base arms) source (src/App/Extensions/PuppetState/Handler.cpp).

The creator puppet has no arm cyberware equipped, so by the same rule it takes holstered_default hypothesis. The wiki's arms cheat sheet notes a separate arms_full component used only by the character creator wiki.

First person uses its own parts (t0_000_pwa_fpp__torso.mesh, a0_000_pwa_fpp__full_l/_r.mesh, n0_000_pwa_fpp__neck.mesh) in the FPP_Body and holstered_*_fpp groups resource [wiki: body cheat sheet, manavortex]. The wiki lists t0_000_pwa_base__full_seamfix.mesh as a seam cover at the shoulders. The body and arms appearances name no seam-fix component; the head's skin-type .app brings it, and both its chunks (arms and neck, metal_base.remt) are MCF_RenderInShadows only, a shadow proxy the preview correctly never draws resource (render coverage §8).

2. Skin: one skin model for the head and the body

Every body skin part (body, feet, arms, genitals) is skin.mt with a local material per tone over the same four-level tone chain as the head, so a skin tone is again only TintColor, TintScale and the tint mask (head CC rendering §2) resource. The tone reaches the body through the creator's link: body_color, the arms options, the feet, nipples and genitals are followers of the skin color link, as the head's skin types are (file chain "Links") resource. Unlike the head, the body has no skin type: its albedo, normal and roughness are shared by every tone (vanilla base\characters\common\base_bodies\woman_average\textures\t0_000_wa__c_base_d02.xbm, t0_000_wa__c_base_n02.xbm, t0_000_wa__c_base_rm02.xbm), and the vanilla tone chain sets no SecondaryAlbedo resource. On the reference profile the KS UV texture framework patches the body meshes onto a player-only copy of the chain (base\characters\common\skin\player_mat_instance\…) with its own maps (base\4k\common\body\wa\textures\d02_naked.xbm, n02_naked.xbm, wa_base_rm02.xbm, 8192² there) and a full-body SecondaryAlbedo overlay (base\4k\common\overlays\fullbody_overlay_d01.xbm) that overlay tattoo mods replace resource (tattoos §8). The framework also replaces both arm meshes: their UVs place the arms in that texture's left column (the right arm in its top half, the left in its bottom half), and their materials take the same d02_naked albedo, so body, feet and arms read one full-body texture resource. The preview once drew the base game's left arm over it (a foot on the forearm): WolvenKit can't export the framework's left arm as it is, and with the game folder silently exports the base game's copy instead. The exporter now refuses such a copy and repairs the framework's own (PIPE-106, evidence); the game draws the framework's arms in both censorship modes, since neither the arms nor their materials carry a censorship rule resource. What the skin shader adds for the body (one program and light for head and body, one SSS profile slot across the neck seam, no wrinkles) is in the skin reference §3.2.

3. Censorship and nudity resource source

Body options carry a censorship rule, censorFlag Censor_Nudity with censorFlagAction Activate or Deactivate resource. While the game censors nudity, Deactivate options turn off and Activate options turn on:

Whether nudity is allowed is native (gameuiICharacterCustomizationSystem.IsNudityAllowed()); the scripts use it to equip the basic underwear items (Items.Underwear_Basic_01_Bottom, and _Top for a female V) on the creator puppet when nudity is not allowed, and to keep the underwear bottom on in gameplay unless genitals were chosen [source: preGameMenuGameController.script UpdateCensorshipItems, equipmentSystem.script IsBuildCensored, ShouldShowGenitals]. In ordinary gameplay without clothing V wears that underwear, a clothing item (clothing §2.3).

The Studio's policy (clothing render backlog, decided 27 September 2026): the player decides, as in the game. By default the V wears the game's censorship underwear; an opt-in setting draws the game's own uncensored mode, never more than the game can show.

Uncensored (opt-in). The Character panel's "Show my V uncensored, as the game can" (in the Body part of the panel, below the Body heading's show/hide switch; preview.setUncensored, stored per workspace, off by default) makes the character context's request carry nudity: true (xfs/character-request-7). The host then plans the body by the table above with nudity allowed (bodyRole(…, "nudity")): every appearance option whose rule has the flag Censor_Nudity and the action Deactivate draws as chosen (the uncensored skin, nipples, genitals and their parts), and every one with Activate doesn't (the censorship underwear, the censored skin); morphs apply as always. A rule with another flag keeps its censored role, and an option the merged creator resource doesn't define still never draws. Nothing is marked cover or covered and no censored twin is planned, so the fail-closed rules below have nothing to guard; with the body turned off the request asks for no nudity. The creator rows the underwear covers read the coverage status uncensored (since xfs/cc-panel-3) and are marked not shown only while the setting is off. Screenshots committed or stored as evidence stay censored; the uncensored path is checked by tests (tests/uncensored-mode.test.ts, tests/character-detail-plan.test.ts) [source: the Studio].

Censored (the default). The preview's body is the V with nudity allowed, covered by the game's own censorship underwear, decided from the creator's own rules only (censorRole in character-detail-plan.ts):

• options without a rule draw as the game draws them; morphs apply (the breast size shapes the body under the cover);
• an option the rule only turns on and that has no twin (the underwear cover, underpants) draws, standing in for the default underwear, which is clothing: a cover;
• of a pair the rule swaps (the body skin and its censored twin: another appearance option on the same creator slot and link, with the same flag and the opposite action; both vanilla resources pair body_color and body_color_censored on the slot body_color and the link skin color resource), the uncensored one draws only while every cover the body's consumer groups list draws; otherwise the censored twin, the game's own censored skin, draws in its place, and with neither the body isn't shown;
• an option the rule turns off and that has no twin (nipples, genitals) never draws: the cover sits over it; nor does a descriptor the merged creator resource doesn't define.

The uncensored skin carries the female nipples in its albedo resource, so the floor must fail closed wherever the cover can be lost after the plan (PIPE-97): the plan marks the cover cover and the uncensored skin covered and plans the censored twin beside them; the host serves the covers first (so the texture budget never cuts one) and, if one can't be served, serves the censored twin instead; the record reader keeps covers within its part cap and withdraws the whole body if a covered part outlives a cover (withdrawUncoveredBody); and the loader does the same when a cover fails to load or is over the texture budget, releasing what it made and saying so in plain words.

4. How the Studio draws the body

Record (xfs/render-detail-11, src/render-detail.ts; the body slot came with v8): a body slot, last in the load order, and on each body component the shape keys the resolver applied to it (morphs: <target>_<region>, as WolvenKit names a morph target's shape keys: t0_000_wa_base__full_breast_big_breast, a0_000_pwa_base__nails_l_nails_l) resource and its part in the censorship policy (censor: cover or covered; §3).

Planning (planBody, src/character-detail-plan.ts): the body and arms appearances the consumers above read, the censorship policy, one component per repeated part (the body skin is listed twice in its appearance) [hypothesis: one component per name in an entity], the skin's parts first so the decals read it, then the creator's option order, with the covers after every other body option. With the Body switch off the request says so (body: false, xfs/character-request-6) and the host prepares the head alone, neither dressing nor resolving the body, so the scene releases the body's GPU resources. previewInput resolves only the head and those body groups (a save lists every perspective and holster state). The feet state is a BodyState (bodyStateFor): worn footwear sets lifted_feet (clothing §6); bare feet are flat, except while one of the creator's idles plays, when the request asks for the creator puppet's feet (puppet: "creator", the feet group its character_creation group lists: lifted), because those clips are authored for them (body animation §4). No option, mod or resource is named: a body replacer, a UV framework or a nails framework resolves by archive precedence and ArchiveXL patches like everything else.

Textures: the host serves a texture larger than 4096 on a side halved until it fits (2×2 means of its bytes, like a mip level; SERVED_TEXTURE_MAX, once per export), and says so in the record's notes. The halving streams (decodePngHalved: rows are unfiltered and halved as zlib inflates them on its thread pool, so an 8K map never costs its 256 MB decoded) and the result is compressed on the thread pool too, before the record is written, so the host's event loop keeps serving. Every vanilla head, face and eye map is at most 4096², so the head is served as before.

Materials: the body's skin parts use the head's skin adapter (skin-material.ts: the same tone tint, detail and microdetail arithmetic, the same dual-lobe light and subsurface stand-in); layered chunks (the personal link, layered nail designs) the layered adapter; the body's decals (tattoos, scars, the underwear cover) the face decals' decal family, lit by the body skin's light and blended against the skin under each vertex, read on the body, feet and arms (skinSurfaceUnderlay).

Shape: each body component's influences are the record's morphs at full weight; the body never follows the head's facial shapes. A body decal with no shape keys of its own (the underwear cover, a plain garment) gets the body skin's applied shape carried over from the nearest body vertex as one shape key, xfs_body_shape (transferDeltas), so the cover stays over an enlarged breast [hypothesis: an approximation of the game's garment support, which pushes a garment out over the body; the cover carries garment-support data of its own]. The body's shape field and its search grid (VertexGrid: numeric cells over the body's bounds; a vertex outside them is unmatched without a search) are built once per load. A garment is reused across loads while the body's shape (its meshes and applied shape keys) is unchanged, whatever its chunk masks, so a clothing change doesn't bake every garment again; the field comes from the body chunks served, so a garment over a chunk another item hides takes its shape from the nearest shown chunk [hypothesis: small at full-body framing; not compared with the game].

Rig and idle resource [offline]: WolvenKit 9.0.1 exports each body part with its joints flat under the armature. The main joints (Hips, Spine…, LeftArm, LeftForeArm, LeftHand, Neck and so on) have the same names and the same rest transforms as the woman_base.rig the idle clips are decoded with (measured within 0.001 of a metre and of a quaternion component), so the idle drives them directly. The idle is one of the game's preview idles, chosen in the Motion panel (the creator's close-up by default, the creator's full body and nails loops, gender selection, the inventory's; body animation §2). Their helper, muscle and twist joints (l_deltoid_…_JNT, l_Wrist_0_JNT, the knuckle joints) are not in that rig: the game solves them with the player's deformations rig, and the preview evaluates that rig's graph from the game's own files (deformation-rig.ts, served with the record as rigs; body animation §3). Only without it does a helper joint move rigidly with the rig segment nearest it (IdleAnimation.nearestDriver), which turned the latissimus, scapula and chest joints with the upper arm and pinched the torso's sides under the ribs. With the idle off, the body stands in the bind pose (the arms at about 45°).

Rigid parts: a morph target whose first export has no skin is exported again from its own raw copy with the game folder, which gives WolvenKit the base mesh's rig: the reference profile's nails (a nails morph mod) then follow their fingertip joints (body animation §5). A body part still without a skin after that is bound whole to one bone at its centre, which the idle moves with the nearest rig segment (rigid-body-part); a rigid piercing part stays where the export placed it (rigid-part).

Scene: the body shows by default and has its own visibility toggle (preview.setBody, the Character panel's Body); the whole-body view (camera.body: the viewport toolbar, the Preview panel, the head menu and the command palette; refused while the body is off) frames a standing V at the current lens; while the body shows the depth range covers it (bodyClipPlanes), and the head views keep exactly their planes. The orbit reaches 5 m (it was 3.5 m) so the whole body fits at the default lens.

What it looks like (the body fidelity pass: body animation and private captures evidence/screenshots/body-fidelity/, the reference V with the torso's sides smooth, flat feet in the inventory idle, lifted feet in the creator's and the nails on the fingertips; earlier, reference MO2 profile, default V and a V with senna tone, body tattoo 1, body scar 1, big breasts, long nails and a layered nail design; private captures evidence/screenshots/body-render/): the neck joins the head without a visible seam and the tone matches; the body, feet, arms, hands and nails align with the head in the bind pose and in the idle; the underwear covers the chest and groin at every breast size; tattoos and scars follow the breast shape. Not compared with the game.

5. What clothing uses from the body (the four requirements)

The clothing render plan needed four things from the body, and gets them without special cases (worn clothing §6):

1. Components by resource name: every body component keeps its component name and depot path in the record (t0_000_pwa_base__full, a0_001_pwa_base_hq__full, l0_000_pwa_base__cs_flat, i0_000_…), so tag rules can match names and prefixes.
2. Chunk masks as data: the resolver applies each component's chunk mask (ResolvedComponent.chunkMask → the record's chunks), and the served geometry is a chunk copy of the cached export, so a tag or partsOverrides mask re-plans and re-copies without exporting again. Drawing all chunks and hiding by mask at draw time would need the resolver to resolve the masked chunks' materials too.
3. Feet state: BodyState.feet picks the feet group (flat_feet or lifted_feet); the HighHeels and FlatShoes tags mask body chunks 5–7 and show the matching l0_ chunks instead.
4. Garment support: the arms, feet and the cover carry _GARMENTSUPPORTWEIGHT, _GARMENTSUPPORTCAP and a GarmentSupport shape key in their exports resource; nothing reads them yet, and the loader keeps every attribute, so a later per-vertex offset has its data.

Open questions

1. Which rig resource drives the body's helper and twist joints? Answered resource [offline]: every player puppet's deformations component, woman_base_deformations.rig with woman_base_deformations.animgraph, which the preview now evaluates; the inferred node semantics reproduce the rig's A pose for 179 of 181 joints (body animation §3). Still open: the semantics away from the A pose, checked against the game in strong poses.
2. How does the game move the underwear cover over a changed breast shape: its garment-support data, or a morph the preview doesn't read?
3. Does the running game draw exactly the parts §1 lists for a V without clothing (for example, no seam-fix component at the shoulders)?
4. Does the arms' holster state follow equipped arm cyberware alone? Mostly answered resource source: the equipped ArmsCW item's holsteredItem names the group through its appearanceName (§1.1). Still open: the native step from that item to the group, how the drawn state picks the unholstered_* groups, and which state the creator puppet uses (default by the same rule hypothesis).
5. Why does WolvenKit export the reference profile's nails morph target without its skin? Answered [offline]: the export. The morph target carries a fingertip skin; WolvenKit writes it only with the game folder, which the first export omits (body animation §5).
6. Which archive wins each body texture on the reference profile? §2 attributes the body maps to the KS UV framework's player-only chain, while the head CC evidence records an installed Arkhe body complexion package (##_Arkhe_UniversalSkinTone_BODY_FAIR.archive) that replaces body, arm, nipple and genital albedos at their own paths. Whether it ships the vanilla t0_000_wa__c_base_d02 paths or the framework's d02_naked ones is not recorded; an archive listing settles it offline.
7. Why doesn't the preview draw the head's seam-fix part? Answered resource: both hold. Its material is metal_base.remt, and both chunks are MCF_RenderInShadows only, so the render-mask rule skips it (§1).

In-game test asks

Batch with the next session; record ArchiveXL and the body, UV and nail mods in use.

1. Body against the preview. Photo mode, a V without clothing (strip every slot), frontal and side full-body frames under one light: compare with the preview's whole-body view (studio and creator presets): tone match at the neck and wrists, the feet shape (flat), the underwear's coverage.
2. Breast size under the underwear. Creator body page, big breasts: the underwear must cover as in the preview; a gap in game but not in the preview (or the reverse) answers open question 2.
3. Idle arms. Creator face page idle, a close-up of a shoulder, the torso's side under the ribs and a wrist: the deltoid, latissimus and wrist shapes against the preview's evaluated deformation rig.
4. Holster state. A V with Gorilla Arms equipped, weapon holstered, third-person photo mode: the forearms must show the Gorilla Arms plating (holstered_strong_tpp), not bare arms. Then draw the fists once to see the unholstered_strong shape. Record which arm cyberware the save has.
5. Uncensored parity. With the game's nudity setting allowed, a V without clothing in photo mode, frontal full-body frame: compare with the preview with "Show my V uncensored, as the game can" on (nipples, genitals and the skin as chosen, no underwear). Keep the captures private.
6. Framework arms (PIPE-106). On the reference profile, a close-up of both forearms and hands: the skin must be continuous from the shoulder to the fingers, with no foot or dark patches, as the preview now draws them.

Related pages

Head CC rendering · CC file chain · Worn clothing · Tattoos · Materials and shaders · Facial animation · Body render evidence