The branch of CesiumJS is still experimental. There are a few things that may still change. And there are a few things that are not yet fully working as expected.
One of these things seems to be: Dynamic adjustments of the coordinate transforms.
When I did a few experiments with a basic splats tileset, I also stumbled over some of these issues. Now, I tried it out based on the current state, and noticed that it does take into account the tileset.modelMatrix
, but only under certain conditions. One of the conditions seems to be (roughly) that the modelMatrix
has to be set before the splat content is loaded.
At least, I created the following test, which just loads a tileset, assigns its modelMatrix
. And this does seem to take into account the rotationMatrix
:
const viewer = new Cesium.Viewer("cesiumContainer");
// Create the tileset in the viewer
const tileset = viewer.scene.primitives.add(
await Cesium.Cesium3DTileset.fromUrl(
"http://localhost:8003/tileset.json", {
debugShowBoundingVolume: true,
})
);
// Prepare the model matrix
const modelMatrix = Cesium.Matrix4.clone(Cesium.Matrix4.IDENTITY);
// Transform the tileset to some position on the globe
const transform = Cesium.Transforms.eastNorthUpToFixedFrame(
Cesium.Cartesian3.fromDegrees(-75.152408, 39.946975, 20)
);
Cesium.Matrix4.multiply(modelMatrix, transform, modelMatrix);
// Apply some rotation
const rotationMatrixX = Cesium.Matrix3.fromRotationX(
Cesium.Math.toRadians(90), new Cesium.Matrix4());
const rotationMatrix = Cesium.Matrix4.fromRotation(
rotationMatrixX, new Cesium.Matrix4());
Cesium.Matrix4.multiply(modelMatrix, rotationMatrix, modelMatrix);
// Set the final model matrix
tileset.modelMatrix = modelMatrix;
// Zoom to the tileset, with a small offset so that
// it is fully visible
const offset = new Cesium.HeadingPitchRange(
Cesium.Math.toRadians(-22.5),
Cesium.Math.toRadians(-22.5),
20.0
);
viewer.zoomTo(tileset, offset);
In contrast to that, here is a sandcastle with basic editing components for the model matrix, and one can see that this does not work: It does not seem to take into account changes of the matrix, and if it does (e.g. by modifying the camera/view), then the changes don’t seem to be taken into account correctly.
Sandcastle URL for localhost
on SPZ branch
A bit more generally:
There are several other “moving targets” right now, because Gaussian Splats are currently a tremendously active research topic.Specifically: The fundamental question of “How are Gaussian Splats oriented (in terms of axis conventions)?” seems to largely be unanswered right now. There is a related question in an issue about splat file formats that suggests that many tools are using different axis conventions.
For Gaussian Splats in glTF with SPZ the situation should be more clear:
glTF uses the y-up-convention. Whatever the source format of the splats is: In glTF, it has to be y-up. And the KHR_spz_gaussian_splats_compression
extension proposal contains a conformance section that says:
When compressing or decompressing the SPZ data to be stored within the glTF, you must specify a Left-Up-Front (LUF
) coordinate system in the SPZ PackOptions
or UnpackOptions
within the SPZ library. This ensures that the data is compressed and decompressed appropriately for glTF.
This refers to the Coordinate System convention of SPZ. But there might still be data out there that was generated with different conventions.