Increasing access
Matrix uniforms are a basic building block for shader work (transforms,
instancing, lighting), but the strands helpers for them are currently
discoverable only by reading the source, and parts of the path fail
silently. Silent failures are hardest on exactly the learners p5.js
serves — a sketch that renders nothing with a clean console gives a
beginner no thread to pull. Documenting and testing these helpers turns
an undocumented internal into a supported, learnable feature, and removes
the need for workarounds like the three-vec3 hack in Renderer3D.js.
Most appropriate sub-area of p5.js?
Feature enhancement details
Other-p5.strands,WEBGPU.
Context: in #8953 (comment: [https://github.com/processing/p5.js/issues/8953#issuecomment-5000277736]) I traced the current
state of strands matrix uniforms on main (8886f4c6e), and @perminder-17
confirmed the uniforms half is a good separate piece and asked for a
scoped issue. The operator/arithmetic side (m * v etc. in
binaryOpNode) is explicitly out of scope here — @perminder-17 is
working on that under #8953.
What exists today (verified empirically):
- The DataType loop in
strands_api.js auto-registers uniformMat2x2,
uniformMat3x3, and uniformMat4x4 from the mat entries in
ir_types.js.
- WebGL:
uniformMat3x3('uM', [...9 floats]) generates a valid
uniform mat3x3 uM; declaration (strands shaders are
#version 300 es), compiles, links, and renders.
- WebGPU: the same call generates a correct
mat3x3<f32> member in the
hook uniforms struct with proper bindings.
- However: zero references in
docs/ or test/ — the helpers are
generated-only, never exercised, never documented.
Proposed scope:
Open questions for maintainers:
- Naming: the registration only produces
uniformMat3x3-style names (no
uniformMat3 alias, since the alias branch covers only vec and
sampler types). Should shorter aliases be added, or is the explicit
NxN form preferred? Happy to follow whichever.
- Should the
p5.Matrix acceptance in setUniform be part of this
issue or split out?
I'd like to fix this myself if approved.
Increasing access
Matrix uniforms are a basic building block for shader work (transforms,
instancing, lighting), but the strands helpers for them are currently
discoverable only by reading the source, and parts of the path fail
silently. Silent failures are hardest on exactly the learners p5.js
serves — a sketch that renders nothing with a clean console gives a
beginner no thread to pull. Documenting and testing these helpers turns
an undocumented internal into a supported, learnable feature, and removes
the need for workarounds like the three-vec3 hack in
Renderer3D.js.Most appropriate sub-area of p5.js?
Feature enhancement details
Other-p5.strands,WEBGPU.
Context: in #8953 (comment: [
https://github.com/processing/p5.js/issues/8953#issuecomment-5000277736]) I traced the currentstate of strands matrix uniforms on
main(8886f4c6e), and @perminder-17confirmed the uniforms half is a good separate piece and asked for a
scoped issue. The operator/arithmetic side (
m * vetc. inbinaryOpNode) is explicitly out of scope here — @perminder-17 isworking on that under #8953.
What exists today (verified empirically):
strands_api.jsauto-registersuniformMat2x2,uniformMat3x3, anduniformMat4x4from the mat entries inir_types.js.uniformMat3x3('uM', [...9 floats])generates a validuniform mat3x3 uM;declaration (strands shaders are#version 300 es), compiles, links, and renders.mat3x3<f32>member in thehook uniforms struct with proper bindings.
docs/ortest/— the helpers aregenerated-only, never exercised, never documented.
Proposed scope:
WebGL backend (
test/unit/webgl/), including the mat2 upload pathadded in Add mat2 uniform support to WebGL setUniform, fixing silent no-op (#8… #8978
test/unit/webgpu/),verifying upload end-to-end (codegen is confirmed correct; the
upload/buffer-layout path is currently untested)
.modify()sketch on both backendsexisting documentation pattern in
p5.strands.jssetUniformaccepting ap5.Matrixdirectly (there is currentlyno
isMatrixunwrapping alongsideisVector/isColor, so onlyflat column-major arrays work)
Open questions for maintainers:
uniformMat3x3-style names (nouniformMat3alias, since the alias branch covers only vec andsampler types). Should shorter aliases be added, or is the explicit
NxN form preferred? Happy to follow whichever.
p5.Matrixacceptance insetUniformbe part of thisissue or split out?
I'd like to fix this myself if approved.