Skin and makeup on spawned objects

Maturity: Draft. How an object placed or spawned in the world can show a character's skin and makeup: a copy of V that follows the player's own creator choices, a static head built from explicit mesh components, and what XF Finish Showroom builds from the second. Consolidated on 28 September 2026 from the installed 2.31 game (with Phantom Liberty) read with WolvenKit CLI 9.0.1 and XF Studio's TweakDB reader, the installed mod V's Faceplate (H10) 1.1.0 read in place, the Codeware source and the XF Finish Showroom build. The static route (§2, §4) has been seen in game through XF Finish Showroom in sessions 5 and 6 (29 September 2026, experiment 032); the replica route (§1) has not, beyond the mod's own result reported by the maintainer (the face in the tank looks right). Grades follow the knowledge rules; [installed] is a mod package in the reference MO2 instance, read only (paths inside mods/<mod name>/).

This page answers: can a prop in the world show skin and makeup the way V's own head does, and what exactly does it take?

In brief

• There are two routes, and they answer different questions.
  • A replica of V is an entity with no meshes of its own, only the character creator's controllers. It shows whatever V wears in the creator right now: her head, skin and every face decal, XF Eye Artistry included. The game uses it for V's head in a tank in Phantom Liberty, and V's Faceplate (H10) places that same vanilla entity in V's apartment. resource [installed]; that the controllers copy the player's state is [hypothesis, strongly supported].
  • A static head is an entity whose appearance lists the head, eyes and decal meshes explicitly, skinned to a head rig. It shows exactly the meshes and mesh appearances it names, whatever V wears. The game's own shop mannequins are built this way. resource
• Only the static head can show several looks at once. Every replica follows the one creator state, so a lineup of replicas would all wear V's current preset. A lineup of different presets needs static heads, one mesh appearance each. XF Finish Showroom uses that route (§4).
• Nothing special is needed for skin or decals on a static entity. The head mesh's own appearance picks the skin material (tone and type), and a mesh_decal plate drawn after it writes into the same surface buffer as on V. ArchiveXL expands the plate's {material} texture paths when the mesh loads, wherever it is used. resource source; in game the result matches V's head closely enough to judge finishes (the showroom's fidelity check, §4.3) runtime.

1. The replica route: V's head in a tank

1.1 The vanilla entity

Phantom Liberty's quest data holds two TweakDB character records, Character.q304_v_head_in_jar_wa and Character.q304_v_head_in_jar_ma, in tweakdb_ep1.bin [resource, read with tweakdb-flats.ts]:

The template resource (feminine SHA-256 4f53133c…, masculine 15d41cd2…):

With no mesh of its own, anything the entity draws comes through its controllers. The face group is the one XF Eye Artistry registers its selector in, because the player entities' face controller reads it in gameplay and photo mode (package-resources.ts SELECTOR_GROUPS; CC file chain). So a replica is expected to show V's current look: skin, face decals, makeup and the XF selector's preset alike. [hypothesis, strongly supported: the entity's composition, and the mod's own description that "the face in the tank is dynamic and personal to your V"]

1.2 How V's Faceplate (H10) places it

V's Faceplate (H10) by MisterChedda (Nexus mod 24599, version 1.1.0; the author is named by the archive's own paths, misterchedda\v_faceplate\…, and by the creator link on its description) keeps the faceplate from the Phantom Liberty quest "Birds with Broken Wings" in V's H10 apartment stash room. It ships no mesh, texture or entity: its 20 KB archive holds six resources, and everything it shows is vanilla [installed] (archive/pc/mod/v_faceplate.archive, SHA-256 442f3be0…; v_faceplate.archive.xl, 746f32c5…).

So the mod's technique is placement, not rendering: the same entity, animation and tank the quest uses, in a new place, with a quest phase that spawns and poses it. V's skin and makeup reach it the way they reach the quest's own copy. [installed] How the rest of the body is kept out of view in the tank (hidden by a controller or the workspot, or simply framed by the tank) was not traced.

1.3 What the route is good for

2. The static route: the shop mannequin

The game's clothing mannequins show a real NPC head on a posed body resource (basegame_4_gamedata.archive, base\environment\decoration\small_shops\stands\mannequin_real\):

