Character Mesh Replacement

Intermediate40-60 minutesWindowsNotepad++Unity Editor

Unturned™ provides a mechanism for entirely replacing the player's character mesh through a specialized shirt item configuration. This system, termed character mesh replacement, allows a modder to substitute the default player model (the base human character mesh that every player sees in first-person and third-person views) with a custom mesh of the modder's own design. The replacement is not a cosmetic overlay or a texture swap. It is a complete substitution of the character's geometry: the skeleton remains the same, and the engine continues to drive the same animation rig, but every polygon rendered for the player's body is supplied by the modder's replacement mesh rather than by the vanilla character model.

57 Studios™ has documented and validated the character mesh replacement subsystem across the Unturned™ modding community. This article covers every field specific to the mesh-replacement configuration, the first-person and third-person prefab requirements, the material override system, hair and beard visibility control, the integration points with the broader clothing system, the documented limitations of the replacement system, a complete worked example, and a diagnostic reference for common mesh-replacement failures. The shared shirt-item fields that accompany the mesh-replacement fields (GUID, ID, Type, Rarity, Slot, Size_X, Size_Y, and the clothing-slot designation) are documented in Item Asset Property Reference and Clothing Asset Reference; this article focuses exclusively on the fields that enable character mesh replacement.

Documentation source: This article references the official Smartly Dressed Games modding documentation for the character mesh replacement specification (Chapter 92) and the CharacterMeshReplacementTest item (ID 1522). The prefab-naming conventions, LOD indexing scheme, and material-override behavior are drawn directly from the SDG documentation. Example source files are included in the ExampleAssets.unitypackage under the Shirts directory.

Who this article is for

This article is written for Unturned™ mod authors who have completed at least one clothing mod using the standard clothing asset pipeline and who understand the shared item property surface documented in Item Asset Property Reference. The article presupposes that the reader can author a Unity prefab with a MeshFilter component, configure LOD groups, export a master bundle, and author a shirt .dat file with the standard clothing fields. Readers new to clothing modding should start with Clothing Asset Reference and return here once the standard shirt-authoring workflow is familiar.

What you will learn

• How the character mesh replacement system works at the engine level and why it is restricted to the shirt clothing slot
• The five configuration fields that enable and control mesh replacement, with type, required designation, and behavioral semantics
• The prefab authoring requirements for first-person (Character_Mesh_1P_Override_0) and third-person (Character_Mesh_3P_Override_N) replacement meshes
• How the material override system interacts with the standard clothing texture pipeline
• Hair and beard visibility control and how it integrates with the replacement mesh's head geometry
• The documented limitations of the system: the shirt-slot restriction, the first-person arms-only requirement, and the animation-binding constraint
• A complete worked example with annotated .dat file, prefab hierarchy, and material configuration
• A diagnostic reference and FAQ covering the most common mesh-replacement failures

How the character mesh replacement system works

The character mesh replacement system operates at the rendering layer of the Unturned™ player model. When a player equips a shirt item that carries the mesh-override fields, the engine performs a sequence of asset lookups and mesh substitutions that replace the default character geometry with the modder's custom geometry. The system is distinct from the standard clothing system, which overlays clothing meshes on top of the base character mesh; mesh replacement removes the base mesh entirely and substitutes the replacement mesh as the new rendering surface.

The system is restricted to the shirt clothing slot for a documented reason: Unturned™ loads only the shirt-equipped model for first-person view rendering. The pants slot, the hat slot, the mask slot, and every other clothing slot are not loaded for the first-person camera; they are visible only in third-person view and in the inventory-paper-doll preview. Because character mesh replacement must affect both the first-person and third-person views to produce a consistent visual result, and because only the shirt slot is loaded in both view contexts, the system is necessarily confined to shirt items.

The sequence diagram above traces the full mesh-replacement chain from equip to render. The engine loads the first-person mesh and the third-person meshes from the shirt item's master bundle, optionally loads a custom material, and then substitutes the loaded geometry for the default character mesh at the renderer level. The animation skeleton is not affected; the replacement meshes are skinned to the same bone hierarchy as the vanilla character mesh, and the same animation clips drive their deformation.

The first-person versus third-person mesh split

The character mesh replacement system distinguishes sharply between the first-person and third-person replacement meshes. The first-person mesh (Character_Mesh_1P_Override_0) is loaded when the camera is in first-person view and renders the player's arms and hands as seen from the player's own perspective. The third-person meshes (Character_Mesh_3P_Override_0, Character_Mesh_3P_Override_1, etc.) are loaded when the camera is in third-person view and when the character is viewed by other players, and render the full body.

This split exists because the first-person and third-person camera perspectives impose different rendering requirements. The first-person view renders the player's arms and hands at very close range, filling a large portion of the screen, and must preserve the spatial relationship between the weapon, the hands, and the camera frustum. The third-person view renders the full character body at variable distances, from close-up (other players nearby) to distant (players at the edge of the draw distance), and must scale across multiple LOD levels.

The split also accounts for the animation-binding constraint: in first-person view, only the arms and hands of the player character are animated; the torso, legs, and head are culled and not rendered at all. A first-person replacement mesh that includes a full body model (torso, legs, head) will have those body parts culled by the renderer and will appear incomplete when the camera switches to first-person view. The documented requirement that the first-person replacement mesh "should only contain the arms because the rest of the body is not animated" (SDG, Chapter 92) is a rendering constraint, not a validation rule: the engine does not reject a full-body first-person mesh, but the non-arm geometry is invisible and wasted.

Mesh-replacement field reference

The five fields that control character mesh replacement are documented below. These fields are placed in the shirt item's .dat file alongside the standard shirt fields. They are specific to the character mesh replacement subsystem and are not recognized by any other clothing slot or item type.

