Translucent tiles change colors on mouse move when picking

[ebogo1]

Sandcastle example: link

Browser: Firefox

Operating System: Linux

Found by @lilleyse in #9399. From a comment in that PR:

[ebogo1]

Some notes -

@lilleyse Suggested that this was due to a frame buffer not being cleared, and after testing I'm pretty confident this is true. When translucency in the above Sandcastle is set to 0.01 instead of 0.5, the ghosting effect of old frame buffers loading back in is much more noticeable and gradual.

This also seems to happen when an old frame buffer is present and the camera moves, and results in a ghosting artifact like this -

Maybe something to do with the passState.framebuffer logic in TranslucentTileClassification.executeTranslucentCommands? Still digging.

[ebogo1]

I found something that might be of note -

1. Scene.executeCommands calls TranslucentTileClassification.executeTranslucentCommands and TranslucentTileClassification.executeClassificationCommands, in that order.
2. The translucent commands function increments TranslucentTileClassification._frustumsDrawn by +=1 if hasTranslucentDepth is true. All the other places where frustumsDrawn is changed set it to 0.
3. In TranslucentTileClassification.executeClassificationCommands, the drawClassificationFBO only gets cleared if frustumsDrawn is greater than 1. Setting the check to >= instead of > appears to fix this bug, and does not seem to impact correctness of Scene.pick's return value in the above Sandcastle.

Is it possible for frustumsDrawn to become greater than 1? In Scene.executeCommandsInViewport, it is set to 0 in updateAndClearFramebuffers before the call to executeCommands, so at first glance it looks like it it isn't. @lilleyse @likangning93 Any thoughts, maybe I'm missing something?

[lilleyse]

I don't remember all the details but I believe frustumsDrawn is there in case the scene renders multiple frustums like when log depth is disabled (scene.logarithmicDepthBuffer = false)

[ebogo1]

Update - I believe this bug happens because Picking.pick might call TranslucentTileClassification's execute commands before the classification's clear function has a chance to run during the last render.

• TranslucentTileClassification stores an accumulationFBO if there are more than one frustums using the classification. In the clear function, this is handled by always clearing the drawClassificationFBO and only clearing the accumulationFBO if frustumsDrawn > 1.
• The check if (this._frustumsDrawn > 1) in executeClassificationCommands before clearing the looks like an optimization to avoid clearing the classification FBO both in the execute function and in the clear function.
• It is possible for the picking function to call the two execute functions in TranslucentTileClassifications in between the time that the render executes the translucent classification commands and clears the buffer for the next frame. This is because Scene calls updateAndClearFrameBuffers before it calls executeCommands in executeCommandsInViewport.

I wasn't sure what the best way to test this was but I figured that with the above thinking, the bug could be replicated outside of picking by only clearing the classification FBO in clear if frustumsDrawn > 1. This would simulate the behavior of not clearing the FBO in between consecutive calls to executeClassificationCommands. With this change, the same ghosting artifacts can be seen because the uncleared FBO stacks on itself without picking -

A better solution might be to force the pick function to clear the classification FBO if the commands are being executed as part of a pick rather than a render. I'm not sure how easy of a change that'd be, so for now I opened a PR with the simpler change - #9440.