Camera and Player Perception¶

The camera must keep a fully physical player readable inside caves, ruins, circle architecture, flight corridors, and close combat without becoming an invisible scout. It may move, compress, or remove a presentation obstruction. It may never grant information that God does not possess.

This document owns Darkfire's player-facing perception contract, camera priorities, tight-space behaviour, cutaway policy, lock-on visibility rule, accessibility requirements, and game-specific proof fixtures. The reusable pose solver, camera rigs, collision queries, procedural affordance schema, and render implementation belong to HellspawnEngine's CAMERA_SYSTEM_DESIGN.md. Geography owns terrain and topology. World Simulation owns persistent state. Traversal owns the controlled body's movement. Melee owns combat actions and contacts.

Governing Principle¶

The player character owns perception. The camera owns presentation. Procedural may remove a presentation obstruction; it cannot grant knowledge the character lacks.

The camera is not a world authority, a physical authority, or an information authority. Rotating it cannot discover an enemy behind God, look through a wall, expose a secret room, or turn a remembered location into current sight. It can only present facts already authorized by God's perception.

The player body is the one deliberate exception. The whole controlled body remains display-authorized even when the ideal camera lies partly outside the current enclosure. This is self-presentation, not supernatural sight. It does not authorize anything behind or beside the body.

Two-Stage Visibility¶

Every gameplay view resolves visibility in two stages:

player-character perception
    -> AuthorizedVisibleSet
    -> camera framing and view-local obstruction removal
    -> presented image

Conceptually:

AuthorizedVisibleSet = WholePlayer
                     union DirectlyVisibleFromPlayerCharacter
                     union ExplicitlyPerceivedByPlayerCharacter

The exact representation may operate on entities, semantic regions, anatomical regions, meshlets, primitives, or fragments. The invariant is more important than the storage form: camera visibility is an intersection with character perception, never a replacement for it.

Direct Sight¶

Direct sight begins at the current player-character perception origin and orientation, not at the external camera. It uses the character's eye or head pose, directional field of view, authoritative occluders, and the current room/portal/topology graph. A low-resolution character-depth or visibility pass may establish broad authorization, then refine uncertain boundaries per object or fragment where combat requires it.

• A fully visible enemy may be shown in full.
• A partly covered enemy remains partly covered. The camera cannot fill in the hidden half.
• A fully hidden enemy is not rendered merely because the camera has a geometric line to it.
• An enemy that moves behind cover disappears from current sight even if the player saw it one second ago.
• Turning or moving God's body may change direct sight. Rotating only the camera may not.

Explicit Perception¶

Sound, vibration, smell, magic, remembered position, testimony, and inferred evidence may tell God something without making its source visually present. The perception system must state what each sense authorizes. A heard enemy may produce direction, uncertainty, an authored sensory treatment, or no visual treatment at all; it does not silently authorize a rendered body.

God's tribrid perception can explicitly expand this set. Folds are the canonical example: God perceives a real topology manifestation others cannot. The supernatural sense reveals only what its own rule authorizes. It is not a blanket excuse for camera omniscience.

Indirect Evidence¶

The view may show visible evidence without showing its hidden cause:

• a shadow cast into the authorized space;
• dust or water displaced around a corner;
• light crossing a doorway;
• a weapon or limb that physically protrudes into sight;
• sound transmitted through architecture;
• a recent mark, footprint, impact, or damaged object.

This preserves the difference between perceiving an effect, inferring a source, and seeing the source directly.

What the Camera Must Preserve¶

The preferred gameplay view preserves, in order:

1. the whole player body and its contact with the environment;
2. the weapon, hands, feet, wings, and current physical action;
3. every currently authorized threat region needed to read contact and intent;
4. the local route, support surface, edges, openings, and hazards God can perceive;
5. stable screen-space motion and a consistent input reference;
6. authored composition where it does not violate the higher rules.

This is not a demand to center everything. The camera may choose a slightly imperfect composition to remain stable. A continuous, legible view is preferable to a theoretically optimal pose that jitters between candidates.

