[PICO][OpenXR] Give IOpenXRExtensionPlugin ability to remove some UE's optional extensions.

Development Platform & Builds
, ,
1

Do you think UE can let vendor’s IOpenXRExtensionPlugin to remove some optional extensions that UE wants to use but IOpenXRExtensionPlugin not. Current implementation, the plugin can only add optional extensions, but can’t remove extensions that they don’t want to enable for some reason.

[Image Removed]

[Attachment Removed]

2

Interesting. So maybe a BlockOptionalExtensions hook? Can you share any specific ones you are thinking of blocking? This does seem like a good idea but i’d like to think through the implications as much as possible. Definitely would want to put good logging on this if we do it.

[Attachment Removed]

3

Well, it seems like a good thing to have. Actually for this exact case we might want something like a cvar that can disable any optional plugin in UE core. Then you could put that cvar call into an ini to turn off optional functionality.

However I went ahead and implemented the following hook:

/**

* Fill the array with optional extensions blocked by this plugin.

* This can be used to disable optional extension usage by the UE OpenXR core and by other ExtensionPlugins.

* Required extensions either from UE OpenXR core or from ExtensionPlugins are NOT blocked. In the latter case disabling plugins may have the

* same effect. Otherwise code changes will be needed.

* In general blocking optional extensions used by UE’s OpenXR core should be ok because it is designed to run correctly without those extensions

* and it seems likely the blocking plugin is replacing that functionality somehow.

* Blocking optional extensions added by plugins is potentially more complicated and ExtensionPlugins that do this may make themselves harder to use

* along with other ExtensionPlugins. They are optional, so it should work, but feature use may become complex.

* Plugin settings to explicitly disable extension use or splitting plugins up so that features can be individually enabled/disable should be considered.

* If false is returned the returned extension list will be ignored.

*/

virtual bool GetBlockedOptionalExtensions(TArray<const ANSICHAR*>& OutExtensions)

{

return false;

}

What this does is that in OpenXRHMDModule.cpp when we are adding optional extensions for UECore and when we are adding optional extensions for ExtensionPlugins (including this one!) we skip adding them to the optional request list.

I’m going to add the cvar feature i described above as well and expect to submit this soon.

[Attachment Removed]

4

Ok, I did submit that, should be in github in a few hours. I am going to add a cvar or ini setting to do the same thing.

[Attachment Removed]

5

I also added an openxr plugin project settings/ini property to block the use of *any* extension.

OpenXRHMDSettings BlockedExtensions

-Added a config variable backed project setting to block the use of a list of OpenXRExtensions even if the runtime supports them and even if they are required for us to run OpenXR at all.

[Attachment Removed]

6

[Image Removed]

  • To be honest, the reason for asking this question is due to a bug in the PICO runtime. Although PICO has claimed to support this optional extension, once it is enabled, it will cause a crash on the PICO4. However, since the system upgrade after the PICO4 runtime fix is relatively slow, if we have the ability to optionally remove this optional extension within the plugin, we can avoid this crash through the plugin before the PICO4 is upgraded. In the future, it is uncertain whether we will encounter similar issues again, where Unreal correctly uses a certain optional extension but there is actually a bug in the runtime even though it claims to support it (of course, we admit that this is caused by the instability of the vendor’s runtime, and UE has used the extension completely correctly).
  • The second reason is that optional extensions provide additional capabilities, which means maybe incurring additional performance overhead(except some optional extension is used to optimize performance). However, developers should seemingly have the right to decide whether to enable a particular optional extension, as the capabilities within optional extensions may not be needed by developers, but enabling them at runtime could lead to performance waste.
  • Overall, this new requirement is not highly prioritized. If UE evaluation determines that no changes are needed, we will also accept it. This will also help us conduct more rigorous reviews of the implementation of extensions during runtime.
  • But I hope​:grin:
    [Attachment Removed]
7

Jeff Thank you very much！:+1: I saw the commit on the main branch at GitHub. The implementation is very professional and considerable.

[Attachment Removed]