WMR has a ridiculous transition that seems to take about 15 seconds to go in and out. I don’t suppose there’s a way to turn it off or know if it’s on screen?
I’m calling quit/init to change the supersampling resolution (maybe that’s overkill, I’m not sure) and I can’t seem to find anything that works but to hard code in 5s of Sleep and a 11 second wait to make sure synchronization happens. I want to display a message to explain what’s happening to the user. Their super sampling selection for example.
I’m thinking this is all messy because other runtimes may have no transitions or short transitions or may actually report when apps are visible and focused. As near as I can see the WMR (Microsoft) runtime always quickly proceeds to FOCUSED even when its animation is playing, but it’s fully opaque.
I’m curious what the landscape is like? I wonder if there’s any desire to disable these transitions because they’re torture for developers and it’s seem like toggling quit/init is a scenario where it’s unwarranted. I think part of the problem is I can actually see the FPS display reflect the new resolution in the set before the exit transition starts playing… so I think it’s ready to go instantly but WMR still plays through these animations. It’s also a time when a monster could murder a player in a video game in theory
Yes, it’s overkill. You should only need to re-create your swapchains, and continue with the existing session.
Do you know about changing the input bindings? I tried to back out of xrEndSession but I couldn’t get it to recover with xrBeginSession. I tried adding xrRequestExitSession but it all became too complicated, so I figure it just wants to quit and all of this is a formality for gauging timing?
EDITED: In my mental model I thought you would end-session, then reset action bindings, and then begin-session. It all seems very messy. But that seems not possible.
I’ll have to ask my inputs expert and get back to you!
Can you describe more precisely your use case for changing the input bindings mid-session? Thanks.
One use case is for the user to be able to rebind their inputs while using VR, and be able to test out those binds immediately.
Currently it is only possible for the runtime to provide rebinding interfaces while maintaining the action abstraction, but not a single runtime seems to have a working implementation (I think SteamVR is the only one that even has an interface for it, but it has been broken since release two years ago).
I think the lack of this is detrimental to the abstraction layer provided by OpenXR. Application developers may have to resort to breaking the action abstraction by providing generic sets of actions to the API, and binding them internally to their real actions. This breaks forward compatibility with any runtime binding interfaces and new controller types, since the actions provided to them do not directly map to any in-application action.
Mainly it’s something I experimented with because I’ve written a simplified wrapper around OpenXR to hoist it out of a program that needs to be more backward compatible than this state-of-the-art stuff… and I came to the conclusion maybe xrBeginSession and xrEndSession don’t make sense to expose in this wrapper if they provide no meaningful functionality. Basically I was wondering why this even exists. (It’s still in there as xbegin and xend but probably xinit and xquit and xwait is enough in my experience so far.)
or even just change your SubImage (the image rect that you’re using). But definitely not a full cycle of your session.
wait steamvr’s rebinding is broken? I should ping somebody about that.
Yes, I agree that the lack of rebinding UIs in runtimes is really detrimental. I’m a bit too busy to volunteer to write a suitably-permissive open source rebinding UI that the runtime vendors can do, but I’ll continue to push for folks to do this or otherwise provide rebinding support.
In my experience it has never worked properly since the runtime was released. It seems to correctly apply bindings when changing them individually in the UI, but when it does that, it also sets the interaction profile to a null path. Loading the bindings on startup doesn’t work, it shows the user bindings being applied, but loads the application supplied bindings instead.
Also, the UI is very buggy and often fails to work, and it doesn’t display the localized action names.