Zooming scroll wheel too fast zooms through the globe to other side

[hpinkos]

Reported on the forum: https://groups.google.com/forum/?hl=en#!topic/cesium-dev/o5Zt-SpkZK8

For me it happens over 90% of the time that I zoom in on the corridor on the clamp to ground example, however I cannot get it to happen on Windows.

When I zoom into terrain in Chrome on a Windows machine the zoom speed slows as I get closer to the earth. If I do it on my Mac it does not slow as you get closer and ends up shooting straight through the earth.

1. Go to the following link in Chrome on an OS X machine:
   http://cesiumjs.org/Cesium/Apps/Sandcastle/index.html?src=Ground%20Clamping.html&label=Showcases

2. Select 'Draw corridor'

3. Change the camera angle to be looking straight down (90 degrees) at the corridor and zoom as quickly as you can into the corridor using a laptop trackpad, or mouse with smooth scroll (ie logitech mouse with free-spinning mode). I can get the issue to occur occasionally with a standard scroll wheel, but more like 10% of the time.

Almost every time I do this it will go through the earth to the other side, and occasionally another weird bug seems to happen after glitching through the earth where zoom will now scroll the view sideways instead of zoom in and out, even if the camera is nowhere near the earth.

I think this was introduced in 26 or 27

Video example: https://www.youtube.com/watch?v=92_hFjYItLc&feature=youtu.be&hd=1

---

Also reported here: #4680

Reported on the forum: https://groups.google.com/forum/#!topic/cesium-dev/xeRAg8lObUg

If you go to this sandcastle:
http://cesiumjs.org/Cesium/Apps/Sandcastle/index.html?src=Geometry%20and%20Appearances.html&label=Showcases

Make the camera perpendicular to the earth then zoom in quickly as far/fast as you can using the mouse wheel with the mouse over a 3D shape, you'll zoom through the earth about 10-20% of the time.

NOTE: It doesn't seem to happen nearly as often if the camera is on an angle, or if the mouse isn't over a shape.

It only seems to happen for me on Mac OS X and Ubuntu. It does not happen on Windows. I am able to reliably re-create the issue using OS X Sierra and Chrome 55

[hpinkos]

A few other users have responded to that forum post saying they've seen this problem, so I marked this issue as 'priority'

[lilleyse]

I think this may be related to #4680 or #4767?

[denverpierce]

I've definitely seen this on machines other than mac, but it's difficult to reproduce. I've gotten more reports of it on slower machines, which makes me think that sometimes when the frame is delayed there's 'intertia' and the camera tends to clip through terrain or something similar. I'll see if I can reproduce it on a windows machine.

[kring]

I saw this yesterday too, on a very slow machine in a demo room here. It happened so consistently I couldn't zoom in close at all even with a few tries. I thought I was losing my mind.

[jsalankey]

Also seen this happen with reasonable repeatability, maybe 1 in every 10 times zooming close to the earth.

[pjcozzi]

@kring do you have any bandwidth to look at this?

[kring]

Yeah, I'll see if I can get into that demo room tomorrow to debug it.

[duvifn]

@pjcozzi, @kring, the problem seems to be related to this code block.

Here is a sandcastle code that for me produces a similar behavior, often and consistently.
Just zoom in fast...

    var viewer = new Cesium.Viewer('cesiumContainer');
    var cesiumTerrainProviderMeshes = new Cesium.CesiumTerrainProvider({
        url : 'https://assets.agi.com/stk-terrain/world',
        requestWaterMask : true,
        requestVertexNormals : true
    });
    
    viewer.terrainProvider = cesiumTerrainProviderMeshes;
    
    var entity = viewer.entities.add({
        position: Cesium.Cartesian3.fromDegrees(0.0,0.0),
        point: {
            pixelSize: 10
        }
    });
    var Cartesian3 = Cesium.Cartesian3;
    var cameraPostion = new Cartesian3(4434431.293296404, 564852.1359136868, 4572103.03136818);
    
    viewer.camera.position = cameraPostion;
    viewer.camera.setView({
        orientation: {
            heading: 0.0,
            roll: 0.0
        }
    });
    var scene = viewer.scene;
    
    var handler = new Cesium.ScreenSpaceEventHandler(scene.canvas);
    handler.setInputAction(function(movement) {
        var ray = viewer.camera.getPickRay(movement.endPosition);
        var cartesian = Cartesian3.add(viewer.camera.positionWC,Cartesian3.multiplyByScalar(ray.direction,300,new Cartesian3()),new Cartesian3());
        entity.position = cartesian;
    }, Cesium.ScreenSpaceEventType.MOUSE_MOVE);

