PixelQubed /

LEARNING GUIDE

Secondary-view rendering: declarations, ordering and limits

draft illustrative

Origin: original-commentary · review: draft · snapshot: 3ba1c69afc74a97f-7fcd0798fd6ea455

Secondary-view rendering: declarations, ordering and limits

This guide explains the smallest evidence-backed shape for a second camera

view. It is original commentary over the pinned snapshot, not Facepunch

documentation.

What the snapshot establishes

The metadata declares `Sandbox.CameraComponent.RenderToTexture` with a target

texture and an optional `Sandbox.Rendering.ViewSetup`. It also declares camera

composition and scene-camera update operations. The indexed source contains

call sites and guards around camera rendering, command-list scheduling and

render-target lifetime. Those call sites explain implementation behaviour in

the supplied public tree; they do not establish that every step is callable by

game code in the installed build.

A safe working sequence

1. Check the active snapshot and resolve the exact overload, rather than using

the short name `RenderToTexture`.

2. Create or obtain the destination target before asking the camera to render.

Keep the target alive for the complete render pass and release it through

the owning resource contract.

3. Build a `ViewSetup` from the destination camera state. Treat projection,

clipping, viewport, fog and temporal history as explicit inputs; none of

them should be assumed to follow from a texture render.

4. Schedule the operation in the render phase supported by the selected

surface. A source call site is evidence of an engine path, not proof that a

game component may call it directly.

5. Restore the previous target and view state. Bound recursion and reject

re-entry before a second view can schedule itself indefinitely.

Common mistakes

  • Treating a clipped portal proxy as a second physical scene. Rendering a

    • destination texture does not move rigidbodies, contacts, or network

    authority.

  • Reusing entry-view viewport/history/fog resources for the destination view.

    • The portal workflow records this as a testable hypothesis for black tiles,

    not as a verified cause.

  • Calling deprecated hook surfaces because their names are familiar. The

    • snapshot carries obsolete attributes where present; resolve and display that

    state before copying an example.

    What remains unverified

    No example in this handbook has been compiled or run against an installed

    S&box build. Direct recursive framebuffer composition, fog transport and

    temporal-resource reuse therefore remain bounded experiments. A useful probe

    is one destination camera, one target, recursion disabled, and logging of pass

    ordering, viewport, projection, history and cleanup.

    Constraints and verification

    Linked API declarations