Proposal: glTF extension that holds model-viewer settings

[hybridherbst]

So, I've recently explored quite a bit how custom extensions for glTF work, what they can do, etc.
Turns out the principle is easy, the implementation is easy, and it dawned upon me:

Why not solve the "configuration problem" for model-viewer (e.g. specifying which settings per model are right) by including them in a custom glTF extension? This way, each file would bring its own settings.

Cons:

• would mean to have a kind-of-stable configuration of parameters, but I think that point has already been reached

Pros:

• authoring tools (e.g. in our case, Unity, or maybe Blender) could add support to put the parameters into the file
• parameters could still be overriden by putting them in the HTML
• viewing a fully configured model-viewer GLB file would be as easy as dropping the GLB into any supporting model-viewer

This could be a totally custom extension, no need to align with the rest of the industry, but an opportunity to spearhead this kind of in-file "viewer hints". E.g. MODELVIEWER_configuration, or GOOGLE_modelviewer_configuration, or ...

There's a couple of things that need more thought (e.g. HDRs), these could either be as binary in custom bufferViews or referenced by URI (as right now) or use one of the extension proposals for IBL.

What do you think?

[elalish]

It's totally true and we've discussed this before internally. I'd like to see some use cases, personally. I feel like this would only have value as a shared extension if what it describes is generic enough to be implemented consistently by other viewers. In some sense this is the same issue I have with Apple's <model> proposal; that this API is too large and full of arbitrary choices that standardizing it would be a nightmare. Your solution is better in that would be less disruptive and easier to experiment with.

My preferred alternative would be something like a web bundle, using standard HTML, CSS, & JS inside a zip to create a complete experience that is easily embeddable via iframe on any web-surface. No format specification necessary; just a pinned MV version (or any other viewer!) and the appropriate assets. That's the only thing I would trust to be long-term stable and completely extensible. What do you think of that alternative?