quantized_attributes extension

[mlimper]

Preview:
https://github.com/mlimper/glTF/tree/spec-1.0/extensions

This is currently a small draft for very first feedback, nothing ready for merge - just some questions:

• Can this be considered multi-vendor? It's not too complicated to implement, and maybe it helps to push it? But it can also become single-vendor for now, I'm totally open for proposals.
• Do we usually use lowercase letters for extension names (like binary_glTF)? I could adjust the spelling then to "Quantized_Attributes" or "quantized_attributes".

[pjcozzi]

Can this be considered multi-vendor? It's not too complicated to implement, and maybe it helps to push it? But it can also become single-vendor for now, I'm totally open for proposals.

It will need a second implementation to be multi-vendor. We want to implement this in Cesium (assuming there are no IP concerns), but we need to update our glTF loader and tools from 0.8 to 1.0 first. If our intention is to ratify this, we can use the KHR_ prefix. We can ask Khronos if you want.

Do we usually use lowercase letters for extension names (like binary_glTF)? I could adjust the spelling then to "Quantized_Attributes" or "quantized_attributes".

Yes, lowercase like WebGL: https://www.khronos.org/registry/webgl/extensions/

[pjcozzi]

FYI, I just added a new Status section to the template in #413.

[pjcozzi]

This is a good start - will definitionally be a useful extension!

Question: should we keep this scoped to vertex attributes? I imagine the same approach can be applied to animation keyframes as quick-and-dirty compression. I don't think we would want to include that in this extension though since lots of users will just care about attributes.

[mlimper]

there are no IP concerns), but we need to update our glTF loader and tools from 0.8 to 1.0 first. If our intention is to ratify this, we can use the KHR_ prefix. We can ask Khronos if you want.

Oh yes, please. We don't have IP concerns. I'll keep EXT for now until we got a response from Khronos.

[mlimper]

Question: should we keep this scoped to vertex attributes? I imagine the same approach can be applied to animation keyframes as quick-and-dirty compression. I don't think we would want to include that in this extension though since lots of users will just care about attributes.

Oh, good question - so far we were only dealing with static content, and I didn't really check how keyframe animations work with glTF. I guess a keyframe is basically a frozen intermediate state of an animation, meaning it is something like a mesh that shares the same order of vertices / the same indices with other keyframe meshes of the same animation? In that case compression would already be "built in" when compressing vertex attributes... but again, I am just guessing, it would probably make sense to let someone who is familiar with keyframes in glTF give some feedback.

[pjcozzi]

Keyframes are an array of time/TRS pairs (Translation, Rotation, or Scale) that target a node's model matrix. I think the TRS values could be quantized, but I don't think it should be in the scope of this extension since many users will only care about attributes, which is your use case and also the use case I have in mind.

I'll look into the KHR prefix now.

[mlimper]

ok, got that - makes sense.

[pjcozzi]

I looked into the prefix, and KHR is for Khronos members that will be able to put the extension through ratification.

For this extension, we could:

• Leave it as EXT and wait until we have a second implementation before merging this. We are interested in implementing it in Cesium, but we need to do all the other glTF 1.0 work first.
• Create a vendor extension for Fraunhofer (or perhaps Web3D) and use that. It is OK for other vendors to implement a vendor extension, and an extension does not need to go through the EXT stage to be ratified.

[mlimper]

Ok, thanks for checking!

I guess the prefix is not that important to us, it would be more important to speed up the ratification process.

Did I understand correctly that having a WEB3D_ or FHG_ prefix (FHG = "Fraunhofer Society") would potentially lead to a faster ratification than if we would use EXT? If so, I would change the prefix to one of those.

[mlimper]

... besides that, this should be ready for review now.

[pjcozzi]

The extension prefix doesn't impact the speed of ratification. I just meant that, in general, some extensions never get an EXT prefix, e.g.,

VENDOR_ -> EXT_ -> KHR_   or just
VENDOR_ -> KHR_

However, an extension will have multiple implementations before it is ratified even if never asks for the EXT_ prefix.

As for getting this extension ratified, we need to discuss it with Khronos (sorry, I am the tech guy). I'll start that conversation separately.

[pjcozzi]

Wow, this looks really good. I made a few edits and opened a pull request into your branch.

Can you also merge KhronosGroup:spec-1.0 into your branch since there is a merge conflict (probably trivial)?

[mlimper]

Thanks for the quick review - I'll check that tomorrow.

[mlimper]

ok, should be mergable now

[pjcozzi]

I brought your schema fix into spec-1.0 - d057f6f

We should have a second implementation before merging this since it has the EXT_ prefix. We will implement it in Cesium after we do the other glTF 1.0 issues, but let me see if EXT_ can also mean "intend for multiple implementations."

[mlimper]

Sorry, I just realized I pushed the first version of the SRC stuff into my "spec-1.0" branch, so it is now also part of this pull request. In case you want to have a first look:

https://github.com/mlimper/glTF/tree/spec-1.0/extensions/Vendor/WEB3D_SRC

https://github.com/mlimper/glTF/tree/spec-1.0/extensions/Vendor/WEB3D_streaming

I'll put those to separate branches (and open separate pull requests) soon.

[pjcozzi]

Awesome progress @mlimper. To keep discussion organized, can you please open a pull request for each of WEB3D_SRC and WEB3D_streaming?

[pjcozzi]

@mlimper any update?

To keep discussion organized, can you please open a pull request for each of WEB3D_SRC and WEB3D_streaming?

[mlimper]

Sorry for being silent so long - here we go, at least for WEB3D_SRC:
#426

This is a quite verbose proposal, it could probably be shortened... just did the first writeup.

This is now branched from my "spec-1.0" branch, which still contains the changes from this pull request - but maybe that's still not such a big problem, as the WEB3D_SRC extension should depend on EXT_quantized_attributes. There's also still the stub from the WEB3D_streaming extension... I can remove that one soon.

[pjcozzi]

Thanks, will have a look at comment in that PR.

[pjcozzi]

@mlimper if we want to merge this right away, I suggest we rename it to WEB3D_quantized_attributes (since only have one implementation; we want to implement it in Cesium, but haven't gotten to it yet), and then clean up the branch so it includes only this extension.

[pjcozzi]

Also, I added WEB3D as an extension prefix to Prefixes.md since I noticed you are using it in other extensions.

[mlimper]

Here's a clean pull request from dedicated branch, without any other changes:
#444