GSOC 26: multi-material buildGeometry - #9063
Open
Nixxx19 wants to merge 7 commits into
Open
Conversation
Nixxx19
force-pushed
the
buildgeometry-parts
branch
from
August 9, 2026 17:01
488b9bd to
ccfc526
Compare
This was referenced Aug 9, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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:how
GeometryBuildersnapshots 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 newp5.GeometryPart, so the result is ap5.Geometrymade of parts exactly like the obj loader produces, andmodel()draws it per part with no renderer changes.fill stays baked into
vertexColors, so a plainfill()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
partStatein p5's vocabulary, and format translation kept in the import layer.testing
fill()change alone does not split (stays one part)model(geom, n)works per partpart of the gsoc multi-material .mtl work, follows #8879 and #8955.