cesium icon indicating copy to clipboard operation
cesium copied to clipboard

[Regression] Clamped entities sometimes incorrect position

Open mzschwartz5 opened this issue 2 weeks ago • 7 comments

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):

Image

What it looks like now (billboard underground):

Image

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 avatar Dec 04 '25 20:12 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.

mzschwartz5 avatar Dec 04 '25 21:12 mzschwartz5

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: https://github.com/CesiumGS/cesium/issues/12887

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

Image

alarkbentley avatar Dec 05 '25 04:12 alarkbentley

@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).

javagl avatar Dec 05 '25 12:12 javagl

^ 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 avatar Dec 05 '25 14:12 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 avatar Dec 05 '25 15:12 mzschwartz5

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

mzschwartz5 avatar Dec 05 '25 17:12 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.

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 https://github.com/CesiumGS/cesium/blob/ea5f4d9d2db6e9743ba8658852b4d63e41568685/packages/engine/Source/Scene/QuadtreePrimitive.js#L1450 to false to observe whether the problem is indeed caused by the cache.

BlockCnFuture avatar Dec 10 '25 04:12 BlockCnFuture

@BlockCnFuture good idea, though ti doesn't seem to be the cause here, at least.

mzschwartz5 avatar Dec 12 '25 17:12 mzschwartz5