WebGPURenderer: Relocate VAO handling in WebGLBackend

[aardgoose]

Associating the VAO with the WebGL pipeline causes the wrong attributes to be used in a draw call when materials are shared.

A previous PR added geometry id as an element to the pipeline cache but that has the side effect of excessive shader program compilations etc.

Move the VAO creation into a separate method and cache against the renderObject. This aligns more with the WebGPU backend.

With the previous PR enabling video textures this enables the example 'material / video' to work correctly with the WebGL backend

[sunag]

I had to rebase to add support for InterleavedBufferAttribute to the existing code...

Would you have an example to reproduce the bug?

One of the reasons I delayed the merge of the previous PR was the geometry.id, other thing is that NodeMaterial can also add anonymous attributes. I think it's better to improve the caching system instead of bringing this logic to the draw().

[aardgoose]

The addition of the geometry.id in the previous PR solves the problem in the occlusion example where both objects use the same material and the second object gets the VAO from the previous object unless they use different pipeline objects.

I spotted the problem of additional non geometry attributes so I cached VAO by RenderObject rather than using geometry.id in this PR. I still think the draw call is the correct place because it should allow pipelines to be used for multiple objects. Attributes are set up per draw call in the WebGPU equivalent code.

[sunag]

The problem is that this is not passing through the cache logic, I agree with you about geometry.id and I explained in the comment above, other reasons, I think replacing renderObject.geometry.id with renderObject.id in getCacheKey() could give the same result provisionally and saves this check in draw(), I would merge this if it works until we improve the cache.

If we follow that each RenderObject will have a VAO independent, we will never have shared VAO, as we have a RenderObject for each Mesh, regardless of whether it has the same Geometry and Material.

[aardgoose]

I have finally worked what problem this addresses. The webgpu_materials_video example required a new gl.linkProgram() for each cube rendered, although only two shader objects were created (vertex and fragment) which results in a noticeable delay when starting the video.

I agree ideally vaos would be cached by something that captured the combination of geometry and material generated attributes.