Field	Type	Required	Default	Purpose
Has_1P_Character_Mesh_Override	bool	Conditional	false	When true, the engine attempts to load a prefab named Character_Mesh_1P_Override_0 from the item's master bundle and uses it as the first-person character mesh. The prefab must carry a MeshFilter component with the replacement arms mesh. This field must be true for mesh replacement to activate; setting only the third-person override fields without this field produces no visible effect.
Character_Mesh_3P_Override_LODs	uint8	Conditional	0	The number of third-person LOD levels to load from the master bundle. When set to a value greater than 0, the engine loads prefabs named Character_Mesh_3P_Override_0, Character_Mesh_3P_Override_1, and so on, up to the count specified. Each prefab must carry a MeshFilter component with the replacement body mesh for that LOD level. A value of 1 loads a single LOD (no distance-based switching). A value of 3 loads three LODs for near, medium, and far rendering distances.
Has_Character_Material_Override	bool	Optional	false	When true, the engine attempts to load a material named Character_Material_Override from the master bundle and applies it to both the first-person and third-person replacement meshes. When false (or when the field is absent), the engine uses the equipped shirt and pants textures as the material for the replacement meshes, which applies the standard clothing-texture pipeline to the replacement geometry.
Hair_Visible	bool	Optional	See description	Controls whether the player character's hair mesh is rendered when the replacement mesh is active. When true, the vanilla hair mesh is rendered on top of the replacement mesh. When false, the hair mesh is hidden. The default behavior when the field is absent depends on the shirt item's configuration; a shirt that uses the standard clothing system typically shows hair, but a mesh-replacement shirt may configure this field explicitly to prevent the vanilla hair from clipping through the custom head geometry.
Beard_Visible	bool	Optional	See description	Controls whether the player character's beard mesh is rendered when the replacement mesh is active. The same behavior and defaults as Hair_Visible, but for the beard mesh. Use false when the replacement mesh includes its own facial-hair geometry or when the vanilla beard would clip through the custom face mesh.

The two conditional fields (Has_1P_Character_Mesh_Override and Character_Mesh_3P_Override_LODs) are conditional in the sense that the mesh replacement system activates only when Has_1P_Character_Mesh_Override is true. Setting Character_Mesh_3P_Override_LODs to a value greater than 0 without also setting Has_1P_Character_Mesh_Override to true leaves the third-person mesh override configured but inactive, because the activation gate is the first-person flag.

Prefab authoring requirements

The mesh replacement system loads prefabs from the shirt item's master bundle by fixed naming convention. The modder does not specify the prefab names in the .dat file; the engine constructs the names internally based on the override fields and the LOD index.

First-person prefab: Character_Mesh_1P_Override_0

The first-person replacement mesh prefab must be named Character_Mesh_1P_Override_0 and must be present in the master bundle. The prefab's root GameObject must carry a MeshFilter component with the replacement arms mesh assigned. The following hierarchy is the minimum required structure:

Character_Mesh_1P_Override_0 (root GameObject)
└── MeshFilter (with replacement arms mesh)
└── MeshRenderer (configured with the replacement material or left empty for material override)

The replacement arms mesh must be authored with the following constraints:

Constraint	Requirement
Bone binding	Skinned to the standard Unturned™ arm skeleton (shoulder, elbow, wrist, finger bones). The bone names and hierarchy must match the vanilla character skeleton exactly.
Polygon scope	Arms and hands only. The torso, legs, neck, and head must not be included in the mesh. Polygons outside the arm region are culled by the first-person renderer and contribute unnecessary draw calls.
UV layout	Match the standard Unturned™ character UV layout if the material override is disabled (the engine will apply shirt and pants textures to the UVs). If a custom material override is used, the UVs can follow any layout the modder prefers.
Pivot orientation	The mesh must be authored in the same coordinate space as the vanilla character mesh, with the arms extending forward along the weapon-aiming axis.
Scale	Model at real-world scale. The vanilla character arms are approximately 0.7 meters from shoulder to fingertip.

A common authoring mistake is to include the entire body mesh in the first-person prefab and rely on the renderer to cull the non-arm geometry. While the culling does occur, the non-arm polygons still contribute to the draw-call count and increase the bundle size with geometry that is never rendered. The arms-only constraint is a performance optimization as much as a rendering requirement.

Third-person prefabs: Character_Mesh_3P_Override_N

The third-person replacement mesh prefabs follow the naming convention Character_Mesh_3P_Override_0, Character_Mesh_3P_Override_1, Character_Mesh_3P_Override_2, and so on, where the numeric suffix is the LOD index. The number of prefabs loaded is controlled by Character_Mesh_3P_Override_LODs. For a replacement with three LOD levels, the bundle must contain Character_Mesh_3P_Override_0, Character_Mesh_3P_Override_1, and Character_Mesh_3P_Override_2.

Each LOD prefab must carry a MeshFilter component with the full body replacement mesh for that LOD level. The LOD 0 mesh is the highest-polygon, highest-detail model, rendered when the character is near the camera. The LOD 1 mesh is a reduced-detail version rendered at medium distances. The LOD 2 mesh (and any further LODs) is the lowest-detail version rendered at long distances where individual polygons are no longer distinguishable.

LOD index	Typical triangle count	Typical rendering distance
LOD 0	8000-15000 tris	Near (0-20 meters)
LOD 1	3000-6000 tris	Medium (20-60 meters)
LOD 2	1000-2000 tris	Far (60+ meters)

