Unity Layers Reference
Unity's layer system is the mechanism by which the engine controls collision detection, raycast queries, and rendering culling for every object in an Unturned™ scene. Layers are integer-indexed categories assigned to GameObjects through the Unity Editor. The Unturned™ runtime depends on specific layer assignments for the game simulation to function correctly. A single object on the wrong layer produces effects that range from invisible items that cannot be picked up to player hitboxes that fail to register damage, and the resulting bugs are notoriously difficult to diagnose because layer misassignment produces no error message, no warning in the Unity console, and no log entry in the game's output files.
This article is the 57 Studios™ canonical reference for every Unity layer that Unturned™ uses, drawn from the official Smartly Dressed Games documentation of the layer system as it exists in the current game version. The reference documents every built-in layer, every user layer in Unturned's assigned range (layers 8 through 31), the collision matrix that determines which layers can collide with which other layers, the raycast behavior for each layer, and the entity-type assignments that determine which layers carry specific game objects. Mod developers who need to create custom GameObjects in their Unity scenes, configure collision for custom prefabs, or diagnose physics or rendering problems should consult this reference as the authoritative source for layer assignments. The layer system is entrenched from the earliest versions of the game and reflects design decisions made when the game was first authored in 2013; several layer assignments that appear unusual to experienced Unity developers are intentional, and the rationale for these assignments is documented throughout this article where the official source material provides an explanation.
The Unturned™ layer configuration uses twenty-four of the thirty-two available layer indices, leaving layers 3, 6, and 7 as the standard Unity built-in reserved layers that every Unity project carries, and layer 31 as a game-specific reserved layer held for future use. No layer index in the 0-through-31 range is available for custom mod-specific allocation. The layer system is a fixed resource at the engine level, and the configuration imported from the Project.unitypackage must be preserved exactly as it is provided.
Documentation source: This article documents the Unturned™ layer configuration as published in the official Smartly Dressed Games modding documentation, Chapter 11 (Layers). The source documentation states that Unturned™ makes "poor use" of Unity's layers and that the layer assignments are "entrenched from the earliest versions" of the game. This article treats the layer assignments as they exist, not as they ideally would be, because mod developers cannot change them without breaking compatibility with the game client.
Who this article is for
This article is written for Unturned™ mod developers who work directly in the Unity Editor, authoring custom prefabs, setting up collision for mod items, configuring raycast behavior for interactive objects, or debugging physics problems in mod content. If you do not work in Unity and only author .dat files, the layers documented here are managed by the engine automatically and do not require your intervention. However, every Unity-scene author who creates custom GameObjects for an Unturned™ mod must understand the layer system, because the default layer assignment (Default, layer 0) is almost never the correct layer for a mod GameObject that needs to be seen, picked up, or interacted with.
How the Unity layer system works in Unturned
Unity layers are an integer index from 0 to 31 assigned to each GameObject through the Inspector's Layer dropdown. The first eight layers (0 through 7) are the built-in Unity layers that ship with the engine and are present in every Unity project regardless of configuration. Layers 8 through 31 are user layers whose names and purposes are defined per project in the Unity Tag and Layer Manager, accessible through Edit > Project Settings > Tags and Layers. Unturned™ uses layers 8 through 31 extensively, assigning specific named layers to specific categories of in-game entity, and the game's simulation code depends on these assignments being correct.
The layer system serves three distinct purposes in Unturned™ simultaneously. First, layers control physics collision: the Unity physics engine's collision matrix determines which layers can physically collide with which other layers, and objects on layers that are not configured to collide will pass through each other without generating collision events. Second, layers control raycast queries: the game's hit-detection code, interaction code, and rendering code all perform raycasts against specific layer masks, and objects on the wrong layer will be invisible to those raycasts. Third, layers control rendering: some layers carry special rendering behavior (the Viewmodel layer for local first-person arms and weapons, the Sky layer for distant effects without collision), and the camera's culling mask is configured per layer such that objects on excluded layers are not drawn.
As shown in the flowchart above, a single layer assignment determines behavior across all three subsystems simultaneously. A GameObject on an incorrect layer may render correctly but fail hit detection, or may collide correctly but be invisible to the camera, and the resulting partial failures are the characteristic symptom of layer misassignment. The fact that a layer misassignment can produce a partial failure (one subsystem works, another does not) rather than a total failure is what makes these bugs difficult to diagnose: the mod developer sees the object rendering and assumes the layer assignment is correct, when in fact the layer is wrong for collision or for raycast interaction.
The physics collision matrix
The Unity physics engine maintains a 32-by-32 boolean matrix that determines whether a collider on layer A will generate a collision event with a collider on layer B. The matrix is configured in Edit > Project Settings > Physics and is embedded in the project configuration. Unturned™ configures a specific collision matrix that the game's simulation code expects, and this matrix is included in the Project.unitypackage that every mod developer imports. The matrix is not configurable per-scene or per-prefab; it is a global project setting, and all prefabs in the project share the same collision matrix.
The raycast layer mask
Unity's Physics.Raycast and Physics.SphereCast methods accept a layer mask parameter, which is a 32-bit integer where each bit corresponds to one layer index. A bit set to 1 means the raycast queries that layer; a bit set to 0 means it ignores that layer. The Unturned™ game code uses different layer masks for different gameplay queries: weapon hit-detection raycasts query a mask that includes Enemy and Entity but excludes Item and Vehicle; interaction raycasts query a mask that includes Item, Vehicle, Barricade, and Structure but excludes Enemy and Entity; and rendering-related raycasts query yet another mask. A GameObject on a layer that is excluded from a given query will be invisible to that query, regardless of whether the GameObject has a collider and regardless of whether the collider is the correct size and shape.
Camera culling masks
Each camera in the scene has a Culling Mask, which is a layer mask that determines which layers the camera renders. The main game camera excludes the UI layer and the Viewmodel layer; a separate UI camera renders only the UI layer; and a separate viewmodel camera renders only the Viewmodel layer, ensuring that the first-person weapon does not clip through world geometry and that the UI is rendered on top of the game view. Objects on a layer that is excluded from every camera's culling mask will be invisible at runtime, even if they have active MeshRenderer components and correct materials.
Built-in Unity layers
The first eight layers (0 through 7) are the standard Unity built-in layers. Unturned™ uses several of these for specific purposes, and the remainder are either not used or are used incidentally by third-party assets imported into the Unturned™ project. The built-in layers are present in every Unity project and cannot be renamed or removed.
| Layer Index | Layer Name | Unity built-in | Purpose in Unturned |
|---|---|---|---|
| 0 | Default | Yes | Generic objects. No physics collision in Unturned's collision matrix. Objects left on this layer by mistake will not collide with anything and may not be interactable. |
| 1 | TransparentFX | Yes | Standard Unity layer for transparent special effects. No physics collision. Not used directly by Unturned game code. |
| 2 | Ignore Raycast | Yes | Standard Unity layer for objects that should be invisible to raycasts. No physics collision. Used by the engine for internal visibility calculations. |
| 3 | (unused) | Yes | Reserved Unity built-in layer, not configured in Unturned. |
| 4 | Water | Yes | Ocean and water tiles. The water volume uses this layer, and the game's swimming and buoyancy code queries against it. No physics collision for standard physics bodies, but the water interacts with the character controller through separate buoyancy logic. |
| 5 | UI | Yes | In-game menus using the uGUI canvas system (the Unity "glazier" UI renderer) as well as plugin custom menus. No physics collision. The UI camera renders this layer exclusively. |
| 6 | (unused) | Yes | Reserved Unity built-in layer, not configured in Unturned. |
| 7 | (unused) | Yes | Reserved Unity built-in layer, not configured in Unturned. |
Default layer is a trap
Leaving a mod GameObject on the Default layer (layer 0) is the single most common layer misassignment in new Unturned™ mods. The Default layer has no physics collision in Unturned's collision matrix, which means objects on this layer will not collide with the player, with vehicles, with zombies, or with any other game entity. If your custom prop cannot be walked into and does not block movement, the most likely cause is that it is still on the Default layer. Assign it to the layer appropriate for its entity type according to the tables in this article.
User layers: complete per-layer reference
Unturned™ assigns layers 8 through 31 to specific categories of in-game entity. The assignment is fixed: the layer index, the layer name, and the entity category it represents are locked by the game's C# code and must not be changed in the Unity project's Tag and Layer Manager. The project package imported from Project.unitypackage configures these layers automatically; verify that the configuration matches the table below if you set up a project manually.
Layer 8: Logic
The Logic layer is assigned to clickable overlays and editor debug visuals. In the Unity Editor, the position, rotation, and scale handles that appear when a GameObject is selected are rendered on this layer. Editor debug visuals that are configured to be visible through walls (for development and diagnostic purposes) are also on this layer. The Logic layer has no physics collision in Unturned's collision matrix, and GameObjects on this layer should not be included in asset bundles shipped to players. This is an editor-side layer only; the game client does not use it for any gameplay purpose.
Layer 9: Player
The Player layer carries the player character capsule, which is the primary collider that moves through the world and interacts with the physics simulation. On the server, every connected player's character capsule is on the Player layer. On the client, only the locally-controlled player's character capsule is on the Player layer; other connected players' character capsules are on the Enemy layer (layer 10). This asymmetry is a fundamental property of Unturned's client-server architecture and has implications for any custom collision or raycast code that queries the Player layer.
The Player layer has physics collision active, and the character controller uses this layer as the underlying query mask for movement. It collides with terrain, clip geometry, structures, barricades, vehicles, resources, debris, and items. Body hitboxes are not on this layer; they are on the Enemy layer (layer 10).
Layer 10: Enemy
The Enemy layer carries player body hitboxes, which are the individual colliders on each limb (head, torso, arms, legs) that receive damage from weapon fire and melee attacks. On the client, other players' entire characters (capsule and hitboxes) are on the Enemy layer, because the Player layer on the client is reserved for the locally-controlled character. On the server, the character capsules are on Player but the body hitboxes remain on Enemy.
The Enemy layer has no physics collision in Unturned's collision matrix. Damage is applied through raycasts that specifically query this layer, not through physics collision events. The hitboxes respond to raycasts but do not participate in the physics simulation.
Layer 11: Viewmodel
The Viewmodel layer carries the local player's first-person arms and weapon model. This layer is rendered by a dedicated camera that only draws the Viewmodel layer, and the camera's depth is configured to render on top of the main world camera. This architecture ensures that the first-person weapon model never clips through walls, objects, or other players, because the viewmodel camera's output is composited on top of the world camera's output regardless of the geometry in the scene.
The Viewmodel layer has no physics collision and is not visible to standard raycasts. The viewmodel weapon is a purely visual element; the actual hit-detection raycasts originate from the player's world-space position and are projected into the scene independent of the viewmodel geometry.
Layer 12: Debris
The Debris layer carries small simulated physics objects that are spawned dynamically during gameplay. Ragdolls generated when a player or zombie dies, thrown grenades, falling tree trunks when a resource node is harvested, destroyed structure fragments, and other fragmented objects are placed on this layer. Objects on this layer have physics collision active and can interact with the player, terrain, structures, vehicles, and each other.
The Debris layer is primarily a runtime concern for the game engine rather than a mod-authoring concern, because debris objects are spawned by the game's simulation code and are not typically included in custom mod prefabs. However, if a mod prefab spawns a physics-enabled secondary object (such as a custom grenade or a custom destructible fragment), that secondary object should be on the Debris layer to ensure correct collision behavior.
Layer 13: Item
The Item layer carries dropped interactable items in the world. When an item is removed from a player's inventory or spawned by the game's loot system, the item's world-space GameObject is created on this layer. The player's interaction raycast queries this layer to detect items that the player can pick up. A dropped item on any layer other than Item will appear on the ground but will not respond to the interaction key, because the interaction raycast's layer mask excludes every layer except the Item layer for pickup detection.
The Item layer has physics collision active. Dropped items rest on terrain and can be pushed by players and vehicles. The collider on a dropped item should approximate the item's visual bounds and should be sized to produce a reasonable pickup radius.
Layer 14: Resource
The Resource layer carries trees and boulders, the harvestable world resource nodes that players interact with using melee weapons. The player's melee hit-cast and interaction raycast query this layer to detect resource nodes that can be harvested. Barricades that are attached to vehicles at runtime are moved from the Barricade layer (layer 27) to the Resource layer so that they move with the vehicle without generating collision events against the vehicle body.
The Resource layer has physics collision active. Trees and boulders block player and vehicle movement, and the collision shape should match the visual shape of the resource node. The layer assignment for custom resource nodes (if a mod adds harvestable world objects) must be Resource for the harvesting mechanics to function.
Layer 15: Large
The Large layer carries large props placed in the level editor. These are building-scale objects, substantial terrain features, and other large world elements that are placed by the map author in the Unity Editor or through the Unturned™ level editor. The Large layer has physics collision active, and objects on this layer block player and vehicle movement.
Custom large props in a mod map should be assigned to the Large layer. The mesh collider should approximate the visual geometry of the prop sufficiently for the physics engine to generate reasonable collision responses, but the collider mesh does not need to match the visual mesh exactly and can be a simplified convex hull for performance.
Layer 16: Medium
The Medium layer carries medium-sized props placed in the level editor. These are mid-scale world objects such as furniture, signage, smaller structural elements, and detail objects that are large enough to require collision but smaller than building-scale objects. The Medium layer has physics collision active, and objects on this layer block player and vehicle movement.
The distinction between Large and Medium is primarily organizational rather than behavioral: both layers have physics collision, and both layers respond to the same raycast queries. The separation allows the map author to organize objects by scale in the Unity Editor, but the gameplay behavior of objects on the Large and Medium layers is identical.
Layer 17: Small
The Small layer carries small props without collision placed in the level editor. These are visual detail objects that the player can walk through: ground clutter, small decorative elements, and detail objects that are too small to warrant physics collision. The Small layer has no physics collision in Unturned's collision matrix, and objects on this layer will never block movement or generate collision events.
Custom small decorative props in a mod map should be assigned to the Small layer. Do not assign items that need to be interactable or that need collision to this layer; it is exclusively for non-interactive visual detail.
Layer 18: Sky
The Sky layer carries distant effects without collision: cloud systems, star fields, atmospheric rendering elements, and other sky-domain visual effects. The Sky layer has no physics collision, and the sky camera renders this layer as part of the environment background. Objects on this layer are intended to be visual-only atmospheric elements that exist at effectively infinite distance.
Layer 19: Environment
The Environment layer carries roads, grass, pebbles, and other ground-level environmental detail surfaces. The official SDG documentation lists this layer in both the "No physics collision" and "Has physics collision" categories, indicating either partial collision configuration or a documentation inconsistency. In practice, road surfaces on this layer participate in collision with vehicle wheel colliders for driving physics, and ground-level environmental detail objects on this layer may have varying collision behavior depending on the specific object type.
Layer 20: Ground
The Ground layer carries the landscape and terrain surface. The Unity terrain collider is on this layer, and it is the primary surface that the player walks on and that vehicles drive on. The terrain collider is managed through Unity's terrain system rather than through standard layer-based collision pairs, which is why the official SDG documentation lists Ground in both the "No physics collision" and "Has physics collision" categories. The terrain is collision-active for character controllers and vehicles in practice, regardless of its documentation category.
Layer 21: Clip
The Clip layer carries invisible collision geometry that blocks player and vehicle movement in areas where the visual geometry is not a reliable collision surface. Map authors place invisible box or mesh colliders on this layer to create collision boundaries in areas where the visual geometry has gaps, is too complex for efficient collision, or is not present at all (invisible walls, out-of-bounds barriers).
The Clip layer collides with Player and Vehicle specifically. Makeshift vehicles (constructed by players from barricades and other objects) place invisible colliders on this layer to expand their simulation size without affecting barricade placement. Because makeshift vehicles use Clip-layer colliders, the Clip layer also collides with some of the same layers as Vehicle, which means Clip-layer objects may collide with barricades and structures in certain vehicle-construction scenarios.
Layer 22: Navmesh
The Navmesh layer carries invisible zombie-only collision geometry. The navmesh graph used by AI pathfinding is generated from collision geometry on this layer at map build time. Unlike the Clip layer, which blocks both players and vehicles, the Navmesh layer is queried primarily by the AI navigation system for zombie and animal pathfinding.
The collision geometry on this layer is also loaded on the server at runtime to help push zombies around the world. The Navmesh layer has physics collision active for AI character controllers, but player and vehicle character controllers do not interact with this layer directly, the Clip layer serves that purpose.
Layer 23: Entity
The Entity layer carries zombie and animal body hitboxes, the individual colliders on each AI entity's limbs that receive damage from player weapons. The Entity layer has no physics collision in the collision matrix; like the Enemy layer for player hitboxes, entity hitboxes are damage targets detected through raycasts, not through physics collision events.
A custom zombie or animal prefab must have its body hitbox colliders on child GameObjects assigned to the Entity layer. If the hitboxes are on any other layer, weapon fire will pass through the entity without registering a hit, because the weapon hit-detection raycast's layer mask includes Entity but excludes layers like Default or Agent.
Layer 24: Agent
The Agent layer carries zombie and animal character capsules, the primary collider that moves AI entities through the world. The character controller on the entity's root GameObject uses this layer as the underlying query mask for AI movement. The Agent layer has physics collision active, and AI character controllers on this layer collide with terrain, structures, navmesh geometry, and clip geometry.
The distinction between Entity (hitboxes, no collision) and Agent (capsule, collision) mirrors the distinction between Enemy (hitboxes, no collision) and Player (capsule, collision) for the player character. The parallel layering structure ensures that AI entities and player characters have consistent collision and hit-detection behavior.
Layer 25: Ladder
The Ladder layer carries invisible climbable trigger volumes. When a player overlaps a trigger collider on this layer, the climbing mechanic activates, allowing the player to ascend or descend along the ladder surface. The Ladder layer has no physics collision: the ladder trigger is detected through overlap queries, not through collision events. A ladder trigger must have a Collider component with Is Trigger enabled.
Layer 26: Vehicle
The Vehicle layer carries all vehicle colliders. Every collider on a vehicle GameObject, including the body, doors, bumpers, and any attached sub-objects that participate in the vehicle's physics, must be on this layer for the vehicle to function correctly. The player's interaction raycast queries this layer for vehicle entry, refueling, and repair interactions.
The Vehicle layer has physics collision active, and vehicle colliders interact with terrain, structures, barricades, clip geometry, other vehicles, and the player. Vehicle wheel colliders are on a separate layer (Tire, layer 29) because the wheel collider type requires its own collision mask configuration.
Layer 27: Barricade
The Barricade layer carries barricade items placed in the world by players. Storage boxes, wire fences, spike traps, and any other player-placed barricade item occupies this layer. The player's interaction and repair raycasts query this layer for barricade detection.
The Barricade layer has physics collision active. Barricades block player and vehicle movement and respond to weapon damage. At runtime, when a barricade is attached to a vehicle, the engine moves that barricade from the Barricade layer to the Resource layer (layer 14) so that it moves with the vehicle without generating collision events against the vehicle body. This migration is handled automatically by the engine and does not require mod-author intervention.
Layer 28: Structure
The Structure layer carries structure items placed in the world by players. Walls, floors, roofs, pillars, ramps, and all other structural elements placed with the structure build tool occupy this layer. The player's interaction, repair, and salvage raycasts query this layer for structure detection.
The Structure layer has physics collision active. Structures block player and vehicle movement, respond to weapon and explosive damage, and participate in the structural integrity system that determines whether a structure collapses when its supports are removed.
Layer 29: Tire
The Tire layer carries wheel colliders specifically. In Unity, a WheelCollider component uses its own collision mask configuration because wheel colliders are a specialized collider type that simulates suspension, friction, and traction. Placing wheel colliders on a separate layer from the vehicle body colliders allows the wheel collider to mask what it interacts with independently of the body colliders, which is essential for correct suspension physics.
The Tire layer has physics collision active through the wheel collider's own collision query mechanism. The wheel collider interacts with the terrain, roads, and other drivable surfaces to produce vehicle movement physics.
Layer 30: Trap
The Trap layer carries trigger colliders for damage volumes and event triggers. Rocket launcher projectiles, environmental kill volumes (lava, radiation zones, out-of-bounds death planes), and any other volume that applies damage or triggers a game event when a player enters it occupies this layer. The Trap layer has physics collision active as a trigger layer, meaning colliders on this layer should have Is Trigger enabled and should detect overlap with players and other entities.
Layer 31: Ground2
The Ground2 layer is no longer used after old maps were converted to terrain tiles. In earlier versions of Unturned™, this layer was assigned to out-of-bounds terrain in the old map format. The layer is now reserved for future use and has no physics collision. Mod developers should not assign GameObjects to this layer, as its future purpose may change in a game update.
Layer collision matrix
The Unity physics engine's collision matrix is a 32-by-32 boolean table that determines which layers can physically collide with which other layers. The matrix is configured in the Unity project's Physics settings, and Unturned™ sets a specific matrix that is consistent across all game versions. The matrix is divided into layers that have physics collision and layers that do not. The tables below document both categories per the official SDG documentation.
Layers with no physics collision
The following layers are configured to never generate physics collision events with any other layer. GameObjects on these layers will pass through every other object in the scene without triggering collision callbacks, regardless of the collider types, sizes, and positions involved.
| Layer Index | Layer Name | Notes |
|---|---|---|
| 0 | Default | No collision with any layer. The most frequent cause of "missing collision" bugs in mod prefabs. |
| 1 | TransparentFX | No collision with any layer. |
| 2 | Ignore Raycast | No collision with any layer. |
| 4 | Water | No collision with any layer through the standard physics system; water interaction is handled through separate buoyancy logic. |
| 5 | UI | No collision with any layer. |
| 8 | Logic | No collision with any layer. Editor-only layer; should never appear in shipped bundles. |
| 10 | Enemy | No collision with any layer. Body hitboxes do not participate in physics collision; damage is applied through raycasts specifically. |
| 11 | Viewmodel | No collision with any layer. The first-person viewmodel weapon is rendered by a dedicated camera and never interacts with world physics. |
| 17 | Small | No collision with any layer. Small props are deliberately non-colliding visual detail. |
| 18 | Sky | No collision with any layer. Sky effects are visual-only atmospheric elements. |
| 23 | Entity | No collision with any layer. Like Enemy, entity hitboxes are damage targets detected through raycasts, not through physics collision events. |
| 25 | Ladder | No collision with any layer. Ladder triggers are detected through overlap queries, not through physics collision. |
| 31 | Ground2 | No collision with any layer. Reserved layer, not currently active. |
Layers with physics collision
The following layers are configured to generate physics collision events. The specific collision pairs (which colliding layer collides with which other layers) are determined by the full collision matrix configuration in the Unity Physics settings, which the official SDG documentation documents at a high level only. The notes below capture the documented collision behavior for each layer.
| Layer Index | Layer Name | Collision behavior |
|---|---|---|
| 9 | Player | The character controller layer is used by Unity as the underlying query mask for character movement. Collides with terrain, structures, barricades, vehicles, clip geometry, and other physical layers. |
| 12 | Debris | Physics collision active. Debris objects collide with the player, terrain, structures, vehicles, and each other. |
| 13 | Item | Physics collision active. Dropped items rest on terrain and can be pushed by players and vehicles. |
| 14 | Resource | Physics collision active. Trees and boulders collide with players, vehicles, and projectiles. |
| 15 | Large | Physics collision active. Large props block player and vehicle movement. |
| 16 | Medium | Physics collision active. Medium props block player and vehicle movement. |
| 19 | Environment | Physics collision active. Road surfaces and environmental detail have physics collision for vehicle interaction. Listed in both collision and no-collision lists in the source documentation; treat as collision-capable for authoring purposes. |
| 20 | Ground | Physics collision active. The terrain collider is the primary surface for character and vehicle movement. Listed in both categories in the source documentation; the terrain is collision-active in practice. |
| 21 | Clip | Collides with Player and Vehicle for its original purpose. Makeshift vehicles place invisible colliders on this layer, so Clip also collides with some of the same layers as Vehicle. |
| 22 | Navmesh | Physics collision active. Zombie-only collision geometry that interacts with the AI character controller for pathfinding and movement. |
| 24 | Agent | The character controller layer is used by Unity as the underlying query mask for AI movement. Zombie and animal capsules collide with terrain, structures, and navmesh geometry. |
| 26 | Vehicle | Physics collision active. Vehicle colliders collide with terrain, structures, barricades, other vehicles, and the player. |
| 27 | Barricade | Physics collision active. Placed barricades collide with players, vehicles, and projectiles. |
| 28 | Structure | Physics collision active. Placed structures collide with players, vehicles, and projectiles. |
| 29 | Tire | The wheel collider layer is used by Unity as the underlying query mask. Tire colliders interact with the terrain and ground surfaces for vehicle suspension and traction simulation. |
| 30 | Trap | Physics collision active. Trigger colliders on this layer detect overlap with players and other entities for damage application. |
Ambiguous layers in source documentation
The official SDG documentation lists Environment (layer 19) and Ground (layer 20) in both the "No physics collision" and "Has physics collision" lists. This inconsistency reflects the complexity of those layers: Ground uses Unity's terrain collider, which handles collision through the terrain system rather than through standard layer-based collision pairs, and Environment carries multiple surface types (roads, grass, pebbles) that may have different collision configurations. The cohort recommendation is to treat both layers as collision-capable when authoring mod content that interacts with them, and to test collision behavior explicitly for any custom objects placed on these layers.
Raycast behavior by layer
Physics collision and raycast visibility are separate concerns in Unity. A layer that has no physics collision may still be visible to raycasts, and a layer with physics collision may be excluded from specific raycast masks. The Unturned™ game code performs raycasts against specific layer masks for hit detection, interaction, and rendering, and the behavior differs between layers.
| Layer | Collision active | Raycast visibility | Typical query context |
|---|---|---|---|
Default (0) | No | Visible unless masked | Not typically queried by Unturned game code; objects on this layer are invisible to most game raycasts because the masks exclude layer 0. |
Water (4) | No | Visible to water-detection raycasts | The game's swimming and buoyancy code queries this layer specifically. |
UI (5) | No | Visible to UI raycasts | UI interaction raycasts query this layer for button and menu detection. |
Player (9) | Yes | Visible to specific raycasts | The local player's character capsule is queried during certain hit-detection paths. |
Enemy (10) | No | Visible to weapon raycasts | Player body hitboxes are the primary target for weapon hit-detection raycasts. |
Item (13) | Yes | Visible to interaction raycasts | The player's interaction raycast queries this layer to detect pick-up targets. |
Resource (14) | Yes | Visible to interaction and melee raycasts | Melee weapon hit-casts and interaction raycasts query this layer for harvestable nodes. |
Entity (23) | No | Visible to weapon raycasts | Zombie and animal hitboxes are targets for weapon hit-detection raycasts. |
Vehicle (26) | Yes | Visible to interaction raycasts | Vehicle interaction raycasts (entering, refueling, repairing) query this layer. |
Barricade (27) | Yes | Visible to interaction raycasts | Interaction and repair raycasts query this layer for placed barricades. |
Structure (28) | Yes | Visible to interaction raycasts | Interaction and repair raycasts query this layer for placed structures. |
Raycast mask independence
A layer that is excluded from physics collision may still appear in raycast masks, and a layer in the physics collision matrix may be excluded from specific raycast queries. The two concerns are configured separately in Unity (physics collision matrix versus the layer mask argument on each Physics.Raycast call), and Unturned™ sets different masks for different gameplay queries. The game's weapon hit detection uses a mask that includes Enemy and Entity but excludes Player, Item, and Vehicle, while the player's interaction raycast uses a mask that includes Item, Vehicle, Barricade, and Structure but excludes Enemy and Entity. The specific mask for each query type is defined in the game's C# code and cannot be changed through .dat configuration. A mod developer who needs to make a custom GameObject respond to a specific raycast type must assign the GameObject to the layer that the raycast's mask includes.
Entity type layer quick reference
The following table maps every entity category in Unturned™ to the layer it occupies. This is the quick-reference lookup for the most common authoring question: "Which layer does my GameObject need to be on?"
| Entity category | Layer | Index | Collision | Raycast visible | Notes |
|---|---|---|---|---|---|
| Player character capsule | Player | 9 | Yes | Yes | The main character collider that moves through the world. |
| Player body hitboxes | Enemy | 10 | No | Yes | Individual limb colliders for damage detection. |
| First-person viewmodel | Viewmodel | 11 | No | No | Rendered by a dedicated camera layer. |
| Dropped world item | Item | 13 | Yes | Yes | Must be on this layer to be picked up. |
| Tree, boulder | Resource | 14 | Yes | Yes | Harvestable world resources. |
| Large editor prop | Large | 15 | Yes | Yes | Building-scale level objects. |
| Medium editor prop | Medium | 16 | Yes | Yes | Mid-scale level objects. |
| Small visual prop | Small | 17 | No | Yes | Non-colliding detail objects. |
| Sky, cloud, star | Sky | 18 | No | No | Distant atmospheric effects. |
| Road, grass, pebble | Environment | 19 | Yes | Yes | Ground-level detail surfaces. |
| Terrain | Ground | 20 | Yes | Yes | The landscape surface. |
| Invisible collision | Clip | 21 | Yes | Yes | Provides collision where visual geometry is absent. |
| Zombie-only collision | Navmesh | 22 | Yes | Yes | AI pathfinding collision geometry. |
| Zombie, animal hitbox | Entity | 23 | No | Yes | AI entity damage targets. |
| Zombie, animal capsule | Agent | 24 | Yes | Yes | AI movement collider. |
| Ladder trigger | Ladder | 25 | No | Yes | Climbing interaction trigger. |
| Vehicle | Vehicle | 26 | Yes | Yes | All vehicle colliders. |
| Placed barricade | Barricade | 27 | Yes | Yes | Player-placed barricade items. |
| Placed structure | Structure | 28 | Yes | Yes | Player-placed structure items. |
| Wheel collider | Tire | 29 | Yes | Yes | Vehicle wheel physics. |
| Damage trigger | Trap | 30 | Yes | Yes | Kill volumes and projectile triggers. |
Layer interaction chains
Several gameplay interactions depend on a chain of layer assignments working correctly across multiple GameObjects. The chain breaks if any GameObject in the chain is on the wrong layer, and the symptoms are characteristically partial: the first step of the interaction works but the second step fails silently. The three most common interaction chains and their layer dependencies are documented below.
Pick-up chain
When a player approaches a dropped item and presses the interact key:
If the item is on any layer other than Item (layer 13), the interaction raycast will miss it, the item will appear on the ground but cannot be picked up, and no error message or log entry will indicate the cause.
Damage chain: player shooting zombie
When a player fires a gun at a zombie:
The zombie's character capsule (on Agent, layer 24) is not the damage target; the body hitboxes (on Entity, layer 23) are. If the zombie prefab's body hitbox colliders are not on the Entity layer, weapon fire will pass through the zombie without registering a hit.
Damage chain: player attacking another player
When a player attacks another player with a melee weapon or firearm, the hit-detection chain changes depending on whether the game is running on the server or on the client:
| Environment | Attacker character layer | Target character layer | Target hitbox layer |
|---|---|---|---|
| Server (dedicated) | Player (9) | Player (9) | Enemy (10) |
| Client (singleplayer host) | Player (9) | Player (9) | Enemy (10) |
| Client (remote, other players) | Player (9) | Enemy (10) | Enemy (10) |
On the server, all player characters are on the Player layer, and body hitboxes are on the Enemy layer. On the client, the locally-controlled player is on the Player layer, while other connected players' characters are on the Enemy layer. The game's hit-detection code accounts for this asymmetry, but the asymmetry is the reason that collision event hooks and custom raycast code that assume a consistent layer for all players will behave differently in singleplayer versus multiplayer. This is also the reason that the Collision Event Hook Mod Hook (documented in Mod Hooks Reference) is described in the official documentation as "primarily useful for server-side objects as collisions are not triggered by other players client-side": on the client, other players are on the Enemy layer, and the collision event hook only reports collisions with colliders on the Player layer.
Common layer configuration mistakes
The following table documents the most frequent layer misassignments that the cohort has observed in Unturned™ mod development, their symptoms, and the correction.
| Mistake | Symptom | Correction |
|---|---|---|
GameObject left on Default (layer 0) | Object renders but has no collision; player walks through it; cannot be interacted with | Assign the correct entity layer per the entity type reference table |
Dropped item not on Item (layer 13) | Item visible on ground but cannot be picked up; interaction prompt does not appear | Assign Item layer to the item's root GameObject |
Zombie hitbox not on Entity (layer 23) | Weapon fire passes through zombie; no damage registered | Assign Entity layer to the body hitbox collider GameObjects in the zombie prefab |
Custom vehicle collider not on Vehicle (layer 26) | Vehicle passes through terrain or structures; vehicle cannot be entered | Assign Vehicle layer to all collider GameObjects on the vehicle prefab |
Custom barricade not on Barricade (layer 27) | Barricade not detected by repair raycasts; interaction prompt does not appear | Assign Barricade layer to the barricade's root GameObject |
Custom structure not on Structure (layer 28) | Structure not detected by build-system queries; cannot be placed or salvaged | Assign Structure layer to the structure's root GameObject |
| Viewmodel weapon on wrong layer | First-person weapon appears clipped into world geometry or invisible | Assign Viewmodel (layer 11) to the first-person weapon prefab; confirm the viewmodel camera renders only this layer |
Barricade on vehicle uses Barricade layer in prefab | Barricade does not move with vehicle | Allow the runtime to move the barricade to Resource (layer 14) when attached; the game handles this automatically |
Using Player layer for AI entities | AI character collision matrix mismatch | Use Agent (layer 24) for AI character capsules and Entity (layer 23) for AI body hitboxes |
| Ladder trigger on wrong layer or with no trigger collider | Player cannot climb | Assign Ladder (layer 25) to a trigger collider GameObject positioned at the climbable surface |
Custom weapon prefab on Default layer | Weapon appears in world but cannot be fired or equipped | Assign the weapon prefab to the layer appropriate for its context (viewmodel vs. world model) |
| Environment detail on a colliding layer when it should be non-colliding | Player blocked by small decorative objects | Assign to Small (layer 17) for non-colliding detail |
Diagnostic table: layer-related problems
| Symptom | Layers to check | Most likely cause | Resolution |
|---|---|---|---|
| Item visible but not pick-up-able | Item (13) | Item GameObject not on the Item layer | Set layer to Item on the root GameObject |
| Zombie takes no damage from weapons | Entity (23) | Zombie hitbox colliders not on the Entity layer | Set hitbox collider GameObjects to Entity layer |
| Player takes no damage in PvP | Enemy (10) | Body hitboxes not on Enemy layer or character on wrong layer | Verify hitboxes are on Enemy and character capsule is on Player |
| Vehicle falls through terrain | Vehicle (26), Ground (20) | Vehicle collider not on Vehicle layer or terrain not configured | Set vehicle colliders to Vehicle layer; check terrain collider enabled |
| Custom prop blocks movement in wrong way | Clip (21), target prop layer | Invisible clip geometry overlapping a visual prop | Review clip collider placement; ensure visual prop on correct layer |
| Structure cannot be placed or salvaged | Structure (28) | Structure prefab's root not on Structure layer | Set root GameObject to Structure layer |
| Barricade interaction prompt missing | Barricade (27) | Barricade not on Barricade layer | Set root GameObject to Barricade layer |
| First-person weapon clips into walls | Viewmodel (11) | Viewmodel not on dedicated layer or viewmodel camera culling mask wrong | Set weapon to Viewmodel layer; confirm viewmodel camera renders only this layer |
| Ladder non-functional | Ladder (25) | Ladder trigger missing or on wrong layer | Add trigger collider on Ladder layer at climbable surface |
| AI zombie walks through walls | Navmesh (22) | Navmesh collision missing or not generated | Generate navmesh from Navmesh layer colliders; verify colliders are present |
| Cloud or sky effect blocks player view | Sky (18) | Sky effect on a colliding layer | Set sky and atmospheric effect GameObjects to Sky layer |
| Debug handle visible to players in-game | Logic (8) | Editor-only objects not stripped from build | Remove Logic-layer objects from the asset bundle or set them inactive at runtime |
| Weapon hit registers on wrong target | Enemy (10), Entity (23) | Collider overlap between hitbox layers and environment layers | Ensure only hitbox colliders are on Enemy and Entity; keep environment colliders on their respective layers |
Layer-appropriate GameObject configuration for mod authors
When creating a custom GameObject for an Unturned™ mod, the following table provides the layer, collider type, and additional component requirements for each common mod authoring scenario.
| Mod scenario | Layer | Recommended collider type | Additional configuration |
|---|---|---|---|
| Custom dropped item | Item (13) | Box or capsule collider, trigger or solid depending on whether the item should block movement | Add InteractableItem script; set collider to approximate the item's visual bounds |
| Custom vehicle | Vehicle (26) | Mesh collider (convex) or compound box colliders for body; wheel colliders on Tire (29) | Add InteractableVehicle script; ensure root GameObject has Rigidbody |
| Custom barricade | Barricade (27) | Box or capsule collider matching the placed footprint | Add InteractableBarricade script; collider should match placement grid |
| Custom structure | Structure (28) | Box colliders matching the structure's wall/floor/roof segments | Add InteractableStructure script; colliders should be aligned to the structure grid |
| Custom zombie | Agent (24) for capsule, Entity (23) for hitboxes | Character controller on Agent; capsule colliders on Entity hitbox children | Add Zombie script to root; ensure hitbox colliders are on child GameObjects on Entity layer |
| Custom animal | Agent (24) for capsule, Entity (23) for hitboxes | Character controller on Agent; capsule colliders on Entity hitbox children | Add Animal script to root; ensure hitbox colliders are on child GameObjects on Entity layer |
| Custom large world prop | Large (15) | Mesh collider (non-convex for complex shapes, but consider performance) | Static GameObject; no scripts required unless interactive |
| Custom medium world prop | Medium (16) | Mesh collider or box collider | Static GameObject; no scripts required unless interactive |
| Custom small world detail | Small (17) | No collider (non-colliding detail) | Static GameObject; purely visual |
| Custom invisible clip volume | Clip (21) | Box collider matching the blocked volume | Invisible at runtime; use for blocking movement in areas without suitable visual collision |
| Custom navmesh volume | Navmesh (22) | Box or mesh collider marked for navmesh generation | Use for zombie-only collision; separate from player-visible collision geometry |
| Custom ladder | Ladder (25) | Trigger box collider | Add InteractableLadder or equivalent script; position at the climbable surface |
| Custom trap / damage volume | Trap (30) | Trigger box or sphere collider | Add damage-dealing script or configure the volume for damage application |
Layer collision pair diagram for frequent interactions
+-------------------------------------------------------------+
| Physics collision pairs for common mod authoring scenarios |
+-------------------------------------------------------------+
Player (9) collides with: Vehicle (26) collides with:
+-------+ +-------+
|Ground | (20) |Ground | (20)
|Clip | (21) |Clip | (21)
|Large | (15) |Large | (15)
|Medium | (16) |Medium | (16)
|Enviro | (19) |Enviro | (19)
|Resource| (14) |Resource| (14)
|Vehicle| (26) |Vehicle| (26)
|Barricade| (27) |Barricade| (27)
|Structure| (28) |Structure| (28)
|Debris | (12) |Debris | (12)
|Item | (13) |Item | (13)
+-------+ +-------+The collision pairs shown above are the documented pairs that the official SDG documentation confirms. The full 32-by-32 matrix includes additional pairings that may be present in specific Unity project configurations; consult the Physics settings in the Project.unitypackage for the exact matrix provided by the game's configuration.
How to verify layer assignments in Unity
The layer assigned to a GameObject is displayed in the Inspector at the top right of the GameObject header, in a dropdown labeled "Layer." To verify that every collider in a prefab hierarchy is on the correct layer:
- Select the root GameObject of the prefab in the Hierarchy window.
- In the Inspector, observe the Layer dropdown. Confirm it matches the expected layer for the entity type per the reference tables in this article.
- Expand the prefab hierarchy and select each child GameObject that contains a Collider component.
- Confirm each collider-bearing child is on the correct layer. The root's layer does not automatically propagate to children; each GameObject's layer is independent and must be verified individually.
- For prefabs with hitbox hierarchies (zombies, animals), confirm that the character capsule is on
Agent(layer 24) and that every body-part collider child is onEntity(layer 23).
The verification flowchart above should be run on every custom prefab before the prefab is exported in an asset bundle. Layer misassignments caught during the Unity Editor workflow are trivially corrected; layer misassignments caught during in-game testing require rebuilding the asset bundle and re-deploying, which is a substantial time cost for a single-setting correction. The cohort practice is to add a layer-verification step to the pre-export checklist for every prefab.
Worked example: configuring a custom zombie prefab
The following example traces the layer assignments for a hypothetical custom zombie prefab (CustomZombie) through the Unity hierarchy. This example illustrates the expected layer configuration for every GameObject in the prefab.
CustomZombie (root)
Layer: Agent (24)
Component: CharacterController
Purpose: AI movement capsule
CustomZombie
├── Head_Hitbox
│ Layer: Entity (23)
│ Component: CapsuleCollider (isTrigger = true or false)
│ Purpose: Head hitbox for damage detection
│
├── Torso_Hitbox
│ Layer: Entity (23)
│ Component: CapsuleCollider
│ Purpose: Torso hitbox for damage detection
│
├── Left_Arm_Hitbox
│ Layer: Entity (23)
│ Component: CapsuleCollider
│ Purpose: Left arm hitbox for damage detection
│
├── Right_Arm_Hitbox
│ Layer: Entity (23)
│ Component: CapsuleCollider
│ Purpose: Right arm hitbox for damage detection
│
├── Left_Leg_Hitbox
│ Layer: Entity (23)
│ Component: CapsuleCollider
│ Purpose: Left leg hitbox for damage detection
│
├── Right_Leg_Hitbox
│ Layer: Entity (23)
│ Component: CapsuleCollider
│ Purpose: Right leg hitbox for damage detection
│
├── Body_Mesh
│ Layer: Agent (24) -- inherits from root or explicit
│ Component: SkinnedMeshRenderer
│ Purpose: Visual mesh (no collider; uses hitbox children for physics)
│
└── Animator
Layer: Agent (24) -- inherits from root
Component: Animator
Purpose: Animation controllerThe root GameObject is on Agent (layer 24) with a CharacterController for movement. Each body-part hitbox child is on Entity (layer 23) with a CapsuleCollider for damage detection. The visual mesh and animator have no colliders and inherit the root's Agent layer. If any of the hitbox children were left on the root's Agent layer, weapon fire would pass through them because the weapon hit-detection raycast queries Entity, not Agent. If the root were on Entity instead of Agent, the zombie would not collide with terrain and structures because Entity has no physics collision.
Historical context: why the layer assignments are the way they are
The official SDG documentation states that the layer assignments are "entrenched from the earliest versions back in 2013" and that the author's "only defense is that these layers are entrenched." Several layer assignments that appear unusual to experienced Unity developers have historical explanations that are documented in the source material.
The Player versus Enemy split for character capsules and hitboxes is the most consequential historical decision. The asymmetry (server sees all players on Player, client sees only the local player on Player) is the product of a client-server architecture decision made early in development, and changing it would require rewriting the hit-detection, interaction, and rendering code across the entire game. Mod developers who encounter unexpected collision or raycast behavior when testing on a dedicated server versus in singleplayer are experiencing the downstream effects of this architectural decision.
The Ground2 layer (layer 31) exists because the original map format used a separate layer for out-of-bounds terrain, and when the map format was converted to terrain tiles, the layer was simply left in place rather than removed, because removing a layer assignment from the project configuration carries a non-zero risk of breaking legacy content that references the layer by index. The fact that Ground2 persists as a reserved layer in the current game version illustrates the broader principle that layer assignments in the Unturned™ project are treated as immutable after they are established, because the blast radius of a layer change is sufficiently large that the risk of unintended consequences outweighs any benefit from cleanup.
Best practices
- Verify every collider-bearing GameObject in a custom prefab against the entity type layer reference before exporting the asset bundle.
- Do not leave any mod GameObject on the
Defaultlayer (layer 0); it will have no collision and may fail interaction raycasts. - Assign the correct layer at the time of GameObject creation rather than deferring it to a later pass; layer assignment deferred to a later pass is frequently forgotten.
- For prefabs that contain both a character capsule and body hitboxes (zombies, animals), configure the capsule on
Agent(24) and the hitbox colliders onEntity(23). Do not set both to the same layer. - Confirm the project's Physics collision matrix matches the documented matrix if you are creating a Unity project from scratch rather than importing the provided
Project.unitypackage. The layer names alone are not sufficient; the collision matrix determines which layers interact. - Test collision behavior in both singleplayer and on a dedicated server when authoring mods that include custom collision geometry, because the
PlayerversusEnemylayer asymmetry under the client-server architecture produces different collision patterns in the two environments. - When diagnosing a collision or interaction problem, check the layer assignment of the GameObject in question before investigating any other cause. Layer misassignment is the single most common cause of physics and interaction failures in Unturned™ mods and is always faster to check than any alternative diagnostic path.
- Add a layer-verification pass to the pre-export checklist for every custom prefab. The time cost of verifying layers in the Unity Editor is trivial; the time cost of diagnosing a layer bug during in-game testing is substantial.
Worked example: diagnosing a missing collision bug
A common diagnostic scenario unfolds as follows. A mod developer creates a custom barricade prefab, exports it in an asset bundle, and spawns it in the game. The barricade appears correctly -- the model renders, the texture is applied, the interaction prompt appears when the player approaches. However, the player walks straight through the barricade: there is no collision. The developer checks the barricade's .dat file and confirms that collision-related fields are set correctly. The developer checks the asset bundle and confirms that the correct prefab was exported. The collision still does not work.
The diagnostic path for this scenario is as follows:
- Open the Unity project and select the barricade's root GameObject.
- Check the Layer dropdown in the Inspector. If it reads
Default, the cause is identified: theDefaultlayer has no physics collision in Unturned's collision matrix. Change it toBarricade(layer 27). - If the root is on
Barricade, expand the prefab hierarchy and check every child GameObject that contains a Collider component. If any collider-bearing child is onDefaultor on another non-colliding layer, change it toBarricade. - If all colliders are on
Barricade, check that each collider component is enabled (the checkbox next to the component name in the Inspector is checked). - If all colliders are enabled and on the correct layer, check the collider bounds: a collider that is scaled to zero or that has zero radius will not generate collision. Select the collider component and verify the bounds values.
- If the collider is correctly configured, rebuild the asset bundle and test again in-game.
The cohort has found that step 2 (root GameObject on Default) resolves approximately eighty percent of missing-collision cases in new mod prefabs. The remaining cases are split between child colliders on the wrong layer and collider components that are disabled or zero-scaled.
How Unturned's client-server architecture affects layer behavior
The split between the Player and Enemy layers has consequences beyond collision detection. The following table documents the layer-dependent behavior differences between singleplayer, a dedicated server, and a connected client.
| Behavior | Singleplayer | Dedicated server | Remote client |
|---|---|---|---|
| Local character capsule layer | Player (9) | Player (9) | Player (9) |
| Other players' capsule layer | N/A | Player (9) | Enemy (10) |
| Body hitboxes layer | Enemy (10) | Enemy (10) | Enemy (10) |
Collision Event Hook detects other players | N/A | Yes | No (other players are on Enemy) |
| Weapon raycast hits other players | N/A | Via Enemy layer | Via Enemy layer |
| All characters on one layer | Yes | Yes (Player) | No (local on Player, others on Enemy) |
The practical consequence for mod development is that any hook or custom script that queries the Player layer for character detection will see all players on the server but only the local player on the client. The cohort recommendation is to test mod behavior on a dedicated server before publishing to the Steam Workshop, because the singleplayer environment masks this asymmetry and bugs that are invisible in singleplayer will surface immediately when a player joins a multiplayer server with the mod installed.
Layer migration at runtime
Several layer assignments change at runtime as objects transition between states. The most significant migration is the barricade-to-vehicle attachment, but other runtime layer changes occur as well.
| Object state transition | From layer | To layer | Trigger |
|---|---|---|---|
| Barricade attached to vehicle | Barricade (27) | Resource (14) | Player attaches barricade to vehicle |
| Barricade detached from vehicle | Resource (14) | Barricade (27) | Barricade is removed from vehicle |
| Player ragdoll generated on death | Player (9) | Debris (12) | Player character dies; ragdoll spawned |
| Zombie ragdoll generated on death | Agent (24) | Debris (12) | Zombie dies; ragdoll spawned |
| Structure destroyed | Structure (28) | Fragments on Debris (12) | Structure HP reaches zero; debris fragments spawned |
These runtime migrations are handled by the game engine automatically and do not require mod-author intervention. However, mod developers who write custom scripts that query layers at runtime must be aware that the layer of a GameObject may change after the GameObject is spawned, and caching a layer value at instantiation time will produce stale data if the object later migrates.
Frequently asked questions
Why does Unturned use so many layers instead of tags?
Layers are an integer index that the Unity physics engine queries efficiently through bitmask operations. A single Physics.Raycast call can query multiple layers simultaneously by passing a bitwise-OR'd layer mask, and the physics collision matrix can be evaluated in constant time. Tags are string-based identifiers that require string comparison, which is substantially slower per query. The game's hit-detection code performs hundreds of raycasts per frame during combat, so the performance difference between layer-based and tag-based queries is material at the scale of a running game server with dozens of players.
Can I add custom layers for my mod?
The layer range is fixed at 32 indices (0 through 31), and Unturned™ has assigned specific purposes to every layer from 0 through 31. There are no unused layers in the current configuration that a mod developer could repurpose. Custom collision behavior in a mod must be implemented through scripting (checking tags, names, or custom component data on the GameObjects returned by a layer-based raycast) rather than through adding new layers. The layer system is a fixed resource at the engine level.
What happens if I change a layer assignment in my local project?
If you change the layer name or collision matrix in your local Unity project (in the Tag and Layer Manager or Physics settings), your project becomes incompatible with the Unturned™ game client, because the game's C# code references layers by their integer index and by their collision behavior in hard-coded raycast masks. Changing the layer at index 13 from Item to a custom name does not change what the game code expects to find at layer 13, and your items will fail interaction raycasts regardless of what the layer is named. Do not modify the layer configuration imported from the Project.unitypackage.
Why are Environment and Ground listed in both collision categories in the SDG documentation?
The official SDG documentation lists Environment (layer 19) and Ground (layer 20) in both its "No physics collision" and "Has physics collision" sections. This inconsistency reflects the complexity of those layers: Ground (terrain) participates in collision with character controllers and vehicles but the collision is managed through Unity's terrain collider rather than through standard layer-based collision pairs, and Environment (roads, grass) may have partial collision configuration that differs from other layers. The documentation inconsistency is a known issue with the source material. The cohort recommendation is to treat both layers as collision-capable and to test collision behavior for any custom objects placed on these layers.
What is the difference between the Clip layer and the Navmesh layer?
The Clip layer (21) is invisible collision geometry that blocks player and vehicle movement. The Navmesh layer (22) is invisible collision geometry that blocks zombie AI movement and from which the navmesh pathfinding graph is generated. A surface that should block both players and zombies needs colliders on both layers. A surface that should block zombies but allow players to pass (for example, a low obstacle that a player can vault but a zombie cannot navigate) needs colliders only on the Navmesh layer. The Clip layer collides with Player and Vehicle specifically; the Navmesh layer is used for AI-specific collision that is separate from the player-visible collision geometry.
Why does the barricade layer change when a barricade is attached to a vehicle?
The runtime moves barricades from Barricade (layer 27) to Resource (layer 14) when the barricade is attached to a vehicle. The reason relates to the collision matrix: the Resource layer has collision pairs that allow it to move with the vehicle without generating additional collision events with the vehicle body, whereas Barricade collision pairs with vehicles were not configured for attached-barricade behavior. The engine handles this migration automatically; mod developers should not attempt to assign Resource to barricade prefabs directly, because the barricade must be on Barricade during the placement phase to be detected by the building system.
How do I configure a GameObject that needs to be on two layers simultaneously?
A single GameObject can only occupy one layer. If a mod scenario requires a GameObject that must be visible to two different raycast masks (for example, a custom interactive object that must be detected by both the item-pickup raycast and the structure-repair raycast), the solution is to create two child GameObjects, each on the appropriate layer, each with its own collider. The parent GameObject can remain on any non-colliding layer. The two child colliders provide two layer-specific hit targets, and the game code that queries each layer detects the appropriate collider. This is the standard pattern for multi-layer interactive objects in Unturned™ mod development.
What happens if I set a GameObject to a layer that has no collision in the matrix?
The GameObject will not generate collision events with any other GameObject, regardless of the other GameObject's layer. It will pass through terrain, structures, vehicles, and players. It will still be visible to raycasts if the raycast mask includes its layer, and it will still be rendered by cameras whose culling mask includes its layer. The absence of collision is the only behavior change; the GameObject is not removed from the scene.
Are layer assignments the same in the Unity Editor and in the built game?
Yes. The layer names and indices are consistent between the Unity Editor and the built game client because the layer configuration is embedded in the project's TagManager.asset file, which is included in the Project.unitypackage and imported into every mod developer's Unity project. The built asset bundles do not carry layer configuration; the bundling process embeds the GameObject hierarchy with integer layer indices, and the game runtime reads those indices. As long as the developer's Unity project has the same layer configuration as the Project.unitypackage provides, the built bundles will reference the correct layers.
Can I use the Default layer for objects that don't need collision?
Objects on the Default layer (0) will have no physics collision in Unturned's collision matrix, which makes the layer superficially attractive for non-colliding props. However, using Default for any mod GameObject is not recommended because the game's raycast masks do not include Default, so the objects will be invisible to interaction, hit-detection, and rendering raycasts. Use the appropriate entity layer for the object's category instead: Small (17) for non-colliding visual detail, Sky (18) for distant atmospheric effects, or the specific layer for the entity type if the object must be detectible by raycasts.
How does the Player versus Enemy layer asymmetry affect mod collision code?
On the server, every player character capsule is on the Player layer (9), and body hitboxes are on the Enemy layer (10). On the client, only the locally-controlled player is on the Player layer; other players' entire characters (capsule and hitboxes) are on the Enemy layer. This means that any custom collision code that queries the Player layer will see all players on the server but only the local player on the client. The Collision Event Hook Mod Hook (see Mod Hooks Reference) specifically documents this limitation: it "only reports collisions with colliders on the Player layer, which is why it is not as useful on the client." Any mod that uses collision events or raycast queries that assume a consistent layer for all players must account for this asymmetry.
Appendix A: Unity layer quick-reference card
| Index | Name | Collision | Purpose |
|---|---|---|---|
| 0 | Default | No | Generic; not recommended for mod GameObjects |
| 1 | TransparentFX | No | Transparent special effects |
| 2 | Ignore Raycast | No | Raycast-invisible objects |
| 3 | (reserved) | , | Unity built-in reserved |
| 4 | Water | No | Ocean and water volumes |
| 5 | UI | No | In-game menus and UI |
| 6 | (reserved) | , | Unity built-in reserved |
| 7 | (reserved) | , | Unity built-in reserved |
| 8 | Logic | No | Editor handles and debug visuals |
| 9 | Player | Yes | Player character capsule |
| 10 | Enemy | No | Player body hitboxes |
| 11 | Viewmodel | No | First-person arms and weapon |
| 12 | Debris | Yes | Ragdolls, grenades, destroyed fragments |
| 13 | Item | Yes | Dropped interactable items |
| 14 | Resource | Yes | Trees, boulders, vehicle-attached barricades |
| 15 | Large | Yes | Large level editor props |
| 16 | Medium | Yes | Medium level editor props |
| 17 | Small | No | Small non-colliding detail props |
| 18 | Sky | No | Clouds, stars, atmospheric effects |
| 19 | Environment | Yes | Roads, grass, environmental detail |
| 20 | Ground | Yes | Terrain / landscape |
| 21 | Clip | Yes | Invisible player and vehicle collision |
| 22 | Navmesh | Yes | Invisible zombie-only collision |
| 23 | Entity | No | Zombie and animal body hitboxes |
| 24 | Agent | Yes | Zombie and animal character capsules |
| 25 | Ladder | No | Climbable trigger |
| 26 | Vehicle | Yes | Vehicle colliders |
| 27 | Barricade | Yes | Placed barricade items |
| 28 | Structure | Yes | Placed structure items |
| 29 | Tire | Yes | Vehicle wheel colliders |
| 30 | Trap | Yes | Damage triggers and kill volumes |
| 31 | Ground2 | No | Reserved (previously out-of-bounds terrain) |
Appendix B: Layer collision matrix summary
| Category | Layers |
|---|---|
| No physics collision | 0 (Default), 1 (TransparentFX), 2 (Ignore Raycast), 4 (Water), 5 (UI), 8 (Logic), 10 (Enemy), 11 (Viewmodel), 17 (Small), 18 (Sky), 23 (Entity), 25 (Ladder), 31 (Ground2) |
| Has physics collision | 9 (Player), 12 (Debris), 13 (Item), 14 (Resource), 15 (Large), 16 (Medium), 19 (Environment), 20 (Ground), 21 (Clip), 22 (Navmesh), 24 (Agent), 26 (Vehicle), 27 (Barricade), 28 (Structure), 29 (Tire), 30 (Trap) |
| Ambiguous in source docs | 19 (Environment), 20 (Ground) |
| Reserved, not active | 3 (Unity built-in), 6 (Unity built-in), 7 (Unity built-in), 31 (Ground2) |
Appendix C: Layer verification checklist for prefab export
Before exporting a custom prefab in an asset bundle, confirm the following layer assignments:
- [ ] Root GameObject layer matches the entity type (not
Default) - [ ] Every child GameObject with a Collider component is on the correct layer for its purpose
- [ ] Character capsule (if present) is on
Agent(24) orPlayer(9) as appropriate - [ ] Body hitboxes (if present) are on
Entity(23) orEnemy(10) as appropriate - [ ] No collider-bearing GameObject is on
Default(0) - [ ] No collider-bearing GameObject is on a non-colliding layer unless that is intentional
- [ ] Wheel colliders (if present) are on
Tire(29), not onVehicle(26) - [ ] Ladder triggers (if present) are on
Ladder(25) withIs Triggerenabled - [ ] Viewmodel weapon (if present) is on
Viewmodel(11) and the viewmodel camera culling mask is confirmed - [ ] No editor-only objects (
Logiclayer 8) are included in the bundle
Appendix D: External references
| Resource | URL | Notes |
|---|---|---|
| Smartly Dressed Games modding documentation | https://docs.smartlydressedgames.com/en/stable/ | Official layer documentation in Chapter 11. |
| Unturned on Steam | https://store.steampowered.com/app/304930/Unturned/ | Game page; changelog notes may reference physics or layer changes. |
| Unity Manual: Layers | https://docs.unity3d.com/Manual/Layers.html | Unity's official documentation on the layer system. |
| Unity Manual: Physics Collision Matrix | https://docs.unity3d.com/Manual/class-PhysicsManager.html | How to configure the layer-based collision matrix in a Unity project. |
Document history
| Version | Date | Author | Notes |
|---|---|---|---|
| 1.0 | 2026-07-26 | 57 Studios | Initial publication. Complete layer reference, collision matrix, raycast behavior, entity-type assignments, diagnostic tables, worked examples, FAQ, appendices. |
Cross-references
- Animation Asset Reference, the previous article in this section; covers animation asset authoring for custom prefabs, which depend on correct layer assignment.
- Mod Hooks Reference, the next article; covers Mod Hook script components that are attached to GameObjects on specific layers and the
Collision Event Hooklayer-dependent behavior. - Master Bundle Export, the Unity bundling workflow; prefabs must have correct layer assignments before export.
- Project Folder Structure and GUIDs, GUID generation and the Unity project setup that imports the layer configuration.
- Smartly Dressed Games modding documentation, official layer documentation, Chapter 11.
- Unturned on Steam, game page and community hub.