The camera must not:

• reveal a hidden enemy, item, chamber, route, secret wall, trap, or fold;
• treat lock-on as permission to see through cover;
• remove real tactical cover from the player's information model;
• move the player, weapon, target, or collision to repair a shot;
• change a combat result, topology edge, terrain event, or NPC perception;
• allow a free-look camera to inspect space God is not facing or otherwise perceiving;
• make a view-local aperture persistent, saveable, destructible, or visible to another observer.

Tight Spaces Use a Procedural Aperture First¶

The primary response to a wall crowding the ideal view is not to force an over-the-shoulder camera into the player's body. The preferred response is a stable camera with a view-local opening through the enclosing presentation surface. The cave or wall appears to melt, peel, dissolve, or cut away around the image, revealing the whole player and only the authorized scene.

This solves the recurring tight-space failure directly: the obstruction is removed from this view instead of making the camera fight continuously for the few centimetres left between the player and the wall.

Shoulder compression remains available when a surface is protected from cutaway or no valid aperture can preserve the scene. It is a fallback, not the default identity of Darkfire's camera.

Procedural Camera Affordances¶

Caves, ruins, tunnels, interiors, and circle architecture derive camera affordances from the same semantic feature that derives render geometry, collision, navigation, visibility, and acoustics. A camera affordance should expose facts equivalent to:

CameraAffordanceRegion
    SurfaceId and stable feature/structure identity
    representation and persistent-delta epoch
    room/chamber and transition graph
    tunnel centreline and cross-section frame where applicable
    expanded camera free space
    continuous camera manifolds and portals
    clearance plus boom/pitch/yaw bounds
    preferred shoulder or axial alignment
    player/authorized-target framing capacity
    cuttable and protected occluder classifications
    cross-section material/cap description
    legal mode transitions and hysteresis regions

These records do not contain a precomputed camera animation. They define the legal configuration space in which the runtime solver finds a continuous view. The configuration-space test uses the camera frustum, near plane, and swept camera body rather than a single ray or point spherecast.

Procedural generation may improve camera solvability while preserving authored space: widen or chamfer selected bends, create a ceiling pocket, offset a pillar, preserve an alcove, or place a camera transition before a choke point. This does not mean every cave becomes a combat arena. Confinement remains real; its camera consequences become intentional rather than accidental.

The View-Local Cutaway Volume¶

A cutaway is a rounded cone, capsule, swept frustum, or compatible derived volume between the camera near plane and an interest hull. The interest hull changes with context:

• Exploration: the whole player plus the immediately authorized route and support context.
• Duel: the player, weapon, contact region, and currently player-visible portions of the opponent.
• Multiple opponents: the player plus only the threat regions God currently perceives.
• Flight: the whole player plus the authorized forward trajectory, turn, and braking envelope.

The cutaway may subtract only surfaces classified CameraCuttable, within the current semantic visibility cell and a bounded depth. It subtracts CameraProtected surfaces from the request before rendering.

Typical cuttable surfaces include the enclosing cave shell, ordinary ceilings, and non-tactical exterior wall layers whose sole effect is blocking the current view. Typical protected surfaces include:

• secret or unopened walls and doors;
• boundaries of adjacent occupied chambers;
• tactical cover and pillars whose occlusion is gameplay-significant;
• puzzle, landmark, hero, fold, and authored-topology boundaries;
• destruction-significant construction where a fake breach would lie about the world;
• any surface whose removal would expose unauthorized geometry, lighting, or evidence.

The aperture cuts the current enclosure, not arbitrary objects between God and an enemy. It may reveal the whole player; it may not excavate a sightline to a target.

Presentation, Not Destruction¶

The rendering relationship is conceptually:

main-camera terrain = current terrain realization - CameraCutawayVolume

Everything authoritative remains unchanged:

terrain and structure state
collision and physical contact
navigation and AI movement
hydrology and environmental processes
visibility/portal authority
acoustics and sound transmission
NPC perception and witnesses
save/load and persistent deltas
other cameras, reflections, shadows, and remote views unless explicitly configured

