Keep view upright balance with app's reorientation

You would likely have hard time continuously changing the pitch while standing though. Humans require visual cues to maintain balance.

But yeah, having a good, non-nauseating way to angle the view would be good for accessibility. Accessibility is a big issue for VR in general, and vendor support for it has been very lacking in my opinion.

About fluid movement, the question is how well it is even possible to implement in VR. From everything I have read about it, I keep getting the feeling that developers that have been trying to implement it have never been able to find a good enough solution to make it worth pursuing for them. Seated traditional FPS style games are already a small niche in an already small industry, and there is not much point in making a commercial game only a small number of players can play.

Still it’s always possible there is a way to make it work. I’d recommend testing it out in a modern engine with a good toolset first though, having to worry about porting and low-level implementations at the same time as movement mechanics sounds like it would overcompensate things a lot.

I’m working on the finishing touches before a live demo (just some text rendering to go) so maybe hold off to download a demo (sans OpenXR) from my link before. On fluid movement, it feels fine to me. I’ll tell you what I did. The lineage my project comes from has a very eccentric walk animation that’s very bouncy.

So in the beginning, when I started working on adding analog controls to this game, I first added a horizontal sweeping movement to simulate a natural stride. But I then started gradually reducing the effect to make it more natural, until now you can hardly tell it’s there when walking at average human speed. But before I did that, I worked on fully reproducing how we move our feet when we walk, and turn, so that it simulates footwork. I had to do this because it just felt wrong, and quality is very important to me. So it was relatively easy to tune this footwork with the exaggerated level of effect… the effect can still be dialed up to the original amount or more in the INI file. But now, you can hardly detect the footwork. It’s a bit more evident at high speeds (running) because the amount of movement is greater.

Anyway, apart from this I always focus on smoothness and creating natural circular movements. I don’t use the raw input data because it’s too chaotic, and you can’t animate against it. So I run the analog input
through a pre-filter and then lock it like a ratchet, and then reconstruct the signal through a post-filter.

It’s just been a lot of attention to detail and trial and error over the years to make a game that feels “cinematic” because my objective is to make artistic experiences. Analog controls always present challenges. Finally when I added VR a few years ago (with a twin view 1080p PSVR setup) I decided to dial down the effect even more until it feels good in VR. I decided to keep the default at that level even though it’s much less noticeable on a monitor than in VR. I think of my project as VR first even though until now it’s more monitor based.

It’s open source. In theory if people find my project’s VR superior it can be replicated. I just don’t find it nauseating at all, and I imagine a big part of that too is I’m interested in inhabiting a real body, so I stick to real human speeds.

EDITED: On inputs. In most big budget commercial games it feels like they throw away 50% of the analog controller’s sensitivity. I think it’s because (mainly) the game has to work even on bad sticks that send out errant data. In VR you need more sensitivity on the analog. I always try to use as much of the stick as possible, but I’ve always wanted to code a very detailed controller configuration system to mitigate a lot of the problems I see with controllers. I think I’m going to be doing that project before too long. Fingers are also not good analogues to limbs. Fingers are shaky. Old fingers are shakier. But in general, VR needs sensitivity. I think thumb-sticks are vital to VR and it’s a problem they’re not standard.[1] VR controllers need to standardize on very sensitive and smooth analog sticks.

[1] I thought just Sony’s PS5 would have them, but Valve’s Index looks like it does too.

One neat thing about tracked VR controllers is that you have very good sensitivity and precision in the pose of the controller itself. While it might be less useful for traditional games, I much prefer it in room scale games. Even with stick locomotion, if a game has controller relative movement, I end up using the controller to adjust direction and speed more than the stick itself.

Hey, I know this is late, but I just happened to remember I said I’d follow-up when I published my demo I was working on. It got delayed because I had a weird coincidence that led me to combine it with an unrelated (hopefully high visibility) event (https://www.patreon.com/posts/70518653) but the game demo itself is at the same place (KING'S FIELD 25th PROJECT by swordofmoonlight) and here’s a devlog post too for good measure: Triple event, incl. PCVR via WMR+OpenXR & Secrets of KF and the Moonlight Sword! - KING'S FIELD 25th PROJECT by swordofmoonlight (Edited: Note, rewritten the main page to include a VR and controls guide.)

I am very curious if you (Rectus) can make this work with your Valve Index. I’m not sure my app supports it since I built it against Microsoft’s WMR and it seems maybe OpenXR has provided a common API but not a common delivery mechanism so far. I’m afraid I’m leaving a lot of VR owners in the dark despite my good intentions.

It outputs Stereo Unavailable (3) if I try enabling stereo mode. Guessing Microsofts OpenXR loader will only attempt to use the WMR runtime, and WMR has no support for non-WMR headsets whatsoever.

The official Khronos loader will use whatever runtime is set in the ActiveRuntime key in the Windows registry, so it’s probably at least a better option in general. For other options, the Unity engine seems to have a more advanced loader that lets you pick which runtime to use if you have multiple installed.

See my other post here:

There is no such thing as “the Microsoft OpenXR loader”. I have no idea what gives you the impression that there is. I’m not even sure where you would be getting a “Microsoft OpenXR loader”? Do you mean the VS Nuget package for OpenXR? Because that ships the Khronos loader, bit to bit.

I use ActiveRuntime on my system to toggle between WMR, Varjo, Oculus, SteamVR, Pimax without any problems.

I will try OP app later today.

Yes, sorry. We figured out that my app’s problem is it’s 32-bit, which SteamVR doesn’t accommodate. Maybe it doesn’t even require SteamVR, but Valve Index doesn’t have a 32-bit OpenXR runtime option.

EDITED: Sorry… I really appreciate you tried Rectus! I’m sorry it doesn’t work with Valve Index… in more ways than one!!

Thanks for trying! I’m glad to know it works… you never get much feedback in these things :slight_smile:

RE “Do you mean the VS Nuget package for OpenXR?” yes, it’s just because it’s what’s in the documentation in Microsoft’s guide, that gives the impression it’s part of MS’s WMR/OpenXR solution. BTW: If you’re asking me this question, I may’ve assumed SteamVR/OpenVR had its own loader, since OpenXR seemed experimental in its environment, but I may’ve jumped to that conclusion because it wasn’t working in my case.

Yeah, the issue is with SteamVR. The big problem with that is that anyone that has SteamVR set as the active runtime will not be able to play your game, regardless of what headset they use.

It might be worth telling Valve that you have an use case for 32 bit support in their OpenXR runtime.

Yes, this is off-topic, but I agree Valve and the others are just a hole in the API now since others are supporting 32-bit and I don’t see why they shouldn’t. I hope something is done, ideally fast… I will try to make a case, because it’s a problem for me. I think any modding like project will run into this problem, so it should be fixed.

Apparently this was a reason the upcoming Half-Life 2 VR mod opted to not go with OpenXR.

1 Like

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.