Skip to main content

PS1 Rendering & Level Authoring

This page explains the most important idea behind Polygon Engine's PS1 workflow:

The editor can be primitive-driven, but the PS1 build must be geometry-aware.

Why Scenes Fail on PS1​

The PlayStation GPU draws ordered 2D primitives. It does not solve visibility with a z-buffer.

That creates recurring problems when a level is authored from large, scaled primitives:

  • floor pieces fight each other,
  • wall faces overlap incorrectly,
  • geometry disappears near the camera,
  • large rounded props read as boxes or prisms,
  • fixing one artifact often reintroduces another.

Those are not random bugs. They are a sign that content is reaching the PS1 runtime in a form that is too coarse for the hardware's ordering-table model.

What Polygon Engine Protects Automatically​

Polygon Engine does not add a z-buffer to the PlayStation. It prepares geometry and uses deterministic fallbacks around the failure modes it can identify.

Safe projection and clipping​

Triangles and quads use the normal GTE path while their projection is safe. If depth would overflow the perspective divider or the GTE reports saturated screen coordinates, the runtime switches that primitive to a bounded CPU path. The polygon is clipped against the near, far, left, right, top, and bottom view planes before packets are emitted.

Shared clipping edges use a canonical fixed-point intersection. Adjacent polygons therefore calculate the same clipped vertex even when their edge winding is opposite. This prevents a wall or floor seam from opening only because the camera crossed the near plane.

Generated surface continuity​

Static built-in floors and walls are converted into conforming surface cells:

  • adjacent cells share subdivision boundaries,
  • surface cells stay native PS1 quads where the material path allows it,
  • spatial chunks use snapped local origins to retain vertex precision far from world zero,
  • visibility bounds remain in world space so rebased distant chunks are not culled as if they were near the origin,
  • and a recessed parent surface covers background-colored pinholes between floor or wall cells.

These rules apply to generated built-in surfaces. They are not permission to import an arbitrary desktop mesh and assume it will become optimal PS1 level geometry.

T-junction repair​

Model import and Level Builder export detect vertices that lie on another triangle edge and split that edge deterministically. New vertices interpolate the original normals and UVs. This closes a common source of one-pixel cracks without discarding the authored texture mapping.

Repair can increase vertex and triangle counts, so the post-import stats and post-bake budget remain the source of truth.

Ordering precision and local interior rendering​

3D depth is mapped across the complete scene portion of the ordering table after the reserved UI buckets. Close objects therefore retain useful depth resolution instead of collapsing into the UI boundary. When surfaces share a bucket, oriented mesh bounds provide a better object-order hint than a sphere's height alone.

Trigger-only meshes can temporarily render interior faces when the camera is inside their render volume. Normal solid geometry keeps back-face culling, so this exception does not silently double the packet cost of every wall.

Distance fog is evaluated from each clipped or subdivided vertex in fixed-point. Large floors and walls keep a depth gradient instead of inheriting one fog value from the object origin.

Correct Workflow in Polygon Engine​

1. Author fast in the editor​

Use:

  • Plane for floors,
  • Cube for walls and gates,
  • authored UI elements for menus and HUD,
  • Lua for interactive stations and flow.

2. Build specifically for PS1​

During PS1 export, Polygon Engine can:

  • bake static built-in geometry to staged meshes,
  • split generated surfaces into conforming cells and spatial chunks,
  • repair T-junctions in imported and Level Builder meshes,
  • preserve materials and scene layout,
  • package a startup scene, manifest, and runtime-friendly asset set.

3. Run the chunked result on hardware​

This is the key difference between:

  • a scene that only looks correct in the editor, and
  • a scene that survives real PS1 ordering, clipping, and affine rasterization.

Rules for Stable Geometry​

Floors​

  • Avoid one giant coplanar floor under the whole map.
  • Prefer logical floor regions that match rooms, corridors, and thresholds.
  • Let the PS1 build bake or chunk static floor surfaces rather than sending raw giant primitives.

Walls​

  • Prefer modular wall segments.
  • Avoid hidden internal faces where adjacent cubes meet.
  • Use wall thickness and chunk boundaries that line up with floor boundaries when possible.

Props​

  • If a prop needs a rounded silhouette, use a low-poly authored mesh.
  • Avoid relying on a dense built-in capsule as a final PS1 hero object.

Near-Camera Geometry​

  • The runtime clips unsafe polygons, including side-grazing geometry, instead of trusting saturated GTE coordinates.
  • Smaller well-authored surfaces still produce more stable ordering and more useful fog/lighting interpolation than giant polygons.
  • Do not use the clipping fallback as a substitute for reasonable camera collision and near-plane-aware level dimensions.

Intersections and Transparency​

  • Two physically intersecting objects can still have an ambiguous draw order; the ordering table sorts primitives but does not resolve per-pixel depth.
  • Avoid coplanar duplicate surfaces and decorative meshes buried almost entirely inside another object.
  • Keep semi-transparent surfaces separate from opaque walls and floors. Test them from every intended camera side.
  • Prefer one coherent mesh when a small inset detail must always appear as part of a larger surface.

What Is Not Guaranteed​

The protection above prevents known numeric, clipping, seam, and coarse depth failures. It does not guarantee desktop-renderer behavior for every scene.

  • Ordering tables cannot perfectly sort mutually intersecting polygons.
  • Affine texture mapping still warps across large polygons.
  • Semi-transparency remains order-dependent.
  • Excessive subdivision can overflow triangle and packet budgets.
  • Invalid Room/Portal data intentionally fails open for visibility; it does not become exact occlusion.

Validate the current scene, inspect the post-bake report, and test the packaged CUE while moving the camera through the closest intended viewing distances. For visibility-specific rules, see Visibility and Culling.

UI Guidance​

For shipping UI:

  • author it in the scene,
  • keep it under the runtime limit,
  • prefer Text, Button, Image, and Panel,
  • reserve UI.DrawText() for temporary debug overlays.

The bundled showcase follows this rule:

  • menu,
  • hub,
  • in-level prompt/progress text,
  • memory-card feedback.

What the Showcase Demonstrates​

The first-person showcase is intended to validate:

  • modular PS1-safe rendering,
  • collisions and trigger logic,
  • audio feedback,
  • lighting state changes,
  • animation state transitions,
  • memory card save/load,
  • authored UI flows from menu to gameplay.

If a showcase level does not survive PS1 export, the fix should usually happen in one of these two places:

  1. authoring and bake strategy, or
  2. runtime clipping/culling policy.

The first choice is usually the safer one. Runtime fallbacks protect valid content at hardware edge cases; they should not carry an unnecessarily ambiguous level design.