We've received reports of rendering issues with materials in CesiumJS (https://github.com/CesiumGS/cesium/issues/9827), including translucent and dashed materials, on iOS devices using WebGL via Metal. These were occurring as of the latest Safari 15.5 release. Disabling order independent translucent in the engine appears to remedy the issue, so we're working on narrowing the issue down to a specific extension, though we believe it may be related to EXT_color_buffer_float.
Unfortunately this doesn't reproduce on M1 hardware, so Apple engineers will have to triage it. Submitter, please tell us any specific iOS device types that demonstrate the failure.
I can repro on iPad Pro 4th gen https://sandcastle.cesium.com/gallery/Wall.html observe the blue translucent wall rendered as wire-frame only, no blue.
Gabby, if it is simple for you to do and you have the time: - It'd be of great help debugging this if there was a .zip file with one scene that reproduces this, as simple scene as possible, with all the source files that are needed. - Additionally I notice that it was worked around with disabling the order independent translucency. It would be great if the example disabled this workaround, so that the example would reproduce the issue.
iPad Pro 4th gen is Apple5 A12 iOS GPU Family 5
Created attachment 459888 [details] Translucency issue - Cesium minimal scene Thanks! Attached is a minimal scene with the workaround disabled. It uses a CDN of the unminified CesiumJS library. If you need an example which packages the source code directly, please let me know.
Looks like this a lack of support for GL_EXT_float_blend. Commenting this out causes M1 hardware to stop rendering the squares.
I think I understand what's going on: We've added EXT_Color_buffer_float support to the Metal based backend for WebGL. However, Cesium doesn't consider the limitations of EXT_Color_buffer_float when performing rendering. Specifically, please note the limitations here: https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_color_buffer_float.txt By default, EXT_color_buffer_float does not require blending for R32F, RG32F, and RGBA32F textures. You also must check for GL_EXT_float_blend support.
Contrast this with the OpenGL backend, which has no support for EXT_Color_buffer_float, so OIT.js line 28 (const extensionsSupported = context.colorBufferFloat && context.depthTexture;) returns false. _translucentMRTSupport, and _translucentMultipassSupport will both be false, so we never create a render pass that requests blending. I suggest also adding context.floatBlend to the list of extensions required for OIT.
Just pasting this for my personal use future use: - OpenGL ES 3.0 states floating-point textures are not color-renderable (render to floating-point texture) - EXT_color_buffer_float makes floating-point textures color-renderable - EXT_color_buffer_float requires blending to be disabled when rendering to floating-point textures. - EXT_float_blend allows blending to be enabled when rendering to floating-point textures. In WebGL, EXT_float_blend is automatically enabled when enabling EXT_color_buffer_float, but only if EXT_float_blend is supported in the first place. https://www.khronos.org/registry/webgl/extensions/EXT_color_buffer_float/ https://www.khronos.org/registry/webgl/extensions/EXT_float_blend/ https://www.khronos.org/registry/webgl/specs/latest/1.0/ https://www.khronos.org/registry/webgl/specs/2.0/ https://www.khronos.org/registry/OpenGL/specs/es/3.0/es_spec_3.0.pdf https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_float_blend.txt https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_color_buffer_float.txt Closing as working as intended. There's something to be said about Web Inspector being able to identify this, but likely it wouldn't have helped as this was failing on device and people (including me) rarely look for the errors on device...