Make Eye Dome Lighting more efficient and compatible

[likangning93]

Eye Dome Lighting currently depends on a pile of WebGL extensions, including a couple that I didn't even realize it was using when the feature went in (my bad!). See #6792 (comment)

It needs:

• EXT_frag_depth
• OES_texture_float listed, but actually WEBGL_color_buffer_float/EXT_color_buffer_float
• WEBGL_draw_buffers

It might not need float texture support at all though. The current implementation uses MRT to store eyespace positions and a log depth per pixel in a RGBA float gbuffer, but this is probably overkill... seems like given the log depth we could compute most of the other information in the fragment shader, and we already have well-proven code for packing depth. This could also improve rendering performance since we'll be writing/reading much fewer texture bits per fragment.

[likangning93]

log depth in EDL, see the potree thesis: https://www.cg.tuwien.ac.at/research/publications/2016/SCHUETZ-2016-POT/

[likangning93]

It might not need float texture support at all

Need to think about this more, the log depth in eye dome lighting isn't normalized. Forgot that the log depth in potree also is for a different purpose than "actual" log depth. I'll figure it out...

[likangning93]

So we can probably derive the "non-normalized log depth" in the FS by building the position EC in the eye dome lighting shader.

But then at this point wondering, why use MRT instead of just using the 3D Tiles depth texture? (other than depth texture inaccuracy problems on certain platforms)

[likangning93]

But then at this point wondering, why use MRT instead of just using the 3D Tiles depth texture? (other than depth texture inaccuracy problems on certain platforms)

The MRT technique lets you apply stuff per-tileset though. Wonder if this gets more complicated as a depth-texture based post-process.