WebGL2Renderer

[mrdoob]

This week Chrome announced their intent to ship WebGL 2.0 so I guess it's about time to start adding support!

There are already some PRs that add support to WebGLRenderer for some of the new features but, somehow, it didn't feel it was good idea to make WebGLRenderer support both webgl and webgl2.

Say hello to WebGL2Renderer! 2ff9d41 👋

A new renderer not only will save us from tons of conditionals but also will give us the chance of cleaning things up; starting with only supporting BufferGeometry ✌️

Sorry for all the people which PRs didn't got merged because of my indecision! 😔

[bhouston]

Very nice. :) I was actually a bit worried as to how to handle the complexity of WebGL 2 and 1.

It would be great to prefer to use UBO. :) And I love the idea only supporting BufferGeometry - that should simplify things tremendously.

It would be cool to support mostly same shaders though if we stick with forward rendering (which seems to be what UE4 is doing for speed for VR.) I think we can likely swing that? What do you think?

I guess I would like to maintain shader compatibility so that if WebGL2 isn't available we can fall back to something that looks similar, just slower.

[fallenoak]

@mrdoob Hip hip hooray! And great to hear that BufferGeometry will be exclusively used. 👍

I second @bhouston's suggestion of preferring UBOs.

Would it be possible to also more fully decouple lighting and shadow handling from the renderer, too? The defaults are really handy, but when you want complete control over lighting and shadow logic, WebGLRenderer and co. feel like they put up a fight.

And while I'm listing wishlist-y type items, could sort algorithms be made 'pluggable'? I have sorting needs that are outside of the scope of three, and it seems unnecessarily difficult to override the sorting functions in the current WebGLRenderer. Perhaps this could be an optional setting when creating the renderer object?

[bhouston]

I almost wonder if one should just modify WebGLRenderer 1 and remove support for anything but BufferGeometry objects. That may be an easier way forward. If there is a simple function for converting Geometry to BufferGeometry that one forces people to call...

I guess I say this because I am worried about trying to maintain feature parity between WebGLRenderer and WebGLRenderer2. It is easier to evolve a single code base rather than maintain two in parallel.

[mrdoob]

I almost wonder if one should just modify WebGLRenderer 1 and remove support for anything but BufferGeometry objects. That may be an easier way forward. If there is a simple function for converting Geometry to BufferGeometry that one forces people to call...

There is a function like that already. But is not that simple...

I think it's better to build WebGLRenderer2 from scratch so we can reconsider the API and the supported features.

[ghost]

Firefox 51 now has WebGL 2 support: https://www.mozilla.org/en-US/firefox/51.0/releasenotes/

[marcofugaro]

Can't wait for this!

[takahirox]

Chrome 56 supporting WebGL 2.0 was released!
https://developers.google.com/web/updates/2017/01/nic56

[takahirox]

Good time to move WebGLRenderer2 forward? XD

[edankwan]

Should we also create a WebGLDeferredRenderer2?

[mrdoob]

Planning to start looking into all this next week! ✌️

[NicolasRannou]

Any chance you already had some time to look into it! Soooo looking forward to it! (3D textures)

[takahirox]

@mrdoob
Any updates?
If you have some concerns, please share with us!
We can discuss and help ;D

[mrdoob]

Haven't had time yet. Soon soon! 😇

[ghost]

https://blog.chromium.org/2017/03/faster-3d-rendering-with-webgl-20.html

[medihack]

Any updates? I am especially interested in 3D textures for volume rendering some medical images. I am also willing to help to make this pull request succeed.

[Spaxe]

The current three.js webgl2 sandbox doesn't work :( https://threejs.org/examples/webgl2_sandbox.html
Might be a three.js version build issue?

[mrdoob]

If online <script type="module"> had been implemented already...
https://groups.google.com/a/chromium.org/d/msg/blink-dev/uba6pMr-jec/tXdg6YYPBAAJ

[Spaxe]

At least Mozilla is working on it https://bugzilla.mozilla.org/show_bug.cgi?id=1240072

@mrdoob, Does this mean we can expect Three.js API to take advantage of <script type="module"> when updated to WebGL 2.0? ;)

[bhouston]

BTW I think it is easiest in the mean time to just add WebGL 2.0 support to WebGLRenderer. I think that this would allow incremental adoption and we can do feature detection to see if we can use WebGL 2 features. I don't think it is the hardest thing to do. I know it leads to a little complexity as opposed to a pure WebGL 2 renderer, but it is the easiest path in near and medium term. And we slowly evolve where we eventually leave behind WebGL 1 once WebGL 2 has somewhere above 90% adoption.

[backspaces]

Khronos just had a webinar on webgl2:
https://docs.google.com/presentation/d/11-mTDNmSJzJnRVGu9Vu6AUzOt34yV3PO7oqw4E5wc2o/edit#slide=id.gd15060520_0_38
The media will be out shortly, but the presentation was mainly voice-over of the slides and associated demos in the slides.

Its pretty clear that this requires a new start, not "updating" from the existing WebGLRenderer.

[backspaces]

In terms of es6 modules, I think the current approach of the source being es6 modules, then using rollup for a bundle is still the way to support a "dual build".

I've done this now for a week or so, testing modules on Safari Tech Preview and the bundle on all browsers. Really results in build/ having the source tree as well as the current bundle. One-liner Rollup as you currently have, and a copy of the source tree for module use.

[mrdoob]

@bhouston tempting...

[backspaces]

Latest status?

[fetox74]

Antialiasing in Postprocessing would definately be beneficial.

[backspaces]

