AGI extensions

[emackey]

Hi @vpenades,

I'm not sure if you actually want this, as I might be the only user of it. I guess if someone else out there also wanted to use C# to write glTF models for use in AGI software, they could use it too, but it seems unlikely. But I plan to use it, so it's useful to one person at least. 😄

I managed to get your CodeGen project to read both of the AGI schemas. The rest of the hookup is very bare-bones, no unit tests, docs, or even validation functions, just proof of concept. I want to get a lot farther along on the project that uses this before I commit to really polishing it, as it's all experimental for now.

So if it should just live on a separate branch in my fork for now, that's fine. But if you think it's worthwhile to include, feel free.

Thanks again for all your help in #93, it was very useful to get this off the ground!

[emackey]

it's out of my mind how the khronos board approved it to be hosted in the main repository.

To be clear, the Khronos Board does not approve or ratify any extensions other than those beginning with the KHR_ prefix that are marked "Status: Complete" in the main repo. Other extensions are provided for informative purposes only, they are not officially sanctioned by Khronos.

The EXT_ extensions are agreements between multiple vendors, and typically have some popularity that makes them worthy of inclusion in projects like this, even without official Khronos ratification.

The single-vendor extensions, such as MSFT_ and AGI_ ones, ended up being hosted there as these companies worked on forging the standard in the first place, and decided to publish some of their extensions. Personally I've been having some second thoughts about this, as Khronos has neither the time nor personnel to maintain a curated list of single-vendor extensions, that burden is perhaps better placed on the individual companies. That would make these harder to find and consolidate, but would provide more equal footing for any org that wanted to publish their own extension. But that's an issue for a different repo.

One last comment, KHR_techniques_webgl was intended as a backwards-compatibility bridge from glTF 1.0, but it suffers all of the problems of glTF 1.0. As a result it was never completed nor ratified, it's still "Draft" status. It will likely change to some new status like "Archived" or something and come out of the main extensions folder at some point. So, it can be dropped.

[emackey]

Also ADOBE_materials_thin_transparency has been superseded by KHR_materials_transmission which is ratified now.

[vpenades]

I understand what you mean... the thing is that from the point of view of an outsider who has not bee involved in the conversations and the decisions, the list of extensions hosted in the khronos repository feel like they're "first category" regardless of the prefix, whereas any other extension hosted anywhere else feels like "second category".

But also I like having all extensions hosted in the same repo for simplicity.... so it's a win/loss situation.

I think the way to solve this is to keep hosting these extensions in the khronos repo, but list them in the readme along links to the repos of other extensions "of the same category".

For example, I think that extensions like BLENDER_Physics are far more interesting, but sometimes it's hard to track which public extensions exist, and which are worth to implement.

Actually, I found about BLENDER_Physics a short while ago... and it's been around +3years

[vpenades]

Okey, I think the changes are good to go... let me know if you want to add anything else, or if I do the merge.

Over time, it could be good to have some documentation added, and some unit tests too... actually, I will probably add a users regression test folder.

[emackey]

I think for now this should be stable. If I need more changes I can easily make another branch.

It's still up to you if you really want all this extra stuff in your project, or if it should live in a fork. It's useful for people writing out glTF models for use specifically with AGI software, and with CesiumJS (since I added articulation support to Cesium last year).

Hopefully it's not too obtrusive for the majority of folks who will ignore it. In which case, feel free to merge, thanks!

[vpenades]

As you said, the extension is quite isolated from the rest of the project, in fact, except for the codegen and the changes required to register the extension, it doesn't change anything else, so I think it's safe.