cesium: scene.pickPosition returns incorrect position

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

The user created this sandcastle example to demonstrate the problem: http://hosting.virtualcitysystems.de/demos/temp/pickProblem/Apps/Sandcastle/?src=3D Tiles.html&label=undefined

The demo is using the latest 3d-tiles branch

pickPosition works fine if you run the example inside sandcastle, but if you click ‘Open in New Window’ sometimes the returned position sits in front of the building you clicked instead of where the click intersects with it. Maybe it’s related to the canvas ratio? See the forum post for more details.

I couldn’t reproduce this with any of our sample models, but I asked the user if he could share a tile for us to test with.

About this issue

  • Original URL
  • State: open
  • Created 8 years ago
  • Reactions: 3
  • Comments: 41 (30 by maintainers)

Most upvoted comments

https://github.com/CesiumGS/cesium/issues/11031 is likely caused by this issue directly, but only arose after the Model refactor changed how point clouds were handled.

There are some good debugging notes from @UniquePanda in that issue.

@emackey

  1. I’m not sure that the ‘jittering’ in your animation is due to the pickPosition results . On my machine, If I set eyeOffset.z to a fixed value this doesn’t happen.

  2. I think it’s worth adding scene.globe.depthTestAgainstTerrain = true; to the code in your comment, because this is not the default in the sandcastle. pickPosition returns different values on terrain if depthTestAgainstTerrain == false , usually below the ellipsoid surface (maybe of the DepthPlane).

  3. The Alt string in this example code is truncated so it shows an wrong height. for example: -143976.41485355987 becomes 3976.41.

Based on the debugging that @UniquePanda did, along with some of our own, the problem here might be linked to a bad depth copy around here, where existing values are being overwritten. That could be affecting other picking functions as well, such as sampleHeight.

To solve, either pickPosition should look both at the pick and depth textures and chose the the closest value, or we could possibly move pick depth earlier and composite in later values.

Additionally, this does not eliminate the possibility that multifrustum may still be playing into the issue.

In looking at this while debugging #4855, I saw a case where I had only a single frustum, and yet the position returned by pickPosition was wildly wrong. For example, values in pickGlobe in ScreenSpaceCameraController.js:

image

That’s without anything in the scene except for the globe (and sun and moon and such I suppose, but not explicitly-added primitives).

So I don’t think it’s necessarily multi-frustum related.