KhronosGroup / KhronosGroup/glTF
Intended use(s) of mesh primitives
- Dominant language
- HTML
- Stars
- 7.8k
- Forks
- 1.2k
- Avg merge
- 17h 26m
- Merged PRs (30d)
- 5
Description
For the three.js glTF exporter, @takahirox has proposed a change that allows us to export multi-material meshes efficiently: https://github.com/mrdoob/three.js/pull/13536. It raised some questions for me about how to load primitives in three.js, there were more possible use cases than I had thought of:
1. Each primitive points to different attribute accessors, but share a material. Use case mentioned in the spec would be to "limit number of indices per draw call", and engines might very reasonably choose to merge them into one draw call.
2. Each primitive points to different attribute accessors, and different materials.
3. Each primitive points to the same attribute accessors, but different indices, and all use a single material. Again the purpose is probably to limit number of indices per draw call, but engines wishing to merge draw calls should concatenate indices rather than vertex attributes.
4. Each primitive points to the same attribute accessors, but different indices, and different materials.
5. A single mesh arbitrarily combines all of the above.
6. Multiple meshes, each with 1 primitive, use the same attribute accessors to represent attributes of a single mesh with different materials.
I'd only been thinking of cases (1), (2), and (6) and was pretty close to writing code that would have been very inefficient with (3) and (4), so thought I'd open an issue here.
Anyone else have loaders or exporters making particular assumptions about this question? I don't necessarily think any spec change is needed, just wanted to get a better idea of what to expect and how to be consistent here.
Somewhat related to https://github.com/KhronosGroup/glTF/issues/1249.
Contributor guide
Research direction
Start by reading the glTF mesh primitive specification alongside the use cases listed here, then review the related issue #1249 and three.js PR #13536. Compare the assumptions made by the referenced loader or exporter approaches and determine whether the expected handling should be clarified in the specification; done means an agreed interpretation or documented change.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- three.js
- Domain
- computer-graphics
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100