Skip to main content

Khronos Blog

WebGL Happenings

by webgl, opengles

WebGL Happenings: Working Group members address topics such as universal WebGL 2.0 availability, the upcoming WebGPU standard, and updates on cool WebGL applications and tools in November’s Virtual WebGL Meetup

WebGL is a cross-platform, royalty-free web standard for rendering low-level interactive 2D and 3D graphics API based on OpenGL ES within any compatible web browser without the use of plug-ins. Major browser vendors Apple (Safari), Google (Chrome), Microsoft (Edge), and Mozilla (Firefox) are members of the WebGL Working Group.

Developers familiar with OpenGL ES 2.0 will recognize WebGL as a Shader-based API using GLSL, with constructs that are semantically similar to those of the underlying OpenGL ES API. WebGL 1.0 exposes the OpenGL ES 2.0 feature set; WebGL 2.0 exposes the OpenGL ES 3.0 API.

On November 18, 2020, WebGL held an engaging and informative virtual WebGL Meetup. Co-organizer of the event, Damon Hernandez, led the discussion and kicked off the meeting by having the Chair of WebGL, Ken Russell, giving an update on the latest WebGL progress along with some “Cool WebGL Stuff.” After the update, the guest speakers addressed the following topics:

  • Emmett Lalish of the Google Chrome Media team spoke on <model-viewer>
  • Alban Denoyel presented an update from Sketchfab
  • Rami Santina of BlackSmithSoft provided an overview of how WebGL and other standards work in Building Information Models (BIM) and reality capture (point clouds) for management of construction projects.
  • Lindsay Kay from xeolabs gave an update on xeokit
  • William Eastcott spoke on the latest PlayCanvas developments
  • Ib Green of Unfolded shared Unfolded Studio, which shows advanced geo-analytics on the web via WebGL
  • Jason Carter of Microsoft showcased the latest features of Babylon.js

At the end of the Meetup, the audience submitted questions for the speakers during a live Q&A, which can be found below. This is not a verbatim transcription. If you have additional questions, please comment below and we’ll be sure to get back to you.

If you’d like to reference the Meetup materials, the session was recorded for on-demand playback. To access the presentations, visit our Video and Events Library page for the event.

WebGL Resources referenced in this session can be found here:

Question: What is the timeline for WebGPU?

(Ken Russell, WebGL Chair, Google) The WebGPU community group is converging on the first shippable version of the API and shading language specifications. Firefox and Chrome already contain prototypes of WebGPU behind flags that can be used for development purposes. The group is aiming for a "minimum viable product" milestone early in 2021, and the first version of the specification later in 2021. The MVP is an intermediate, non-stable milestone to gather more developer feedback - applications must plan for API updates between then and the first official version of the specification.

Question: Ken, could you suggest a good approach for a progressive progression pipeline from teams that have been vested on WebGL —> to WebGPU

  • How complex will this be? Much refactoring to be expected?
  • Any hypothetical timeline and possible date_stamps
  • How do you see WebXR/WebAR adaptation to WebGPU?

(Ken Russell, WebGL Chair, Google) WebGPU is a different API and will require a different code path in the application. As mentioned above, it can already be tested in Chrome and Firefox by enabling flags, so it's a great time to start exploring the API if you haven't already.

Note (please see the WebGL Working Group updates) that we hope for universal availability of WebGL 2.0 soon. If you need to ship your product today, WebGL 2.0 is the way to go. WebGL will be supported indefinitely. You do not need to worry about it going away.

WebGPU's timeline is discussed in the answer to the previous question. WebXR and WebAR are already working on WebGPU integration.

Question: Currently wasm modules need to "call out" to JavaScript to call WebGL / WebGPU APIs. Are there any ongoing plans for browser implementations to "shortcut" API calls from wasm modules for efficiency?