The triangle counts above are illustrative guidelines. The actual count depends on the replacement mesh's complexity, the target platform (PC versus console), and the server's configured rendering distance. The cohort recommendation is to author LOD 0 at the full detail the modder intends, LOD 1 at roughly 40% of the LOD 0 triangle count, and LOD 2 at roughly 15% of the LOD 0 triangle count. Automated mesh-decimation tools in Blender (the Decimate modifier) produce acceptable LOD reductions for character meshes when the resulting topology is manually cleaned.

The third-person prefab hierarchy follows the same minimum structure as the first-person prefab:

Character_Mesh_3P_Override_0 (root GameObject)
└── MeshFilter (with replacement body mesh for LOD 0)
└── MeshRenderer (configured with the replacement material or left empty for material override)

LOD switching behavior

Unturned™ handles LOD switching for replacement meshes the same way it handles LOD switching for all other rendered objects: the engine selects the LOD level based on the distance between the camera and the character's bounding-box center, falling back to a lower LOD as the distance increases. The LOD-switching thresholds are determined by the engine's quality settings and the player's configured render distance. Modders cannot set custom LOD-switching distances through the .dat file; the thresholds are engine-managed.

If a LOD prefab is missing for an index that Character_Mesh_3P_Override_LODs specifies (e.g., Character_Mesh_3P_Override_LODs is 3 but only LODs 0 and 1 exist in the bundle), the engine falls back to the highest available LOD for the missing distance band. This fallback behavior means that a modder can author only LOD 0 and set Character_Mesh_3P_Override_LODs to 1 to disable distance-based LOD switching entirely, which is acceptable for single-player or local-server testing but is discouraged for published mods that will be used on multiplayer servers with variable player distances.

Material override system

The material override system controls what surface material is applied to the replacement meshes. The system has two modes, selected by the Has_Character_Material_Override flag:

Mode 1: Standard clothing-texture pipeline (Has_Character_Material_Override is false or absent). In this mode, the engine applies the equipped shirt and pants textures to the replacement meshes using the standard Unturned™ clothing material. The shirt texture is mapped to the upper-body UV region, and the pants texture is mapped to the lower-body UV region, using the same UV-mapping convention as the vanilla character mesh. The replacement mesh must be UV-unwrapped to match the vanilla character UV layout for the clothing textures to map correctly. If the replacement mesh has a different UV layout, the clothing textures will appear stretched, misaligned, or inverted on the custom geometry.

Mode 2: Custom material override (Has_Character_Material_Override is true). In this mode, the engine loads a material named Character_Material_Override from the master bundle and applies it to both the first-person and third-person replacement meshes. The equipped shirt and pants textures are ignored for the replacement mesh and are not rendered. The custom material is authored entirely by the modder and can use any shader, any texture set, and any material properties that the bundle's Unity shader supports.

The flowchart above traces the material-resolution path. Mode 1 (standard pipeline) is useful when the replacement mesh is a minor variation on the standard humanoid body and the modder wants the player's chosen shirt and pants textures to continue to appear on the replaced character. Mode 2 (custom material) is useful when the replacement mesh is a radically different creature, robot, or entity whose surface appearance is not compatible with the clothing-texture pipeline.

Material override and skin support

A mesh-replacement shirt item can support Workshop skins through the standard skin system, but the interaction between the skin material and the character material override requires careful configuration. If Has_Character_Material_Override is true, the skin's material replaces the Character_Material_Override material for the replacement mesh, which is the expected behavior: a skin applied to the shirt item should change the character's appearance. If Has_Character_Material_Override is false, the skin applies to the shirt item's clothing material, and that material continues to be mapped onto the replacement mesh using the UV-mapping conventions of the clothing-texture pipeline.

Hair and beard visibility

The Hair_Visible and Beard_Visible fields control whether the vanilla hair and beard meshes are rendered when the replacement mesh is active. The default hair and beard meshes are separate geometry from the character body mesh; they are rendered as additional mesh instances on top of the body surface. When a mesh-replacement shirt is equipped, the replacement body mesh substitutes for the vanilla body, but the hair and beard meshes are not automatically hidden. They continue to render at their default positions on the skeleton unless explicitly hidden by the .dat configuration.

The most common hair-and-beard configuration for mesh-replacement shirts:

Replacement type	Hair_Visible	Beard_Visible	Rationale
Full-body human character with custom head	false	false	The replacement mesh includes its own head geometry; the vanilla hair and beard would clip through or float above the custom head.
Creature or non-human entity	false	false	The replacement entity does not correspond to a human head and should not display human hair or beard meshes.
Robot or mechanical character	false	false	The same rationale: no human facial hair on a mechanical surface.
Partial human override (arms and torso only)	true	true	The replacement mesh does not include head geometry; the vanilla hair and beard should continue to display normally.
Cosmetic shirt with no head override	true	true	The replacement mesh affects only the body; the head geometry is the vanilla head, and hair and beard should remain visible.

The hair and beard meshes are attached to the character's head bone in the skeleton. If the replacement mesh's head geometry is authored at a different scale or position than the vanilla head, the hair and beard meshes will be offset from the custom head even when visible. The only reliable way to position hair and beard correctly on a custom head is to include the hair and beard geometry directly in the replacement mesh and set Hair_Visible and Beard_Visible to false. This approach eliminates the position-mismatch problem entirely, because the hair and beard are part of the same skinned mesh as the custom head.

Integration with the clothing system

The character mesh replacement system does not replace the clothing system. It operates alongside it. When a mesh-replacement shirt is equipped, the following interactions occur between the replacement mesh and the player's other equipped clothing items:

