multi-material model parts (obj/mtl)

[Nixxx19]

Part of my Google Summer of Code 2026 project, "Full Texture Support for .mtl Files in p5.js". Works toward #6924.

This PR covers phase 1 and phase 2 of the project: the design and the data + parser foundation that multi-material support is built on. The renderer side (phase 3) follows as a separate PR once this lands. Public API is unchanged across the whole project; everything happens underneath loadModel().

Project phases for context:

• phase 1: design + pipeline study
• phase 2: data model + obj/mtl parser (this PR)
• phase 3: per-part rendering (next PR, already working locally)

what's in here:

• new p5.GeometryPart, holds one material's verts/faces/uvs plus its draw state
• p5.Geometry now holds parts. single-material models get one part so the shape stays uniform
• parseMtl reads the full token set (Kd/Ka/Ks/Ns/d/illum/map_Kd/map_Ka/map_Ks/bump), split into a pure parser so it's testable
• obj faces get bucketed into one part per material with localised verts
• map_Kd textures load onto the part state

tests:

• parseMtl tokens + mtl to part-state mapping (test/unit/io/parseMtl.js)
• geometrypart + single-part wrap (test/unit/webgl/p5.GeometryPart.js)
• multi-material obj splits into the right parts, textures load, a missing texture doesn't fail the load (test/unit/io/loadModel.js)

internally a loaded multi-material model now carries geometry._parts, each a GeometryPart with its own buffers + partState (fill/specular/shininess/opacity/texture). public loadModel/model api is unchanged.

[p5-bot]

Continuous Release

CDN link

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

Published Packages

• https://pkg.pr.new/p5@4598ddb

Commit hash: 962112d

Previous deployments

---

This is an automated message.

[davepagurek]

I think we don't yet have an actual global concept of opacity in our shaders -- we have tint, which can do opacity, but only for textured assets. Maybe worth making an issue for this (something like drawingContext2D's globalAlpha but for WebGL) and not putting too much effort into it here until that's added?

Also, should texture be in here too?

[davepagurek]

Maybe double check, but I assume that since this check is in the constructor, geometry built via buildGeometry will hit this path too and end up having its vertices mapped to a single part.

One thought: maybe we can default to having one part if none have been made yet, and that's where the data lives, and on the geometry itself we just have getter/setters that map to that first part? If we mark it as empty with a flag, then a method to add a part can check for that first and delete the old one if it's the default empty one?

Regardless, we maybe want to make parts a documented thing (so, maybe without the _ prefix on the name) and mark the direct access of vertices.faces/etc deprecated so that it's still there for now, but the expectation is that it's removed in 3.0?