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! https://github.com/mrdoob/three.js/commit/2ff9d410753b72a5e43b211dc3be26f0f0ab8a0e 👋

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?

[fernandojsg]

I've got somehow mixed feeling about this. Initially I was thinking about the same path as @bhouston proposed, going incrementally adding webgl2 features to the current WebGLRenderer. But that would make the renderer more complex and hard to deal with features that differ the most between the two version ending up with a messy code full of branches and condition checks. One option could be to clone the WebGLRenderer as the starting point for WebGL2Renderer and keep removing/adding features without messing with the original renderer. If we take a look at engines like Playcanvas, which is probably the one out there with the earliest webgl2 support, we can see that it even doesn't take the advantage of the new webgl2 features like UBO or VAO because it's something that will modify many parts of the engine.

I strongly believe that if we try to mix both versions on the same renderer we'll end up with a harder to maintain code and as soon as webgl2 will get fully support we'll need to refactor this anyway as I guess we'll be forced to follow a design to keep that compatibility, instead of design it from scratch having webgl2 in mind.

So my vote is to start WebGL2Renderer from scratch even if we'll go slow (we still have room for improvement until webgl2 will get close to 100% support out there).

Some files other than just the renderer itself must be modified, for example textures, programs and so on. Should we create a subfolder renderer\webgl2 and keep adding the files that will be specifically created for that renderer?

We could create an issue with the list of changes we should do to have a webgl2 fully compatible renderer to have them in mind when writing the renderer, and also create a list of features we would like to have for MVP to focus our effort on discuss these in this initial state to kick off a deeper conversation on the implementation.

[sasha240100]

Any updates on its development?

[mrdoob]

Not yet. I was giving priority to WebVR this month.

[tstanev]

I tried a quick'n'dirty in-place conversion to WebGL2 and ES3 shader language, as suggested by @fernandojsg above. Here is the squashed diff: https://github.com/tstanev/three.js/compare/master...tstanev:traian/webgl2 Actually, it doesn't look nearly as bad as I expected initially. It's almost looking like it would not be super ugly to support both via some strategically placed ifdefs. [Edit: Updated link.]

[sasha240100]

@tstanev Do you have a working example?

[tstanev]

The bundled three.js examples in the linked branch are working (as you can see in the diff, I converted the ones that required extensions previously). You can clone the repo/branch and run them locally.

[sasha240100]

@tstanev How about making performance comparison for webgl2 changes online?) Would be nice to see it. (three.js vs three.js on webgl2)

[mh-alahdadian]

hi thanks you for this best idea. I wants to use webgl2renderer in my program but I couldn't use it in precompile version(r86) so I get the source and uncomment the webgl2rendrer in three.js importing and then build it. now my code and your example (webgl2-sandbox) will run without any error but they show nothing

EDIT: I had test them in firefox 54 and chrome 60 my example using bufferGeometry and ShaderMaterial and will be work correctly in webglrenderer

[mh-alahdadian]

no one answer me? what is the problem of webgl2renderer now?

[looeee]

@MHA15 presumably it's not included in the build because it's not ready for production yet.

[edankwan]

Hey guys, how is the WebGL2Renderer development going? I know that the decision was made to recreate it from scratch. But it has been a while and the development is kind of slow on this topic as it is a great amount of work to recreate it I believe.

At this point, can we reconsider making a clone of WebGLRenderer and change it into WebGL2 instead like what @mattdesl did in https://github.com/mrdoob/three.js/issues/8125 ?? We can then modify the renderer based on some new features like UBO as @fernandojsg said. Eventually, we will remove all of those webgl 1 legacy codes.

In my opinion, creating the renderer from scratch requires a huge amount of work and ideally it can only begin with a few contributors. This conversation was started a year ago. And unless we got to the point we have a savior who would spend a few months full-time building it from scratch, I believe we will probably be on the same page next year.

[mrdoob]

In my opinion, creating the renderer from scratch requires a huge amount of work and ideally it can only begin with a few contributors.

That it's true. But even then, I think that's easier than making WebGLRenderer harder to maintain by adding conditionals everywhere. I've spent most of my last 5 years trying to make WebGLRenderer easier to read and maintain.

[mrdoob]

Also, I think @fernandojsg was planning on giving it a go in the coming weeks.

[edankwan]

That's awesome. Looking forward to great work from @fernandojsg!!

P.S. I gotta say.. Thank all of the contributors of this project for widening my horizon of the computer graphics. Hoping I will be able to contribute some examples in the future.

[fernandojsg]

I agree with @mrdoob that it will be easier to create a new renderer from scratch than modified the current one. As he said, I wanted to give it a try in the following weeks. My approach is to start creating just what it's needed for a simple box on the screen and keep adding features to it step by step, instead of taking what is already there and try to refactor it. As an example just take a look at the current state of the WebGLRenderer, there have been lot of discussions about making it more modular and customizable but still even if the internal code keeps improving over the time, outside from there it's just a black box. As soon as I'll have something working I'll open a PR so we could keep discussing there the next steps.

[mrdoob]

While we are at it... 5f889ce296aaf447ec5992a6df726691098a9110 8aab6e0382cd6ba8fd3fb943e7f65141bf3a50bc webgl2_sandbox works again (requires es6 modules though).

[wdanilo]

@mrdoob do you have any rough estimate when will it be available in master / release? :) I'm happy it is happening! :)

[mrdoob]

@wdanilo Not really... What features from WebGL2 do you need?

[abogartz]

@mrdoob the biggest improvements would come from the Uniform Buffer Objects and the Sampler2DArray. The texture array would be seriously beneficial to my current project because we're up against texture unit limits as I'm using a complex shader that layers multiple materials masked by alpha maps.

[gaomeng1900]

@mrdoob New keywords like flat in glsl would be very helpful too.

[pieper]

My project needs 3D textures.

[mrdoob]

Interesting... Super helpful to be aware of the specific cases people need WebGL 2.0 for. Keep them coming!

[Wizarth]

3D Textures is also the big feature for us. I think we also use some shader features.

[takahirox]

Sometimes I want MRT

[pieper]

+1 for multiple render targets too

[mattdesl]

Multiple render targets is already supported in WebGL1 via an extension, and there's even a PR for it in ThreeJS: https://github.com/mrdoob/three.js/pull/9358 (demo).

I think multisample render targets is my favourite feature. Most clients request post-processing (bloom, LUTs, etc) but they are disappointed in the lack of proper anti-aliasing once the post FX are implemented. With MSAA render targets we can finally have a nicely anti-aliased and post-processed scene.

[kylegmaxwell]

I agree. Workaround shaders for anti aliasing on post processed scenes with effects composer do not suffice for true anti aliasing.