Split Screen

Use split screen when two or more local players need independent characters, cameras, controls, and HUDs in the same scene. Each player requires a complete camera-to-character assignment, while Material Swapper keeps a first-person player’s third-person body visible to the other cameras.

Without per-camera material swapping, another player’s view can render the materials intended only for the local first-person camera:

With Material Swapper on the required camera GameObjects, each view renders the correct body and first-person objects:

Before you begin

• Follow Quick Setup so the scene managers, render-pipeline integration, first camera, and one character work before duplicating anything.
• Create a separate playable character for every local player with Character Creation. Test each character’s Movement Type, View Types, inventory, and input separately first.
• Decide the number of players, viewport layout, input-device ownership, and HUD layout before building the duplicates.
• Treat this as a local multiplayer setup. UCC does not use this workflow to provide network spawning, ownership, replication, device joining, or synchronized game state.

Set up the player cameras

1. Select the working camera GameObject that contains Camera, Camera Controller, and Camera Controller Handler.
2. Duplicate the complete camera GameObject once for each additional local player. Keep any child FirstPersonCamera with its parent when the first-person View Type uses Overlay Render Type > Second Camera.
3. Give every camera a clear player-specific name, such as Player 1 Camera and Player 2 Camera.
4. Keep exactly one enabled Audio Listener in the scene. Remove or disable it on the other cameras. UCC does not split or mix listener output per viewport.
5. On the first Camera Controller, expand Character, keep Init Character On Awake enabled, and assign Player 1 to Character. Assign Player 2 to the second Camera Controller, and repeat for additional players. Do not leave Character empty and rely on the shared Player tag in a multi-character scene.

1. Confirm that each camera has the intended first-person or third-person View Types and that each View Type uses the correct Movement Type on its assigned character.
2. Set each Camera’s Viewport Rect to a unique normalized screen region using X, Y, W, and H.

Add Material Swapper

Add Material Swapper to every main camera GameObject that contains Camera Controller. Assign Invisible Material to the pipeline-compatible invisible shadow caster used by the characters, and leave Manual Swap disabled for automatic per-camera rendering.

Active rendering path	Required Material Swapper locations
Overlay Render Type > Second Camera in the Built-in Render Pipeline	Main Camera Controller GameObject and its child FirstPersonCamera, for every local player
Overlay Render Type > Render Pipeline	Main Camera Controller GameObject only; the URP or HDRP integration must already be configured
Overlay Render Type > None	Main Camera Controller GameObject only, although first-person objects can intersect scene geometry in this mode
Third-person-only local player	Material Swapper is not required; omit it unless a first-person View Type is added to that camera before Play Mode

Use Second Camera for the Built-in Render Pipeline and Render Pipeline for the configured URP/HDRP integration. The current SRP child Material Swapper filters callbacks to its parent Camera Controller’s camera, so Second Camera in URP/HDRP does not provide the per-child render timing this workflow requires. It needs a source correction before using that combination.

The component restores the character’s normal third-person materials when its own camera is not rendering, then applies the correct first-person visibility only for that camera’s render. This allows another player’s camera to see the complete body.

First-person-only character packages

When Character Manager creates a first-person-only character without a third-person Movement Type, it replaces the selected third-person Renderer materials with the invisible shadow caster. Material Swapper cannot restore materials that were already invisible when it cached them. Restore the real body, head, arms, and item materials on those Renderers before testing split screen.

Do not remove the Third Person Object identifiers. They tell the perspective and material systems which Renderers belong to the visible third-person body.

Choose a viewport layout

Camera Viewport Rect values are normalized from 0 to 1, with the origin at the bottom-left of the screen:

Layout	Player	X	Y	W	H
Two players, left and right	Player 1	0	0	0.5	1
	Player 2	0.5	0	0.5	1
Two players, top and bottom	Player 1	0	0.5	1	0.5
	Player 2	0	0	1	0.5
