EXT_mesh_primitive_restart

[pmconne]

This extension permits the prohibition against maximal index values in index buffers to be selectively relaxed for groups of primitives, while providing a trivial fallback for implementations that don't support primitive restart. Discussed in #1142.

[lexaknyazev]

@emackey @javagl
What do you think about making this an EXT extension? It seems quite trivial to support it in viewers.

Also since it extends mesh objects, should it be called *_mesh_primitive_restart?

[javagl]

^{Disclosure: I'm an independent contributor, but also a freelancer with a connection to Bentley. I do not speak on behalf of either side here. I also have not yet reviewed this extension proposal on a technical level (only causally watching the comments and discussions).}

Only about the naming:

Whether the prefix is BENTEY or EXT is up do decide for the person who proposes the extension.

(Although some of the extension development process is about to be refined, the section at https://github.com/KhronosGroup/glTF/tree/main/extensions#naming will likely still be kept in a similar form. One addition here might be that the EXT prefix suggests some broad, general applicability or that the extension is not bound to any form of ~"vendor-specific functionality" - but that's very vague...)

The naming section also says

Names SHOULD be structured as <PREFIX>_<scope>_<feature>, where scope is an existing glTF concept (e.g. mesh, texture, image)

It is not entirely clear whether that only refers to top-level elements (somehow related to the point of gltfProperty vs. glTFChildOfRootProperty above), and whether any "sub-element" should be part of the name.

One could make a case to always include the "top-level" element name. Be it at least for the case that someone defines an extension that goes into an animation.sampler, and we want to make sure that it is called EXT_animation_sampler_example, and not just EXT_sampler_example, which would cause an ambiguity with the top-level sampler.

So I'd be leaning towards _mesh_primitive_restart here.

[pmconne]

Whether the prefix is BENTEY or EXT is up do decide for the person who proposes the extension.

If there's no objection, I will push a change to rename the extension to EXT_mesh_primitive_restart and assign the copyright to Khronos.

[bghgary]

Should we just name it KHR_ directly? We have already ratified some EXT_ extensions and wasn't able to rename to KHR_ due to compatibility. Would we ever consider ratifying this extension?

[lexaknyazev]

Should we just name it KHR_ directly?

We'd have to get an agreement within 3DF WG first and commit to providing Sample Assets at least.

[pjcozzi]

Should we just name it KHR_ directly?

We'd have to get an agreement within 3DF WG first and commit to providing Sample Assets at least.

@lexaknyazev @bghgary any update on this? Or any additional feedback for @pmconne?

[aaronfranke]

The feature makes sense as an optimization when this is supported, and adds minimal data, while keeping the same visual appearance. However, I am curious, what prevents importers from doing this implicitly instead of checking for this explicit extension? I guess it would be complicated to check for mostly-identical primitives of the right topology type not used by morph targets.

[pmconne]

what prevents importers from doing this implicitly instead of checking for this explicit extension?

An importer that sees multiple line/triangle strip primitives all using the same vertex attributes could conceivably batch them together to be drawn using primitive restart, but that would require extra work on the importer's part to detect this and then rebuild the index buffer accordingly, whereas the extension ensures that the index buffer is already laid out for primitive restart.

[emackey]

Looks good to me.

[emackey]

@lexaknyazev @javagl @bghgary Anything else for this PR before it gets merged?

[bghgary]

Did we discuss whether this should be KHR or EXT? Should there be a sample model that uses it?

These are not blocking though. I'm fine with merging regardless.

[emackey]

Did we discuss whether this should be KHR or EXT?

I don't think it came up in the WG. I'm fine with EXT, unless there's some strong desire to ratify this I'm not aware of.

Should there be a sample model that uses it?

That would be great, but it's a separate PR into the sample asset repo, so shouldn't hold this up.

[pmconne]

What can I do to help get this over the finish line?

[pmconne]

We have implemented this extension. Please let me know what if anything is required before this can merge.

[weegeekps]

@lexaknyazev Are there any other changes you'd like before we merge?

[lexaknyazev]

@weegeekps Please confirm the copyright info. If it's fine, feel free to merge.

[lexaknyazev]

@weegeekps All checked-in files must have SPDX copyright headers. The question was who is the owner in this particular case.

[weegeekps]

@lexaknyazev My mistake. I've opened a new PR to correct this: #2533