[p5.js 2.0+ Bug Report]: `get()` can only be used on storage buffers

[eupthere]

Most appropriate sub-area of p5.js?

• Accessibility
• Color
• Core/Environment/Rendering
• Data
• DOM
• Events
• Image
• IO
• Math
• Typography
• Utilities
• WebGL
• WebGPU
• p5.strands
• Build process
• Unit testing
• Internationalization
• Friendly errors
• Other (specify if possible)

p5.js version

2.2.3

Web browser and version

Chrome 147.0.7727.137

Operating system

MacOSX 26.4.1

Steps to reproduce this

Steps:

1. Create a WebGPU sketch that uses buildComputeShader().
2. Inside the compute callback, define a helper function that returns an array, for example return [1, 2].
3. Read from that returned value using computed indexing like arr[0].
4. Call buildComputeShader(errorCallback) and then try errorShader.inspectHooks().

Snippet:

let shader;
let errorShader;
let storage;
const COUNT = 10;

async function setup() {
  await createCanvas(400, 400, WEBGPU);
  noLoop();
  background(100);
  storage = createStorage(new Float32Array(COUNT));

  shader = buildComputeShader(callback);
  shader.inspectHooks();
  console.log("======Compute shader source:======");
  console.log(shader.computeSrc());
  console.log("================================");
  
  errorShader = buildComputeShader(errorCallback);
  errorShader.inspectHooks();
  console.log("======Error shader source:======");
  console.log(errorShader.computeSrc());
  console.log("================================");
}

function errorCallback() {
  let data = uniformStorage(storage);
  function getArray() {
    return [1, 2];
  }
  let arr = getArray();
  data[index.x] = arr[0] + arr[1] + index.x;
}

function callback() {
  let data = uniformStorage(storage);
  function getNumber() {
    return float(index.x);
  }
  let num = getNumber();
  data[index.x] = num;
}

async function draw() {
  compute(shader, COUNT);
  const data = await storage.read();
  console.log(data);
}

Console error:

Uncaught (in promise) Error: get() can only be used on storage buffers

Expected behavior:

buildComputeShader(errorCallback) should either:

• support indexing into a helper-returned array/vector-like value, or
• fail with a clearer compile/transpile error explaining that this pattern is unsupported.

It should also ideally still be possible to inspect the generated hooks/source for debugging.

Actual behavior:

buildComputeShader(errorCallback) throws before errorShader.inspectHooks() can run, so the shader is never returned and its generated source cannot be inspected.
The scalar-return version works:

function getNumber() {
  return float(index.x);
}

but the array-return version fails when indexing the returned value with arr[0].

Additional notes:

From local repo inspection, this looks like a p5.strands transpilation issue rather than a WGSL compile error:

• array literals are transformed into strands values
• computed indexing like arr[0] is rewritten into .get(0)
• .get() currently appears to only work for storage buffers

So the bug seems to be specifically that non-storage array/vector indexing is being routed through the storage-buffer access path.

[SOUMITRO-SAHA]

Hi! I'd like to work on this issue if no one else is already on it.

I spent some time digging into the p5.strands transpilation pipeline to understand what's happening. Here's what I found:
The MemberExpression handler in strands_transpiler.js converts all computed access arr[0] into .get(0), regardless of the target type. Then StrandsNode.get() in strands_node.js checks nodeData.baseType !== 'storage' and throws for anything that isn't a storage buffer.

The good news is that the WGSL backend (strands_wgslBackend.js) already handles the ARRAY_ACCESS opCode generically, generating ${bufferExpr}[i32(${indexExpr})] which is valid WGSL for both storage buffers and vectors. So the backend is ready, it's just the get() method that gates it behind a storage-only check.

I think the fix is straightforward: modify get() to remove the storage-only guard and keep the struct proxy path as a conditional branch (only for storage buffers with a schema). This would let arrayAccessNode work for non-storage vectors/arrays too. The change would be limited to src/strands/strands_node.js,

Would this approach make sense? Happy to hear any feedback before I start working on it.

[davepagurek]

I think allowing [] index access on vectors would be ok (this could be for both webgl and webgpu modes). One question for other contributors (cc @perminder-17, @aashu2006, @Nixxx19, @LalitNarayanYadav and others if you have opinions!) is whether we think it's still the right call to have all arrays turn into vectors. I think overall it's still by far the most common thing you'd be doing in a shader, but I can imagine it being confusing that if you use arrays like in the snippet here, that it won't work if you add a fifth element in the array, because it is not actually an array under the hood, it's a vec4.

Possibly the thing to do is make array index access work for vectors and make sure we give an informative error message if you try to make an array with length > 4?

[LalitNarayanYadav]

Thanks for the detailed breakdown, very helpful to have the root cause already mapped out.

I agree with the proposed direction: keep array literals as vectors, fix get() to
remove the storage-only guard, and add an explicit transpile-time error for invalid
lengths. A few refinements worth considering before the PR goes up:

---

strands_node.js - narrow the guard, don't just remove it

Rather than deleting the storage check entirely, I'd suggest replacing it with a
narrower condition so struct-backed buffers still take the existing path:

get(index) {
  if (this.baseType === 'storage' && this.schema) {
    return this._getFromStruct(index);
  }
  return new StrandsNode({ op: 'ARRAY_ACCESS', args: [this, index] });
}

