Screen Space Camera Controller glitches in version 1.114

[javagl]

There are some cases where new behavior of the screen space camera controller that was implemented in 1.114 causes problems with the navigiation.

I noticed this with one particular data set. It's not clear whether this data set can be shared. I'll share a link internally, and try to update this issue when I find a case where it happens for other data sets. (Note: It might also be that something is (vaguely:) "wrong" with the data itself. But I couldn't imagine what this could be, and in any case, it worked as expected with 1.113).

When serving this data set on localhost and loading it in a Sancastle (shown below), then it will look at a certain set of buildings, and it should be possible to zoom to the buildings by right-dragging the mouse down or using the mouse wheel.

With 1.113, this works as expected
With 1.114, it seems to prevent the zooming and afterwards behave erratically when trying to rotate and zoom...

Disabling the collision checks with disableCollision: true resolves this.

---

const viewer = new Cesium.Viewer("cesiumContainer");

const tileset = viewer.scene.primitives.add(
  await Cesium.Cesium3DTileset.fromUrl(
    "http://localhost:8003/tileset.json", {
    debugShowBoundingVolume: true,
  })
);

viewer.scene.camera.setView({
  destination: new Cesium.Cartesian3(1333182.0955672108, -4658338.042458538, 4137747.1821384085),
  orientation: new Cesium.HeadingPitchRoll(0.5789641954988802, -0.7513114431912946, 6.283165796771483),
});

[javagl]

I'm currently playing with ~"automatic generation of artificial tilesets" (some spare-time stuff that derailed a bit), and I noticed a case where some of the glitches can be reproduced in a relatively isolated and reproducible (!) fashion. This test case is here:

Cesium 114 interaction tiles-test-2024-02-11.zip

The archive contains a tileset that is essentially a 4-level quadree of a 100mx100m plane, and a sandcastle for showing it. The interaction is:

• Zooming in by right-dragging the mouse down
• Rotating by middle-dragging the mouse up

I'd expect the new functionality to prevent the camera from going under the plane, but it doesn't ... in most cases:

When rotating the view by moving the mouse horizontally while the middle mouse button is pressed, then the camera sometimes "jumps" on the plane (and can then sometimes not easily be brought below the plane again).

I haven't read the exact implementation of the changes and this getHeight function that this seems to be based on. From this example, it looks and feels like it simply could not compute a proper (limiting) height because the required tiles are not in the view frustum, but I cannot imagine this to be the actual reason.

Maybe such a small, artificial case helps for debugging...

[ggetz]

Also reported in #11822.

[ggetz]

Thanks for the test case @javagl! This should be a help in tracking down the issue for sure.