Provide API that returns a controller mesh

[cabanier]

To get the controller that is correct for the current hardware, we return a specific name. We then created a repository that contains the assets to render that controller.
OpenXR has an API that returns the mesh. It seems that this would be easier to use than the current workflow and it would also help if a user agent wants to tweak the position of the controller or hand joints.

I believe this was discussed at some point but I don't remember the outcome...
/facetoface

[toji]

One of the primary outcomes of the previous discussion was, IIRC, the concerns were:

• OpenVR had a mesh API but none of the others did at that time.
• We'd either have to spec a new mesh format or have the web platform implicitly "give it's blessing" to an existing one (glTF, USDZ, OBJ, etc).
• Mappings for animations, etc would be complex.
• Size requirements for platforms that were compatible with multiple devices (like desktops) could be significant.
• Depended on browser maintainers to accept and integrate new meshes.

In the end it was decided that an external library would offer ~all the benefits of a mesh API with very few downsides, and thus the webxr-input-profiles library was born. (Thanks again, @NellWaliczek!)

I'd still be interested in reviewing the OpenXR API, but I've actually been quite happy with the adoption that the library has received and don't feel a pressing need to replace it.

[cabanier]

Since the input profiles repository only has gltf, we already gave blessing to that format :-)
As for mappings, we could return the same data.

I guess you're right that there would be more work for browser vendors but given that most are moving to OpenXR backend, they could return a model based on what OpenXR returns.