Non-VR keyboard interface - request for feedback

[goatchurchprime]

A keyboard control interface is essential if your development cycle is on the Quest where it can take more than a minute to upload and check something out. You can get away without it if you are doing PCVR development and your headset is on a tripod where you can easily peer into it one second after hitting the Play button.

Often you're just trying to develop a single interaction effect (eg running over a ramp) and can centre it in your scene in front of the startup point where you can test it immediately.

This PR is probably not up to coding standards of the toolkit yet, so I'm asking for feedback.

I'd like it to have the ability to move the controllers and grab things using the mouse so it has just enough functionality to debug other important effects.

In an ideal world this node would be good enough to convert any VR game instantly into a POV pancake game, like the reverse of @teddybear082's project to convert every 3D game he can find into a VR game, but this would probably take more than a few iterations to achieve.

[BastiaanOlij]

I don't believe this is the right way forward for this, it clashes with many of the other implementations and doesn't really test what you're testing because you suddenly change your input model.

The real requirement here is that you want to have a VR simulator, something that has been asked for a lot of times, something that makes the game think it is running on a VR headset, but in reality its running on the desktop, with the output shown on screen and controllers simulated by mouse and keyboard.

I know some people at one point were working on a SteamVR driver that did just that, wonder what ever happened to that..

[BastiaanOlij]

Note, asked around a bit and Monado seems to have a few working options that they are perfecting but most of them are currently Linux only. There may be a windows version of one of their options so I'll see if I can get that to work.

[goatchurchprime]

I disagree. The full VR interface simulator is useful if you're developing a part of the game that depends on the VR interface. But there are many parts of a game that have nothing to do with the VR interface (eg the way that enemies move or animate when you get close to them) where the VR interface just gets in the way and slows down the debugging process. That's what makes a non-VR keyboard interface an essential tool in many instances.

[Malcolmnixon]

I just played around with it, and it's certainly easier than trying to use the Chrome WebXR interface to drive VR input. I haven't had a chance to play with Monado because I'm on a windows PC.

I would certainly want to isolate this from the "shipping" XR code - possibly in a "debug" folder . We may end up with other debugging tools - for example in my older demo project I had a camera you could place, and a wrist-monitor that would show what's in the camera view - something I used with visual colliders to inspect the players body collider.

If this were to go in, there are a few changes I would suggest:

• To detect whether VR is active, you would want to inspect the get_viewport().arvr rather than ARVRServer.find_interface("OpenXR")
• I found the inputs a little challenging. You may want to consider mapping to something more standard for first-person shooter such as mouse-look for the turn left/right and head up/down; and then use arrows for move/strafe
• You may want to add a Jump option which invokes player_body.request_jump()
• You should also use the new player_body.rotate_player() method rather than the local _rotate_player
• You should update the file header comment to match the style elsewhere (needed for Godot 4 compatibility)

[goatchurchprime]

@Malcolmnixon I've made all your recommended changes, except the file header comment thing, because I don't know anything about that. The MouseMotion capture works like in Portal2, which I've been playing recently.

You need to instance this MovementNonVRKeyboard node into MainMenuLevel and then the demo scenes works (for this first scene).

This is still a WIP: I think it should keep the controllers relative and in sight of the camera view, with maybe Shift key and scroll wheels to move the controllers separately and in and out. Remember, it's just an instant debugging tool to help people to develop non-VR effects (eg networking, highlighting objects, lighting, explosions, etc).

[BastiaanOlij]

I haven't had a chance to play with Monado because I'm on a windows PC.

They have a windows build but it doesn't have their most advanced controller yet.

• To detect whether VR is active, you would want to inspect the get_viewport().arvr rather than ARVRServer.find_interface("OpenXR")

Sadly that won't cut it either, there is no guarantee the main viewport is used and get_viewport() may thus return a different viewport than you're expecting. I'm guessing ARVRServer.primary_interface is the better way to check. If its valid we likely have a running VR system.

[Starkium]

My personal preference would be a set up similar to the VRE in Unreal engine. Here you have two hands at the corners of your screen that grab/interact with mouse clicks and a traditional fps set up. This is how I've worked with my unreal vr projects for around 5 years now and it's super straightforward. This also makes it possible to develop a game that works in both vr and non vr using one interface type. This type of set up would be even more convenient in godot with how simple the signals and animations system are.

Some examples videos of the VRE: Youtube Link