Skip to main content

Building PS1-Safe Levels from Editor Geometry

Creator of Polygon Engine

Polygon Engine started with a familiar idea: let the user build a level from visual objects in an editor. The PS1 immediately pushes back on that idea. A scaled cube in an editor is easy. A scaled cube that sorts correctly, clips correctly, collides correctly, and packages correctly for PS1 is a much bigger requirement.

This is why level authoring in Polygon Engine is split into two related paths: scene primitives and reusable Level Builder mesh assets.

Scene Primitives vs Mesh Assets

The editor supports built-in scene primitives such as Plane, Cube, and Capsule. They are useful for fast blockouts and simple level structure.

The Level Builder creates editable mesh assets. Those are saved as project-owned source meshes and compiled into runtime mesh files.

That distinction matters:

Authoring pathSource locationRuntime outputBest use
Built-in scene primitiveScene JSONBaked/staged mesh when compatibleFloors, walls, blockers
Level Builder meshAssets/Meshes/*.pmshLibrary/meshes/*.mshReusable custom pieces
Imported modelAssets/Models/*.obj or .fbxLibrary/meshes/*.mshExternal low-poly art

All of them can end up as runtime mesh data, but they have different editing and validation rules.

The Bake Path

The PS1 build pipeline can process compatible static built-in Plane and Cube geometry. The goal is to avoid shipping huge raw primitives to a renderer that has no z-buffer.

The bake path uses constants that are deliberately conservative:

SettingCurrent valuePurpose
Mesh bake quantization scale4096.0Mesh-local bake representation; distinct from runtime world-position scale
Default cell size1.0Split large surfaces into safer cells
Default chunk size3.0Keep staged chunks manageable
Min cell size0.125Avoid accidental over-subdivision
Max segments32Bound generated geometry
Visibility groupingBuild-derivedGroup baked geometry for conservative runtime candidate selection

The exact grouping and runtime cell size are implementation details and can change independently as the visibility path is tuned. Do not build gameplay logic around a fixed sector dimension. The stable authoring rule is that large primitives should become smaller runtime surfaces when that is safer for the ordering table and visibility workload.

Covered Faces and Conservative Removal

Adjacent boxes often contain faces the player never sees: wall-to-wall contact faces, floor/wall overlaps, or hidden backsides inside modular construction. Removing some covered faces helps performance and reduces ordering conflicts.

Polygon Engine's removal is intentionally conservative. It should never behave like a full constructive-solid-geometry system. It does not solve arbitrary mesh boolean operations, and it does not claim to optimize every imported model.

The useful target is narrower:

  • remove obvious covered faces for compatible static primitive layouts,
  • preserve material assignment,
  • preserve world placement,
  • avoid deleting faces when the decision is ambiguous.

For a PS1 editor, a safe partial optimization is better than a broad optimization that silently breaks levels.

Level Builder Mesh Assets

Level Builder is the in-editor path for authoring reusable mesh pieces. The workflow is:

Create Primitive / Load Mesh Asset
-> edit in Object, Vertex, Edge, or Face mode
-> validate mesh
-> save source .pmsh under Assets/Meshes/
-> export runtime .msh under Library/meshes/
-> register GUID in Library/asset_db.json
-> place mesh in scene

The compiled mesh runtime format uses the PGMSH1 magic. The runtime validates the header, vertex count, index count, index range, and data size before using the mesh.

Topology Editing Is a Product Feature

Moving a face should not accidentally detach it from the model. Pulling an edge should not move only one triangle unless the tool is explicitly separating or extruding geometry.

That sounds obvious, but it is one of the most important pieces of a trustworthy level editor. If a non-engine-programmer user can create broken topology without realizing it, the engine is not production-ready.

Level Builder therefore needs clear tool behavior:

  • selection modes must be explicit,
  • gizmo drags must transform the selected geometry, not the camera,
  • shared vertices and edges should remain shared by default,
  • destructive operations such as Delete, Duplicate, Extrude, Inset, Merge, and Subdivide should be intentional,
  • validation should surface degenerate faces, long edges, and non-manifold risk.

The modeling tool does not need to compete with Blender. It needs to produce reliable PS1 gameplay geometry.

Colliders Are Not Optional

Visual geometry and collision geometry are separate concepts. A mesh can render correctly and still let the player walk through it if the scene has no Collider component.

When a Level Builder mesh is placed into a scene, Polygon Engine creates a GameObject with:

  • Mesh Renderer referencing the saved mesh asset,
  • an AABB Collider based on the mesh bounds.

That collider can be edited in the main Inspector. The build validation also warns when a Level Builder mesh reaches the PS1 runtime path without a Collider, because that object can be walked through.

This is a good example of product-oriented validation. The warning explains the gameplay consequence, not only the data problem.

Authoring Rules That Matter

For PS1-facing levels, good content is usually:

  • modular,
  • low-poly,
  • chunked into rooms, corridors, and thresholds,
  • built from simple opaque materials,
  • explicit about collision,
  • validated before packaging.

Bad content is usually:

  • giant coplanar surfaces,
  • thin overlapping shells,
  • dense rounded primitives used everywhere,
  • transparent surfaces placed across the main view,
  • imported art with no collider or budget review.

Polygon Engine's authoring workflow exists to move users from the second list to the first without asking them to understand every PS1 hardware detail.

Continue Reading

Updated for Polygon Engine 0.1.0-ea.2.