# 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.
- Ordinary dock and Inspector resizing mutates the existing HDR Image asset's extent while keeping
  its stable asset ID. Egui owns exactly one strong registration for that ID; an exceptional target
  replacement or absent/collapsed target explicitly unregisters the previous image.
- The editor host window prefers a non-FIFO presentation path (`AutoNoVsync`) so interactive
  NVIDIA/Wayland window resizing cannot wedge the UI behind repeated one-second swapchain-acquire
  timeouts. Packaged game windows retain `AutoVsync`.
- 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.
- Repeated splitter movement has bounded render-target ownership instead of retaining one
  full-resolution HDR image per intermediate panel width.
- Repeated native-window resizing remains interactive even when the compositor cannot immediately
  supply a FIFO swapchain image; this editor-specific latency choice does not change game VSync.
- 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.