KhronosGroup / KhronosGroup/glTF

Intended use(s) of mesh primitives

Open
#1,278 4 comments 0 reactions 0 assignees View on GitHub
best practices
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.