Skip to main content

Visibility and Culling

Polygon Engine uses conservative visibility rejection to reduce the geometry submitted to the PS1 ordering table. The current system combines optional Room and Portal connectivity, build-time geometry processing, runtime spatial candidate collection, bounds tests, frustum tests, back-face policy, near-plane clipping, and far-distance checks.

It does not use a modern hardware occlusion buffer or an exact portal-plane frustum renderer.

Build-Time Preparation​

Compatible static built-in geometry can be baked and divided into runtime mesh chunks. The build records bounds and visibility metadata for those chunks and reports:

  • baked mesh and triangle counts,
  • sectorized renderer counts,
  • worst visible-group triangle estimates,
  • packet-buffer estimates,
  • geometry that could not use the static visibility path.

The grouping scale is an engine implementation detail, not a public world-grid contract. Do not align gameplay coordinates or level modules to a hard-coded visibility-sector dimension.

Runtime Candidate Path​

The runtime constructs a spatial grid from eligible static mesh bounds. A fixed-capacity hierarchy groups grid cells into conservative volumes so an off-screen group can be rejected before testing every member. Potentially visible groups still run exact per-cell tests, then individual mesh bounds and triangles go through the renderer's normal visibility and clipping path.

The hierarchy is rebuilt only when the visibility-grid revision changes. If its input is invalid or exceeds capacity, the runtime fails open to the flat cell path rather than risking missing geometry.

Objects that cannot safely enter the static grid remain in the non-grid candidate list. This includes dynamic or behavior-bearing objects such as parented GameObjects and GameObjects with scripts, animation, collision, audio, lights, cameras, player components, or interaction components.

Conservative means that the system prefers submitting an extra candidate over incorrectly hiding visible geometry. It does not mean every submitted triangle will be drawn.

Room Connectivity​

Environment renderers can be assigned to Room GameObjects. When the camera is inside an authored Room, the PS1 runtime retains every room behind a valid adjacent opening, then recursively follows later enabled open Portals whose conservative aperture cones overlap. One-way Portals traverse from Room A to Room B; Two Sided Portals also allow B to A.

The cone around an opening contains the complete authored rectangle. This can keep extra rooms, but avoids rejecting geometry that could be visible through the portal chain. Ambiguous or malformed graph, camera, transform, opening, or capacity state fails open. No hardware occlusion buffer or BVH is promised, and global/unassigned renderers stay eligible. Editor Play Mode and the PS1 runtime use the same aperture-cone construction, overlap tolerances, recursion limits, and fail-open policy. The packaged build remains the authoritative performance and hardware test. See Rooms, Portals, and Navigation.

Authoring for Reliable Visibility​

  • Split very large floors and walls into practical chunks.
  • Prefer Level Builder meshes or build-baked primitives over one enormous imported mesh for an entire level.
  • Keep bounds representative of the visible object.
  • Avoid tiny coplanar offsets and deeply intersecting surfaces.
  • Subdivide geometry that can approach or cross the near plane.
  • Use opaque materials for structural geometry whenever possible.
  • Mark thin surfaces double-sided only when both sides must actually render.
  • Keep scripts and dynamic components off purely static environment chunks.

The UV Editor solves texture-coordinate layout; it does not change visibility bounds or draw ordering.

Diagnose a Visibility Problem​

  1. Determine whether the object is actually absent or is losing an ordering or transparency conflict.
  2. Check its material for semi-transparency and double-sided rendering.
  3. Inspect mesh bounds and transform scale.
  4. Check whether a script, parent, collider, Animator, or other component makes the object dynamic.
  5. If Renderer Room is assigned, verify the camera Room and every directed open Portal along the expected connection path.
  6. Review the PS1 Budget runtime workload and post-bake scene report.
  7. Test close camera approaches, oblique angles, and movement across chunk boundaries in the packaged DuckStation build.

If a problem only appears near the camera, review Rendering and Level Authoring. If it appears only on transparent or intersecting surfaces, treat ordering and material authoring as the first suspects rather than increasing the visibility range.