The implementation should not remesh authoritative terrain every frame. A renderer may use clipping, signed-distance evaluation, mesh or primitive classification, stencil/depth techniques, or another measured path. Procedural supplies correct cross-section caps and the geology or wall layers visible at the cut, so the opening reads as a deliberate view through the same material rather than a missing backface.

Uncut geometry continues to own physical lighting and shadowing. The renderer must explicitly handle cap depth, ambient occlusion, decals, particles, motion vectors, reflections, temporal history, and exterior/background capping so the aperture cannot reveal an adjacent room through a secondary effect.

The aperture expands quickly to prevent loss of information and contracts slowly to prevent flicker. A recent swept union, hysteresis, and a preference for one coherent opening over many small holes keep the result temporally stable.

If gameplay genuinely destroys the wall, World Simulation records a semantic terrain or construction event. The presentation then transitions from a view-local aperture to the real opening without a pop. The camera never authors that event.

Runtime Camera Solver¶

At every update the solver receives the player pose, velocity, control intent, weapon/contact state, currently authorized perception, camera profile, procedural affordances, authoritative collision, and relevant streaming state. It solves for a continuous pose inside the legal camera configuration space.

Hard constraints include:

• finite orientation and a declared up convention;
• no forbidden camera-body or near-plane penetration;
• a reachable swept path from the previous pose;
• no crossing of authored topology or protected boundaries;
• no presented fragment outside the authorized perception contract.

Among legal candidates, the score should minimize:

player and authorized-threat occlusion
whole-body and contact-region framing error
camera translation, rotation, acceleration and jerk
boom, field-of-view and shoulder changes
camera-relative input-reference rotation
mode transitions and aperture churn

Predictive inputs include body velocity and intent, braking distance, wing and weapon sweep, target/contact motion, cave curvature, the next chamber or camera portal, and the current route tangent. The camera begins transitioning before the player reaches a bend or choke point rather than correcting after the shot is already broken.

Fallback Order¶

The fallback ladder is:

1. retain the stable preferred camera;
2. slide along the current procedural camera manifold;
3. enlarge the legal view-local aperture;
4. apply a modest distance or field-of-view change;
5. use an axial tunnel or chamber camera;
6. compress to shoulder or close-body framing only when cutaway is prohibited or insufficient;
7. enter a protected authored transition with an explicit receipt.

No rung may relax perception authorization or cross a protected topology boundary.

Ground, Flight, and Three-Dimensional Routes¶

God can move and fight in three dimensions. Flight camera affordances are therefore volumes, not ground splines. The solver predicts along the controlled body's trajectory, current turn authority, braking envelope, emergency landing volume, and nearby collision. It uses the route tangent and a stable physical or authored up reference; it does not introduce arbitrary roll merely because the player banked.

In confined flight, the whole body, wings, likely collision side, and authorized forward route take priority over a cinematic trailing distance. At continental speed the camera consumes broad-form and horizon truth; before descent it requires fine collision, topology, and camera-affordance data early enough to choose a continuous arrival view. See Traversal.

Combat, Lock-On, and Input¶

Device-independent action mapping, rebinding, focus/device-loss cancellation, accessibility feedback, and prompts belong to Player Interface and Input. This camera contract owns framing, perception authorization, stable input reference, and comfort; camera assistance cannot add targets or hidden knowledge.

Lock-on selects a control and framing relationship among targets already perceived by God. It never adds a target to the authorized visible set. When cover fully breaks direct sight, the body disappears from the image. The control system may retain a remembered or uncertain target state only if the perception rules allow it, and its presentation must not pretend that memory is sight.

Partially visible opponents remain partially visible even when locked. Camera cutaway may remove the player's enclosing wall, but not the opponent's cover. Weapon tips, shadows, sound, or debris remain usable evidence when physically perceived.

Camera-relative movement and guard direction use a stabilized reference frame. Brief solver corrections must not invert input, swap shoulders repeatedly, or rotate the control basis faster than the player can read. An accessibility profile may reduce shake, angular velocity, field-of-view change, aperture edge motion, and automatic recentering without changing perception authorization, collision, combat outcomes, or world truth.

