WebGL2Renderer

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! 😔

Author: Fantashit

19 thoughts on “WebGL2Renderer

  1. 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.

  2. 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.

  3. 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.

  4. @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.

  5. @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).

  6. (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.

  7. 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).

  8. 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?

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

Comments are closed.