Hi Cesium team,
I have implemented a standalone JavaScript loader that allows CesiumJS 1.145 to load raw 3D Gaussian Splatting PLY files directly, without converting them to glTF, SPZ, or 3D Tiles.
It parses common 3DGS attributes and renders them using CesiumJS’s existing GaussianSplatPrimitive. It also supports loading progress, ENU positioning, quaternion rotation, and scaling of both splat positions and ellipsoid sizes.
The current prototype uses an in-memory tileset-like adapter and several private fields of GaussianSplatPrimitive, so I understand that it would need to be refactored before being suitable for CesiumJS.
I already have working code and a demo. Would direct raw PLY loading be in scope for CesiumJS? If so, would you recommend implementing it as a new loader or adding a public API that creates GaussianSplatPrimitive from attribute arrays?
I would be happy to prepare a PR based on your preferred architecture.
Thank you!
Cesium 团队你们好。
我实现了一个独立的 JavaScript 加载器，使 CesiumJS 1.145 可以直接加载原始 3D Gaussian Splatting PLY 文件，而不需要先转换为 glTF、SPZ 或 3D Tiles。
它会解析常见的 3DGS 属性，并使用 CesiumJS 现有的 GaussianSplatPrimitive 进行渲染。同时支持加载进度、ENU 定位、四元数旋转，以及对 splat 坐标和椭球大小的缩放。
当前原型使用了一个内存中的 tileset-like 适配器，并访问了 GaussianSplatPrimitive 的部分私有字段。因此我理解，在合入 CesiumJS 之前还需要进行架构调整。
目前代码和 Demo 已经可以运行。请问直接加载原始 PLY 是否属于 CesiumJS 的功能范围？如果属于，你们更建议实现一个新的 Loader，还是为 GaussianSplatPrimitive 增加从属性数组创建对象的公共 API？
我愿意根据你们建议的架构整理并提交 PR。
谢谢！
Thanks for offering this. But it’s unlikely that a PR that “just adds PLY support” would be reviewed and merged right now.
The current implementation of splat support in CesiumJS is pretty much focussed on the KHR_gaussian_splatting_compression_spz_2 extension. I could explain extensively why it is so focussed, but a very rough summary is: This format was originally supposed to be the (one and only) representation of splats in glTF. And CesiumJS was kind of a “reference implementation” of that. Fortunately, the splat support in glTF was generalized to have KHR_gaussian_splatting as the base extension, with the option to have different ...compression... extensions. (There are many ways of compressing splats, and it’s by no means clear what the “best” one is. This is, in fact, a pretty active research topic…). The implementation in CesiumJS was not yet “generalized” to support other compressions, or the KHR_gaussian_splatting extension on its own.
This leads to the case of PLY files (even though it may not be obvious) :
PLY files for splats are usually huge. They can easily be 10 times as large as compressed glTF/GLB files. So a ‘direct’ support for splats using PLY in CesiumJS would hardly make sense for any “real-world” data sets.
(There are additional issues with PLY. The format is well specified, but how it is currently used for splats is completely unspecified. There are some “de-facto” standards for what a “Splat PLY” contains, but some loaders/writers deviate from that fairly arbitrarily, and even in the best case, the coordinate system that the splat data is stored in varies between all the loaders/writers).
A more sensible path forward for CesiumJS would be to first generalize it to have support for KHR_gaussian_splatting (without compression). If this was already supported, then it could easily be “fed” with PLY data, even at runtime (leaving aside some performance/memory drawbacks for now).
It is clear that this has to be done, eventually, but there is no timeline for it. And when this is supposed to be addressed, there should first be a clear idea about how it will actually be implemented. Roughly: There should be an issue to bring this up, considerations about how the current implementation could be modified, and only when this has converged to a clear goal, a PR for addressing it should be opened.
Hi Marco,
Thanks for the thorough explanation — that clears things up completely, and I agree that a PLY-specific PR wouldn’t be the right move given the current architecture.
I’ll step back from the PR for now and follow the project’s direction on generalizing to KHR_gaussian_splatting first. If there’s ever an issue or design discussion where outside help would be useful, I’d be happy to contribute.
Thanks again for taking the time to explain the reasoning.