Draft extension for SPZ compression support for Gaussian splats

[keyboardspecialist]

Follows EXT_draco_mesh_compression as pattern.

[lilleyse]

Looks pretty good. Just a few comments from me.

[weegeekps]

I did something I shouldn't have and managed to completely pollute the history for this branch. I will try to clean it up later.

@lilleyse - when you have a moment another review pass is appreciated.

[weegeekps]

This is required by the glTF spec for all POSITION accessors.

In reality, we should probably calculate the actual bounds, but right now this is good enough since we don't need them for implementation.

A good ask for the working group is if we can relax this requirement when our extension is in use.

[weegeekps]

A good ask for the working group is if we can relax this requirement when our extension is in use.

I changed my mind about this. I think there's still potential for these bounds to be very useful in some engines. We should still require these bounds to be properly calculated.

[lilleyse]

I was able to fix the history by

• merging main into 3d-tiles-next
• merging 3d-tiles-next into this branch
• changing the target branch to 3d-tiles-next
• Adding back the 3d-tiles-next files that were removed

Though none of this will matter once a PR is opened in the Khronos repo (at least I don't see the need to keep the commit history)

[lilleyse]

Just a few small comments from me. I like how simple the extension schema is now.

[weegeekps]

I'm going to close this PR and create a new branch cherry picked from this one. While Sean fixed the issue for our review purposes, my mishap still creates quite a mess for a PR into the official glTF repo.

[weegeekps]

Reopened in the Khronos Group glTF repo: KhronosGroup#2490

[GISUser1]

GISBox now fully supports the KHR_spz_gaussian_splats_compression slicing function. This feature, through an innovative slicing compression algorithm, significantly improves the transmission efficiency and rendering performance of Gaussian splatting point cloud data.