instancedArray.element(x).assign() does not chain correctly, always assigns at instanceIndex under WebGL2 fallback

[LastPhoen1x]

Description

As the title says.
In the following fiddle worker 0 should assign element 1, but it assigns element 0 (it's own index) to the storage array.

Either methods don't chain properly or it writes DataTexture at the wrong coordinates.
Is it possible to fix this behaviour?

Reproduction steps

1. Make instancedArray.
2. Compute Fn() with 1+ workers that assigns values to this array at indexes other than instanceIndex.
3. Under WebGL2 values are assigned at instanceIndex instead.

Code

Fn(() => {
        If( instanceIndex.equal(0), () => { //ONLY if instanceIndex is 0
            posArray.element(1).assign(vec3(1, 1, 1)) //assign to element 1 only
        } )
        })().compute(count)

Live example

https://jsfiddle.net/gmcoh3jz/2/

Screenshots

Version

r177

Device

Desktop

Browser

Chrome

OS

Windows

[cmhhelgeson]

Related Issue: #31221

@LastPhoen1x If you want to look into this, I'd start with https://webgl2fundamentals.org/webgl/lessons/webgl-gpgpu.html which explains how transform feedback works.

[mrdoob]

@RenaudRohlinger 👀

[RenaudRohlinger]

Supporting writes to non-current attributes would introduce significant complexity, as this operation is fundamentally incompatible with the current transform feedback mechanism.

In my previous work (three.js#27661), I added support for reading from external elements using Pixel Buffer Objects. This represented a practical and non-invasive extension of transform feedbacks, one of the few viable paths available without requiring a complete architectural overhaul.

Enabling write access to external elements e.g., through a call like instancedArray.element(x).assign() would necessitate abandoning transform feedback in favor of a full GPGPU approach. This would involve managing dual render targets (textures) and converting the current WebGL compute fallback to a fully texture-based computation pipeline.

Given the imminent mainstream adoption of WebGPU (expected to surpass 90% coverage by the end of the year), I would strongly advise against investing further engineering effort into complex WebGL-specific workarounds at this stage.

[cmhhelgeson]

Enabling write access to external elements e.g., through a call like instancedArray.element(x).assign() would necessitate abandoning transform feedback in favor of a full GPGPU approach. This would involve managing dual render targets (textures) and converting the current WebGL compute fallback to a fully texture-based computation pipeline.

If this is the case then this limitation should probably be documented somewhere. I think there may be (and certainly was on my part) an assumption that the WebGLFallback renderer at least provided equivalent compute/gpgpu capabilities to the WebGLRenderer.

Given the imminent mainstream adoption of WebGPU (expected to surpass 90% coverage by the end of the year), I would strongly advise against investing further engineering effort into complex WebGL-specific workarounds at this stage.

If this is the case, then what is the future of the WebGLBackend for the WebGPURenderer, if any, and should we understand the WebGLBackend to effectively be in maintenance mode, ala the WebGLRenderer, such that the only relevant issues should be bug fixes and not feature requests/architectural changes?