Skip to content

GSOC 26: multi-material audit, edge cases, and a windows path fix - #9096

Open
Nixxx19 wants to merge 2 commits into
processing:mainfrom
Nixxx19:phase8-audit
Open

GSOC 26: multi-material audit, edge cases, and a windows path fix#9096
Nixxx19 wants to merge 2 commits into
processing:mainfrom
Nixxx19:phase8-audit

Conversation

@Nixxx19

@Nixxx19 Nixxx19 commented Aug 16, 2026

Copy link
Copy Markdown
Member

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:

  • usemtl naming a material the .mtl doesn't define: loads, that group falls back to an empty material instead of throwing
  • the same material used in two separate usemtl groups: collects into one part, since grouping is by name
  • an obj with no vn lines: normals are computed per part
  • an obj with no mtllib: loads as plain geometry
  • a minimal two-material obj: one part per material, every face accounted for

api parity

model() has to behave the same for single and multi-material geometry. added tests for the two cases most likely to break quietly:

  • material state set before model() survives the call, so the next shape doesn't silently inherit the model's material
  • a multi-material model drawn inside buildGeometry() comes through whole

instancing 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.

@p5-bot

p5-bot Bot commented Aug 16, 2026

Copy link
Copy Markdown

Continuous Release

CDN link

Published Packages

Commit hash: b13305c

Previous deployments

b1887cb


This is an automated message.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant