If I wanted to get started with "VR development" what should I search for? Is "OpenXR" the thing? Do I need some proprietary SDK?

@aeva 1. Most VR headsets will actively punish you for using C. Unity/Unreal is standard.

2. OpenXR is what you want, or maybe just WebXR.

3. What I use (for my commercial product) is I think this is more in line with the kind of development you seem to like. You write straightforward Lua scripts, it wraps the parts you don't want to think about, it leaves everything else to you.

@aeva (This said Lovr has some problems, it leaves EVERYTHING to you— things like shadow drawing are not inbuilt— and it's a small project which means some glitches/shortcomings like a long standing bug with flickering on some GPUs that we believe will be gone in the next release, which uses Vulkan.

If you want to use "not Unity/Unreal", I'd probably suggest either using Lovr or yoinking wholesale its C components (separable from the Lua frontend)

@aeva in general none of the VR vendors want to be doing developer support, so if they can farm those duties out to Unreal, or Unity, or the OpenXR committee, they're happier

@aeva a dream that people on the lovr project have independently approached, but never quite successfully packaged for reuse, is a text editor window floating in VR that lets you edit the game script you're running while you're inside it

@mcc I want to eventually add VR support to Tangerine, and I think LOVR might be similar enough that I can probably look at what they do for reference. The ability to live edit models (which requires a text editor) while in VR would be incredible.

@mcc I much prefer to build everything myself, so LOVR doesn't sound so bad.

Would you say this is a reasonable checklist, and are there any steps you think are missing or aren't realistic?

1. Make something simple in LOVR

2. Open up LOVR and see what they do ("OpenXR"???)

3 - N. ???

N + 1. Tangerine VR support!

@mcc I wonder if the vive tracking pucks are supported. I want to buy a bunch of them and stick them to my keyboards and synthesizers so I can see them in VR

@aeva I think the controllers are relatively hard-coded (this has been a cause of argument in the past, I've wanted to make controller data more general but we failed to nail down an API for it the project lead was satisfied with) but if you're building yourself it's in a place it would be easy to monkeypatch in support for controllers>2. The main thing I'd worry about is whether the pucks expose to OpenXR. now that we use the OpenXR driver instead of the old Vive one.

@aeva generally, OpenXR describes a "universal" /minimal VR configuration and anything special unique to a given vendor is described through extensions. So you might have to enable an extension for the pucks. Or maybe they just present as funny handsets, I don't know.

@mcc oh noo. I guess that rules out using lovr for my idea of "klingon pain stick simulator"

@aeva To be clear what I mean is on the order of "you may have to add a few items to this enum and recompile". I'm just trying very hard not to oversell anything

@aeva Looks like the vive tracker extension is named XR_HTCX_vive_tracker_interaction, though it's not clear to me if it's deployed yet.

...Alternately, if you use Lovr 15.0, which is the currently shipped stable version, it is still shipping OpenVR (Vive's traditional/native api). We were gonna take the OpenXR+Vulkan plunges at the same time I think

@aeva (The reason I would probably use Lovr's C bits even if I wasn't writing Lua is that it has the abstraction layer that evens out OpenVR/VrApi/OpenXR/WebVR/WebXR, which is LESS important than it used to be now everything is moving to OpenXR, but gross exceptions like this still crop up! And who knows if Apple will remotely play nice with the standards body.)

@mcc a side thought with an important disclaimer: I know nothing about LOVR's internals so I have no idea if this could in any way work out, but I do wonder if it might make sense to rework Tangerine so it can be used as a middleware for things like LOVR

@aeva you mean, a middleware on top of things like lovr?

It might just make more sense to do it as a library for lovr if you want to integrate them, not sure.

One thing I've long dreamed about is a "Unity" driver for lovr tho lol. Just run your game inside a unity scene

@mcc oh yeah I mean like a library. Like, Tangerine's API could probably just be exposed to LOVR's Lua environment, and then I assume the hard part is figuring out how to make the respective renderers play nice together.

@aeva we have a plugin architecture so this shouldn't be too hard, theoretically it's a matter of just checking out a repo with a CMakeLists in a particular directory in the lovr build tree and it builds a dll/dylib you can redistribute to users of stock lovr

@aeva assuming tangerine can run at 90 fps, I've never been clear if it's an online or offline renderer

@mcc it is real time, but right now the lower bound is often at "interactive speeds". I have some ideas for how to decouple the ray marching from rendering the final image though, so in theory it could be made to always hit any target frame rate provided the resulting convergence artifacts were acceptable. I consider this to be a prerequisite to supporting VR.

Show newer
Show newer

@aeva seems sensible. The code in lovr is pretty well organized and the "driver" files (the ones that interface to OpenXR, etc) are simple, so it should be easy to use those files as sample code if nothing else.

Sign in to participate in the conversation
Gamedev Mastodon

Mastodon server focused on game development and related topics.