Closed AltoRetrato closed 4 years ago
Hey, I've encountered similar problem! Gloves flick not working even with scripted motion :( I'm setting offset and tilt to alvr.controller_position and controller_orientation on click but it doesn't trigger gravity action https://imgur.com/a/Vr8jIqd
I had the same idea - since in ALVR the controller rotation axis seems to always happen on the elbow, perhaps changing the axis to the wrist would trigger the flick detection. I've tried a few variations (you can see the source of my script here: https://github.com/AltoRetrato/Half-Life_Alyx_on_Oculus_Go ), without luck...
I also scanned the game for console commands and binding actions. I've dumped most of the strings in the client.dll file (large file warning: 1.5 MB! https://raw.githubusercontent.com/AltoRetrato/Half-Life_Alyx_on_Oculus_Go/master/Half-Life%20Alyx%20strings%20in%20client.dll%20.txt ) and there are some interesting things in there that might help, from "/actions/" bindings to "vr_enable_fake_vr" and other "fake*" console commands. Unfortunately I still didn't have time to tested them, though.
It seems that gravity gloves flick gesture requires acceleration data in order to register, so we need to provide additional controller data to SteamVR #622
v2.4.0-alpha5 seems to 'Fix throw motion is not recognized by some games' #317 #341 but I can not test it due to it seems to be Quest-only release and I can't map my GearVR controller buttons
Hmm... I'll try to make a build with that patch!
i wanna have spoilers
XD
I managed to build a working driver_alvr_server.dll using ALVR-2.3.1.
Then, in alvr_server\RemoteController.h
, where there was only:
m_pose.vecPosition[0] = controllerPosition.x;
m_pose.vecPosition[1] = controllerPosition.y;
m_pose.vecPosition[2] = controllerPosition.z;
m_pose.poseTimeOffset = 0;
... I added:
m_pose.vecVelocity[0] = info.controller_LinearVelocity.x;
m_pose.vecVelocity[1] = info.controller_LinearVelocity.y;
m_pose.vecVelocity[2] = info.controller_LinearVelocity.z;
m_pose.vecAcceleration[0] = info.controller_LinearAcceleration.x;
m_pose.vecAcceleration[1] = info.controller_LinearAcceleration.y;
m_pose.vecAcceleration[2] = info.controller_LinearAcceleration.z;
m_pose.vecAngularVelocity[0] = info.controller_AngularVelocity.x;
m_pose.vecAngularVelocity[1] = info.controller_AngularVelocity.y;
m_pose.vecAngularVelocity[2] = info.controller_AngularVelocity.z;
m_pose.vecAngularAcceleration[0] = info.controller_AngularAcceleration.x;
m_pose.vecAngularAcceleration[1] = info.controller_AngularAcceleration.y;
m_pose.vecAngularAcceleration[2] = info.controller_AngularAcceleration.z;
I logged the results and it seems the client doesn't provide any controller_LinearVelocity
values. While it does provide the other values, I'm not sure if they are in the scale or format expected by OpenVR. You can see some sampled data (select a column and click Explore.
I tested this new driver, but the flick hand gesture was still not being recognized.
Just for a quick test, I replaced info.controller_LinearVelocity
with info.controller_LinearAcceleration
(a wrong value, but better than nothing - at least could see if it helps to trigger the flick hand).
The controller position is now VERY erratic (there is a lot of jitter), but... Bingo! 👌 IT'S ALIVE!!! I can easily pull objects in my direction. :satisfied: I also noticed that, for the 1st time, I can also throw objects (before this, any time I tried to throw something it would just fall down).
Now the question is: should we change only the server (with a "better" hack) or try to get the "real" linear velocity from the client as well (if that's possible in the Oculus Go and Gear VR, and in that case, how)?
For now I'll do a few more tests and check other ALVR releases to see if any of this was already implemented (even if just partially).
Dividing the acc. value by 60 stops flick detection, but dividing by 10 it still works and give little to no jitter. I haven't tested this new driver more than a few seconds, but it is already available if you want to try it, @dnnkeeper .
Dividing the acc. value by 60 stops flick detection, but dividing by 10 it still works and give little to no jitter. I haven't tested this new driver more than a few seconds, but it is already available if you want to try it, @dnnkeeper .
I managed to calculate linearVelocity and angularVelocity as derivative of position and rotation data and It worked! Gloves are working, The Lab objects correctly acquires velocity when being thrown. Try it out from my fork. I'll make pull request later. https://github.com/dnnkeeper/ALVR/tree/ControllerVelocityFix
Nice! I might try it later, but don't expect that @polygraphene will accept your pull request soon (or ever): @polygraphene's activity basically stopped 9 months ago... 😞 If I were you, I would provide another release for those who can't build it themselves.
This request is just for people to discover solution more easily. I also made similar modification for alpha5 but that version is too unstable.
I built from your fork (with configs "Release" and "test") and used GearVRExtendedController.py.
Sometimes, at the start, the controller goes missing (or doesn't seem to appear at all). It seems it works only if I start FreePIE after everything is up and running, but even so not always...
I really like your script, and might steal a few of your ideas! 😄 But unfortunately, even when the controller works, I can't trigger the hand flick gesture using your fork when playing with the Oculus Go...
I also noticed some performance degradation on my machine.
Nice! I might try it later, but don't expect that @polygraphene will accept your pull request soon (or ever): @polygraphene's activity basically stopped 9 months ago... 😞 If I were you, I would provide another release for those who can't build it themselves.
Have you tried the latest commit from my fork? I've been working on some totally virtual fake vr driver to make game playable without connecting headset and accidentally encountered some esoteric race-condition-like bug with controllers initialization.
You should try building exactly pull requested commit (it doesn't contain much changes - should work fine) or try my latest update where I managed to resolve the issue (hopefully).
I've got a different idea which is to add support for joy-cons (cheap clones at least) directly in to ALVR via bluetooth. Then you can use these two motion controllers instead of the single Go controller. They'd also be running PC side. It involves grafting this code (https://github.com/fossephate/JoyCon-Driver/tree/master/joycon-driver) into a fork of ALVR. I tried using Driver4VR to achieve the same but that software is so buggy it was a waste of time (and money). Anyway I'm at the point where I'm mostly building ALVR but the CUDA component RGBToNV12.cu isn't built and linked and therefore I get an undefined symbol - anybody know how to fix this ?
@azw413, a complete error message is always better to explain what is going on, but you can also see @dnnkeeper's commit to see changes in project files related to newer versions of libraries and tools.
If you are looking for the Cuda Toolkit 9.2 (and patch), it is here. Be sure to retarget the solution for your installed SDK (right-clicking the solution and selecting "Retarget solution"). To build the CUDA library, I commented out line 133 in "C:\program files\nvidia gpu computing toolkit\cuda\v9.2\include\crt\host_config.h".
But I wonder if you could do what you want directly on FreePIE, without changing ALVR at all...
I figured it out thanks, updated the dependencies to CUDA 10.2 and retargeted and it now builds. I did look at FreePIE and there is a joycon driver but it doesn't support the gyro, just the buttons so it would be no better than a gamepad. I'm now in a position to try grafting in the controller code. Does anybody else have a fork with newer fixes in it ? I know about JackD83 but I think that's a Quest only fork unless I'm mistaken which is no good for me as I'm a Go user.
Yes, JackD83's fork is Quest only. I'm using the latest stable release, v. 2.3.1, which works fine for me.
If you still don't have those joy-cons (any idea about the cost?), why not add a second Gear VR controller (US$ 10~15) or Go controller (US$ 25)? I think at least the Gear VR controller was already "hacked".
I've found another issue while playing: double-clicking a controller key doesn't trigger the respective binding in the game. To be specific, the "Toggle Burst Fire" should be triggered by double clicking the "Menu" key (that I mapped to the Oculus Go "back" button), and I'm not sure why it doesn't... OTOH, a long press works (but I'm already using it for another action, the "Magazine Release").
Here is some footage of HL:A without VR, with WSAD movement: https://youtu.be/wkdI2ZCmi2A You can download this version from my fork release.
I've been playing Half-Life: Alyx on the Oculus Go without any major problem for some time, so I'll close this issue. If anyone is interested, I'm still updating the related information and files at https://github.com/AltoRetrato/Half-Life_Alyx_on_Oculus_Go
Hi there!
I started playing Half-Life: Alyx on my Oculus Go with ALVR. It looks great and runs fine until I have to use the gravity gloves. For the moment, it is the only part I can't go through because you are supposed to do a "flick of the wrist" and, unfortunately, the game doesn't detect that movement with ALVR...
I'm not sure why this happens, but I guess the controller rotation axis in ALVR is near the elbow, and for the game to detect that movement the rotation should be near the wrist. So I tried to write a FreePIE script to work around the issue, but so far I could not get it to work (but I'm still working on that). Also, in the FreePIE reference I could not find anything related to the rotation axis of the controller.
Does anyone have any suggestion about how to change the rotation axis of the controller?