• mannequin_real_woman_a_censored.ent: an entEntity whose one component is an entCorpseComponent named root, with its appearance in a generated .app.
• The source .app (sources\mannequin_real_woman_a.app, appearances default and doggy) lists the head's parts explicitly: an entAnimatedComponent face_rig with the NPC head's own skeleton rig, woman_average_sermo.animgraph and the head's .facialsetup, parented to root; the head mesh (entGarmentSkinnedMeshComponent), eyes, teeth, brows and the freckle decal (entSkinnedMeshComponent), each with its parent transform and skinning bound to face_rig; the body, nails and a proxy mesh bound to root.
• generated\head\h0_009_wa_c__young.ent holds the same head parts, including the eye-makeup, lip and pimple decal meshes, bound to an external component.

Nothing reads the player's state: each mesh shows the mesh appearance the component names. That is the pattern a showroom head needs.

The player's head fits it. Every bone the feminine player head (h0_000_pwa_c__basehead.mesh, 254 bones) and her eyes (he_000_pwa_c__basehead.mesh, 57 bones) skin to is in the head's own skeleton rig, h0_000_pwa_c__basehead_skeleton.rig (344 bones) resource. In that rig's reference pose the Head joint sits 1.640 m above the rig root and the eye joints at 1.691 m, and the head mesh's bounds run from 1.462 m (the neck's cut) to 1.830 m, so a head skinned to that rig stands at a person's height above the entity's origin, facing +Y [resource; arithmetic offline]. The XF eye plate is cut from the same head with the same bones and skin bytes (plate), so it skins to the same rig and lands exactly on the head.

Skin on a static head comes from the head mesh's own appearances resource (head CC rendering §2): 60 local materials, one per tone and type, named like 01_ca_pale (type 1) and 03_ca_senna_d03 (type 3). 01_ca_pale has TintScale 0, so its skin is the albedo untinted; any other tone can be chosen by name.

Decals on a static head. The plate's mesh_decal material writes into the surface buffer after the skin, as vanilla makeup does on NPC heads (materials §4). Its textures are soft paths with {material}, which ArchiveXL expands in its mesh-loading hook for any mesh, not only those in a creator scope (mod loading §5) source. The same holds for the mesh-appearance stubs that ArchiveXL expands from the seed appearance.

3. Spawning at run time

Static spawning is asynchronous: SpawnEntity returns an ID at once and the entity exists a few frames later (IsSpawned, GetEntity) source. A spawned gameObject can be moved and turned with the teleportation facility, as CharLi moves its lights (photo-mode lights §3) [installed].

4. What XF Finish Showroom builds

XF Finish Showroom is XF Studio's in-game test equipment for judging makeup finishes side by side. It follows the static route; the build and its checks are in the pipeline guide, the commands in the runtime bridge.

4.1 One entity, one appearance per preset

The heads are feminine for now: the plate the pipeline prepares first is hers. Vanilla meshes are referenced by path, never copied.

What sessions 5 and 6 showed (29 September 2026, experiment 032) runtime:

• The heads spawned through Codeware in normal play and in photo mode, faced the camera or V, and wore their eyes, lashes and makeup.
• In session 5 every head drew a few centimetres above its column, which then topped out 8 mm above the neck's cut, so the head draws higher than the rig's reference pose puts it; why (the face rig's pose without animation) is a hypothesis. The 0.5.2 build seats the neck 6 cm into a taller column, and in session 6 the neck sat in its column with no gap.
• The heads looked slightly larger than V at the "same" distance: the bridge measured that distance to the entity's origin, about 13 cm behind the face, and horizontally. Since 0.5.2 it places each head's eyes at the distance asked, in 3D, as photo.frame's distance_m measures to V [offline].
• Height is not yet right by default. 0.5.2 raises each head to the camera's eye line (height_from: "camera"), which put the eyes about 0.18 m too high (the frame showed the neck); for a head 1.3 m in front of the photo-mode camera, a height of 1.9 m above the base framed the face, 1.75 m was too low. The default probably counts the eye offset twice; the bridge track owns the fix.
• Lit by the creator rig at that framing, the heads separate Gloss A (wet streaks) from Gloss C (flat), show the Shimmer grain as a pearly sheen with no dot grid, and show the Glitter board's flecks: close enough to judge finishes (the verdicts are in the experiment page). A nine-head lineup under the shared key light, 2.8 m away, was too dark to judge, and at the card's 1.6 m it didn't fit the frame.

4.2 Light rigs as templates

Each rig is an entity of entLightComponents with every native field set at build time from the creator rig table (creator lighting §2): positions and spot axes converted from the Studio frame to the entity's (Studio (x, y, z) = local (x, −z, y)) and moved so the rig's head slot (1.62 m) sits on the showroom head's Head joint (1.640 m). The rig is spawned at a head's origin and facing, so every head gets the same light in its own frame. Baking the rig into templates avoids adding components at run time, which the lighting mirror needs for arbitrary Studio setups. Whether a spot's axis is its +Y for a spawned component is the mirror's open question too hypothesis.

Identical light has a price in spacing. A rig per head also lights the neighbours. With the engine's decoded falloff and cone forms (full-angle reading, Φ/4π), the full creator rig's rims and fills add about 90 % of a head's own light from neighbours 0.9 m away, 9 % at 2 m and under 1 % beyond about 3 m, while the key light alone (Main_Face, a 45° cone from about 1 m) adds none at 0.6 m [offline: tools/showroom/plan.ts, direction and shadows ignored]. So a lineup is judged side by side under the key light, and under the full rig one head at a time, or a few heads 3 m apart; the bridge's showroom.light reports the estimate for each placement.

4.3 The fidelity check

A showroom head beside V, both wearing the same preset under the same rig, tests whether the static route shows makeup as V's head does. A replica (§1) would be a third reference that needs no preset of its own, but it needs Phantom Liberty and a quest-free way to spawn it; it is left as an option.

Result: pass runtime (session 5, F5–F8). A head beside V, both wearing Gloss A · as before, under the same key light and then the creator rig on each in turn, with a five-step sweep of the head. The maintainer's verdict: "you pretty well nailed the mannequin head's materials." So a showroom head is a fair stand-in for V when judging a finish, and finish verdicts can come from showroom close-ups instead of per-finish creator visits. Skin scattering, ambient occlusion and the creator's render target still differ from V's in principle; nothing in the comparison showed them.

Open questions

1. Do the creator controllers copy the player's state into any entity that carries them, and when (spawn, appearance change, each frame)? A replica spawned by DynamicEntitySystem from Character.q304_v_head_in_jar_wa would answer it, and would show whether it follows a creator change live.
2. How is the replica's body hidden in the tank: controller settings, the workspot's animation, or only the tank's framing?
3. Does an entAnimatedComponent with the player head's rig, graph and facial setup, and no animation driving it, hold the reference pose, as the shop mannequin's face appears to? The face looks right in game, but the head draws a few centimetres higher than the reference pose puts it (§4.1) runtime; why is open.
4. Does a static head lit by the same rig show a preset's finish as V's head does? Yes, well enough to judge finishes (§4.3) runtime.
5. Does a skinned mesh in a plain entMeshComponent (World Builder's mesh spawnable) draw in its bind pose? That would allow heads without a rig component.

Sources

• Game 2.31 with Phantom Liberty: tweakdb_ep1.bin; ep1_2_gamedata.archive (the q304 templates); basegame_4_gamedata.archive (the shop mannequin); basegame_4_appearance.archive (the player head, eyes and head rig). Read with WolvenKit CLI 9.0.1 (unbundle --hash, convert serialize) and tweakdb-flats.ts.
• V's Faceplate (H10) 1.1.0 (Nexus 24599, file 123152) in the reference MO2 instance, read only; its six resources converted to JSON in a private scratch folder.
• Codeware v1.20.4 (613a1cb8): scripts/World/StaticEntitySpec.reds, StaticEntitySystem.reds, src/App/World/StaticEntitySystem.cpp.
• Who made each and what it taught us: community credits.

Related pages

World and streaming · Head CC rendering · CC file chain · Creator lighting · Photo-mode lights · Runtime access