Add methods to construct p5.Geometry from other p5 drawing functions

[davepagurek]

Resolves #5393

Changes

This adds two constructs that can be used to save drawing commands to a p5.Geometry: beginGeometry()/endGeometry(), and buildGeometry(callback).

Here's an example using buildGeometry:

Live: https://editor.p5js.org/davepagurek/sketches/7pbF9zxer

Another example testing some different shape modes and begin/endGeometry:

Live: https://editor.p5js.org/davepagurek/sketches/-MAJP6SWM

This also fixes a bug in the p5.Matrix 3x3 functions, as it was assuming a row-major order of indices rather than column-major, which is what the 4x4 matrix uses.

Future work

• Maybe use WebGL2 transform feedback instead of doing the transformation flattening on the CPU?
• This opens up the possibility of adding stuff like CSG, swept surfaces, etc without tanking performance

PR Checklist

• npm run lint passes
• [Inline documentation] is included / updated
• [Unit tests] are included / updated

[aferriss]

It's a cool example, but it requires a user to know about recursion. Is there a simpler way to demonstrate the feature?

[davepagurek]

I'm going to replace it with a bunch of spheres in a Gaussian distribution cloud, just using a loop instead of recursion: https://editor.p5js.org/davepagurek/sketches/bxXK1bLVp

[aferriss]

Can we update the inline docs here with the same text as in the GeometryBuilder file?

[aferriss]

Should we test that a variety of materials also still work correctly with the builder?

[davepagurek]

This one is a little weird for now because although we support per-vertex fills, we don't yet have support for per-vertex ambientMaterial, specularMaterial, etc. So right now, we can't fully support all material properties, and one would have to make a separate model for each one (similar to how something from loadModel only has global material settings.) I'm not sure just yet what the right way to add support would be, maybe making those properties be optionally per-vertex too, or is that too confusing? In any case, this bit seems like something that probably should be a follow up issue with some discussion first

[aferriss]

I think if the resulting geometry is limited to only being able to use a single material (which probably makes sense), we should note that in the documentation. I'm fine with that limitation and don't think there'd be an easy or scalable way around that anyway.

But even in the case of a single material on the geometry, lets just double check that all the prefab materials (specular, ambient, etc...) are working correctly.

[davepagurek]

Good call, I added a test and noticed an issue! Previously, all fills were getting stored in vertexColors, which override the fill() set before drawing the geometry with model(). We don't have a good way of optionally saying "ignore the vertex colors for this draw" so for now I've added some code to not store the vertex colors if every vertex is the same color.

[aferriss]

Really exciting feature, thanks for putting this together! I also think the solution presented feels simple and easy to understand, but educating users about the existence of this feature and when they should use it seems like an important piece of making it accessible. Part of that will be demonstrating some different use cases, whether that's point clouds, particles, fractals, or whatever else.

It would be good to validate that this is in fact faster than current p5 implementations as well.

Since it's a fairly large PR I think it'd be good to get more eyes here as well. Maybe @aceslowman @kjhollen or @stalgiag can take a look if anyone has time!

[davepagurek]

Here's a performance test for with/without geometry: https://editor.p5js.org/davepagurek/sketches/sgQP9AYzs

The build here includes the current PR, the just-merged one adding contour support, and the line perf improvements in #6230 to give the no-geometry baseline as favourable odds as I can. I get 60fps using geometry, and 16fps without.

[davepagurek]

educating users about the existence of this feature and when they should use it seems like an important piece of making it accessible.

Agreed, I was thinking of editing this tutorial https://p5js.org/learn/getting-started-in-webgl-custom-geometry.html and maybe adding a new example to the p5 site too. I could also add more reference examples maybe? e.g. keep the simpler example with the spheres, but add an additional example with the tree again if that would be helpful?

[aceslowman]

educating users about the existence of this feature and when they should use it seems like an important piece of making it accessible.

Agreed, I was thinking of editing this tutorial https://p5js.org/learn/getting-started-in-webgl-custom-geometry.html and maybe adding a new example to the p5 site too. I could also add more reference examples maybe? e.g. keep the simpler example with the spheres, but add an additional example with the tree again if that would be helpful?

I think editing that tutorial would be a great idea, I'm interested in these new methods so I'll try to experiment with it some over this next week.

[kjhollen]

hey folks, thanks for tagging me on this. I don't think I'll have capacity to do a thorough review in the next few weeks and I don't want to hold things up. @davepagurek @aferriss I think if you're both happy with where things are, we can go ahead and merge this!

[aferriss]

Here's a performance test for with/without geometry: https://editor.p5js.org/davepagurek/sketches/sgQP9AYzs

Thanks for including this. Weirdly on my machine I'm not seeing any difference in fps between the two modes using an intel mac with chrome, but I do see the difference in speeds when using firefox (60fps and 9 fps) and safari (30-40fps and 7-8 fps). Any idea what could be accounting for that?

Agree that updating the learn page would be ideal, but don't think it's blocking for this PR

[davepagurek]

Weirdly on my machine I'm not seeing any difference in fps between the two modes using an intel mac with chrome, but I do see the difference in speeds when using firefox (60fps and 9 fps) and safari (30-40fps and 7-8 fps). Any idea what could be accounting for that?

Interesting, on Chrome on my M1 mac, it goes from 20fps to 60. I think it depends how fast the machine can send data from the CPU to the GPU -- if doing that is slow, then p5.Geometry will have a big speedup since it doesn't need to send that data every frame. (That's also part of the logic behind no longer checking the backface culling state in #6230, since that check is pretty slow on some hardware and browser combinations.) If it's already reasonably fast, then this probably makes less of a difference. I'm not sure why there would be so much of a difference between Chrome and Firefox/Safari though!

Agree that updating the learn page would be ideal, but don't think it's blocking for this PR

I'll make an issue on the p5.js-website repo for this.