Streaming, Identity, and Invalidation¶

Camera demand is additional demand, not a second world model. The streaming layer predicts the collision, visibility, room graph, cap material, and camera-affordance data needed along the likely route. Gameplay truth remains higher priority than visual ornament.

Derived camera artifacts include at least SurfaceId, semantic region and feature/structure identity, representation epoch, persistent-delta epoch, camera-profile version, and algorithm version in their compatibility keys. A cave crossing several cells retains one camera-affordance identity. Eviction and regeneration must recover the same legal portals, protected surfaces, and framing constraints for the same authoritative state.

Local destruction, repair, door movement, collapse, flooding where it changes traversal, or a topology-state change invalidates only the dependent camera affordances. Publication is atomic with the compatible collision, visibility, and architecture/terrain views required by that event.

Ownership Boundary¶

Verification Contract¶

The camera is accepted by invariants, not by a few attractive captures.

Perception and Information¶

• The whole player remains visible when the preferred camera lies outside an enclosing cave shell.
• A fully player-visible enemy may render fully; a partly covered enemy remains partial; a hidden enemy renders no body.
• An enemy that moves behind cover disappears even while lock-on retains an allowed remembered relationship.
• Camera rotation alone never expands AuthorizedVisibleSet; moving or turning God can.
• A shadow, sound, dust plume, protruding weapon, or other visible effect may remain without exposing its hidden source.
• A secret wall, adjacent chamber, unopened door, disconnected fold endpoint, and protected cover are never exposed by cutaway, lighting, reflections, particles, temporal history, or cross-section generation.

Camera Continuity¶

• Every traversable player path in a proof fixture has a continuous legal camera path or a declared authored transition.
• Camera body, frustum, and near plane never penetrate a protected surface.
• Translation, rotation, acceleration, jerk, field-of-view change, aperture motion, and mode transitions remain within profile bounds.
• The solver does not thrash shoulders, repeatedly enter/leave axial mode, invert input, or oscillate between equal candidates under small pose noise.
• Ground, climbing, falling, confined flight, high-speed approach, forced landing, and combat weapon sweeps remain legible under their declared profiles.

World and Procedural Integrity¶

• A camera aperture changes no collision, contact, navigation, hydrology, acoustics, AI perception, witness record, persistent delta, save, or other view.
• Cave and structure camera-affordance identity survives promotion, de-promotion, cache eviction, save/load, clean and incremental rebuild, and legal schedule variation.
• A destruction event invalidates only dependent camera artifacts and transitions cleanly from view-only aperture to a real opening.
• CPU and GPU implementations, cache hit and miss, and clean and incremental derivation agree within declared numeric tolerances while categorical protection and visibility results remain exact.
• Receipts preserve the perception source, chosen rig/candidate, rejected hard constraint, aperture classification, fallback rung, invalidated dependencies, and first failure.

First Proof Fixture¶

The first bounded fixture contains one connected cave/ruin route with:

• an S-bend and low tunnel;
• a ninety-degree corner and a narrow doorway into a chamber;
• a spiral or curved descent and a vertical shaft that permits flight;
• one central pillar, one wall-hugging enemy, and at least two visible route branches;
• the player against a wall with a full weapon sweep;
• one secret or protected wall and one adjacent occupied chamber;
• one genuinely destructible wall.

The gate requires a headless deterministic route trace and visual regressions. The stable preferred camera must remain outside the shell where useful, produce one coherent material-capped aperture, keep the whole player visible, show only the player-visible parts of the locked enemy, preserve every protected boundary, and transition the destructible wall from a view-only aperture to an authoritative opening after one validated event. All perception, camera, Procedural, Rendering, Physics, streaming, and world-state assertions above run against the same fixture.

Production cave generation, circle-interior generation, or broad camera tuning does not begin until this bounded gate is green on the target performance tiers.

The Rule¶

Show the whole player. Show the world God can perceive. Melt only the presentation obstruction between them.