Globe and sky/background corrupted for 1 frame after loading large 3d tiles point cloud

[spatial-dan]

What happened?

When loading a large 3D Tiles point cloud, the globe and sky/background briefly render completely black for one frame, then recover on the next frame. Using Git bisect we tracked it down to:

First bad commit: 854907babbc420d83d5676212ab317b33ea96154 “Add docs, simplify signatures for depth buffers”

Cesium versions affected: 1.122 (regression appears exactly here) 1.135 (still present; manually reverting the same commit fixes it)

Reverting this commit removes the flicker entirely on every affected release. We are working though that commit to further narrow it down but it looks like the changes to depth buffers may have introduced this bug. Possibly where one frame of the framebuffer is resolved/copied before receiving proper depth or stencil contents.

Reproduction steps

1. Use a large 3D Tiles point cloud that covers a large part of the globe.
2. Use default Cesium viewer configuration with requestRenderMode = true to best see the issue.
3. Have a view that is fairly zoomed out but also so that first loading the point cloud will display points.
4. The rendering seems to be corrupted for one frame where Globe disappears (black, no outline) and Sky/background becomes black.
5. Next frame everything is normal.

We can reproduce consistently with our own app, as when more going on increases the likelihood of it happening. We have been able to recreate in a clean Sandcastle only rarely but it does happen. We are working on a more repeatable Sandcastle or simplified code example. It does seem to occur more frequently when loading the data from a custom server URL than Ion.

Data that can be used to recreate is: https://www.dropbox.com/scl/fi/nsgp8hi73n6cdf92hvurn/F1_2020.laz?rlkey=np86hbjug4uqyhzt741tl2yt1&st=3fstkpm5&dl=0

Sandcastle example

No response

Environment

Browser: Any CesiumJS Version: 1.122 - 1.135 Operating System: Win/Mac/Linux

[alexpaulson1]

@ggetz - inform - this issue has been escalated by a few users

[jjhembd]

Thanks @spatial-dan for the report, and for tracing it back so thoroughly!

I haven't tried to reproduce it yet, but I looked through the problem commit for potential issues. Some things we could test:

• In Scene.prototype.updateAndExecuteCommands, don't call updateAndClearFramebuffers unless backgroundColor is defined. This may require reverting a few checks from if (useGlobeDepthFramebuffer) back to if (defined(globeDepth) && useGlobeDepthFramebuffer)
• In GlobeDepth.prototype.executeUpdateDepth, are we checking this._clearGlobeDepth before it was set for the pass? It is set in GlobeDepth.prototype.update, which is called in Scene from updateAndClearFramebuffers

[jjhembd]

Hi @spatial-dan, do you have any progress on this item?

We are working on a more repeatable Sandcastle or simplified code example.

I haven't been able to reproduce with a clean Sandcastle. Here's my local Sandcastle code. I added a button to trigger the point cloud loading manually--otherwise the point cloud often appears before the globe renders. But I still don't see any flashing of the globe or skybox when the point cloud loads.