(Ken Russell, WebGL Chair, Google) There’s ongoing work in Chrome to optimize calls out from JavaScript to APIs like WebGL and WebGPU. This will inherently make all JavaScript and WebAssembly applications which use these APIs run faster. If you have specific test cases that you think should run more quickly, please post them on webgl-dev-list.

Question: What is the biggest model size you have loaded with xeokit?

(Lindsay Kay, xeolabs.com) I've yet to do a proper investigation of that, but it's on the near-term roadmap! I'm still setting up a few machines/browsers for a proper test, so we will have some results on that soon.

Question: For xeokit, any plans to read other than IFC file format in the future like Revit, .vue, .rm etc…?

(Lindsay Kay, xeolabs.com) Not currently. If Revit can export everything we need in IFC, then we'll go with that for now.

Question: Unfolded, are there any features that you want to implement, but WebGL is not moving quickly enough? Will WebGPU resolve that?

(Ib Green, Unfolded) Generally being able to transfer data efficiently between GPU and CPU is always a major concern - being able to do async queries from the GPU (supported on all platforms, including Macs), is something we really will use. We’d also love to see native GPU 64-bit support exposed through a WebGPU extension.

Question: Emmett, does <model-viewer> work on Chrome for both Android and iOS? I'd also be curious if you can use <model-viewer> in Twitter "cards" or Facebook "cards", but I don't think this is a well-formed question since I don't think Twitter cards can use JavaScript? On a Google search, I see Sketchfab was able to get 3D embeds on Twitter Cards working, but I don't know if they have a special backdoor from Twitter.

(Alban Denoyel, Sketchfab) We had to negotiate with both Twitter and Facebook to get Sketchfab whitelisted.

(Emmett Lalish, Google) <model-viewer> works across browsers and devices; if you find any that don’t work, please file a bug! Sounds like I should chat with Twitter and Facebook.

Question: Emmett, does <model-viewer> use Filament?

(Emmett Lalish, Google) No, but I do collaborate with the Filament team on rendering techniques.

Question: <model-viewer>, How do you detect the performance?

(Emmett Lalish, Google) We use the delta between RAF callbacks. We target a frame rate a bit below the display rate to give the feedback loop room to maneuver.

Question: Any comments on custom shader support in <model-viewer>?

(Emmett Lalish, Google)

<model-viewer> does not support custom shaders, as glTF defines materials to be rendered with physically-based rendering.

Question: Emmett, I'm not familiar with WebComponents. Are there extra steps to embedding your <model-viewer> element in the jsx dom of a React/Preact app or does it just work somehow?

(Emmett Lalish, Google) It should just work. I know of others who are using <model-viewer> in React. Search our Github issues for problems and solutions others have found.

Question: What is the largest model you can use in <model-viewer>? What are the limitations?

(Emmett Lalish, Google) There are a lot of ways to measure the largeness of a model, and usually long before you crash the renderer you get terrible performance. Much will also depend on the GPU. I’d recommend staying far away from the limits.

Question: <model-viewer> - is there a public roadmap?

(Emmett Lalish, Google) There’s a To do list you can see on Github that contains our top priorities. Most of the planning is short term rather than long term. The best way to affect our roadmap is to comment on or file issues.

Question: You mentioned that <model-viewer> uses three.js. However, Google has a great in-house PBR rendering engine Filament. Will it eventually use it or will it stick to three.js?

(Emmett Lalish, Google) I think you mean Google has two great in-house PBR rendering engines. Three.js is a much smaller JS bundle and is better tested on the web. There is a lot of cross-pollination of rendering ideas between these two engines.

Ways to Learn More and Get Involved

You can learn more about the WebGL Working Group efforts at the WebGL Overview Page. You can also join the WebGL public mailing list here, as well as the WebGL Dev list in Google Groups. If you would like to become directly involved in the WebGL Working Group, or any other Khronos Working Group, any organization is welcome to join Khronos to have a voice in the evolution of any of its standardization activities.

Comments