We had some struggle with the camera navigation when deactivating the globe. For the most part we are able to implement our own camera movements, when the default Cesium way does not fit our needs. But this seems to be a bug that we can't just work around. I don't believe that this never happened to anyone else but I couldn't find a post or issue about it.
When deactivating the globe the camera zoom won't work correctly if you rotate the camera to a point "inside the globe" (where the globe would have been if not deactivated). Instead of zooming in and out you are only able to zoom out and the movement is much faster than usual. This applies to the mouse wheel and to the right click + drag method.
I only tried it in Chrome on Linux (Ubuntu 18.04) with the newest (and some older) Cesium Versions.
Here's a modified version of the simple point cloud example (so you have the point cloud as reference for zooming/rotating):
Just rotate around the point cloud (middle mouse button) so you look at it from the bottom. Then try to zoom in.
The only change is, that I set globe to false when creating the viewer:
var viewer = new Cesium.Viewer('cesiumContainer', {
globe: false
});
I also have overwritten the default zoom with some basic version in my code. Tried the following (triggered on mouse wheel event) and got the same behaviour:
let moveScratch = new Cesium.Cartesian3(); Cesium.Cartesian3.multiplyByScalar(window.viewer.camera.direction, 10, moveScratch);
Cesium.Cartesian3.add(window.viewer.camera.position, moveScratch, window.viewer.camera.position);
Even when I just add a fixed vector to the camera position the same bug appears (but it's harder to see then):
let moveScratch = new Cesium.Cartesian3(0.0, 0.0, 10.0); Cesium.Cartesian3.add(window.viewer.camera.position, moveScratch, window.viewer.camera.position);
Woops.. I just saw that we turn on the standard zoom again in our code which interfered with my experiments.
Actually the bug *does not* appear with the code snippets i posted before. Only with the default camera movement methods of Cesium/the default zoom. But I get a very noticeable lag with using the code snippets when zooming from the bottom ("inside globe") vs when zooming from the top.
The problem I described in the first post is very likely related to the method _adjustOrthographicFrustum() in cesium/Camera.js as it is the only difference to my own code.
I did open a GitHub bug report for similar difficulties I had with the camera when the globe was turned off:
The recommendation there was to implement custom camera controls, but it sounds like you have, and the problem now is a lag when zooming in from below vs above? If you can share a Sandcastle example in that (perhaps in the same GitHub issue above or in a new one) it might turn out to be something the engine can handle better. I would definitely love to see more intuitive ways of working with the camera when the globe is off or underground.
Underground in general is a highly requested feature over the years that just hasn’t gotten priority yet:
yes you're right. That's what I experienced. I didn't had the time to implement a Sandcastle Example. Now that I did, I can't reproduce the lagging. So it might be just something else in my own code. Nonetheless I'll share the example to show, what I did. Here I just use Cesiums camera move methods and it works fine.
I actually saw your Issue a while ago and started to implement my own camera because of the answer
Didn't find the other issue by myself, so thanks for that. Seems like many people have slightly different problems all related to the same cause ^^
It feels like this shouldn't be a really tough problem to solve (well, you never know). If I find some time to work on this I will give it a try. Would love to see some progress in this direction. But I can't give a promise here.
That’d definitely be awesome! Even if you never get around to finishing the contribution, opening a pull request could help a lot in getting this moving.