The WGSL backend already emits expr[i32(index)] for ARRAY_ACCESS, which is valid
for vectors, temporaries, and storage buffers alike, so the restriction was always
artificial.

---

strands_transpiler.js - enforce 2–4, not just ≤ 4

WGSL has no vec1, so the lower bound matters too. In the ArrayExpression visitor:

if (len < 2 || len > 4) {
  throw new Error(
    `Array literals in shader functions are transpiled to WGSL vectors ` +
    `and must have 2–4 elements (got ${len}).`
  );
}

Including the actual length in the message makes the error immediately actionable.
Attaching node.loc would improve DX further if that pattern is used elsewhere in
the transpiler.

---

Tests - one additional case worth adding

The two obvious cases (regression fix + length guard) are right, but there's a third
that validates the full pipeline:

// inline literal indexing — no named variable
[1, 2][0]

This ensures .get() isn't accidentally scoped to named variables only, and that the
AST → node → backend path works end-to-end.

---

[aashu2006]

@davepagurek @eupthere

keeping the arrays mapped to vectors makes sense, since that’s the most common shader use case and keeps things simple.
Allowing the [] indexing on vectors would fix the current issue in a natural way.

and yes also, giving a clear error if the array length exceeds 4 sounds like a good way to avoid confusion while still supporting typical cases.

[SOUMITRO-SAHA]

Thanks for the feedback @davepagurek , and great refinements @LalitNarayanYadav

I agree with the direction. To summarise the approach based on everyone's input:

1. Fix get() in strands_node.js: Narrow the guard so struct-backed storage buffers keep their existing path, but allow arrayAccessNode to work for non-storage vectors too. This covers both WebGPU and WebGL modes.

2. Add array length validation: In the ArrayExpression handling, throw a clear error if the array length is outside 2-4 (since WGSL has no vec1 and max is vec4). The error message should include the actual length so it's immediately actionable (as @aashu2006 suggested).

3. Tests: Cover the regression fix (helper function returning an array, then indexing), the length guard error, and the inline literal case [1, 2][0] to validate the full pipeline end-to-end.

@davepagurek @LalitNarayanYadav @aashu2006 does this sound right?

Would you be open to assigning this to me? I'd like to start working on it.

[LalitNarayanYadav]

Yes, that summary looks right to me. Good luck with the implementation.

[Nixxx19]

nice breakdown @SOUMITRO-SAHA, plan looks solid to me. one thing i ran into while poking around the backends though, figured i'd flag it before the PR goes up:

WGSL handles ARRAY_ACCESS fine (it's hooked up in src/webgpu/strands_wgslBackend.js at lines 328 and 507), but the GLSL backend doesn't actually have a branch for it anywhere. so it'd fall into the generic binary path which does ${left} ${opSym} ${right}, and OpCodeToSymbol[14] is undefined cause ARRAY_ACCESS isn't in OperatorTable in ir_types.js. so we'd just be spitting out broken glsl in webgl mode the moment someone writes arr[0].

basically once get() stops checking for storage, webgl breaks silently even though the issue itself is tagged webgpu. probably worth adding an ARRAY_ACCESS branch in strands_glslBackend.js (similar to how MEMBER_ACCESS is done at line 314) that just emits ${left}[${right}], otherwise the fix only really lands on one backend.

other than that +1 to @LalitNarayanYadav's 2-4 length check and the inline literal test, both feel pretty necessary.
happy to help out if anything's needed, best of luck with the pr!

[aashu2006]

good catch on the WebGL side @Nixxx19, that makes sense the ARRAY_ACCESS would need handling there as well once the guard is relaxed.

overall this direction looks solid to me 👍

[SOUMITRO-SAHA]

nice breakdown @SOUMITRO-SAHA, plan looks solid to me. one thing i ran into while poking around the backends though, figured i'd flag it before the PR goes up:

WGSL handles ARRAY_ACCESS fine (it's hooked up in src/webgpu/strands_wgslBackend.js at lines 328 and 507), but the GLSL backend doesn't actually have a branch for it anywhere. so it'd fall into the generic binary path which does ${left} ${opSym} ${right}, and OpCodeToSymbol[14] is undefined cause ARRAY_ACCESS isn't in OperatorTable in ir_types.js. so we'd just be spitting out broken glsl in webgl mode the moment someone writes arr[0].

basically once get() stops checking for storage, webgl breaks silently even though the issue itself is tagged webgpu. probably worth adding an ARRAY_ACCESS branch in strands_glslBackend.js (similar to how MEMBER_ACCESS is done at line 314) that just emits ${left}[${right}], otherwise the fix only really lands on one backend.

other than that +1 to @LalitNarayanYadav's 2-4 length check and the inline literal test, both feel pretty necessary. happy to help out if anything's needed, best of luck with the pr!

Good catch @Nixxx19 , thanks for flagging that. You're right, without the ARRAY_ACCESS branch in the GLSL backend it would just fall through to the generic binary path and output undefined as the operator since OpCodeToSymbol[14] doesn't exist in OperatorTable.

I've added it to the plan now. The fix will include an ARRAY_ACCESS handler in strands_glslBackend.js after the SWIZZLE handler (following the same pattern as MEMBER_ACCESS at line 322), emitting ${bufferExpr}[${indexExpr}] without the i32() cast since GLSL doesn't need it.

I'll also make sure to test both WebGL and WebGPU modes before submitting the PR. Appreciate the heads up!