attributeArray.element(x) always returns current element

attributeArray.element(x) returns [instanceIndex] element always. In fact it does not care about parameters at all, you can write attributeArray.element() it will do the same. Or even just attributeArray.

const count = 2
const posArray = attributeArray(new Float32Array(count * 3), 'vec3')
posArray.setPBO(true);

for (let i = 0; i < count; i++)
    posArray.value.array[i*3] = i+1 //so every vector has x set as it's position +1

const computeWithoutChanges = Fn(() => {
        const pos = posArray.toVar() //take element at index
        posArray.element(instanceIndex).assign(pos) //assign to all elements
    })().compute(count)

console.log("Array before: " + posArray.value.array) //array before compute is just fine

const renderer = new THREE.WebGPURenderer()
renderer.computeAsync(computeWithoutChanges)
        .then(() => renderer.getArrayBufferAsync(posArray.value))


        .then((buffer) =>
        console.log("Array after: " + new Float32Array(buffer)))

why no assign
posArray.element(1).assign(vec(1, 1, 1)) //explicitly asking to assign element 1
floods the array
why assign

In flocking example attributeArray.element is used liberally to access arbitrary elements of the buffer, what am I doing wrong?

EDIT: Can anyone confirm the example here three.js examples is working properly? For me with webgl2 fallback birds just converge in the center, no boid behaviour applied.

I was experiencing the exact same issue. It appears to be specific to the WebGL backend, as everything works as expected with WebGPU.

I’ve submitted an issue and believe it’s likely just a minor fix.

3 Likes

Whew, I thought I was going mad here… well, I do, but at least this problem is not related to that.

Was thinking about making a bug report myself, but you saved me the trouble.

4 Likes

Same here :sweat_smile: . It took me half a day to realize it was actually a bug.

4 Likes

Turns out it’s not a bug, it’s a feature!

As @sunag pointed out, we need to call .setPBO(true) for it to work. That makes sense, given that WebGL doesn’t support compute shaders and requires texture uploads in this case.

3 Likes

Still don’t get why it does not work with attributeArray, unless it is not supposed to. But it does on WebGPU?

Can anyone who has WebGPU-enabled browser run this fiddle and post the results? I do not have access to such thing at the moment.