Clothing slot	Interaction with replacement mesh
Hat	The hat continues to render on the character's head bone at its standard attachment point. If the replacement mesh's head is larger, smaller, or positioned differently than the vanilla head, the hat will float above, sink into, or be offset from the custom head geometry. Modders who create replacement meshes with non-standard head proportions should test hat compatibility explicitly.
Mask	The mask continues to render on the character's face bone. The same scaling and positioning considerations as the hat slot apply: a replacement mesh with a non-standard face shape will produce mask clipping or floating.
Vest	The vest renders as an overlay on the character's torso. If the replacement mesh's torso geometry is substantially different from the vanilla torso, the vest will clip through or float above the replacement body.
Backpack	The backpack renders on the character's back. The same positioning considerations as the vest slot, with the additional factor that the backpack's attachment point may be inside, on the surface of, or floating above the replacement mesh's back geometry.
Pants	The pants texture is applied to the lower-body UV region of the replacement mesh (in Mode 1) or is not rendered (in Mode 2). The pants mesh itself (a separate clothing mesh on the legs) continues to render and may clip through the replacement mesh's leg geometry.
Glasses	The glasses render on the character's face. The same head-geometry considerations as the hat and mask slots.

As shown in the flowchart above, every other clothing slot continues to render independently when a mesh-replacement shirt is equipped. The replacement mesh and the clothing items share the same animation skeleton, which means the clothing items follow the skeleton's bone positions correctly. The visual mismatch arises only from geometric differences between the replacement mesh and the vanilla mesh: a clothing item that was authored to fit the vanilla body proportions may not fit the replacement body proportions.

Documented limitations

The SDG documentation identifies two explicit limitations of the character mesh replacement system, and cohort testing has surfaced additional practical constraints.

First limitation: shirt-slot restriction

The mesh replacement system is confined to the shirt clothing slot. A hat, pants, mask, vest, backpack, or glasses item cannot carry mesh-replacement fields; these fields are recognized only by the shirt asset subclass and are silently ignored when placed in any other clothing-slot .dat file. The reason for this restriction is technical: Unturned™ loads only the shirt-equipped model for first-person view rendering. If mesh replacement were available on other clothing slots, the first-person and third-person character views could diverge, producing a first-person view that shows the vanilla arms and a third-person view that shows the replacement body (or vice versa). The shirt-slot restriction guarantees that the first-person and third-person views always agree on the character's body mesh.

Second limitation: first-person arms-only content

The first-person replacement mesh prefab (Character_Mesh_1P_Override_0) should contain only the character's arms and hands. Polygons for the torso, legs, neck, and head are not animated in first-person view and are culled by the renderer. This is not a validation constraint; the engine does not reject a first-person prefab that contains full-body geometry. The constraint is a performance and correctness guideline: non-arm polygons in the first-person prefab contribute unnecessary draw calls and bundle size without producing any visible output.

Additional practical constraints surfaced by cohort testing

The 57 Studios™ modding cohort has identified several additional constraints through testing mesh-replacement shirts in multiplayer environments:

• Animation binding fidelity. The replacement mesh is skinned to the vanilla character skeleton, which has a fixed bone count and a fixed bone hierarchy. A replacement mesh with significantly different body proportions (e.g., a quadruped creature, a serpentine entity, a character with extra limbs) will not animate correctly on the vanilla skeleton. The animation clips that drive the vanilla skeleton assume a humanoid body plan; a mesh bound to that skeleton inherits the same movement range and joint articulation as the vanilla character. Creatures with fundamentally non-humanoid body plans cannot be implemented through character mesh replacement alone.

• View-model weapon alignment. The first-person view renders the player's arm meshes and the equipped weapon model in the same camera frustum. If the replacement arm mesh deviates significantly from the vanilla arm proportions (longer arms, shorter arms, differently-angled wrists), the weapon will appear to float above, sink into, or be offset from the replacement hands. The weapon-to-hand alignment is determined by the skeleton bone positions, not by the mesh geometry, so the replacement arm mesh must follow the skeleton bone positions closely for the weapon to appear correctly held.

• Hitbox consistency. The character mesh replacement changes only the rendered geometry. The player's hitbox (the collision volume used for hit detection by other players' weapons) is derived from the skeleton and a set of capsule colliders that are not affected by the replacement mesh. A replacement mesh that is substantially larger or smaller than the vanilla character will produce a visual mismatch between the rendered body and the collision volume: a large custom creature will have a human-sized hitbox, and a small custom entity will have a human-sized hitbox as well.

• Server-authoritative rendering. On multiplayer servers, the mesh-replacement shirt is a client-side cosmetic change. The server does not validate, enforce, or transmit the replacement mesh data to other clients beyond the standard shirt-item equip message. Each client loads the replacement mesh from its local copy of the shirt item's master bundle. If a client does not have the mod installed, the shirt item renders with its fallback appearance (typically invisible or a default shirt model), and the player appears to other clients as a vanilla-character wearing a default shirt.

Worked example: a complete mesh-replacement shirt

The worked example below demonstrates a complete character mesh replacement for a robot character. The robot has a custom body mesh with mechanical proportions, a custom material with metallic surface properties, and invisible hair and beard.

.dat file

ID 50350
GUID 8f2a1b3c4d5e6f708192a3b4c5d6e7f8
Type Shirt
Name RobotCharacterShirt

Rarity Rare
Slot None
Size_X 2
Size_Y 2

Bypass_ID_Limit

// ── Clothing base fields ──
Armor 0.95
// The robot body provides high damage resistance.

// ── Character mesh replacement fields ──
Has_1P_Character_Mesh_Override true
Character_Mesh_3P_Override_LODs 3
Has_Character_Material_Override true
Hair_Visible false
Beard_Visible false

Prefab hierarchy in Unity

The master bundle for this item must contain four prefabs. The prefab structure in the Unity project before bundle export is:

