What to inspect before opening a Gaussian splat

A practical preflight checklist for identifying format, schema, resource risk, and safe next steps before a full decode.

Direct answer. Inspect the header and property layout before allocating large CPU or GPU buffers. A safe preflight identifies the real schema, estimates decoded resource needs, and preserves the source when the file cannot open safely.

Diagram of a safe Gaussian splat opening sequence: identify the header, validate the schema, then plan the decoded resource budget
Safe opening sequence A preflight is useful before rendering begins: identify, validate, then estimate. This is a technical workflow diagram, not a captured app screen.

How Boreal Splat helps

Boreal Splat keeps inspection available when rendering cannot continue

The product is designed to separate lightweight file inspection from full scene allocation. When a file is unsupported or exceeds a safe display plan, the useful diagnostic result should remain visible and the source file should remain untouched.

Captured from Boreal Splat running on an iPhone simulator. Sample files are used only to demonstrate the current interface.

Boreal Splat File Preflight showing detected content, Gaussian count, memory estimates, and a recommended action
File PreflightA current app screen showing the evidence available before full rendering.

A Gaussian splat file can be perfectly valid and still be a poor fit for the device in your hand. The safe opening path starts before rendering.

Identify content, not just the extension

The filename is a hint. The file header and property layout are the evidence. A .ply file may contain a Gaussian splat schema, an ordinary point cloud, or a layout produced by a tool your viewer does not understand.

A useful preflight should report the detected format and version, element counts, required properties, spherical-harmonic data, and any mismatch between the extension and the content.

Estimate before allocating

Compressed size is not a memory budget. Decode buffers, sort data, GPU resources, and temporary copies can make peak use substantially larger than the file on disk.

Before creating buffers proportional to every Gaussian, estimate the likely CPU and GPU footprint. If that estimate is outside the device budget, choose a display-only quality reduction or stop with a clear explanation. A failed render should still leave useful inspection results visible whenever the header could be read safely.

Preserve a deterministic result

For a difficult file, three outcomes are reasonable:

  1. Open it at the intended quality.
  2. Open a clearly identified, lower-resource display representation without modifying the source.
  3. Stop before an unsafe allocation and explain what the user can try next.

A crash, indefinite spinner, or silent source-file change is not a fourth outcome.

Keep the source untouched

Inspection should be read-only. If a later conversion is needed, write to a new temporary output, validate it, and complete the save atomically. The original file is the recovery path and should never be silently overwritten.

Primary format references

Continue the file check

Compare the container families before the handoff.

Learn why PLY, SPZ, and .splat filenames are only the beginning of a compatibility decision.

Compare the formats