Unable to see VR controller in godot_openvr demo #67
Comments
|
@georgewsinger there was a writeup that @beniwtv did one of the info issues on this job, that describes a number of things you need to be aware off on Linux. Unfortunately I don't use Linux myself but it has a few gotcha's if I understand correctly |
|
The tracker error is due to a bug in the demo - the ID of the left (IIRC) controller is set to 0 instead of one. |
|
The special Linux things to be aware of are in the README - under "Linux notes". However, I have not needed this on Manjaro anymore - and since the demo does display in the HMD this seems to be fine for you as well. |
|
be sure to have launched it through the SteamVR system environment :
cd ~/.steam/steam/ubuntu12_32/steam-runtime/ ./run.sh ../../steamapps/common/SteamVR/bin/vrmonitor.sh and in another terminal to run godot under the same dir with ./run.sh /path/to/your/godotbinary also verify your compilation flags (godot-cpp compiled with platform=windows) ... alternatively, I could verify it works also well and easily to use godot 3.2 with the online add-on repository to add the Godot-ARVR addon on debian 10 with off. nvidia drivers |
@Olm-e I launched via this way just to make sure, and I'm still not getting a controller in the demo. (Also: I didn't compile godot-cpp with
@beniwtv Is fixing this error required to get controller functionality working in the demo? |
|
Yes for that controller it wouldn't work if the tracker ID is 0. |
|
@beniwtv I'm assuming the thing to change is func load_controller_mesh(controller_name):
# if ovr_render_model.load_model(controller_name.substr(0, controller_name.length()-2)):
if ovr_render_model.load_model(controller_name.substr(1, controller_name.length()-2)):
return ovr_render_model
# ...in |
|
Nope, it's in the Godot scene -> click on the left controller and in the inspector set the controller ID property. |
Adjusting this as follows (see top right of picture: "Controller Id" is set to "1"): I now get the following launch crash: |
|
I remember there being a crash about materials, this seems to look like it. From what I remember that was an incompatible Godot version to the OpenVR plugin. This might require downgrading the godot-cpp headers to a suitable version. In my PR there should be an .so that works with Godot 3.1: #64 |
I'm assuming you're referring to changing I'm looking forward to testing your pull request but am having trouble getting it up and running (see here). |
|
Can you post some of the compilation errors? |
|
For (This repeats for a long while). |
|
Has godot_openvr been confirmed to run properly on Linux for other people? |
|
Yes, definitively, I have other Linux users for my VR overlay (albeit with the pre-compiled binaries for the module). That error above still looks to me like an inconsistency between the headers. Let me look which exact headers commit I use. |
|
Here they are: cdd50260d0c2bd620f15d16e2e00a4d8c965eb67 godot-cpp (v1.0.0-alpha2-146-gcdd5026) |
|
@beniwtv Retrieving those branches via cd godot-cpp
git checkout cdd50260d0c2bd620f15d16e2e00a4d8c965eb67
scons platform=linux target=release generate_bindings=yes bits=64
cd ..
cd openvr
git checkout 52065df3d6f3af96300dac98cdf7397f26abfcd7
cd ..
scons platform=linux target=releaseI get the following compilation error: |
|
Binaries? Does anyone have binaries they can lend me of a working linux godot-openvr? The ones in I tried copying these binaries to my project (SimulaVR/Simula) and I get what appear to be godot-cpp errors during a call to |
|
Let me try downloading your project and trying it here. For Godot 3.1.1 from the official these binaries do work for me in the demo (I did compile them after all) :) |
|
Hmm I fail to make it detect wayland_scanner. I installed pywayland, but to no avail. Do I need to do something special there? |
|
Can you post the console error/distro you're using? If you're using Ubuntu |
|
I'm using Manjaro, error is: |
|
@beniwtv Thanks for your help.
|
|
I do have Wayland as I use this as my primary display server, but I can't find wayland-scanner here :( The Godot 3.1 branch should be the correct one - but I just saw that in godot_openvr master Bastiaan did update the cpp bindings -> maybe try rolling back the godot_openvr repo to commit cd58016 for those compile issues |
|
@beniwtv Pinning the commit to the one you specified gets godot_openvr to compile(!): git checkout cd58016a5edb4e626b0bee830de1d723c1b46a57
cd godot-cpp
scons platform=linux target=release generate_bindings=yes bits=64
cd ..
scons platform=linux target=releaseHowever, I'm unable to find the updated lib/binary in the project? The contents of |
|
Try to clean the build with |
|
@beniwtv: After running I tried deleting Question: You suggested using EDIT: Woops. I accidentally closed (and reopened) this issue. |
|
I tried again with the following combination: and ran into the same issue. While everything compiles, I get the same godot-cpp run-time error in Simula. |
|
And that is with Godot 3.1.1? |
|
This is using the version of Godot compiled from the EDIT: For good measured I tried this with |
|
Is that with or without the Haskell plugin? |
|
It's with the |
|
Can you run plain Godot 3.1.1 + the demo with your compiled module, does that work? |
|
@beniwtv With the demo I'm getting the |
|
I'm really puzzled about that milkyway thing - but I guess you can remove the reference to it and still test if it runs |
|
@beniwtv I removed references to followed by several errors of form that flood the console (probably because controller id needs changed to 1, which I can adjust when I have access to the godot GUI). So it looks like the demo is running fine modulo this issue? |
|
Yes that seems ok to me (the tracker is indeed that it needs to be changed) |
|
So this seems to indicate that the call to Which indicates that when we call EDIT: Our Haskell binding bindARVRInterface_initialize
= unsafePerformIO $
withCString "ARVRInterface" $
\ clsNamePtr ->
withCString "initialize" $
\ methodNamePtr ->
godot_method_bind_get_method clsNamePtr methodNamePtr
{-# NOINLINE bindARVRInterface_initialize #-}
instance Method "initialize" GodotARVRInterface (IO Bool) where
runMethod cls
= withVariantArray []
(\ (arrPtr, len) ->
godot_method_bind_call bindARVRInterface_initialize (coerce cls)
arrPtr
len
>>= \ (err, res) -> throwIfErr err >> fromGodotVariant res)just wraps a call to (in psuedo-code): |
|
I suspect there is some weird interaction between the two modules. We did have an issue some time ago where a return value would not be passed correctly from the module to Godot. I am wondering if something similar is happening here. Or - the Haskell module is compiled against a different and incompatible GDNative definition than the OpenVR module. @BastiaanOlij any ideas? |
|
One issue that we've had that should have been corrected has to do with a recent change in godot-cpp where all the bindings are now initialised in a single call (not a fan of this solution). This call happened when the first script was constructed through a gdns file. Seeing our singleton gets created waaaaay before that it would result in calls into Godot before the bindings were setup. If that is our problem check if godotengine/godot-cpp#327 is part of the build you're doing. The other thing I've previously had problems with is that you need to specifically add bits=64 to the compile settings for godot-cpp to create the correct names for the files. That was on Windows though. |
|
Using godot_openvr master master + reverting to godot-cpp master. By this I mean I clone the godot_openvr repo and run before compiling as usual. This both gets past the godot-cpp launch error above and allows me to run the demo (w/o the strange Milkyway.png error). However, the demo only launches whenever I start it without a controller. If I launch the demo with a controller, or I launch the demo without a controller and then turn it on, I get the following godot-cpp runtime crash: |
|
Yeah that looks like the crash that was present during the rewrite to godot-cpp, and was later solved, as far as I know. I suspect either the index of the material is wrong or the material is not loaded yet - or correctly. Let me see if I can reproduce this somehow (I did update my branches to current master + what godot-cpp version was linked there on Monday). |
|
ok so that crash happens because surface_set_material() does not exist in Godot 3.1. It does in the beta of Godot 3.2 and no crash there. But, the .so I compiled that is still in master of GodotVR will work on Godot 3.1, as it is an older build without that function - and no crashes. So I see two options:
|
|
Ok thanks -- this clarifies things a lot. I think I'm leaning towards option (1) right now, though the reason why we're updating godot-openvr is due to the HMD freeze issue (#55), which occurs for us (even with the latest godot-openvr). |
|
I'll try to look into that issue - just left a comment there. |
|
Hi there, this is a quite old issue now - can we consider this solved? |
Running Ubuntu 19.04 + nvidia 418.56 + godot on the
3.1branch, I compiledgodot_openvrviaand launched the demo via
The demo looks like this:
but I am not able to use HTC Vive controllers. FWIW I also see a constant stream of
in the console. If I try to run the demo again (running
pkill godotfirst), the demo launches the same except not in my HMD (I only see it in "pancake mode" in the window):sometimes followed by a popup
Note that I only see the table in front of me in pancake mode, not in the actual VR demo.
The text was updated successfully, but these errors were encountered: