Hi,
I haven’t had much success with tiling 3DGS .ply files.
Is there any documentation about the structure a .ply file needs to follow to be successfully tiled?
Thanks in advance.
I think that there is no “official” documentation for that - at least, not on this low technical level. One problem is that the concept of “splat PLY files” is underspecified. The PLY format itself is specified clearly. But a PLY file can literally contain anything.
However, there is a “de-facto” standard of what constitutes a “splat PLY file”. This happened “by chance”, derived from some research paper that made splats popular. Most of the common splat-generation tools do export splats in PLY files with this format. And this format should have a header like this one:
ply
format binary_little_endian 1.0
element vertex 9
property float x
property float y
property float z
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
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_2
property float f_rest_3
property float f_rest_4
property float f_rest_5
property float f_rest_6
property float f_rest_7
property float f_rest_8
property float f_rest_9
property float f_rest_10
property float f_rest_11
property float f_rest_12
property float f_rest_13
property float f_rest_14
property float f_rest_15
property float f_rest_16
property float f_rest_17
property float f_rest_18
property float f_rest_19
property float f_rest_20
property float f_rest_21
property float f_rest_22
property float f_rest_23
property float f_rest_24
property float f_rest_25
property float f_rest_26
property float f_rest_27
property float f_rest_28
property float f_rest_29
property float f_rest_30
property float f_rest_31
property float f_rest_32
property float f_rest_33
property float f_rest_34
property float f_rest_35
property float f_rest_36
property float f_rest_37
property float f_rest_38
property float f_rest_39
property float f_rest_40
property float f_rest_41
property float f_rest_42
property float f_rest_43
property float f_rest_44
end_header
(The order of the properties does not matter. The f_rest_<n> properties are optional)
If you encounter any issues when tiling such a PLY file, then it could be good to describe the error more specifically, if possible. I know, it won’t tell you more than “Something went wrong”, unfortunately. So maybe when you post the ‘asset ID’ of the asset where the tiling processed failed, someone can have a closer look.
Thanks @Marco13 
that’s really useful.
Do you also know if there will be native support for .spz files within Ion?
Support for SPZ files as the input for the tiling could be fairly easy. But there actually are good reasons to not offer this: SPZ is a (lossy) compressed format. And it has some limitations for its use as a “general format for splats”.
For example, it will quantize the positions of the splats, to 12 bits by default. This means that it cannot represent “large value ranges”. I stumbled over this, with some details summarized in Question about position encoding · Issue #52 · nianticlabs/spz · GitHub . On top of that, the other compression approaches in SPZ (like quantization for spherical harmonics) will cause small errors. And when the input data already has small errors, and is passed through the tiling pipeline, and then written as SPZ, this will “accumulate” additional errors, meaning that this may cause some rendering artifacts or low(er) visual quality in the final output.
In general, the input for any processing pipeline should preferably be an uncompressed (or losslessly compressed) format. (We might think about the option to upload ZIPped PLY files, for example, just to save on transmission size…)
An aside: Cesium ion is currently writing glTF assets with SPZ-compressed splat data by default. And this makes sense: It is in a form that is intended for “last-mile” delivery, and should therefore be in a compact representation. Limitations of SPZ - like the limited value range for the positions - are not so critical when the data is divided into smaller tiles.
However, sooner or later someone will upload a “large” model (i.e. with a large spatial extent), and the position limitations will kick in. I already opened an issue for that. People can call this “pessimism” or “foresight”, but right now, I’m just waiting for that issue to become “active”, so to speak.
1 Like