# ADR 0014: Unified Viewport Model

## Status

Accepted

## Context

The editor previously exposed separate Scene View and Game View tabs. They used separate offscreen
targets and UI paths even though only one 3D camera could safely own the full project rendering
stack at a time. This made Play-in-editor feel inconsistent: entering Play changed tabs, editor
overlays were controlled separately from player rendering, and future multi-viewport work had to
account for two special-case primary panels.

## Decision

The editor has one primary **Viewport** tab backed by one HDR `ViewportRenderTarget`.

- Edit mode and Play-ejected bind the editor fly camera to the viewport target.
- Play-possessed binds the player camera to the same viewport target.
- `render_view.rs` continues to move the project render stack to exactly one active 3D camera.
- `G` toggles a clean game-view overlay that hides editor chrome, grid, selection outlines,
  transform gizmos, visualizers, and selectable proxies without changing camera ownership.
- `Ctrl+G` toggles the grid.
- Saved dock layouts containing the old Game View tab are migrated to one Viewport tab.
- Multi-viewport support is represented as future-facing state/API shape only; secondary visible
  viewports remain future work.

## Consequences

- Play starts in place instead of switching to a Game View tab.
- Camera ownership is explicit: F8 possession selects player camera vs editor camera; G only hides
  editor overlays.
- The HDR/swapchain invariant remains centralized around one offscreen viewport target.
- Future secondary viewports should add viewport-id keyed rects, targets, cameras, and overlay state
  rather than reintroducing a Scene View/Game View split.
- Post-FX and GI on the active viewport camera are owned by `game_hot::rendering::viewport_camera`
  (see [ADR 0015](0015-viewport-camera-stack-ownership.md)); editor systems must not strip the stack.
