multi-material model parts (obj/mtl)#8879
Conversation
| ambientColor: null, // Ka | ||
| specularColor: null, // Ks | ||
| shininess: null, // Ns | ||
| opacity: null, // d |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
+1 Global opacity issue (discussion stage sounds most applicable?)
There was a problem hiding this comment.
hey @davepagurek @ksen0, yeah dropped opacity for now, can open a discussion for the webgl globalAlpha thing
texture i'd keep though, it's per-material and the renderer can actually bind it per part
| } | ||
|
|
||
| if (this._parts.length === 0) { | ||
| this._wrapInSinglePart(); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
thanks @davepagurek for the detailed thoughts here, really helpful
checked the buildGeometry path, you're right, it goes through the same Geometry constructor so it gets wrapped into one part too. works fine, tests pass, good to confirm
i like the first-part-holds-the-data idea. in the renderer follow up i just had the geometry be its own first part (parts = [this]) so there's only one copy, but happy to do the getter + empty-flag way if you prefer it
and agreed on making parts public, renamed it already, and i'll mark direct vertices/faces access deprecated so it keeps working for now but is set to go in 3.0
3 participants
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:
what's in here:
p5.GeometryPart, holds one material's verts/faces/uvs plus its draw statep5.Geometrynow holds parts. single-material models get one part so the shape stays uniformparseMtlreads 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 testabletests:
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.