LucidVR
Is this project abandoned?
Its been over a year since the last commit, and nearly two years since and major updates. Is there still active work being put into this or is prototype 5 becoming a Half-Life: 3?
From what I have seen there has been little to no communication with the creator Lucas in the past 9 months. I know that there are still some plans for Prototype 5, but they might have to be completed by community members.
The discord server (https://discord.gg/lucidvr) is still active if you want to talk and ask questions, and I know there are a couple of upgrades like Fae Mod that help to improve prototype 5.
I made a pull request back in April. He contacted me and said he'd look at it when he had some free time. Unfortunately MIT and Free Time don't exactly go hand-in-hand.
I think the project is still hot, it would be nice if somebody could pick it up. Today I'm applying for the German "prototypefund" to get sponsored for work on lucidvr. More specifically, I'm applying for funds to update lucidvr's driver to OpenXR and help with the BLE part.
Apart from that, if anyone is willing to take over (part of) the project, I would contribute a small monthly donation.
I think the project is still hot, it would be nice if somebody could pick it up. Today I'm applying for the German "prototypefund" to get sponsored for work on lucidvr. More specifically, I'm applying for funds to update lucidvr's driver to OpenXR and help with the BLE part.
Apart from that, if anyone is willing to take over (part of) the project, I would contribute a small monthly donation.
I can only talk for opengloves: I wouldn't say it's abandoned - I am still more than happy to help with questions that people have with the code and am also happy to review contributions.
A lot of projects (and companies) now actively ship opengloves - or have at least incorporated it into their codebase - to make their gloves compatible with SteamVR and I've continued to help with questions these vendors have.
It's great to hear that you're keen on developing opengloves; feel free to let me know if you have any questions. Opengloves already supports OpenXR through SteamVR, but unfortuantely there currently doesn't exist a spec to make drivers native for OpenXR. Supporting BLE would be very neat, and will be happy to review any changes you make. Feel free to keep me in the loop 🙂.
@danwillm thank you very much for your work! I guess you're talking about https://github.com/LucidVR/opengloves-driver. Sorry if it sounded like I said this project is abandoned. From what I've personally seen so far, this is (still) the most active open-source data glove driver.
What I meant was no one is dedicating time in the scale of 100h to implement major changes. I just glimpsed into the discord channels and GitHub issues, so my opinion is not very well-informed. I was thinking "the last commit is from 12.2023", "OpenVR is not supported by Quest standalone, the most prominent headset", "there is a BLE issue/PR from April that probably won't be finalized and merged".
A lot of projects (and companies) now actively ship opengloves - or have at least incorporated it into their codebase - to make their gloves compatible with SteamVR and I've continued to help with questions these vendors have.
So super nice of you :), That's one of the things I planned to do if I'd got a grant for it.
but unfortuantely there currently doesn't exist a spec to make drivers native for OpenXR
In the docs it says:
We emulate the index controller to achieve this compatibility, which means that we are limited to the inputs that the index controller exposes.
It is referring to the OpenVR implementation, but Isn't the same possible for an OpenXR device? Emulating the index controller? And having a custom profile or a profile leaned on another hand tracking product as an extended alternative?
My hypothesis is:
- Migrating to OpenXR will make it compatible with the most popular headset, the Meta Quest, and other standalone headsets.
- With OpenXR it is more likely to run in monado versions on linux and macos without compatibility issues.
I don't have a prototype to verify or falsify these claims.
My personal dream is to replace my keyboard with a data glove, that's why I'm working actively with the data glove manufacturer Cynteract in my free time so I can pursue my dream. If you know a project/company that is active in that direction, please let me know <3
A lot of projects (and companies) now actively ship opengloves - or have at least incorporated it into their codebase - to make their gloves compatible with SteamVR and I've continued to help with questions these vendors have.
Do you have a list of them available?
Quest standalone cannot currently be supported as there isn't an interface available to write device drivers in OpenXR, or to load external layers on Quest. As for Monado, I actually did implement a driver for that here: https://gitlab.freedesktop.org/monado/monado/-/tree/main/src/xrt/drivers/opengloves.
The gloves currently emulate index controllers, which means they appear to SteamVR as index controllers. SteamVR does the work translating between OpenVR and OpenXR, which means the gloves are supported when running OpenXR games with SteamVR.
Fwiw, this emulation of index controllers is not required anymore, and if you receive funding to work on the project you should consider switching to emulated controller bindings, see https://github.com/ValveSoftware/openvr/blob/master/docs/Driver_API_Documentation.md#application-compatibility
Thanks :) I can see that I mixed up the OpenXR term.
Is the project title for the driver "opengloves-driver"? I guess LucidVR initially named it like that with it's SteamVR ITrackedDeviceServerDriver implementation. You extended the project with the Monado xrt_device implementation.
The driver interface to the input device is Bluetooth serial, USB serial and named pipes. BLE is approved.
The driver's other side is not so clear to me. Currently, it is implemented as Monado and SteamVR input device. It can potentially interface to:
- First-party game code.
- Third-party game-engine/input-library API.
- VR runtime API, e.g. Monado or SteamVR. Is this also possible for the other runtimes? Do they have equivalents to xrt_device and ITrackedDeviceServerDriver that can be hooked into the target device?
- Operating system via Firmware, i.e. the exposed USB and Bluetooth interface.
The target platform limits the supported VR runtime:
- Quest 2 Standalone game: OculusXR, OpenXR.
- Linux PC game: OpenXR via Monado, SteamVR via Proton.
- Windows Steam game: SteamVR , OculusXR, OpenXR.
- A generic Windows game: the above, plus WMR/Pimax/Varjo/VIVE/etc.
The choice of game engine limits the supported VR runtime as well:
- Godot 4.0: OpenXR. Deprecated support for OculusXR.
- Unity: OpenXR, OculusXR, SteamVR, WMR and Varjo XR. Deprecated support for GoogleVR and GearVR.
- Unreal: the above, plus Pico SDK.
According to https://docs.godotengine.org/en/stable/tutorials/xr/openxr_hand_tracking.html#the-hand-tracking-api and https://github.com/joemarshall/openxrhands there is an OpenXR API for hand tracking. Can the opengloves-driver expose a hand-tracking device and additionally a controller device to the OpenXR runtime?
I stopped writing the above text, it's gotten too much for my schedule at the moment.
if you receive funding to work on the project you should consider switching to emulated controller bindings, see https://github.com/ValveSoftware/openvr/blob/master/docs/Driver_API_Documentation.md#application-compatibility
Would that mean something like: Bob starts a VR game. He plugs in his glove which implements the opengloves-driver. The driver queries the capabilities of the glove. Depending on that the driver registers it as knuckles-controller/valve-index/etc. and translates the inputs to inputs of that specific emulated controller?