automatic rewrite of custom functions in Strands

[Orsenna187]

Increasing access

Make p5.strands more intuitive.

Most appropriate sub-area of p5.js?

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

Feature enhancement details

From the original Discord discussion:

Orcé:

Hi there!

I'm going through the strands introduction. First off, let me say that p5.strands is an awesome idea and a huge improvement on the previous ways of using GLSL with p5.js.
That said, I'm running into issues with creating reusable functions for strands.

Looking at this example from the intro:
function instancingCallback() {
// a pseudorandom function from:
// https://stackoverflow.com/questions/4200224/random-noise-functions-for-glsl
function rand(seed) {
return fract(sin(dot(seed, [12.9898, 78.233])) * 43758.5453123);
}

fract(sin(dot(seed, [12.9898, 78.233])) * 43758.5453123); seems like a very useful function to put in a utils library. I'm probably going to use it over and over again. However, defining a rand() funtion elsewhere and trying to call it within the callback sends an error:
Uncaught (in promise) TypeError: Failed to execute 'useProgram' on 'WebGL2RenderingContext': parameter 1 is not of type 'WebGLProgram'.
I assume this is because the code within the callback gets transpiled to GLSL without resolving the reference to the rand() function?

Before I embark into some metaprogramming shenanigans, is there a recommended way to extend p5.strands? Is there a prototype somewhere on which we can define additional functions etc?
I apologize if this is in the doc somewhere, couldn't find anything about this topic.

dave:

hey! so currently there isn't exactly. I'll go into why briefly in order to explain how a workaround for now could work, and how we can then make this a real thing in the future.

So in JavaScript, you can't actually do a + operator between anything but strings and numbers. In order to do it for vectors, we actually have to rewrite your js for you. if you put a debugger statement in your random function, and then run your code with the debugger open, you'll notice the code looks a little different. First, instead of square brackets making a vector, it uses a vector constructor. Second, operators like the multiplication operator turn into a method on the vector, like .mult(). We only rewrite the code in your callback function, which is why currently it doesn't work when you extract it into another file.

So a potential workaround for now is to write your helper function the way it would look without any of those shortcuts that we rewrite (so, using vec2(a,b) instead of [a,b], and using methods like .mult instead of the * operator.)

But as you've noticed this is pretty unintuitive so it would be great to have a real way to do this! Some thoughts:
We're adding some common things like random and noise into p5 core (e.g. #7921) If something is common enough, it could be worth adding for everyone in this way.
We could let you explicitly define strands helpers. We could make a function like rand = strandsHelper(function() { ... }) that applies the preprocessing to your helper even though it doesn't live inside your callback.
More effort, but we could detect calls to external functions in your callback and rewrite them too. This would have to be recursive (those functions could call other functions) and might mean having to deal with scope issues. So it's harder for us, but could mean everything just works for users without having to change anything.

[welcome]

Welcome! 👋 Thanks for opening your first issue here! And to ensure the community is able to respond to your issue, please make sure to fill out the inputs in the issue forms.

For guidance on contributing, check out our contributing guidelines and other resources for contributors.
💬 If you have questions or need support, feel free to join the Processing Foundation Forum or visit our Community page.
📜 Please also review our Code of Conduct to understand our community standards.
Thank You!

[ShaunakMishra25]

I’m interested in working on this issue (#7953) as part of my GSoC 2026 preparation. I plan to implement the get() method for the p5.Color class to support retrieving color values in RGB, HSL, HSB, and other formats, with optional alpha handling. Are there specific guidelines or preferences for this implementation (e.g., alignment with p5.js 2.0 or existing p5.Image.get())? I’d also like to confirm if this issue is suitable for GSoC contribution.

[davepagurek]

Hi @ShaunakMishra25! Are the color/image get() methods related to this issue or are those for a future planned GSoC project?

This issue can definitely be worked on, although I think we need some discussion first. I was looking more into the idea of automatically converting any function referenced inside of a p5.strands callback. However, I was running into an issue while adding instance mode support for p5.strands in #7961: when we parse a strands callback, it doesn't have access to local variables outside of the function. This is a pretty fundamental JS limitation that can probably only be overcome if we parse the entirety of a sketch, which gets hairy (some users use bundlers, TypeScript, module scripts, multiple files, etc, and we'd have to handle all those cases, and parse times can get long.)

So we may unfortunately not be able to do this fully automatically. However, we can definitely still give users way to augment p5.strands! Originally I suggested a thing to wrap functions in, like:

const myHelper = strandsHelper(function (a) {
  return sin(a) + 5
})

...but @Orsenna187 also suggested some other valid formats, e.g. you could attach helpers to a special object whose keys we convert in presetup or something, so users would write:

p5.strands.myHelper = function(a) {
  return sin(a) + 5
}

Note though that the same limitation on variable scope still applies to helpers! So they'd be able to access any other helper, but this would not work:

const five = 5
const myHelper = strandsHelper(function (a) {
  return sin(a) + five // five is not actually in scope of the rewritten function!
})

The workaround I've gone with so far is to have you manually pass in variables from the outside that you need in an object. So using the same paradigm here, that would look like:

const five = 5
const myHelper = strandsHelper(function (a) {
  return sin(a) + five
}, { five }) // By passing five in here, you can now use it in the helper

[ShaunakMishra25]

Hi @davepagurek! I apologize for the confusion in my previous comment. I mixed up two different features I was interested in.

I would like to work on THIS issue (#7953) - making p5.strands more intuitive with reusable helper functions. The color get() methods I mentioned were for a different issue I was considering.

For this p5.strands issue, I'm interested in implementing the strandsHelper() approach you suggested. Could you guide me on:

1. Where to find the current preprocessing code?
2. How to extend it for helper functions?
3. The best way to handle the variable scope limitations?

Thanks for clarifying the technical constraints!

[davepagurek]

Currently the code that does the preprocessing is in the middle of some other stuff in src/webgl/ShaderGenerator.js, but @lukeplowden is in the process of refactoring that file, at which point there will be a nice function you can use to do just the preprocessing. So it might make sense to wait a few days for him to finish that up?

For the API we create, it's true that when making addons, we generally assign functions to special objects, so it might make sense to opt for assigning to p5.strands (which doesn't exist yet and would have to be created), and then add a lifecycles.presetup hook in ShaderGenerator.js to transpile all functions assigned to p5.strands.

To handle the variable scope things though, we would probably still need a wrapper function to pass in context variables using a method similar to what I've been doing in #7961. Maybe the first step here is to see if there's a nice compromise API where we still register hooks by assigning to something, but can optionally also use a wrapping function to pass in context? I'd love to hear any ideas you or @lukeplowden or others have!

Also just a heads up, I'm going to be out of town for a few days, so I'll reply again early next week 🙂