!
This article was composed and written based on a conversation with AI (Claude). While care has been taken regarding the accuracy of the content, it may contain errors or inaccuracies. If you notice any issues, I would appreciate your feedback in the comments.
Situations where 3D point cloud data is used are increasing. Applications continue to expand, including digital archives of cultural properties, 3D scanning of cities, and LiDAR measurement for autonomous driving. However, with many related terms such as PLY, LAS, Gaussian Splatting, and Potree, it can be difficult to grasp their positioning and relationships.
This article attempts to organize how these technologies and formats are connected.
What is a Point Cloud?
A point cloud is a data format that represents the shape of objects and spaces through a collection of points in 3D space. Each point has at minimum position information (x, y, z), and can additionally carry attributes such as color (r, g, b), normal vectors, and reflection intensity.
The main methods for acquiring point clouds include:
- LiDAR (Light Detection and Ranging): Emits laser light and measures distance from the round-trip time of the reflected light. Widely used in aerial surveying, autonomous driving, and terrain surveys, a single scan can yield data of hundreds of millions to billions of points.
- SfM (Structure from Motion): A technique that reconstructs 3D structures from multiple photographs. It generates dense point clouds by combining camera position estimation and triangulation. It can be performed with relatively inexpensive equipment and is increasingly used for digital recording of cultural properties.
- 3D Scanners: Directly measure the surface geometry of objects using structured light or laser. Used for building condition surveys and quality control in manufacturing.
The density, accuracy, and associated attributes of point clouds differ depending on the acquisition method, which also affects the subsequent file format selection.
PLY (Polygon File Format)
A Versatile Container for 3D Data
PLY is a format developed at Stanford University for storing 3D scan data. Its official name is “Polygon File Format,” and it was originally intended primarily for storing polygon (mesh) data.
The key feature of PLY is its versatility. It has a simple structure where attribute definitions are described in the header section and per-vertex values are stored in the data section, supporting both ASCII and binary formats. Importantly, PLY is not a point cloud-specific format. Even with the same .ply extension, completely different types of data can be stored.
Three Types of Data PLY Can Store
PLY files can represent three main types of data depending on the header content.
1. Mesh
Contains face information in addition to vertices. Faces are typically described as lists of triangle vertex indices. Used for 3D scanner output and CG model storage.
ply
format ascii 1.0
element vertex 678866
property float x
property float y
property float z
element face 1357728 <- face present -> Mesh
property list uchar int vertex_indices
end_header
Such a file is mesh data composed of over 1.35 million triangles, rendered as smooth surfaces when opened in a viewer.
2. Point Cloud
Contains only vertex coordinates and attributes like color, without face information. Widely used as output from LiDAR and SfM.
ply
format ascii 1.0
element vertex 100000
property float x
property float y
property float z
property uchar red
property uchar green
property uchar blue
end_header <- no face definition -> Point Cloud
3. Gaussian Splatting Data
The training results of Gaussian Splatting (described later) are also stored as extended attributes in PLY. Details are explained in the “Gaussian Splatting” section.
How to Identify PLY Types
Since the same .ply file can contain different data, you can identify the type by checking the header.
element facepresent -> Meshscale_0,rot_0,opacity,f_dc_0, etc. present -> Gaussian Splatting- Neither of the above, only
element vertex-> Point Cloud
# Simple code to classify PLY file type
def classify_ply(header_lines):
hdr = "\n".join(header_lines)
if "element face" in hdr:
return "Mesh PLY"
if any(k in hdr for k in ("scale_0", "rot_0", "opacity", "f_dc_0", "f_rest_0")):
return "Gaussian Splat PLY"
return "Point Cloud PLY"
Other Major Point Cloud File Formats
In addition to PLY, there are point cloud file formats suited to specific applications and fields.
LAS / LAZ
LAS is a standard format for LiDAR point cloud data established by the American Society for Photogrammetry and Remote Sensing (ASPRS). It natively supports LiDAR-specific attributes such as GPS timestamps, reflection intensity, return numbers (distinguishing multiple reflections from a single laser pulse), and point classification codes (ground, building, vegetation, water surface, etc.).
LAZ is a lossless compressed version of LAS developed by Martin Isenburg. Since file sizes are reduced to approximately 7-20% of the original, it has become the de facto standard for storing and distributing LiDAR data that can reach tens of gigabytes. All major tools including LAStools, PDAL, and CloudCompare support it.
In the surveying and GIS fields, LAS/LAZ is overwhelmingly more mainstream than PLY, and is adopted in projects such as Japan’s Ministry of Land, Infrastructure, Transport and Tourism PLATEAU project.
E57
E57 is a format established as an ASTM international standard for exchanging 3D scan data. In addition to point cloud data, it can bundle 2D images, scanner metadata (model, position, orientation, etc.), and session information from multiple scans into a single file.
Designed as a bridge for exchanging data between scanners from different manufacturers, it is particularly valued in BIM (Building Information Modeling) workflows in the construction and architecture fields.
Other Formats
| Format | Overview | Main Use |
|---|---|---|
| XYZ | The simplest text-based format with one point’s coordinates per line | Lightweight data exchange |
| PTS | Text format used by Leica 3D scanners | Exporting from Leica scanners |
| PCD | Point Cloud Library (PCL) proprietary format with headers, supporting binary and ASCII | Point cloud processing pipelines using PCL |
| OBJ | A mesh format, but sometimes used as a point cloud with vertices only | Data exchange between 3D modeling software |
Gaussian Splatting (3D Gaussian Splatting)
Overview
3D Gaussian Splatting (3DGS) is a real-time Novel View Synthesis method published by Kerbl et al. (SIGGRAPH 2023). It represents scenes as collections of hundreds of thousands to millions of 3D Gaussian distributions (ellipsoids).
Unlike NeRF (Neural Radiance Fields), which uses implicit representation through neural networks, 3DGS is an explicit representation where each Gaussian has explicit parameters, with significantly improved rendering speed as its key feature.
A Third Representation: Neither Mesh Nor Point Cloud
Gaussian Splatting data differs from both meshes and point clouds.
- Mesh: Defines surfaces with vertices + faces (polygons)
- Point Cloud: A collection of points with only position (+ color, etc.)
- Gaussian Splatting: A collection of Gaussian ellipsoids with position, shape, color, and opacity
As a PLY file, it does not have element face, so structurally it is similar to a point cloud. However, each vertex is not simply “a point with position and color” but represents a 3D Gaussian ellipsoid with dozens of parameters including scale, rotation, opacity, and spherical harmonics coefficients. When opened in a standard point cloud viewer, only the center positions of the Gaussians are displayed as points, and the shapes and view-dependent colors are not reproduced. A dedicated viewer is required for correct rendering.
Parameters of Each Gaussian
A single 3D Gaussian has the following parameters:
- Position (x, y, z): Center coordinates of the Gaussian (3 dimensions)
- Covariance: Represents the shape and orientation of the Gaussian. In practice, decomposed into scale (3 dimensions) and rotation (quaternion) (4 dimensions)
- Color: Expressed as coefficients of Spherical Harmonics (SH). To reproduce view-dependent color changes, typically carries 0th to 3rd order coefficients, with 16 coefficients per RGB channel, totaling 48 dimensions
- Opacity: A scalar value (1 dimension) controlling the transparency of the Gaussian
This means dozens of parameters are needed per Gaussian.
Training Pipeline
The processing flow of 3DGS is as follows:
Input images
| SfM (COLMAP, etc.)
Initial point cloud (PLY) + camera parameters
| 3DGS optimization (differentiable rasterizer)
| - Update each Gaussian's parameters via gradient descent
| - Adaptive Density Control (split, remove, clone)
Trained Gaussians (PLY)
| Real-time rendering
Novel view images
The initial point cloud directly uses SfM output. That is, each point’s position and color serve as initial values. Through optimization, each point evolves into a Gaussian ellipsoid with “size, shape, opacity, and view-dependent color.”
Storage Format: PLY and Beyond
In the original 3DGS paper (INRIA implementation), PLY was adopted as the storage format for training results. Leveraging PLY’s flexible attribute definitions, each Gaussian’s parameters are stored as custom properties.
Input PLY (initial point cloud) header example:
ply
format binary_little_endian 1.0
element vertex 100000
property float x
property float y
property float z
property uchar red
property uchar green
property uchar blue
end_header
Output PLY (trained Gaussians) header example:
ply
format binary_little_endian 1.0
element vertex 500000
property float x
property float y
property float z
property float f_dc_0
property float f_dc_1
property float f_dc_2
property float f_rest_0
property float f_rest_1
...
property float f_rest_44
property float opacity
property float scale_0
property float scale_1
property float scale_2
property float rot_0
property float rot_1
property float rot_2
property float rot_3
end_header
File sizes increase significantly compared to the initial point cloud. PLY consumes 236 bytes per point, so scenes with millions of Gaussians can reach hundreds of megabytes to over 1 GB.
Lightweight Formats for Web Distribution
While PLY is suitable for archiving and editing, uncompressed PLY is not ideal for web distribution. Several lightweight formats specifically for Gaussian Splatting have emerged.
SPZ (Splat Zip) is a format open-sourced by Niantic (Scaniverse). By combining quantization, scaling, and column-oriented data layout, it compresses PLY’s 236 bytes/point to 64 bytes/point. Designed with the concept of “doing for splats what JPG did for photos,” it is released under the MIT license.
SPLAT is a simple binary format used by antimatter15’s WebGL viewer. It omits higher-order spherical harmonics coefficients and arranges only the basic parameters of each Gaussian in fixed length, featuring lightweight size and implementation simplicity.
KSplat is a compressed format created for the Three.js-based GaussianSplats3D viewer. It supports conversion from PLY and SPLAT and offers multiple compression levels.
SOG is a compressed format adopted by PlayCanvas’s SuperSplat editor, using texture-based compression technology.
Compressed PLY maintains the PLY structure while compressing the data, and can be generated by tools such as PlayCanvas’s splat-transform tool.
The relationship between these formats can be organized as follows:
PLY (master data / archiving)
|---> SPZ (general-purpose lightweight format, Niantic)
|---> SPLAT (simple binary, antimatter15)
|---> KSplat (compressed format for Three.js)
|---> SOG (for PlayCanvas/SuperSplat)
+---> Compressed PLY (PLY-compatible compressed version)
The current best practice is to retain the original PLY for archiving and editing, and use compressed formats such as SPZ, KSplat, or SOG for web distribution. Tools like 3dgsconverter can be used to convert between these formats.
Potree: Web Visualization of Large-Scale Point Clouds
The Role of Potree
Point cloud data stored in PLY or LAS/LAZ can reach tens of millions to billions of points. Potree was developed to interactively display such large-scale data in web browsers.
Potree is an open-source project primarily developed by Markus Schutz at TU Wien (Vienna University of Technology), consisting of a WebGL-based point cloud viewer and data conversion tools for preprocessing.
Spatial Indexing and LOD
At the core of Potree is spatial partitioning using an Octree and a LOD (Level of Detail) mechanism.
The original point cloud data is divided into an octree, and the points contained in each node are subsampled to create a hierarchical structure. The root node contains a coarsely sampled point cloud of the entire scene, while the leaf nodes at the deepest level contain the densest point clouds.
On the viewer side, only the necessary nodes are dynamically loaded based on the camera’s position and orientation. Regions close to the camera display deep hierarchy (high resolution) nodes, while distant regions use shallow hierarchy (low resolution). This allows smooth rendering even for datasets of billions of points by controlling the number of points sent to the GPU at any time.
Conversion with PotreeConverter
To convert source data to Potree format, use PotreeConverter.
# For PotreeConverter 2.x
PotreeConverter input.ply -o ./output_potree
# Same for LAZ format
PotreeConverter input.laz -o ./output_potree
The directory structure after conversion looks like this:
output_potree/
├── metadata.json # Bounding box, point count, attribute information, etc.
├── hierarchy.bin # Octree hierarchical structure
└── octree.bin # Point cloud data body (stored hierarchically)
In PotreeConverter 2.x, these are consolidated into a small number of files (older versions generated individual files per node).
Supported input formats cover major point cloud formats including LAS, LAZ, PLY, E57, XYZ, and PTS, enabling unified web publication of point clouds from different sources.
Viewer Implementation
The Potree Viewer is a WebGL application based on Three.js, providing features such as point cloud display, distance measurement, cross-section display, annotations, and coordinate system switching. Since it operates with just one HTML file and a JS library, it can be served from a static web server.
Big Picture: An Overview of Data Flow
Let’s organize the content covered so far as a data flow.
[Acquisition]
LiDAR ----> LAS/LAZ
SfM ------> PLY (point cloud)
3D Scanner -> E57 / PLY (mesh or point cloud)
[Processing / Conversion]
PLY (initial point cloud) --> 3D Gaussian Splatting --> PLY (trained Gaussians)
|-> SPZ / SPLAT / KSplat, etc. (for web distribution)
+-> Real-time rendering with dedicated viewers
PLY (point cloud) / LAS / LAZ / E57
|
PotreeConverter
|
Potree data (Octree) --> Large-scale point cloud display in web browsers
[Visualization]
Desktop -> CloudCompare / MeshLab
Web (point clouds) -> Potree / 3D Tiles
Web (GS) -> SuperSplat / GaussianSplats3D and other dedicated viewers
The key point is that PLY functions as a versatile container. It can store three fundamentally different types of data: meshes, point clouds, and Gaussian Splatting data. It is used as output from SfM and 3D scanners at the acquisition stage, as input/output for Gaussian Splatting at the processing stage, and as the starting point for Potree conversion and Gaussian compression for web publication. On the other hand, when dealing with LiDAR data, LAS/LAZ is often the starting point.
Summary
Let’s once more organize the relationship between the technologies covered in this article.
PLY is a simple yet highly extensible general-purpose 3D data format that serves as a hub capable of storing mesh, point cloud, and Gaussian Splatting data. The type of data inside can be determined by checking the file header.
LAS/LAZ is a standard format specialized for LiDAR point clouds and has become the de facto standard in the surveying and GIS fields.
Gaussian Splatting is a technique that starts from point clouds and generates a new representation - “a collection of Gaussian ellipsoids” - that differs from both meshes and point clouds. Training results are stored in PLY, but dedicated lightweight formats such as SPZ, KSplat, and SOG are also available for web distribution.
Potree is a solution for interactively displaying large-scale point cloud data in web browsers using Octree and LOD, accepting multiple formats including PLY and LAS/LAZ as input.
By combining these technologies, a workflow of “acquiring 3D data from the real world, processing it, and publishing it on the web” can be built. Going forward, the coordination of these technologies will become increasingly important in fields such as digital archives of cultural properties, digital twins, and XR content.