Four equal quarters	Player 1, top-left	0	0.5	0.5	0.5
	Player 2, top-right	0.5	0.5	0.5	0.5
	Player 3, bottom-left	0	0	0.5	0.5
	Player 4, bottom-right	0.5	0	0.5	0.5

Choose the split direction around the game’s sight lines and interface. A horizontal split gives each player more width; a vertical split gives each player more height. Test the final target aspect ratios rather than judging only one Game view size.

Assign player-specific input

Each character must resolve a different IPlayerInput implementation. A second camera does not separate controls by itself.

• Unity Input System: Give every character its own Player Input Proxy and child input GameObject with both Opsive’s Unity Input System component and Unity’s Player Input component. On Player Input Proxy, assign Player Input to that same character’s Opsive input component. Pair a distinct device or control scheme with each Unity Player Input; sharing the same unpaired action asset is not device ownership.
• Rewired: Give every character its own Rewired Input component and unique Rewired player assignment, then point that character’s Player Input Proxy > Player Input to it. See Rewired.
• Legacy Input Manager: Global axis names are not player identities. Use separate mappings and a player-specific input implementation, or choose the Input System/Rewired when devices must join and pair dynamically.

Follow Input for the UCC input layer. Device pairing, local-player joining, and per-player UI navigation remain responsibilities of the chosen input system.

Assign a HUD to each player

1. In Setup Manager > Scene, use UI Setup > Add UI to create the first HUD if the scene does not already have one.
2. Duplicate the player HUD hierarchy for each additional player.
3. On every Character Monitor-derived component in the first HUD, assign Player 1 to Character. Assign Player 2 throughout the second HUD, and repeat for the other players. Leave Attach To Camera enabled when the monitor should follow later Camera Controller character changes; disable it when the HUD must remain locked to its explicit Character.

1. Constrain each HUD root to the same screen region as its camera. For a Screen Space – Overlay Canvas, anchor and clip each player’s root panel to that player’s half or quarter. For a Screen Space – Camera Canvas, assign the corresponding player camera and confirm the Canvas fills only that camera’s viewport.
2. Test crosshairs, damage indicators, item monitors, menus, and pointer input separately. Interactive per-player menus may need the input system’s multiplayer UI/Event System setup; duplicating Character Monitors only separates the UCC data source.

Key multiplayer constraints

• Use one local Camera Controller, character, input instance, and HUD assignment per player. Remote network characters normally do not receive a local Camera Controller or local input.
• Keep only one Audio Listener unless a separate audio solution explicitly supports multiple listeners.
• Material Swapper handles first-/third-person Renderer materials. It does not divide culling layers, post-processing Volumes, UI canvases, audio, or input devices.
• Every gameplay camera renders its own viewport, so rendering cost grows with the number of cameras. Profile the final scene with all players active.
• Camera-relative effects can differ because each camera evaluates its own culling mask, View Type, post-processing, Object Fader, and Volume position. Configure shared effects deliberately; see Post Processing.
• Runtime joining requires the spawning system to create or assign the character, camera, viewport, input, HUD, and Material Swapper relationship. UCC does not automatically rearrange existing viewports when a player joins or leaves.

Verify in Play Mode

1. Start with all local players visible. Each viewport should occupy only its assigned rectangle, without gaps or unintended overlap.
2. Move and look with one device at a time. Only the intended character and its camera should respond.
3. Equip a visible first-person item for every player. In each player’s own view, arms and items should render correctly; in every other view, that character’s complete third-person body and item should remain visible.
4. Switch each supported character between first and third person. No body, head, arms, item, muzzle flash, or shadow material should remain in the wrong state after the switch.
5. Damage, heal, equip, reload, aim, and kill one character at a time. Only that player’s HUD should update.
6. Verify that only one Audio Listener is enabled and that no multiple-listener warning appears in the Console.
7. Test local Volumes, Object Fader, camera collision, zoom, and screen-space effects in every viewport.
8. Respawn or replace each character. Its Camera Controller, Material Swapper, input proxy, and Character Monitors should attach to the replacement without changing the other players.
9. Test the target display resolutions and profile CPU/GPU frame time with the maximum supported player count.