I debugged this a bit and it seems that this behavior happens when the target position, that is used for the camera path calculation, is behind the camera (I don't think this is Scene.pickPosition error).

In this case the angle between positionToTargetNormal and camera.directionWC is large as in the following image:

Red point : camera.position
Red arrow : camera.directionWC
Blue arrow : positionToTargetNormal
Blue point : object._zoomWorldPosition

You can stop the code exactly when this bug occur by putting a breakpoint at this line with a condition like this:
Cartesian3.dot(camera.directionWC, positionToTargetNormal) < 0

[kring]

After further investigation, #4887 isn't the right fix. The root of the problem appears to be #4368. pickPosition is reporting that the globe surface is only a handful of meters away, when in reality it is hundreds of thousands of meters away. This is why it's so easy for the camera move past the target point on a slow system: the target point is much closer than it should be. I'm still trying to understand why pickPosition is returning rubbish.

[duvifn]

@kring, on my machine, with the above example code (I edited it a bit to make it shorter), Scene.pickPosition returns pretty accurate results but the bug still happens.

for example, the point is in
{x: 3987522.8005546024, y: 1329383.35146225, z: 4949256.648925018}

and Scene.pickPosition returns:
{x: 3987522.7989004473, y: 1329383.3511964455, z: 4949256.646444711}

So I think the code in ScreenSpaceCameraController still has to be fixed

[kring]

@duvifn that first point is reported by globe.pick? If so, yeah, that's much more reasonable than what I was seeing.

Considering how consistently this particular machine has a problem (every. single. time.) and how wildly wrong the pickPosition results are, I wouldn't be surprised if we're looking at a GPU/driver bug on this machine. It's an AMD FirePro V7900. It could potentially be a depth buffer precision difference too, maybe, but I can't see any differences at all between the WebGL report on this system and on my laptop, where I can't reproduce the problem even if I use targetFrameRate to render at 3 FPS.

[smills2929]

@kring Just to add some information to possibly help with the investigation of whether or not drivers affect it, the MacBook Pro (Retina, 15-inch, Late 2013) that I was having the issue with has an NVIDIA GeForce GT 750M 2048 MB GPU. Another person at my company has the same issue with a Macbook Pro 13" that has an Intel Core i5-5257U with Intel Iris 6100 integrated graphics.

It seems to affect Nvidia, AMD and Intel GPUs.

[kring]

@smills2929 that would point to it not being GPU/driver related at all, but I can't explain why I'm unable to reproduce it on my laptop even at a low frame rate, but the demo machine experiences the problem so easily.

To everyone experiencing this issue that has a Cesium dev environment set up, maybe try making the change that I made in #4887 (sorry I deleted the branch, but just copy the one code change) and see if it helps.

[denverpierce]

I've definetly seen it on a number of GPUs, but it can be hard to reproduce on faster hardware.

Anecdotally, #4887 sounds like it should work. Whenever I've had issues, it always seemed to be at high load times (around dataSource.load()s, tilting w/ terrain on a lot of horizon tiles get loaded, etc.) when the hitches seem to happen on better hardware. Slower machines would have a lot more of those times, so they see the issue more.

I'll try out #4887 on slower hardware and see what happens.

[duvifn]

@kring,
My use case is zooming into objects (models, points, lables, billboards, volumes).
In this use case I get this behavior every time, even if scene.pickPosition returns an accurate result (as in my example code above).

Additional examples:

1. Zooming vertically (and fast) into the marked volumes in the following image in this sandcastle example, always reproduce this bug (on my machine).

2. Zooming vertically (and fast) into the milktrack model in this sandcastle example when viewer.trackedEntity = entity; is commented out, always reproduce this bug.

Zooming into terrain on my machine reproduces this bug only in 1/10 - 1/20 of the times.
I guess (not sure) that I don't get this behavior so consistently with terrain because the camera checks collision with terrain (it doesn't use Scene.pickPostion for this) so It's pass through it only in some race conditions.

In all of these examples the code fails in the place I mentioned above (in ScreenSpaceCameraController).

Moreover, If I choose different zoom method, which leads to different code path (for example zoom with tilted camera, close to the earth), I don't run into this issue.

that first point is reported by globe.pick?

The point is the entity's point in my example code and its value is viewer.entities.values[0].position._value.

The point is pretty close to the camera in this case, so it's possible that Scene.pickPostion accuracy depends on the distance.