Under all this is the question: is it time for a new architecture for Three? I recently started using D3, version 4. It was a *complete* redesign. Es6 modules. And far more important, *30* modules, each of which was its own repo. I really recommend looking at the D3 architecture. I'm not saying we need this for Three, but I think we could consider a major version bump. Partially due to webgl2. But also due to need for sub-modules. An example: There is a D3 "selections" repo/sub-module. It's your basic jQuery DOM module but with all the verbosity of the DOM hidden in a functional, chaining design. It can be used as-is without using the rest of D3. Wouldn't you love a Three independent module that made all the webgl verbosity disappear? Maybe even multiple sub-modules for webgl ctx/shader management, buffer management, and so on. Indeed, the buffer geometry is a lot like this. Ditto for shader creation from parts. Just a thought.

[elunty]

@fetox74 Pretty sure you can do AA already https://threejs.org/examples/?q=fxaa#webgl_postprocessing_fxaa

[marcofugaro]

@elunty the FXAAShader doesn't produce a good enough result compared to original antialiasing, I've used it in the wild.

[pailhead]

i'm mostly interested in VAOs and writing to mipmaps which i hope is possible under that spec.

[Mugen87]

@pailhead Related #8705 😉

[atul-mourya]

Looking forward to the native support for EXT_shader_texture_lod.
It may resolve the artifacts being generated while using MeshStandardMaterial and MeshPhysicalMaterial on most of the Android devices and MS Edge and Internet Explorer

[wdanilo]

@mrdoob are there any plans from you or your team to update Threejs to Webgl 2.0? This thread takes literally years and nothing really changes while all other frameworks already moved forward. I’ll have a hard decision soon, we would probably have to migrate over Babylon or something and I would really like to stay with Three. I will, if there would be any, just any plans for its modernization.

[mrdoob]

@wdanilo if WebGL 2.0 is a priority for your project I would recommend you to migrate over to Babylon. I know some three.js contributors are planning on working on it, but I'm personally focused on WebVR and artists workflows (svg support, etc).

[wdanilo]

@mrdoob I really appreciate your fast answer here. I'd really like not to abandon three.js. I like how the lib is constructed under the hood and its assumptions to be "general" framework, not "game-focused" etc. Anyway, thank you for the information and keeping this clear.

[yoshikiohshima]

(Thanks again @takahirox, I was aware of this thread). I just made a pull request #13692. I understand that the focus is not on it but for our purposes, it's been working well.

[takahirox]

Related #13702

I made WebGL2 base branch following #9965 and #12250

Repo: https://github.com/takahirox/three.js/tree/WebGL2Base
Examples: https://rawgit.com/takahirox/three.js/WebGL2Base/examples/index.html

You can start WebGL2.0 + Three.js with it.

(Sorry conflicting with @yoshikiohshima work)

[takahirox]

@mrdoob Can we have a branch for WebGL2Renderer like three.js/dev-2.0? Or can we merge it into dev tho there still be a lot of duplicated codes between for webgl1 and for webgl2?

[yoshikiohshima]

I am new to the past development on this issue. @takahirox, can you summarize the strategy you are taking in and what are supported by https://github.com/takahirox/three.js/tree/WebGL2Base? (and again sorry for my ignorance) but I did not see the need for a lot of duplicated code to support WebGL2. What are the issues?

[mrdoob]

@mrdoob Can we have a branch for WebGL2Renderer like three.js/dev-2.0? Or can we merge it into dev tho there still be a lot of duplicated codes between for webgl1 and for webgl2?

Not sure why this would need a new branch. Why would there be duplicated code?

[takahirox]

Seems no conflicts. There're two demands for WebGL2.0 now.

1. Making WebGL2Renderer to support full WebGL2.0 features and optimizing well
2. Adding webgl2 support to existing WebGLRenderer. But we don't fully support WebGL2.0 features on it and don't optimize for WebGL2.0 because we don't wanna make renderer messed. So basically this's just for early access of Three.js + WebGL2.0 + GLSL3.0

Mine is for 1. His work is for 2. We don't have duplicated code and don't need to make a new branch for 2.

[mrdoob]

@takahirox I think it would be better to work in the same branch for the time being.

If you improve...

https://github.com/mrdoob/three.js/blob/dev/src/renderers/WebGL2Renderer.js

and the webgl2 examples import classes directly (not needing builds)...

https://github.com/mrdoob/three.js/blob/dev/examples/webgl2_sandbox.html#L39-L47

there shouldn't be conflicts.

[takahirox]

You can forget my WebGL2Base so far because it seems we start WebGL2.0 support in one WebGLRenderer.

[DavidPeicho]

Are we still thinking about implementing a WebGL2Renderer?
I have been looking a lot lately to add WebGL2 support, and I am waiting for takahirox changes to rebase mine. But after doing some changes, I started to think that rewriting the renderer would be a really good idea, as well as the WebGLTextures object. If it is still topical, I would be glad to participate.

[mrdoob]

I think so yes. I think adding basic webgl 2.0 support to the current WebGLRenderer is just to have something while we work on WebGL2Renderer.

Feel free to start rewriting the renderer and send PRs (ideally step by step).

[aldanor]

Apologies if asking the obvious, but after reading this whole issue, with the last post being half a year ago, and finding a few references to webgl2 in both the master source code and examples, I still can't seem to quite figure it out.

Wonder if webgl2 is any usable in its current state in Three.js? (even if just rendering simple buffergeometry meshes) Would the EffectComposer work with a webgl2-context-enabled renderer? Would the render target have to be adjusted in any way?

The biggest question, of course, is whether it's currently possible to get proper antialiasing when using composer with custom passes?

[mrdoob]

Seems like in the end we just ended up adding WebGL 2.0 features to WebGLRenderer.
WebGPU will sure need a WebGPURenderer though.