Assets/
└── RobotCharacter/
    ├── Character_Mesh_1P_Override_0.prefab
    │   └── MeshFilter: Robot_Arms_LOD0 (skinned mesh, arms only)
    │   └── MeshRenderer: (empty, material override handles rendering)
    ├── Character_Mesh_3P_Override_0.prefab
    │   └── MeshFilter: Robot_Body_LOD0 (skinned mesh, full body, 12000 tris)
    │   └── MeshRenderer: (empty)
    ├── Character_Mesh_3P_Override_1.prefab
    │   └── MeshFilter: Robot_Body_LOD1 (skinned mesh, full body, 4800 tris)
    │   └── MeshRenderer: (empty)
    ├── Character_Mesh_3P_Override_2.prefab
    │   └── MeshFilter: Robot_Body_LOD2 (skinned mesh, full body, 1800 tris)
    │   └── MeshRenderer: (empty)
    └── Character_Material_Override.mat
        └── Shader: Standard (Metallic)
        └── Albedo: RobotBody_Albedo.png (1024×1024)
        └── Metallic: RobotBody_Metallic.png (1024×1024)
        └── Normal: RobotBody_Normal.png (1024×1024)

Mesh authoring notes

The robot arms mesh (Robot_Arms_LOD0) is skinned to the standard Unturned™ arm skeleton: the Right_Shoulder, Right_Elbow, Right_Wrist, and right-hand finger bones, and the corresponding left-arm bones. The mesh includes only the upper arm, forearm, and hand geometry; the torso, neck, and head are excluded. The robot's hand geometry follows the vanilla hand proportions closely to ensure that equipped weapons align correctly with the robot grip.

The robot body meshes (LODs 0, 1, and 2) are skinned to the full character skeleton: all spine, neck, head, arm, and leg bones. The body proportions are slightly larger than the vanilla character (approximately 10% taller and 15% wider at the shoulders) to convey the robot's mechanical bulk. The increased proportions mean that standard hats, masks, and vests will appear undersized when worn over the robot body; the mod's item set includes robot-specific hat and vest items that compensate for the larger proportions.

English.dat

Name Robot Character Shirt
Description A complete character mesh replacement that transforms the player into a mechanical humanoid. Replaces the first-person arms and third-person body with custom robot geometry. Suppresses hair and beard rendering.

Testing procedure

1. Build the master bundle in Unity with all four prefabs and the material included. Confirm that each prefab's name in the bundle matches the expected engine lookup name exactly.
2. Copy the bundle and .dat files to the local Unturned™ install's mod folder: Workshop/Content/304930/<modID>/Bundles/ and Workshop/Content/304930/<modID>/Items/RobotCharacterShirt/.
3. Launch Unturned™ in single-player.
4. Open the in-game console with ~.
5. Spawn the shirt: @give 50350.
6. Equip the shirt from the inventory. Confirm that the player character's third-person model changes to the robot body.
7. Switch to first-person view. Confirm that the robot arms and hands are visible and that the equipped weapon aligns correctly with the hands.
8. Test with another clothing item equipped (a hat, a backpack). Confirm that the clothing item renders on the robot body at an acceptable position.
9. Test at variable distances (walk away from a mirror or reflective surface, or ask another player to view the character from different distances). Confirm that LOD switching occurs without visual popping or missing-geometry artifacts.
10. Test hair and beard: create a second character with hair and beard configured, equip the robot shirt, and confirm that the hair and beard are not visible.

Diagnostic table: common mesh-replacement failures

Symptom	Most likely cause	Resolution
Equipping the shirt does not change the character model at all	Has_1P_Character_Mesh_Override is not set to true	Set Has_1P_Character_Mesh_Override true in the .dat file
Equipping the shirt produces an invisible character (no model rendered)	Character_Mesh_1P_Override_0 prefab not found in the master bundle	Confirm the prefab name in the bundle matches Character_Mesh_1P_Override_0 exactly
Third-person model is invisible but first-person arms work	Character_Mesh_3P_Override_LODs is greater than 0 but no third-person prefabs exist in the bundle	Add Character_Mesh_3P_Override_0 (and additional LODs) to the bundle; or set Character_Mesh_3P_Override_LODs 0 to disable third-person override
First-person arms are invisible but third-person model works	Character_Mesh_1P_Override_0 prefab is missing or misnamed in the bundle	Verify the prefab exists in the bundle with the exact name Character_Mesh_1P_Override_0
Character model appears with pink (missing-material) surface	Has_Character_Material_Override is true but Character_Material_Override material is not in the bundle	Add the material to the bundle with the exact name Character_Material_Override
Shirt and pants textures appear stretched or misaligned on the replacement mesh	Has_Character_Material_Override is false and the replacement mesh UVs do not match the vanilla character UV layout	Either unwrap the replacement mesh to the vanilla UV layout or set Has_Character_Material_Override true and supply a custom material
Hair floats above or clips through the custom head geometry	Hair_Visible is true and the replacement head geometry is at a different position or scale than the vanilla head	Set Hair_Visible false and include hair geometry in the replacement mesh; or adjust the replacement head to match vanilla head position
Hat floats above the replacement head	The replacement head geometry is at a different position or scale than the vanilla head	Adjust the replacement head bone binding to match vanilla head position; or author hat items specific to the replacement character
Arms are invisible in first-person view for some players on a multiplayer server	Those players do not have the mod installed locally	Inform players that the character mesh replacement requires the mod to be installed client-side
Weapon floats above or sinks into the replacement hands	Replacement arm mesh deviates from vanilla arm bone positions at the wrist	Adjust the replacement arm mesh to follow the vanilla wrist bone position more closely
Character model clips through equipped vest or backpack	Replacement torso geometry is substantially larger or differently shaped than the vanilla torso	Adjust the replacement torso to more closely match vanilla proportions; or author vest and backpack items sized for the replacement body
LOD switching produces visible geometry popping	The triangle-count reduction between LOD levels is too aggressive or the mesh topology does not decimate cleanly	Smooth the LOD transitions by using more LOD levels with smaller triangle-count steps between them; manually clean the decimated mesh topology

