Extensions in Canary
createVertexArrayFromGeometry, but could also be used by billboards and polylines that use vertex buffer directly.Draft WebGL Extensions
color and pick passes in a single pass. Later, with the post-processing framework, we can combine other passes like glow and velocity. Shadow and reflection passes will still be separate since they are rendered with different view parameters.Proposed WebGL Extensions
OpenGL ES 3.0 Features
More on ES 3.0
More on WebGL 2.0
WebGL 2 Demos
Done
The renderer could always expose UBOs and emulate them with traditional uniforms or uniform arrays if they are not supported. This will require some GLSL macros or shader patching for the uniform/uniform-buffer declarations.
Automatic uniforms can be grouped into uniform buffers based on update frequency: per frame and per object (model-matrix).
Each command can provide two uniform buffer: one for uniforms that don't change often and one for uniforms that do. This maps to technique (don't change) and material (do change) parameters. Or one uniform buffer might be fine since the command creator won't have to figure out how to organize them.
Cesium Implementation Status (after #3094)
OES_standard_derivatives is disabled. dFdx, dFdy and fwidth are not recognized when compiling the shader.PolylineArrowMaterial uses standard derivatives.EXT_frag_depth is disabled. gl_FragDepth is not recognized when compiling the shader (neither is gl_FragDepthEXT).OES_texture_float is disabled. Could not create a texture with PixelDatatype.FLOAT.WEBGL_depth_texture is disabled. Could not attach a depth-stencil texture to a FBO.WebGL 2 articles on the RTR blog:
Texture Array: we could use TEXTURE_2D_ARRAY in some cases where texture atlases are used. It will be simpler and great for dynamic updates when the size doesn't change, #2319
Hardware PCF for soft shadows
Model.jsFor FXAA, use textureLod and textureLodOffset like the original shader. Consider using textureSize instead of a uniform.
createPickTexture in Cesium3DTileBatchTable.js and createPickIds in ModelInstanceCollection.jsLikely run our existing GLSL through modernizeShader, #5623, to generate GLSL ES 3.0, and then have a bit of a DSL (domain-specific language) with marcos/etc to handle differences like varying vs in/out. I'm sure it will not be that simple and some thing will have to be GLSL ES 3.0 specific, but we do not want to limit ourselves to only using GLSL ES 1.0 over the long haul, and I believe that engines like Unity do exactly this.
If running a webgl2 context bypass texture upscaling code in Model when generating mipmaps.
EDIT: forgot this was already added above.
See https://github.com/AnalyticalGraphicsInc/cesium/pull/6314 which enabled WebGL 2 by default but hasn't been tested enough yet and had gone stale.
Possible terrain loading bug in WebGL 2: https://github.com/AnalyticalGraphicsInc/cesium/issues/6756
For anyone trying to use CesiumJS with WebGL 2, note this is not currently officially supported, but is on the roadmap. I'm consolidating open issues with running CesiumJS with WebGL 2 here.
For reference, you can activate WebGL 2 by initializing the viewer as follows:
var viewer = new Cesium.Viewer('cesiumContainer', {
contextOptions: {
requestWebgl2: true
}
})
The original issue description is very out of date, if we're going to use this to track WebGL2 implementation, someone should update it with updated thoughts and plan of action.
@mramato 👍
That'll be on me an @YoussefV once we start the WebGL 2 / MSAA work.
In WebGL 2 the camera zooms towards the globe instead of towards the geometry that the mouse is hovering over. This seems like a bug in either ScreenSpaceCameraController or scene.pickPosition.
WebGL 1

WebGL 2

@lilleyse
When ScreenSpaceCameraController needs a pickPosition, it calls both scene.pickPositionWorldCoordinates and globe.pickWorldCoordinates and chooses the closer of the two, assuming both are defined.
In our case, scene.pickPositionWorldCoordinates returns undefined and so ScreenSpaceCameraController uses the globe pick instead.
I played around a little and the problem seems to be that the depth texture is empty.
With the help of this error, I tried hard-coding a NEAREST filtering and it worked alright (even the error was gone). So I guess it's some problem with linear minification/magnification filtering.
I tried it with the changes from 8969, so that can also be a factor.
@dennisadams awesome, that fixes it for me as well. Just to confirm you added nearest filtering to the depth-stencil texture?
globeDepth._depthStencilTexture = new Texture({
context: context,
width: width,
height: height,
pixelFormat: PixelFormat.DEPTH_STENCIL,
pixelDatatype: PixelDatatype.UNSIGNED_INT_24_8,
sampler: Sampler.NEAREST // Fixes the zoom
});
@dennisadams @lilleyse That also fixes the Silhouette post processing as well. Also I look it up, and in WebGL 2, it seems depth texture cannot have linear filtering. That may be a potential problem with other depth textures used by Cesium as well
Just to confirm you added nearest filtering to the depth-stencil texture?
I went on a safe bet - hard-coded the Texture constructor.
Labels look a bit different in WebGL 2. Click the images to see the difference.
WebGL 2
WebGL 1
The AO post process has artifacts: Local sandcastle.
Polyline arrows start to get squashed. Local sandcastle

Cesium Inspector is extremely show when "Show Frustums" is checked. Local sandcastle
Contour lines are much thinner in WebGL 2. Local sandcastle.
First thing I would look into is GL_OES_standard_derivatives which is another built-in define that's part of WebGL 1 but maybe not WebGL 2 (I haven't checked). GL_EXT_frag_depth is another one we should investigate.
Alright that's all I've uncovered so far by going through each sandcastle example with WebGL2 enabled. @baothientran I recomend starting with https://github.com/CesiumGS/cesium/issues/797#issuecomment-646920630 and seeing what other bugs are fixed in the process.
@baothientran since the number of bugs fixes was starting to grow too much I consolidated them into a single CHANGES.md entry: https://github.com/CesiumGS/cesium/commit/65757f8b7dce74d1ffbf9d61ea10d6e4508b86f2
Also I updated the checklist above: https://github.com/CesiumGS/cesium/issues/797#issuecomment-617189407
modernizeShader is too slow. This is something we should address before defaulting to WebGL 2.
Most helpful comment