[p5.strands] Add methods that are shortcuts to a base shader's .modify() function to simplify creation

[davepagurek]

Right now, to create a shader with p5.strands, we have a lot of brackets, e.g. baseMaterialShader().modify(() => { ... }). It may not be obvious to users that baseMaterialShader() is a function (that's actually more an artifact of its implementation, it probably doesn't need to be) and it's easy to forget the brackets, as I do often! We can maybe make new methods for each base shader that skips that step, e.g. modifyMaterialShader(() => { ... }), modifyFilterShader(() => { ... }), etc.

[Satish-Medar]

@davepagurek I’d like to work on this issue. Could you please assign it to me?

[ksen0]

Hi @Satish-Medar, I've noticed a few requests for contributions on different topics - and I've also seen you've been working on some PRs already. Thank you for your enthusiasm! However, in the future, I'd recommend focusing on one or two issues at a time. Also, before asking to contribute, be sure to read through the issue itself (and discussion if there is any). In this case, this is not yet an accepted proposal, there is still discussion that has to take place before implementation - so this issue is not ready to be assigned for work. You are welcome to share your ideas on any feature requests, how they can be improved, and how they can be implemented, though!

[avinxshKD]

Is anyone currently working on this? If not, I'd like to take it on.

[vietnguyen2358]

@davepagurek
Creating shaders currently requires calling baseMaterialShader().modify(...), which can confuse beginners because it’s easy to forget the () after baseMaterialShader. To simplify this, we’d like to add “bracket-free” helper methods like modifyMaterialShader(...), modifyColorShader(...), modifyNormalShader(...), modifyStrokeShader(...), and optionally modifyFilterShader(...).

These would internally call the corresponding base shader methods and forward to .modify(...), so they act as friendlier entry points while keeping the existing forms for backward compatibility. Do you have any preferences on naming, input style (callback vs. object), or whether additional base shaders should be included?

[davepagurek]

I think all the shaders you've listed are all the publicly extendable shaders, so that list looks complete!

For style of arguments, for technical reasons we need to keep it as a callback function (it's how we can transpile the user's code to allow for things like the + operator between vectors) + an optional second argument with context that needs to be referenced within the callback (because we rewrite the callback, it loses access to outside variables and this is our way to add those back, see #8120 (comment) for a longer explanation.) These are technical constraints on how p5.strands works that we'll have to adhere to so we'll keep the same parameters there. We have a little more flexibility within that callback, and currently we require a separate nested callback for each hook that gets modified, but that can be a future update.

For naming, we have a few precedents that we might want to continue:

• create* prefix, e.g. createMaterialShader(...): used in e.g. createVector, createShader, createCanvas, createGraphics. The downside of this is that we already have a createFilterShader(fragSrc) where you pass in a GLSL string. We'd maybe have to modify that one to still do what it previously did if the argument is a string, and otherwise do the baseFilterShader().modify(...) route.
• build* prefix, e.g. buildMaterialShader(...): currently only used in buildGeometry, but this is another instance where we pass in a callback that is used to incrementally construct an object, just like we would be doing here.
• modify* prefix, e.g. modifyMaterialShader(...): not actually used elsewhere except in the current baseMaterialShader().modify(...).

I think my preference might be for build* to establish a precedent that build* methods in p5 have you pass in a callback, and then it generates something based on that callback? Does that sound ok to you too @ksen0?

[ksen0]

@davepagurek that seems reasonable, I agree that build* as a precedent for this kind of callback usage is a better option than modify* or create*, thanks for the detailed breakdown!

[vietnguyen2358]

@davepagurek For the new build*Shader() methods, should we also add unit tests and update JSDoc? I looked through the test suite but did not find existing tests for base*Shader().modify(() => { ... }), so I wanted to confirm whether similar coverage is expected for these new helper methods. Additionally, should the baseFilterShaderlogic be exposed with the addition ofbuildFilterShader(...)` for consistency, or should we hold off on this implementation for now?