Best practices

• Author the first-person arms mesh to closely follow the vanilla arm skeleton bone positions, especially at the wrist, to ensure weapons align correctly with the hands in first-person view.
• Test the replacement mesh with every standard clothing item equipped (hat, mask, vest, backpack, pants, glasses) to identify clipping and floating issues before publication.
• Use LOD levels even for a single-player mod; distant-character rendering on multiplayer servers benefits from LOD reduction.
• Set Hair_Visible false and Beard_Visible false whenever the replacement mesh includes custom head geometry. Vanilla hair and beard meshes will not align with a custom head.
• If the replacement mesh is intended to work with the standard clothing-texture pipeline, unwrap the replacement UVs to match the vanilla character UV layout. If a custom material is provided, the UV layout can be designed independently.
• Test the replacement mesh on a dedicated server with at least one other player connected before publication. Mesh-replacement rendering behaves differently in single-player and multiplayer contexts, particularly with respect to LOD selection and material batching.
• Package all LOD prefabs, the first-person prefab, and the material override (if used) in a single master bundle. The engine expects all mesh-replacement assets to reside in the same bundle as the shirt item.
• Document the replacement mesh's body proportions in the Workshop description so that players understand which standard clothing items will and will not fit the custom character. A robot character that cannot wear standard hats should state that limitation clearly on the Workshop page.
• Generate a fresh GUID for the mesh-replacement shirt item. The mesh replacement does not exempt the item from the standard GUID uniqueness requirement.

Frequently asked questions

Why must the mesh replacement be a shirt item?

Only the shirt clothing slot is loaded for both first-person and third-person view rendering. Pants, hats, masks, vests, backpacks, and glasses are loaded only for third-person and inventory-paper-doll rendering. Because character mesh replacement must produce consistent first-person arms and third-person body appearance, and because only the shirt slot is available in both rendering contexts, the system is necessarily confined to shirts. If the system were available on pants, the first-person view would still show the vanilla arms, producing a visual mismatch between the player's own perspective and what other players see.

What happens if I set Has_1P_Character_Mesh_Override to false but set Character_Mesh_3P_Override_LODs to 3?

The third-person mesh override fields are configured but the mesh-replacement system is not activated. The game does not load any replacement meshes, because the activation gate (Has_1P_Character_Mesh_Override) is false. The character renders with the standard vanilla body mesh. This configuration is not harmful, but it does nothing. The fields are parsed and stored but never consulted because the activation condition is not met.

Can I use the standard shirt texture pipeline with a mesh-replacement shirt?

Yes. Set Has_Character_Material_Override to false (or omit the field). The engine applies the equipped shirt and pants textures to the replacement mesh using the standard clothing-texture pipeline. The replacement mesh must be UV-unwrapped to match the vanilla character UV layout for the clothing textures to map correctly. This mode allows the replacement mesh to benefit from the player's chosen shirt and pants cosmetics while substituting the underlying body geometry.

How do I create multiple LODs for my replacement mesh efficiently?

Author the highest-detail mesh (LOD 0) first. In Blender, apply a Decimate modifier with the Collapse mode and a ratio that produces the target triangle count for LOD 1 (approximately 40% of LOD 0). Apply the modifier, manually clean any degenerate faces or topology artifacts, and export the result as the LOD 1 mesh. Repeat the process for LOD 2 with a more aggressive decimation ratio (approximately 15% of LOD 0). Automated decimation produces acceptable results for character meshes at medium and far distances, but the decimated topology should be manually inspected for holes, flipped normals, and degenerate triangles before export.

Will my mesh-replacement shirt work if the player is also wearing a vest?

Yes, but the vest will render on top of the replacement mesh using its own clothing mesh and material. If the replacement torso is larger, smaller, or differently shaped than the vanilla torso, the vest will clip through or float above the replacement body. The best practice for mesh-replacement shirts that differ significantly from vanilla body proportions is to also author vest, backpack, hat, and mask items that are sized to fit the replacement body, and to indicate in the Workshop description that the replacement character works best with the mod's own clothing set.

Can I author a mesh-replacement shirt that only replaces the arms and leaves the vanilla body?

Yes, but the use case is narrow. Set Has_1P_Character_Mesh_Override true and include a Character_Mesh_1P_Override_0 with custom arms. Set Character_Mesh_3P_Override_LODs 0 (no third-person override) or author third-person prefabs that match the vanilla body proportions. The first-person view shows the custom arms; the third-person view shows the vanilla body. This configuration is useful for arm-specific modifications (prosthetic arms, robotic gauntlets, textured sleeves) without requiring a full body replacement.

What happens if a player equips my mesh-replacement shirt on a server that does not allow client-side mods?

The shirt item renders with its fallback appearance. On a server that does not enable client-side mod loading, the master bundle is not loaded, and the replacement meshes are not available to the renderer. The player's character appears as the vanilla body wearing a standard shirt (or invisible, depending on the server's fallback behavior for missing assets). The mesh-replacement shirt mod should be published with clear documentation that it requires client-side mod installation to function as intended.

Can I animate the replacement mesh independently of the vanilla character animation set?

