experimental: simplify strands tutorial (flat API, no uniforms, no arrow fns)

[nbogie]

This is an experimental PR to allow us to see how the strands tutorial might look if simplified, and what problems we might encounter in trying that.

Status:

• Uses flat API throughout
• Uses buildXShader instead of base().modify()
• Zero arrow functions (once the placeholder for millis() is removed)
• Removed definition of rand(). Use built-in noise() instead
• fix incorrectly indenting sketches (all code spans need two sacrificial leading spaces)
• All but one* use of uniform replaced with now built-in variables

* Actually, you'll see two uses of uniform remaining:

• a temporary one which serves to provide time (and keep sketches working) until millis() is implemented in strands. (added as a separate commit which can be reverted).

• uniformTexture, used to get the original image into the bloom filter. I don't have a solution for how to remove this one and keep the bloom filter.

• ISSUE: The uniform mechanism being used by uniformTexture is yet to be explained in this branch.

[ksen0]

(Minor note: millis() processing/p5.js#8530 is very close. It is aimed for 2.2.2, which is done except for that PR. So I think it is reasonable to expect millis() to be available in a patch release in the next few days.)

[nbogie]

Ta. (It looks like the build is breaking for unrelated reasons (401))

Update: at build, the site is pre-rendering pages for /sketches/<sketchid>, and to do so has to fetch some details of the sketch from the openprocessing API. These fetches were failing with 401 (possibly getting throttled by openprocessing).

Nothing to do with this PR.

[ksen0]

Hi @nbogie ! Build is fixed and millis() should be in.

[nbogie]

I've incorporated millis() again and stripped out the work-arounds.

The only uniform mention is now for the texture for the bloom filter.

[ksen0]

Hi @nbogie ! I was just thinking about this, is it still in draft stage or can it be ready for review? Is it blocked by anything?

[nbogie]

Perhaps for now just read the updated code and see what you think of that, first, before doing any close review of the prose and explanation? If you are happy with the code, I can then spend more time on the text.

I've deployed it here for convenience.

The intended code simplification is done and tested. The prose needs a proofread.

The main thing I don't like about the status of this PR is because I found we couldn't remove uniforms completely (needed just for the final bloom filter) we still need to address them properly, and I may have broken up that gradual intro by removing earlier examples. For now it is hand-waved in passing, only, as follows (The last sentence (untouched) also needs a re-think):

Now:

At this point, the sketch should look identical. However, we can now use this framebuffer in our bloom shader. We’ll pass this texture data into the shader using a “uniform” variable, with the function uniformTexture. We still want to define the default parameter as a function in order for it to be retrieved after we make the Framebuffer in setup.

Originally:

At this point, the sketch should look identical. However, we can now use this framebuffer in our bloom shader. We do so by creating another uniform, but this time a uniformTexture. We still want to define the default parameter as a function in order for it to be retrieved after we make the Framebuffer in setup.

I can of course add a para about what a uniform is, but if we're going to introduce them at all, it should really be done with a gradual series of examples. And guess what - that's what Luke had implemented, originally!

Perhaps a compromise would be a little para on uniforms like this, asking for the reader's grace on the issue, something like:

This tutorial is long enough, so we're not going to get into uniforms or how this works except to say it's a mechanism to pass data into your shader from your sketch. Strands does this already for you for common variables like mouseX, and width and height, using uniforms behind the scenes, but to pass in custom data (like our texture in this case) you have to set up the passing yourself. For more on passing uniforms in strands, see the reference page X.

(Also, I think that in replacing luke's custom-defined random() function with a use of the built-in noise() function, i've introduced a little bald spot in the animation's particle distribution! Nothing to see here! Best eventual solution would be a adding another random() function snippet to strands that has a uniform distribution and making use of that. The multi-octave noise function is neither uniform nor bound 0-1, I learned.)