WebGL2: Added support for Uniform Buffer Objects.

[Mugen87]

This PR enables the usage of Uniform Buffer Objects for ShaderMaterial and RawShaderMaterial with WebGL 2. Users who build their own materials can use UBOs in order to manage global uniforms like camera or lighting related data more efficiently.

WebGLUniformBlocks encapsulates most parts of the UBO related code. The changes to WebGLRenderer are straightforward. At some point, upcoming build-in materials might also use WebGLUniformBlocks.

Related: #13700

[mrdoob]

Looking good! How about UniformsGroup as naming instead?

[Mugen87]

BTW: Thanks to @Alejandro_Insua from the forum for already testing this feature 👍

[Mugen87]

How about UniformsGroup as naming instead?

I've realized that we already have UniformsUtils so UniformsGroup is indeed a more consistent name.

[takahirox]

Honestly I don't think spoiling uniform with __xxx properties is a clean approach. But I think it's ok so far. Let's clean up later if necessary.

[Mugen87]

May I ask why you don't like this approach?^^

[takahirox]

For example, those properties are unnecessarily exposed to other modules which can access uniform (tho the property names begin with __ indicating it's private).

[fernandojsg]

Nice job @Mugen87 with this one. One probably obvious question that probably must be addressed in another PR instead of this one, is what about adding uniform support to the standard materials as most of the devs will be using them instead of custom ones, so we could really get the benefits of UBO in all the apps around

[takahirox]

He mentioned

At some point, upcoming build-in materials might also use WebGLUniformBlocks.

I'm making a test evaluating the performance if built-in material supports UBO. I'll share the result later.

[fernandojsg]

Ops I totally misread that part :D

[Mugen87]

is what about adding uniform support to the standard materials as most of the devs will be using them instead of custom ones, so we could really get the benefits of UBO in all the apps around

You are right, that's of course the long-term goal^^. But let's do it step by step. This PR should be (hopefully) a good basis for further enhancements. And we enable devs like @Alejandro_Insua to use UBOs in their custom shaders.

[takahirox]

Do you think some users may want to change the name runtime?

If I understand correctly name is required. And if we can think it's immutable, what do you think of taking name argument as constructor parameter and removing .setName()?

var group = new THREE.UniformsGroup( 'ViewData' );

[Mugen87]

Do you think some users may want to change the name runtime?

Maybe, although that would actually not make sense. It's like adding uniforms at runtime which would also be an invalid operation. Still, I think the current interface is cleaner than defining everything as ctor parameters.

I consider UBOs as an advanced WebGL feature so the API does not need to be foolproof from my point of view^^

[takahirox]

I commented some stuffs but I don't think they are big deals. Maybe we can enhance, optimize, and clean up later if needed. This PR is looking good as initial UBO support.

[takahirox]

I'm evaluating the performance. One feedback so far. Calling gl.getUniformBlockIndex() and gl.uniformBlockBinding() for every object every frame seems high cost. With the current implementation using UBO is slower here than using regular Uniforms.

[takahirox]

Hi, we Mozilla Hubs wants UBO in Three.js. If the conflicts are resolved, can we get this PR merged? Or is there anything blocking this PR other than the conflicts?

[Mugen87]

@takahirox I've created a new PR (#21558) since a lot of things have changed over two years.