No. The replacement mesh is skinned to the vanilla character skeleton and is driven by the same animation clips that drive the vanilla character. Custom animations that differ from the vanilla animation set require a different approach (custom animation clips in the Animations prefab, custom useable scripts) and are outside the scope of the mesh-replacement system. The mesh-replacement system changes what geometry is rendered; it does not change how that geometry is animated.

How do I ensure my replacement mesh does not cause performance problems on lower-end hardware?

Use LOD levels aggressively. A replacement mesh with 15000 triangles at LOD 0 that drops to 1000 triangles at LOD 2 will render efficiently at all distances. Use a single material for the entire replacement mesh (batching multiple materials on a single character mesh increases draw calls). Avoid transparent materials on the replacement body unless the character design specifically requires transparency (ghosts, holograms), because transparent rendering on skinned meshes is disproportionately expensive. Test the mod on the minimum-specification hardware that the Workshop description claims to support.

Does the replacement mesh affect the player's hitbox for damage calculation?

No. The player's hitbox is derived from capsule colliders on the character skeleton, not from the rendered mesh geometry. A replacement mesh that is significantly larger than the vanilla character body will have the same hitbox as the vanilla character, which means that projectiles that visibly pass through the outer edges of the replacement mesh will not register as hits, and projectiles that visibly miss the replacement mesh by a narrow margin may still register as hits if they intersect the hitbox. This limitation is fundamental to the character mesh replacement architecture and cannot be corrected through .dat configuration.

Appendix A: Mesh-replacement field quick reference

Field	Type	Required	Default	Purpose
Has_1P_Character_Mesh_Override	bool	Conditional	false	Activates mesh replacement; loads Character_Mesh_1P_Override_0 for first-person arms
Character_Mesh_3P_Override_LODs	uint8	Conditional	0	Number of third-person LOD meshes to load; each LOD loads Character_Mesh_3P_Override_N
Has_Character_Material_Override	bool	Optional	false	Loads Character_Material_Override material; bypasses clothing-texture pipeline
Hair_Visible	bool	Optional	See description	Controls vanilla hair mesh visibility on replacement character
Beard_Visible	bool	Optional	See description	Controls vanilla beard mesh visibility on replacement character

Appendix B: Prefab naming convention reference

Prefab name	Context	Contents
Character_Mesh_1P_Override_0	First-person view	Arms and hands mesh only (MeshFilter). No torso, legs, or head.
Character_Mesh_3P_Override_0	Third-person view, LOD 0 (near)	Full body mesh, highest detail (MeshFilter).
Character_Mesh_3P_Override_1	Third-person view, LOD 1 (medium)	Full body mesh, reduced detail (MeshFilter).
Character_Mesh_3P_Override_2	Third-person view, LOD 2 (far)	Full body mesh, lowest detail (MeshFilter).
Character_Mesh_3P_Override_N	Third-person view, LOD N (additional)	Additional LOD levels follow the same naming pattern.
Character_Material_Override	Material override (optional)	Material applied to both 1P and 3P replacement meshes.

Appendix C: Clothing-slot compatibility matrix for mesh-replacement characters

Clothing slot	Renders on replacement mesh?	Visual-mismatch risk	Recommendation
Hat	Yes, on head bone	High if head geometry differs from vanilla	Author hat items sized for replacement head, or set head geometry to vanilla proportions
Mask	Yes, on face bone	High if face geometry differs from vanilla	Author mask items sized for replacement face
Vest	Yes, as torso overlay	High if torso geometry differs from vanilla	Author vest items sized for replacement torso
Backpack	Yes, on back bone	Medium if back geometry differs from vanilla	Author backpack items with adjusted attachment offset
Pants	Yes, as leg overlay and texture	Medium if leg geometry differs from vanilla	Author pants items sized for replacement legs
Glasses	Yes, on face bone	High if face geometry differs from vanilla	Author glasses items with adjusted attachment offset

Appendix D: External references

• Smartly Dressed Games official modding documentation, the authoritative specification for character mesh replacement (Chapter 92) and the CharacterMeshReplacementTest item (ID 1522).
• Unturned on Steam, the Unturned™ store page and community hub.
• Item Asset Property Reference, the previous article; documents the shared item property surface that all asset types extend.
• Clothing Asset Reference, the comprehensive clothing asset article; documents the standard shirt, pants, hat, mask, vest, backpack, and glasses fields that accompany the mesh-replacement fields.
• Arrest Start Asset Reference, the next article; documents the arrest-initiating tool asset type.
• Project Folder Structure and GUIDs, folder layout, GUID generation, and ID-range conventions.
• Master Bundle Export from Unity, Unity bundling workflow used to package mesh-replacement prefabs and materials.

Advanced considerations

Character mesh replacement and RP-server economies

On roleplay servers such as Horizon Life RP, a 57 Studios™ development context, character mesh replacement shirts serve a function that extends beyond cosmetic variety. An RP server may use mesh-replacement shirts to implement playable non-human species (robots, mutants, creatures) as distinct character options, with each species gated behind a different Tebex store item or an in-game progression achievement. The mesh-replacement shirt becomes the mechanism by which a player asserts a visual identity that differs from the standard human character model, and the server's economy and faction system can key off the shirt's item ID to apply species-specific permissions, dialogue trees, and gameplay modifiers.

The cohort-validated RP-server pattern for mesh-replacement shirts is to configure each species shirt as an untradeable, undroppable item (Allow_Manual_Drop false and Should_Drop_On_Death false) that is assigned to the player character on creation and cannot be removed through normal gameplay. The shirt occupies the character's shirt slot permanently, which means the player cannot equip standard cosmetic shirts over the species shirt. This is the intended behavior: the species shirt is the player's base visual identity, and other clothing slots (hat, mask, vest, backpack, pants, glasses) provide the cosmetic customization surface.

