Norbert Nopper

@weegeekps Will add the feedback from my 3D Formats presentation here as well.

`COLOR_0` could be considered to keep its original semantic. One option would be, that the splat is colorized afterwards, especially using the alpha channel to e.g. fade in and fade...

In regards of `DEGREE_x_COEF_y`, suggest to create a separate extension for spherical harmonics (SH). As SH are quite often used in computer graphics, having a separate extension avoids a potential...

Also suggest to have a separate extension for the transformations for later reusage: `TRANSLATION` `ROTATION` `SCALE` Also, please note of the existing and mentioned https://github.com/KhronosGroup/glTF/tree/main/extensions/2.0/Vendor/EXT_mesh_gpu_instancing extension during 3D Formats call....

The `KHR_gaussian_splatting` extension would then mainly depend on the previously described glTF extensions.

@lexaknyazev We are in interest of having an EXT_accessor_float16 (or a KHR_) extension. We are also aware of this proposal for other data types: https://github.com/KhronosGroup/glTF/pull/2395 As @spnda worked on both...

> I agree with earlier concerns that several implementations may want to pick this up for the sake of 64-bit animation keyframes, but not be willing to take 64-bit vertex...

One more detail: Both extensions are still in "Draft" @emackey maybe we review this first?

Who is expected to create these assets?

> There are some tests shown in and linked from [#2397 (comment)](https://github.com/KhronosGroup/glTF/pull/2397#issuecomment-2118802415) above. But based on the points mentioned above, it could make sense to create models that _explicitly_ use...