[Specification] XR_MSFT_controller_model de-branding and enhancement.
Reahreic opened this issue · 7 comments
The current 'Microsoft' extension to the spec should be de-branded in favor of a device vendor agnostic series of API calls. As it currently stands this extension to the specification can be construed as only supporting Microsoft based OpenXR device model data. Leading device vendors to implement their own proprietary model API's/extensions, or for app developers to hack together custom code to fingerprint and support non-Microsoft device models.
If future-proofing, and anti-fingerprinting practices are to be honored, I recommend the core spec include the capability for users to request device model data with a minimum of two levels of detail. The mechanism for this can leverage the current extension, but should include an API call to query the number of available LOD's prior to requesting a model's data stream using one of the returned LOD indices.
Further discussion on the nature and feature set of the device model should be conducted with the results then included into the specification. This model fidelity/functionality guidance will be crucial in building trust in the model data supplied by the API and allows developers to request models at runtime based on need and functionality. EG: Static models for display purposes, Animated models that can respond to user inputs such as thumbstick movement, and Materials that can be manipulated.
That said, if the intended purpose of the spec isn't to supply the 3d model of the hardware in use. Then the spec should allow the developer to determine the specific device in use through granular vendor, and product name data dropping this vendor specific customization of the specification.
I very much agree with everything. We are currently implementing OpenXR in our application and we miss the very easy controller integration of OpenVR where we would get everything from models to animations of the buttons.
The developers shouldn't have to worry about finding the controller models that the customers are using. Because they will have to use a ready-made model which might come with its own legal issues.
I believe that OpenXR should come close to what OpenVR was having but find a scalable way for the controller model supply e.g. Microsoft will have to supply the models of all the WMR devices etc.
From what I understand, the de-branding of extensions works in the opposite order. The extension gets updated and promoted to a multi-vendor extension once multiple vendors start adding support for it.
I think the general idea is to provide a generic-enough API that a model corresponding to the real (physical) device can be provided. In any case, this is something I'm actively interested in, and as you may notice from other vendor extensions regarding this functionality, others are making their attempts at providing this feature set, which are steps toward a cross-vendor extension.
@Rectus My concern is that the behavior of vendor specific extensions promotes fragmentation and proprietary implementations/API's.
@rpavlik exactly, either have the spec mandate models are provided by the API (which has it's own difficulties), or empower developers to load their own device accurate models based on a simple Vendor and Product ID with the understanding that unsupported devices should fall back to using a generic baseline model.
--Soapbox--
As a dev I can't trust that the available OpenXR implementation will be compatible across my users systems. This results in conditional compilation, and custom defines per user platform as I'm having to essentially implement support for MsftXR, MetaXR, SteamXR, VarjoXR, HTCXR, PicoXR all under the guise of a 'single OpenXR' spec. Not to mention supporting WMR devices...
Honestly this feature of the spec feels to me like the old days of HTML, JavaScript and CSS where developers had to implement browser specific hacks and workarounds to ensure a consistent experience. That's not a good thing, and it took ~2 decades(?) for HTML and CSS support to finally be implemented in a standardized way, only happening once Chromium became the underlying code base used by almost all browsers.
@Rectus My concern is that the behavior of vendor specific extensions promotes fragmentation and proprietary implementations/API's.
I agree. It is still the vendors that control OpenXR though, and they will need some kind of consensus before putting out a multi-vendor extension.
or empower developers to load their own device accurate models based on a simple Vendor and Product ID with the understanding that unsupported devices should fall back to using a generic baseline model.
This should already technically be possible by identifying devices by the active interaction profile. It is a very inflexible system though, as it needs new extensions supported both by the spec and runtime to support new controllers. Not to mention that some vendors put multiple different controllers in the same profile.
Don't worry, we're sensitive to concerns of fragmentation. Unfortunately I can't unilaterally give updates on unreleased extensions, I can only say what I'm interested in promoting in the group. (The extension process we use is closely based on the successful Vulkan one, which is similar to the OpenGL one and other Khronos standards, and which has a history of successful usage. See the extension process document for information on how it works.)
An issue (number 1732) has been filed to correspond to this issue in the internal Khronos GitLab (Khronos members only: KHR:openxr/openxr#1732 ), to facilitate working group processes.
This GitHub issue will continue to be the main site of discussion.