Optimize picking

[pjcozzi]

The fix for #583 slows down the fragment shader for picking because it executes the full fragment shader for materials. If we know a material doesn't have any transparent parts (and doesn't write depth in the future), we can just use a simple pass-through shader.

[pjcozzi]

This will also optimize other passes like glow (e.g., a single bit mask) and shadow/depth pre-pass (depth only).

[pjcozzi]

We should also better document the performance costs of Scene.pick (rendering the scene), and encourage users to only call it once from their app. If need be, we could cache the result inside Scene.pick for when the objects/time doesn't change, but it would be a lot of bookkeeping to implement at this level.

[pjcozzi]

FYI...the bottleneck is, of course, in readPixels blocking while the GPU's pipeline flushes. In Open Philly Globe, readPixels is 40% of the profile when the Septa or Pedestrian Count layer is on and the mouse is moving. I'm not sure how much we can do about this without asynchronous readbacks using PBOs.

[pjcozzi]

With WebGL 2.0, we can also use MRT to render the pick buffer in the same pass as the color. CC #797

[billwritescode]

Any thoughts on addressing this? Noticing that gl.readPixels (via scene.pick) is chewing up CPU time: http://cesiumjs.org/releases/1.30/Apps/Sandcastle/?src=Hello%20World.html&label=Showcases&gist=09ea27d7643dceaacded4fe1f31a9471

[pjcozzi]

@billwritescode the biggest win will come from not stalling the CPU and starving the GPU with WebGL's readPixels. I think this is possible with WebGL 2, #797, and we'll investigate when we ramp up WebGL 2.

[skaughtx0r]

10 years later, this still has a huge performance impact. What's the status on this issue now that the WebGL Roadmap is closed and the WEBGL_draw_buffers were not addressed?

[ggetz]

@skaughtx0r We're putting together our roadmap for our next year of development starting in March, and are hoping to take advantage of the fact that WebGL2 is now the default in CesiumJS to do some optimizations like this.

[tmarti]

It should be possible to convert gl.readPixels into async operations by wrapping the check for a webgl2 fence synchronization into an async Promise.

The result would be that, when the mouse moves, the feedback would not be synchronous with the mouse movement, but instead the feedback would come after the data is available, so a bit extra end-to-end time.

The nice thing with this, though, is that there would be no stalling of the GPU pipeline, and you could keep moving the camera while the pixels are being read 🙂.

Mention me if you want a code snippet example in this thread, it’s actually a small bit of code but of course in the consuming side it needs to be taken into account that the pixel reading operation would need to be await-ed .

[skaughtx0r]

@tmarti could you post the code snippet you mentioned?