Troubleshooting

Symptom	Check	Fix
Both cameras follow the same character.	One Character field may be empty, duplicated, or falling back to the shared Player tag.	Keep Init Character On Awake enabled and explicitly assign a different Character on every Camera Controller.
One device moves both characters.	The characters may share the same input component, device pair, control scheme, or legacy mapping.	Give each character its own Player Input implementation and pair distinct devices or player IDs.
Another viewport sees a headless or armless character.	Material Swapper may be missing from a main camera, its child FirstPersonCamera, or its Invisible Material may be wrong.	Add the component at every location required by Overlay Render Type and assign the matching pipeline material.
A first-person-only character remains invisible to other players.	Its original third-person Renderer materials may already have been replaced by the invisible shadow caster during character creation.	Restore the real Renderer materials while keeping the Third Person Object identifiers.
Unity reports multiple Audio Listeners.	Duplicating the camera also duplicated Audio Listener.	Keep one enabled listener and remove or disable the others.
One camera covers the entire screen.	Its Viewport Rect may still be X 0, Y 0, W 1, H 1, or its render order may hide the other view.	Apply the complete layout table to every camera and check for other full-screen cameras.
A HUD shows the wrong health, item, or crosshairs.	One or more Character Monitors may reference the wrong Character, or Attach To Camera may follow another Camera Controller assignment.	Audit every monitor in that HUD and choose either one explicit Character or the intended camera-follow behavior.
Both HUDs render over the full display.	Their Canvas or root RectTransforms may not match the player viewports.	Anchor/clip Overlay HUD roots or assign each Screen Space – Camera Canvas to its player camera.
First-person materials flicker or stay swapped.	Manual Swap may be enabled, a required Built-in child swapper may be absent, or SRP may be using the unsupported Second Camera callback path.	Disable Manual Swap, use the pipeline configuration above, and reassign Camera Controller Character after runtime replacement.
Performance drops sharply with more players.	Every camera repeats scene culling and rendering, and each HUD/effect can add work.	Profile per camera, reduce expensive effects and visible geometry, and set a supported local-player limit.

Related pages

• Camera Controller
• Quick Setup
• Character Creation
• Input
• Rewired
• First Person View Types
• Post Processing
• Object Fader

Developer details

MaterialSwapper listens to the Camera Controller’s OnCameraAttachCharacter event. Built-in rendering uses the component’s own OnPreRender and OnPostRender callbacks. URP/HDRP filter RenderPipelineManager.beginCameraRendering and endCameraRendering against the Camera obtained from the associated Camera Controller. A child swapper resolves that controller on its parent, so its SRP filter also matches the parent camera rather than the child.

In the Built-in branch, the main camera swaps both first- and third-person Renderers, including in Second Camera mode; the child swapper handles first-person Renderers. In the URP/HDRP branch, a main camera uses a third-person-only mask for Second Camera, and both renderer groups otherwise. That mask selection does not fix the child callback limitation described above. The editor warns when a referenced child First Person Camera lacks Material Swapper.

The component caches Renderers under FirstPersonBaseObject and ThirdPersonObject, updates its cache when inventory items are added, cooperates with Object Fader during multi-camera renders, and restores materials on perspective changes and respawn. Manual Swap disables automatic callbacks; a custom system must call EnableFirstPersonMaterials and EnableThirdPersonMaterials at the correct render boundaries.

Camera Controller initializes a serialized Character only when Init Character On Awake is enabled. If that field is enabled and Character is empty, it searches the Player tag; if it is disabled, the serialized Character is cleared so a runtime manager can assign CameraController.Character later. Character Monitor can either hold its explicit Character or update it from its associated camera when Attach To Camera is enabled.

When a networking integration defines multiplayer support, Perspective Monitor keeps remote non-spectator characters in third-person materials and applies first-person visibility only to local players or spectators. That network rule does not create local split-screen cameras, inputs, viewports, or HUDs.