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

[sasha240100]

+1 for draw feedback. Or is it already supported as webgl1 extension in three?

On Thu, Dec 14, 2017 at 9:45 PM Kyle notifications@github.com wrote:

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

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/mrdoob/three.js/issues/9965#issuecomment-351815640, or mute the thread https://github.com/notifications/unsubscribe-auth/AHTX1RhYdGuTVSpmOy1ka-6gy1eslHQAks5tAXrFgaJpZM4Kj_9l .

[wdanilo]

I've got couple of use cases here:

1. I need MRT - currently I'm rendering the same shader 4 or 5 times, changing an attribute just to get different buffers.
2. Rendering to texture with antialiasing is an important feature for us - we make an "node editor" with visualisation preview. Each visualisation is just a texture we draw something too and no proper antialiasing is a pain here.
3. The "flat" keyword - I'm now indexing geometry with an float attribute, which obviously is sub-optimal - worse than indexing with uint one. I'm passing this attribute from vertex to fragment shader and I cannot use uint now, because we lack the support of "flat" kwrd.
4. (smaller) 3D textures are great for high end visualisations that we would like to support in near future.

[marcofugaro]

Using anti-aliasing and post-processing together is the most important one for me.

[martinleopold]

@mrdoob My top 3 WebGL 2 Features/Use cases (in order of importance):

1. Multisampled Render Targets: For proper (MS)AA in post-processing.
2. Integer Textures: For doing image based algorithms like Signed Distance Fields, as well as using more exotic texture based data like DEM (Digital Elevation Models).
3. Transform Feedback: For doing particle systems.

[wdanilo]

@mrdoob by the way, do you know why #9358 PR was not merged? As @mattalat have written, it brings multitarget rendering to threejs. Was commited 2 years ago, fixed several times to keep up to date with other changes and until now it's not there :(

I'm asking about it because I've got a scene heavily using SDF shape descriptions. Each shape outputs 6 different outputs, so now I compute it 6 times passing to the shader numbers from 0 to 5. It would be much nicer to use mutliple outputs and it will bring simply 5x performance boost.

[mrdoob]

@wdanilo It was probably not the right time (many moving things in the renderer at the time). Also, seems like it included the builds which cause conflicts easily. Anyone up for doing a new PR?

/cc @edankwan

[maccesch]

We need 3D Textures and Multisample Render targets.

[elunty]

I'm looking to use it so i can set depthTexture.type = THREE.FloatType.. unless there is another way to currently do such a thing.

[Richard004]

Is there a hope that LineThickness other than 1 would be working on Windows and WebGL 2.0 ? If yes, it would improve some of our outputs.

[Richard004]

And here I reply to myself. Reading thickness-of-lines-using-three-linebasicmaterial on SO I understood that thick lines will need a geometry in the future anyway.

[Mugen87]

@Richard004 This has nothing to do with WebGL 2. We already have a PR for this feature request, see #11349 👍

[erichlof]

Hi @mrdoob and @Mugen87 I need bit manipulations inside the fragment shader as well as dynamic array indexing. The first one is probably not very common, but I need it regardless because I'm trying to port a CUDA kernel over to WebGL (GLSL) and other shader languages allow bit manipulations, but WebGL 1.0 (GLSL) does not.

The second one I think a lot of developers could benefit from: that is, accessing an array element with a variable. Currently in WebGL 1.0 (GLSL), a program like this will fail:

int myData[200];
int x = 3; // 'x' might change later based on my lookup needs
int requestedData = myData[x];

However in WebGL 2.0, you can do this. It is often needed inside a loop, where you need to get different values from an array, but you can't just do an iterative loop (0 to 199 in the example above for instance), because then you would need to check every single element and that's really slow.

[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 :wink:

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