GSOC 26: multi-material audit, edge cases, and a windows path fix - #9096
Open
Nixxx19 wants to merge 2 commits into
Open
GSOC 26: multi-material audit, edge cases, and a windows path fix#9096Nixxx19 wants to merge 2 commits into
Nixxx19 wants to merge 2 commits into
Conversation
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.
the audit pass from the end of my gsoc proposal. it treats the multi-material work as a black box and tests the assumptions made while building it, rather than adding features.
a real bug, fixed
mtl files exported on windows can write texture paths with backslashes (
map_Kd textures\cat.jpg). we passed those straight into the fetch, so the request went out with a literal backslash and never resolved. they're normalised to forward slashes now. this was the one thing in the audit that was actually broken.edge cases, now covered
each of these had no test before. all of them already behaved correctly, so these lock the behaviour in:
usemtlnaming a material the.mtldoesn't define: loads, that group falls back to an empty material instead of throwingusemtlgroups: collects into one part, since grouping is by namevnlines: normals are computed per partmtllib: loads as plain geometryapi parity
model()has to behave the same for single and multi-material geometry. added tests for the two cases most likely to break quietly:model()survives the call, so the next shape doesn't silently inherit the model's materialbuildGeometry()comes through wholeinstancing was already covered.
performance
benchmarked identical geometry split 1 way vs 12 ways, 60 copies per frame, uncapped on a real gpu. the 12-part version runs about 12% slower, which is over the 10% line i set in the proposal, so i dug into whether that's the per-part bookkeeping or just the extra draw calls.
holding the draw count equal answers it: 60 draws of the 12-part model (720 draws) runs at 49.2 fps, while 720 draws of a 1-part model runs at 47.0. the multi-material path is slightly ahead, so the 12% is the draw calls themselves and not the buffer cache lookup or anything the per-part path adds. one
model()call covering 12 parts is cheaper than 12 separate calls.new fixtures are all small and deterministic. full webgl and webgpu suites pass.