PLY is a generic file format that, surprisingly, has nothing to do with Gaussian Splatting in its original design. PLY format is also known as Polygon File Format, hence the .ply extension, or Stanford Triangle Format. It was designed in the mid-90s at Stanford University.

PLY files store 3D shapes as collections of vertices and faces, with optional support for edges, cells, materials, and custom properties.

The power of the format comes from its extensibility, as it supports storing arbitrary properties.

File structure

Each file consists of two sections: header and data. The header defines all elements, such as vertices and faces, and their respective properties. The header also defines how many elements are stored in the PLY file, how data is laid out in the data section, and optionally includes additional comments.

The data section contains a raw sequence of numbers that, when interpreted using the header's blueprint, reconstruct your 3D model.

Gaussian Splatting data

A Gaussian Splatting model is a sequence of 3D Gaussians. Each Gaussian can be described by position, rotation, scale, colour, opacity, and spherical harmonics.

Position stores x, y, and z coordinates. Rotation stores the x, y, z, and w values of a quaternion. Scale stores x, y, and z values along each axis. Colour stores red, green, and blue values. Opacity stores the alpha value, where 0 is invisible and 1 is opaque. Spherical harmonics usually store 9-45 parameters describing view-dependent effects.

A typical Gaussian Splatting header looks like this:

After the header, the file contains raw numerical data for each splat, strictly following the order defined above.

Precision and file size

Each property is defined via the property <type> <name> line. Type is the format of the number. float is the most common and means a 32-bit, or 4 byte, floating point number.

Assuming 45 SH parameters, which is 3 degrees of spherical harmonics functions, each splat is described by 59 parameters, each 4 bytes long. This might not sound like much, but the numbers explode at scale. A model with 1M splats would use 1,000,000 * 59 * 4 = 236,000,000B = 236MB.

236MB is usually too much to send over the network, especially on 4G. Larger files also often take longer to parse and decode.

To put this in perspective: a coffee mug scan might have 200k-800k splats, while an entire room easily hits 2-3M splats or even more.

These calculations assume binary format. ASCII format, while human-readable, typically increases file sizes by 2-3x due to text representation of numbers.

Compression and quantisation

The obvious solution to bloated file sizes is to trade some precision for size reductions. This gives us a simple lever we can pull to find the right trade off between quality and compression level.

While PLY itself doesn't support custom bit depths, there's a clever workaround: pack multiple low-precision values into a single standard float.

For example, RGBA colors don't need 32-bit precision per channel. We can pack all four values into a single 32-bit float using just 8 bits each, and concatenate all bits together into one 32-bit number. Using this approach we can effectively encode 4 data points using just one PLY parameter, achieving a 4x compression.

Similar compression methods have been implemented by Playcanvas and GaussianSplats3D.

An alternative compression approach is described in the Compact 3D Scene Representation via Self-Organizing Gaussian Grids paper. We'll dive into this in another article as Blurry's compression strategy builds upon this.