[Regression] Clamped entities sometimes incorrect position

[mzschwartz5]

What happened?

It's hard to know what's going on here. In some cases, entities are no longer clamping to the correct position.

For example, in this sandcastle, the billboard should be clamped to ground but is actually underneath it. This worked until relatively recently. A git bisect points to this merge commit as the "problem commit". The issue is, that just tells us that something in that merge into the PR was incompatible with something in the PR. It's hard to narrow it down further.

What is should look like (billboard clamped properly to ground):

What it looks like now (billboard underground):

Meanwhile, this sandcastle still seems to work fine.

Other things I've noticed:

Disabling screen space camera collisions for some reason "fixes" the issue. See here.

Reproduction steps

...

Sandcastle example

No response

Environment

Browser:
CesiumJS Version:
Operating System:

[mzschwartz5]

@alarkbentley

Hey Alark, I'm not exactly sure what's going on here, wondering if you have any insight. Somehow, something in the async-picking PR (#12983) has introduced a regression in entity clamping. I can't narrow it down further, but if I revert the PR, the issue goes away.

Entity clamping relies on terrain picking (ray intersections with the terrain mesh), not screen space picking via depth textures (which is what you worked on), so I'm not sure where the regression is coming from. What I do know, is that disabling collision detection on the screen space camera controller also makes the issue disappear ... which maybe is related to screen space picking?

Any thoughts would be appreciated.

[alarkbentley]

As you said, the modifications for async picking only touches with the texture picking so this seems very strange to me. My guess would be that there is some variable caching that goes wrong in ScreenSpaceCameraController and is accidentally shared between ray intersections and depth picking. (See eg. pickGlobeScratchRay, scratchDepthIntersection etc.)

Reminds me of this issue: #12887

Also, I was not able to reproduce the issue using your sandcastle link. It looks correct to me:

[javagl]

@alarkbentley One important aspect that was missing in the description:

When you open the sandcastle (and it shows the globe), and you double click the label, then (it zooms to that label and) the label is ... well, somewhere, but not at the place that it should be (or that it is when you zoom there manually).

[mzschwartz5]

^ Yes good point- if I zoom in manually to it, with the scroll wheel, it seems to display as intended. That's actually an interesting clue (not sure exactly what it means yet, but I see how this could be more related to the camera controller now).

That's also good to know the issue is a little less broad than I thought.

[mzschwartz5]

Another observation: if you even just scroll a tiny bit before double clicking the billboard, that mitigates the issue. So it's as if zooming is initializing something important.

[mzschwartz5]

Note to self (from internal discussion): look into EntityView class

[BlockCnFuture]

Another observation: if you even just scroll a tiny bit before double clicking the billboard, that mitigates the issue. So it's as if zooming is initializing something important.

The caching issue mentioned in #12908 still exists, and I believe this problem is also caused by the cache not being updated correctly. After zooming the scene, the height cache gets refreshed, so the position appears to become correct again.

This issue is actually very easy to test. The caching logic introduced in #12527 is not large. You only need to set the line at

cesium/packages/engine/Source/Scene/QuadtreePrimitive.js

Line 1450 in ea5f4d9

if (defined(cachedData)) {

to false to observe whether the problem is indeed caused by the cache.