GSOC 26: multi-material buildGeometry

[Nixxx19]

what

extends buildGeometry() so a model built in code can carry multiple materials, the same way a loaded multi-material obj has since #8879 and #8955.

right now buildGeometry() flattens everything into one geometry, so if you switch texture or material partway through the callback that change is lost. this makes a material change open a new part instead:

let m = buildGeometry(() => {
  texture(wood);
  box(50);      // part 0
  texture(metal);
  sphere(30);   // part 1
});
model(m);       // each part renders with its own material

how

GeometryBuilder snapshots the renderer's current per part material state (texture, specular, ambient, shininess) on each draw, using p5's own state names. when that snapshot changes between draws it opens a new p5.GeometryPart, so the result is a p5.Geometry made of parts exactly like the obj loader produces, and model() draws it per part with no renderer changes.

fill stays baked into vertexColors, so a plain fill() change never splits and per vertex colors keep working. the split only kicks in with 2+ materials, so single material builds are unchanged (zero regression). custom per vertex attributes aren't split per part yet, so those builds stay a single part for now.

this follows the community bonding design: always on splitting (no opt in flag), per field partState in p5's vocabulary, and format translation kept in the import layer.

testing

• a texture change splits the build into 2 parts
• a fill() change alone does not split (stays one part)
• per part materials render the same as drawing them directly (pixel match)
• instancing draws every part with the instance count, so model(geom, n) works per part
• full unit suite green (2255 passing)

part of the gsoc multi-material .mtl work, follows #8879 and #8955.

[p5-bot]

Continuous Release

CDN link

• https://raw.esm.sh/pr/p5@bbb74e1/lib/p5.min.js

Published Packages

• https://pkg.pr.new/p5@bbb74e1

Commit hash: bbb74e1

Previous deployments

8634511

• https://raw.esm.sh/pr/p5@8634511/lib/p5.min.js
• https://pkg.pr.new/p5@8634511

ccfc526

• https://raw.esm.sh/pr/p5@ccfc526/lib/p5.min.js
• https://pkg.pr.new/p5@ccfc526

488b9bd

• https://raw.esm.sh/pr/p5@488b9bd/lib/p5.min.js
• https://pkg.pr.new/p5@488b9bd

e640325

• https://raw.esm.sh/pr/p5@e640325/lib/p5.min.js
• https://pkg.pr.new/p5@e640325

31a0131

• https://raw.esm.sh/pr/p5@31a0131/lib/p5.min.js
• https://pkg.pr.new/p5@31a0131

c7853e8

• https://raw.esm.sh/pr/p5@c7853e8/lib/p5.min.js
• https://pkg.pr.new/p5@c7853e8

fad82ed

• https://raw.esm.sh/pr/p5@fad82ed/lib/p5.min.js
• https://pkg.pr.new/p5@fad82ed

18cdaf9

• https://raw.esm.sh/pr/p5@be18def/lib/p5.min.js
• https://pkg.pr.new/p5@be18def

00783b2

• https://raw.esm.sh/pr/p5@058467f/lib/p5.min.js
• https://pkg.pr.new/p5@058467f

4144e9f

• https://raw.esm.sh/pr/p5@745898f/lib/p5.min.js
• https://pkg.pr.new/p5@745898f

---

This is an automated message.

[davepagurek]

Does this mean we should make a follow-up issue to get custom vertex attributes to work with multi-part geometry?

[Nixxx19]

yeah exactly, right now the per part split doesn't carry custom vertex attributes over (they would need to be reindexed per part), so this keeps the geometry whole when custom attributes are in play

[Nixxx19]

#9077

[davepagurek]

Nice work, this looks good!