Performance profiling for mesh-replacement characters on multiplayer servers

A mesh-replacement character that renders on a multiplayer server contributes to the server's per-frame rendering budget in proportion to the replacement mesh's triangle count, material count, and draw-call count. The following profiling guidelines are drawn from cohort testing on servers with typical player populations (20-40 concurrent players):

Replacement mesh configuration	Estimated draw calls per character	Performance impact at 40 players
Single LOD, single material, 8000 tris	1 draw call	Negligible
Three LODs, single material, 15000/6000/2000 tris	1 draw call (LOD-dependent)	Low
Single LOD, two materials (body + transparent overlay), 12000 tris	2 draw calls	Moderate
Three LODs, three materials, 20000+ tris at LOD 0	3+ draw calls	High

The performance-impact estimates above are for a server whose rendering budget is already fully utilized by map geometry, lighting, and vanilla player-character rendering. A server with headroom in its rendering budget will absorb mesh-replacement character cost without visible frame-rate impact. A server already at its rendering ceiling will exhibit frame-time increases proportional to the number of mesh-replacement characters in the camera frustum. The cohort recommendation for public Workshop mods is to target the single-material, moderate-triangle-count configuration that keeps the per-character draw-call count at 1.

Shirt-slot occlusion and the invisible-body problem

When a mesh-replacement shirt item is equipped but the master bundle is not present on the client (because the player does not have the mod installed), Unturned™ falls back to rendering the character with the shirt item's default model or with no shirt model at all. Because the mesh-replacement system has substituted away the vanilla character body mesh, and the replacement mesh is unavailable, the character renders as a floating head and hands with no body geometry between them. This is the "invisible body" problem, and it is the most common visual bug reported by players who encounter a mesh-replacement character on a server without having installed the required mod.

There is no engine-level mitigation for the invisible-body problem. The mesh-replacement system does not provide a fallback mesh or a proxy geometry that renders when the replacement bundle is missing. The only mitigation is social: the mod's Workshop description should state clearly that the character mesh replacement requires local mod installation to display correctly, and server administrators who deploy mesh-replacement shirt mods should communicate the installation requirement to their player communities.

Mesh-replacement shirts and the Steam Workshop economy

A mesh-replacement shirt item can be published to the Steam Workshop as a standalone clothing mod, or it can be bundled as part of a larger mod pack that includes the replacement mesh, the replacement material, companion clothing items sized for the replacement body, and any weapon or tool items that are designed to work with the replacement character's proportions. The cohort-validated publishing strategy for mesh-replacement mods is to publish the shirt item, the replacement meshes, and the companion clothing items as a single Workshop submission so that players who subscribe to the mod receive every asset the character requires in one installation operation. Splitting the mesh-replacement shirt into one Workshop item and the companion clothing into a separate Workshop item forces the player to subscribe to two items and introduces the risk that one is subscribed without the other.

Appendix E: Authoring checklist for mesh-replacement shirts

Before publishing a character mesh replacement mod to the Steam Workshop, confirm the following:

• [ ] Has_1P_Character_Mesh_Override is set to true in the .dat file
• [ ] Character_Mesh_3P_Override_LODs is set to the correct number of LOD levels
• [ ] Character_Mesh_1P_Override_0 prefab exists in the master bundle with a MeshFilter component containing the arms-only mesh
• [ ] Character_Mesh_3P_Override_0 (and additional LOD prefabs) exist in the master bundle for each LOD level specified
• [ ] If Has_Character_Material_Override is true, the Character_Material_Override material exists in the master bundle
• [ ] If Has_Character_Material_Override is false, the replacement mesh UVs match the vanilla character UV layout
• [ ] Hair_Visible and Beard_Visible are configured explicitly (true or false) based on whether the replacement head supports vanilla hair and beard rendering
• [ ] The first-person arms mesh follows the vanilla arm skeleton bone positions, especially at the wrist, for correct weapon alignment
• [ ] The replacement mesh is skinned to the vanilla character skeleton with correct bone names and hierarchy
• [ ] The replacement mesh has been tested in first-person view with each weapon type the mod supports
• [ ] The replacement mesh has been tested in third-person view with each standard clothing item equipped
• [ ] LOD switching has been verified at near, medium, and far distances without visible geometry popping
• [ ] The mod has been tested on a dedicated server with at least one other player connected to verify multiplayer rendering
• [ ] The Workshop description documents the replacement body proportions and any known clothing-compatibility limitations
• [ ] The Workshop description states that the mod requires client-side installation for correct rendering

Document history

Version	Date	Author	Notes
1.0	2025-05-18	57 Studios	Initial publication. Complete character mesh replacement reference: field documentation, 1P and 3P prefab requirements, material override system, hair and beard visibility, clothing-system integration, documented limitations, worked example, diagnostic reference, FAQ, and quick-reference appendices.

Cross-references

• Item Asset Property Reference, the previous article; the shared item property reference that this article extends for the mesh-replacement subsystem.
• Arrest Start Asset Reference, the next article; documents the arrest-initiating tool asset type and its useable script.
• Clothing Asset Reference, the comprehensive reference for all seven clothing slots; documents the standard shirt fields that accompany mesh-replacement configuration.
• Item Asset Anatomy, the structural reference for .dat files; covers the parse order, field types, and the relationship between self-referential.dat and per-item .dat files.
• Data File Format Reference, the canonical syntax reference for .dat and .asset files.
• Master Bundle Export from Unity, the Unity packaging workflow; prefabs for mesh replacement are exported through the standard master bundle pipeline.
• Smartly Dressed Games modding documentation, the official field reference for the character mesh replacement subsystem.
• Unturned on Steam, the Unturned™ store page and community hub.