I didn't check yet the difference between pickPosition and Globe.pick values on my machine.

maybe try making the change that I made in #4887

I didn't try it yet, but it seems good to me. One thing I would suggest is to limit the additional pickGlobe only to cases where it's needed. readPixels is quite destructive operation (from the performance aspect) on some machines even if it's called after the frame was rendered.

I've tried (In different implementation) checking the angle between camera.direction and positionToTargetNormal (we can limit this to our frustum configuration) but I didn't prove yet that this covers all of the possibilities.

[denverpierce]

Using @duvifn 's examples, I'm able to reproduce the bug fairly consistently in master (though not 100%).

After a great deal of scrolling I wasn't able to reproduce it using #4887, such as on (http://cesium-dev.s3-website-us-east-1.amazonaws.com/cesium/zoomToNowhere/Apps/Sandcastle/index.html?src=Geometry%20and%20Appearances.html&label=Showcases)

[smills2929]

I can echo what @denverpierce said. I was consistently able to reproduce the bug using @duvifn 's example on 1.29, but was unable to reproduce it using #4887.

[smills2929]

Hi guys, has there been any movement on this? This bug causes us considerable issues when demonstrating our product (constantly having to zoom out and scroll back over to the other side of the planet).

Is there anything I can do to help?

[pjcozzi]

@smills2929 no update, but I added this to #4897, so someone may look at it during the bug bash.

Anything you can do to narrow down the cases when it occurs and even the section of code would be valuable.

[emackey]

@pjcozzi @smills2929 note that @kring writes:

The root of the problem appears to be #4368.

Would be good to confirm this, it sounds true. Edit: It's not.

[likangning93]

I don't know if this is news to anyone, but in the sandcastle example provided by @duvifn I can very reliably reproduce the bug using right-click zoom using what seems like a tiny amount of mouse motion.

[emackey]

It looks like the reason that sample reproduces so easily is that it places an entity right on the pick position. Try modifying the point in that sample to have a hole in the middle:

        point: {
            pixelSize: 20,
            color: Cesium.Color.TRANSPARENT,
            outlineColor: Cesium.Color.WHITE,
            outlineWidth: 5
        }

Still not perfect, but the zoom bug goes away.

[bagnell]

#4967 definitely fixed the issue with the code sample @duvifn posted.

@kring @smills2929 @denverpierce Can you test to see if you can still reproduce this with master?

[denverpierce]

#4967 keeps the view from flipping to the other side of the globe, but also halts zooming until the next mouse move event. IE if you're right mouse zooming and the zoom is halted, a user could keep moving their mouse and not realize why the zoom isn't working. It's an improvement. For me, #4887 was a better fix because it doesn't interupt user control. I also tested think that the #4368 causes this issue to appear more often, but is probably an issue with the GPU as I also see #4368 on an AMD card.

[pjcozzi]

@bagnell if we're going with #4967, can you please update the forum threads referenced in this issue?

[keikland]

The problem occurs consistently on my very fast computer. Having struggled with this problem since Dec 19th, the pattern coming out is that it is related to the new general pointer support in Chrome/Blink and Firefox/Gecko engines. The problem seems to extend to all browsers using those new engines, and I have tested many. Earlier versions do not have the problem!

Completely correlated with the zoom problem is disappearing polylines in a given radius zoom point (a balloon). My app has a range of polylines forming a global network, and the lines are all visible only when the whole hemisphere is visible. As I zoom in, the polylines in a half screen-radius from the zoom point disappear into the ground.

Combined with the observation by others that a ballon/point with a whole does not have the zooming problem, my hypothesis is that the surface reference becomes a black hole. Effectively, I think Cesium may be have the ground "disappearing" by either sin() or cos() approaching zero (dividing by zero) as zoom gets closer to the object. It , but is "saved" by not being allowed to go farther that the other side of the globe.

What about the correlation with adding general support to pointers? My hypothesis is that Cesium does not handle the new pointer event in Chrome and Firefox robustly, and fails to update a parameter that maintains the correct ground reference while zooming. @kring may therefore be on the right track.

Strangely, Edge does not have the problem. Their pointer event model seems to avoid problems in Cesium. Checking polylines, they are fine too! I would not be surprised if Firefox has copied Chrome's pointer event model...

Hope these observations can be useful for the Bug Bash and others.

[cherukumilli]

@keikland
I am running into the same problem.
Did you ever find a resolution to this problem?
If so, can you pls share it?

[hpinkos]

@cherukumilli are you using the latest version of CesiumJS? This should have been fixed in the 1.31 release