Hello @BastiaanOlij !

I am currently working around with the new OpenVR actions described in https://github.com/GodotVR/godot-openvr-asset/wiki/OpenVR-actions. While trying to update my features that were originally bound to the controller (like ObjectInteraction and Telportation) i realized that the ARVRController Node seems kind of redundant as all the wished behaviour can also be achieved with the poses of the action-system.

I am having a hard time with design-philosophy now ... Being bound to the controller the mentioned features were originally children of the controller-node according to the design godot's philosophy.

Do you have any suggestions on how to restructure such a code?

A suggestion i have thought of would be to update the controller to a structure like this:

As suggested in the title making the ovr_main.gd or as in my case an extension of this script a tool, will result in the editor crashing.

This does make sense from my point of view as the editor, as well as the executable will try to access open_vr (still its a bit strange the editor crashes without any error message). Do you see any way for a workaround to this?

Hello!

I am new to Godot, I am trying to get a basic overlay working. In a nutshell, I have a viewport setup as an overlay. there is a child texture rectangle that should expand to take the full viewport.

I am rendering a scene on the rectangle. I want to use the rectangle stretching capabilities to make the scene "resolution agnostic" and always be stretched to 1m width in the headset.

I have several headsets, I noticed that because of resolution, my occulus quest display the overlay significantly bigger that my vive index.

The viewport itself is being scaled correctly to 1m width everytime. The issue is the texture rectangle I am trying to apply scales only to the size of my viewport. That size is ignored because it is overriden when being displayed in VR.

Thus the expand property of the texture rectangle does not work:

Godot often crashes after I exit with the following backtrace:

Dumping the backtrace. Please include this when reporting the bug on https://github.com/godotengine/godot/issues
[0] ARVRInterfaceGDNative::is_initialized (c:\users\basti\development\godot3-git\modules\gdnative\arvr\arvr_interface_gdnative.cpp:133)
[1] ARVRInterfaceGDNative::~ARVRInterfaceGDNative (c:\users\basti\development\godot3-git\modules\gdnative\arvr\arvr_interface_gdnative.cpp:49)
[2] ARVRInterfaceGDNative::scalar deleting destructor' [3] memdelete<ARVRInterface> (c:\users\basti\development\godot3-git\core\os\memory.h:118) [4] Ref<ARVRInterface>::unref (c:\users\basti\development\godot3-git\core\reference.h:264) [5] Ref<ARVRInterface>::ref (c:\users\basti\development\godot3-git\core\reference.h:74) [6] Ref<ARVRInterface>::operator= (c:\users\basti\development\godot3-git\core\reference.h:147) [7] Vector<Ref<ARVRInterface> >::remove (c:\users\basti\development\godot3-git\core\vector.h:369) [8] ARVRServer::~ARVRServer (c:\users\basti\development\godot3-git\servers\arvr_server.cpp:328) [9] ARVRServer::scalar deleting destructor'
[10] memdelete (c:\users\basti\development\godot3-git\core\os\memory.h:118)
[11] Main::cleanup (c:\users\basti\development\godot3-git\main\main.cpp:1850)
[12] widechar_main (c:\users\basti\development\godot3-git\platform\windows\godot_win.cpp:151)
[13] _main (c:\users\basti\development\godot3-git\platform\windows\godot_win.cpp:171)
[14] main (c:\users\basti\development\godot3-git\platform\windows\godot_win.cpp:183)
[15] __scrt_common_main_seh (f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:283)
[16] BaseThreadInitThunk
-- END OF BACKTRACE --

This is the OpenVR Interface unloading at the end, but it seems already gone. I'm not sure why its loaded in the first place as it should only be used when run. Need to give this some more thought. Just logging this so I don't forget:)

It'd be great if Godot devs didn't need to set up the whole windows compile toolchains to use this. Could you please upload binaries when reaching significant milestones?

When using a RemoteTransform on a ARVRController the transform of the node is not applied correctly. Could it be that the rotation gets incremented double time?

On latest Godot 3 code (commit 6a4521d) projects that use the OpenVR library will crash the editor on startup.

I got the following backtrace on Sponza:
Dumping the backtrace. Please include this when reporting the bug on https://github.com/godotengine/godot/issues
[0] <couldn't map PC to fn name>
[1] godot_method_bind_call (e:\godot\godot\modules\gdnative\gdnative\gdnative.cpp:83)
[2] <couldn't map PC to fn name>
[3] ARVRInterfaceGDNative::set_interface (e:\godot\godot\modules\gdnative\arvr\arvr_interface_gdnative.cpp:75)
[4] godot_arvr_register_interface (e:\godot\godot\modules\gdnative\arvr\arvr_interface_gdnative.cpp:223)
[5] register_gdnative_types (e:\godot\godot\modules\gdnative\register_types.cpp:358)
[6] register_module_types (e:\godot\godot\modules\register_module_types.gen.cpp:56)
[7] Main::setup2 (e:\godot\godot\main\main.cpp:1136)
[8] Main::setup (e:\godot\godot\main\main.cpp:928)
[9] widechar_main (e:\godot\godot\platform\windows\godot_win.cpp:138)
[10] _main (e:\godot\godot\platform\windows\godot_win.cpp:172)
[11] main (e:\godot\godot\platform\windows\godot_win.cpp:184)
[12] __scrt_common_main_seh (f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:283)
[13] BaseThreadInitThunk
-- END OF BACKTRACE --

Right now we have an issue in Godot (godotengine/godot#36781) that prevents exported games with OpenVR from working, as SteamVR is unable to find actions.json.

The reason is that currently the function we use in the plugin uses ProjectSettings.globalize_path() to point SteamVR to the actions file. But this function returns a relative path in exported games, which SteamVR is unable to handle.

As a temporary workaround, one can set the path manually in the OpenVRConfig object to something like:

OpenVRConfig.set_action_json_path(OS.get_executable_path() + "addons/godot_openvr/actions/actions.json")

Note: Change path as needed, this is just for the default location of the JSON file inside the addon (which we recommend copying to another directory and adapting it as per https://github.com/GodotVR/godot-openvr-asset/wiki/OpenVR-actions).

Note 2: This will probably not work on systems like Android / iOS, adapt as needed (but I think there is no OpenVR there in any case (?)).

Hi,

I cloned and compiled Openvr as explained successfully. However, my first stumble is in the readme at the "Linux otes" section: "You can place the libopenvr_api.so file alongside the libgodot_openvr.so file in the bin folder. "
Which "bin" folder are you referring to? Godot? Steam? My programm?

My second stumble is at the line "/home//.steam/steam/steamapps/" . There is no such folder called "steamapps" in my ./steam/steam folder. Is this because of the broken steam client?

As steam keeps crashing on my Ubuntu, I'd like to use the approach with the run.sh command and bypass as much steam as possible. (yeah I know I gotta use the lib a.s.o) So I tried the following:

1. Imported the demo from the godot_openvr/demo folder. That runs on my screen find.
2. Exported the demo as a binary to /tmp/vrtest.x86_64
3. run: /home/user/.steam/steam/ubuntu12_32/steam-runtime$ ./run.sh /tmp/vrtest.x86_64
   Result:
   I see the same output on my screen as when I run the demo directly from godot. (It only throws the recursive error at me: ERROR: find_by_type_and_id: Condition ' p_tracker_id == 0 ' is true. returned: __null At: servers/arvr_server.cpp:305.

... aaand the Vive remains dark.

How can I debug the problem?

Hey All,

We'll find a nicer place for this soon but just wanted to share some info. I'll be checking in some changes soon where I've added some boxes and codes to the demo controllers so we can visualise the inputs.

I found out the inputs are mapped as follows on Oculus touch controllers.
Axis 0 = Left/Right on the joystick
Axis 1 = Forward/Backward on the joystick
Axis 2 = Front trigger
Axis 4 = Side trigger

Button 1 = B / Y
Button 2 = Side trigger
Button 7 = A / X
Button 14 = Press down analog stick
Button 15 = Front trigger (on/off version of Axis 2)

The menu/home buttons don't give feedback as they are already actions in OpenVR itself.

Hello,

Not sure if I'm on the right mdule, if not I'm sorry.
I have a bug when adding an environment on ARVRcamera in GLES3 (to add depth of field for example).
It's working great on my phone without it, but the moment I add the environment and launch the app with the one click deploy feature, left and right eye are displayed like seen through fly's eyes.
It's working in GLES2, but performances are awful and several effects aren't here.

Edit : looks like it's the depth of field feature that breaks it.

Usage of ARtoolkit (https://artoolkit.org) instead of apple's arkit since the former is open source

Hey @BastiaanOlij -

I got a Windows MR headset for Christmas. Does OpenVR for Godot support Windows MR headsets?

The OpenVR API has the ability to access a number of 3D models related to rendering controllers and other devices.
We should add support in our module to expose that interface.

I have a few Vive Trackers, and when I go to the SteamVR settings > Controllers > Manage vive trackers, I can set their roles (ex: Waist, Left Foot, Right Foot, etc.). It would be useful if I could get their role from ARVRServer, so I could assign my ARVRController nodes to the correct IDs automatically.

For now I think the only way is to either force the user to turn them on in a specific order, or manually assign them in some sort of menu every time the user starts the game.

I'm following the Overlay tutorial available in the openvr asset wiki, but can't get it to work.

My main scene is configured as follows:

Spatial
|- ARVROrigin (with Tutorial's _init() script)
    |- ARVRCamera
    |- ARVRController
    |- ARVRController2
|- Viewport (with OpenVR Overlay script)

When I run the project, two things happen. I get the console error "Condition ' ptrackerid == 0 ' is true. returned: __null"" and a game window appears, which I can control using my headset, but the overlay does not appear inside SteamVR home.

Thanks in advance.

The legacy input API (GetControllerState and friends) is deprecated, and can't even support all the features of newer controllers such as the Valve Index, including finger tracking (skeletal input API). The new SteamVR Input API supports all these new features, and allows users to rebind controls through the SteamVR dashboard.

The new API works by the developer providing a JSON file with information about all the bindings they want, and several more JSON files with default bindings for various controller types. At runtime you get a handle for each of your bindings and query the state of it. More details can be found at: https://github.com/ValveSoftware/openvr/wiki/SteamVR-Input

Be aware that once you enable the SteamVR Input interface, all legacy input will cease to function, including the legacy method of getting controller poses and triggering haptics. Poses and haptics must be handled as "bindings" through the SteamVR Input interface.

I'm aware that developers can probably still implement all of this stuff themselves through C/C++ code, but that's a fair amount of extra work, so it would be helpful if this module took care of the heavy lifting.

Running Ubuntu 19.04 + nvidia 418.56 + godot on the 3.1 branch, I compiled godot_openvr via

git clone --branch master --recursive https://github.com/GodotVR/godot_openvr.git godot_openvr
cd godot_openvr
cd godot-cpp
scons platform=linux target=release generate_bindings=yes bits=64
cd ..
scons platform=linux target=release

and launched the demo via

cd demo
godot
# godot -e # I also tried launching the demo via the editor

The demo looks like this:

but I am not able to use HTC Vive controllers. FWIW I also see a constant stream of

ERROR: find_by_type_and_id: Condition ' p_tracker_id == 0 ' is true. returned: __null
   At: servers/arvr_server.cpp:305.

in the console. If I try to run the demo again (running pkill godot first), 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.

Feedback from Lamberto, have to examine this further.

When the controllers are turned on after Godot starts, they correctly get ids 1 and 2.
When the controllers are turned on before Godot starts, they incorrectly get ids 3 and 4.

Need to fix this.

Not an issue with Rift.

Godot: current master (d482a1d8e8b4e68f2f386ba618cd091c79c20424)
Windows 10
SteamVR 1.7.15
godot_openvr: current master (3f170b7)
Compiled with Visual Studio 2019

When using the GLES3 renderer everything works as expected but when using the GLES2 renderer there is an infinite loading screen inside steam vr an the console outputs:
OpenVR reports: 105

This can be reproduced with the included demo project when switching to GLES2 but any other project I tried so far produced the same error and infinite loading inside the headset.

Note that both the desktop mirror screen as well as the tracking still work with GLES2. Only inside the headset there is the infinite steam loading screen.

When rendering to a secondary viewport, Godot doesn't render or run any viewport code if the size is set to 0,0. As such, the OpenVR code doesn't autosize the viewport. Setting the viewport to any non-zero size fixes this.

In Linux, while rendering to the main viewport works exactly as expected, rendering to a secondary viewport results in a skybox being rendered (not the default one from godot), but no other objects are rendered.

This has changed as of 3.1.1, as a working project brought from 3.0.6 now exhibits this behavior. HDR is turned off ( on all viewports as a precaution) arvr is only turned on on the required viewport, and fps is correctly set. These settings are set both on the viewport object and in the script.

Example project showing this bug can be found at https://github.com/mrmakeit/VR-Viewport-Test

The PrimaryViewport scene works fine, but the secondaryViewport does not render the actual scene at all on the vive. The headset is tracked fine, and the primary viewport renders, just the vr viewport does not.

This setup is using the OVRFirstPerson scene from the "demo/addons/godot-openvr/scenes" folder of this github.

When running and then using an edge of the window to resize causes the PC to lockup.

I am running the godot_openvr demo in Linux with the following branches:

Problem: I am only able to launch the demo exactly twice before having to restart my machine. If I try to launch the demo a third time (using pkill godot each time to close the previous instance), the demo launches but without any VR support. Instead, I only see the demo launch in a godot pancake window, but nothing shows up in my actual Vive HMD, as here:

When this happens I also see:

OpenGL ES 2.0 Renderer: GeForce GTX 1070/PCIe/SSE2
Construct gdnative interface
ERROR: set_msaa: Index p_msaa=8 out of size (5=5)
   At: scene/main/viewport.cpp:2829.
Usage count increased to 2
Usage count increased to 3
OpenVR: initialising OpenVR context

Application in scene (normal) mode.
Unable to init VR runtime: Another app was already launching (117)

in the demo's console output.

Also, in case relevant, I frequently see

"Source 2- Warning: Only one instance of the game can be running at one time."

as here:

aftering launching the demo first time (and I believe sometimes in instances thereafter).

I've hooked up OpenVRPose to attach a node to a VR controller. As long as OVRFirstPerson remains at 0,0,0 everything works as expected. I change the OVRFirstPerson translation and the node with OpenVRPose remains where it originally was (origin of 0,0,0).

User Fafhrd42 on youtube pointed me to this discussion on Steam:
https://steamcommunity.com/app/358720/discussions/0/343788552536936377/)

Sounds like Valve is running behind slightly on their online documentation. Have to further investigate this interface and figure out the best way to provide controller models that react to controller input.

Played around with this for a bit - great work so far!

I'm not sure if this is a bug specific to Linux (if so that bug might be in OpenVR):

• Button press event is working (allthough firing 3 times in a row or so)
• Button release event is not working (and firing constantly for button 0)
• Axis always return 0 (and the trigger code from the demo doesn't move the in-game controller)

This is on an HTC Vive with two vive controllers.

The actions.json config file is a great start for handling the proliferation of controller systems. However, this leaves out hand-tracking, which is not simply another controller with buttons that could be bound. Also, the way the tech is developing, hand tracking could become the most important controller system of all. Already hand tracking systems cost the same as a pair of controllers, and they don't need batteries.

In order to develop for hand tracking before you have a hand tracker, we need a system that maps the controller buttons to hand gestures, that we can then decode. AltspaceVR has this in-game, but the gestures aren't right. For example, they map trigger button to index finger folded in, when maybe this should be thumb and index finger pinch. Then we can develop our tracker UIs for hand tracking at the same time as controller binding, instead of building it for controllers and bodging something to make hands work. We should instead develop for the hands and controllers simultaneously, and then make tweaks to the controller and hand interfaces separately to take advantage of their unique characteristics.

This is a developmental tool for all of us -- to turn controllers into the hand-tracking interface within the API -- so it should be done at a low level in the plugin to get us into good habits in our development workflow. Otherwise to do it this way we would have to wrap the plugin with another layer that bound the two interfaces together, and we shouldn't have to do that if this is an approach that all of us should be adopting.

I'm running Godot w/ARVR support on Ubuntu (19.04) + HTC Vive (generation 1). The crash pattern is:

1. Launch Godot w/o controller(s)

2. Turn on controller, generating the following console output (but Godot will keep running):

   Found openvr device 1 (vr_controller_vive_1_5)
   Creating render model resource
   OpenVR: increased use count to 2
   Argument count: 1
   Searching for: vr_controller_vive_1_5
   

3. Click controller, causing the following crash:

   handle_crash: Program crashed with signal 11
   Dumping the backtrace. Please include this when reporting the bug on https://github.com/godotengine/godot/issues
   [1] /lib/x86_64-linux-gnu/libc.so.6(+0x43f60) [0x7f89de6b1f60] (??:0)
   [2] /home/george/Simula/addons/godot-openvr/bin/x11/libgodot_openvr.so(+0x2b98) [0x7f89d4abfb98] (??:0)
   [3] ARVRInterfaceGDNative::process() (/home/george/SimulaMax/build/godot/modules/gdnative/arvr/arvr_interface_gdnative.cpp:212)
   [4] ARVRServer::_process() (/home/george/SimulaMax/build/godot/servers/arvr_server.cpp:352 (discriminator 2))
   [5] VisualServerViewport::draw_viewports() (/home/george/SimulaMax/build/godot/servers/visual/visual_server_viewport.cpp:252)
   [6] VisualServerRaster::draw(bool, double) (/home/george/SimulaMax/build/godot/servers/visual/visual_server_raster.cpp:107 (discriminator 2))
   [7] VisualServerWrapMT::draw(bool, double) (/home/george/SimulaMax/build/godot/servers/visual/visual_server_wrap_mt.cpp:104)
   [8] Main::iteration() (/home/george/SimulaMax/build/godot/main/main.cpp:1878)
   [9] OS_X11::run() (/home/george/SimulaMax/build/godot/platform/x11/os_x11.cpp:2959)
   [10] /home/george/Simula/addons/godot-haskell-plugin/../..//bin/godot(main+0xdc) [0x115b82e] (/home/george/SimulaMax/build/godot/platform/x11/godot_x11.cpp:56)
   [11] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f89de694b6b] (??:0)
   [12] /home/george/Simula/addons/godot-haskell-plugin/../..//bin/godot(_start+0x2a) [0x115b69a] (??:?)
   -- END OF BACKTRACE --
   

4. The fuller gdb backtrace output is as follows:

   Found openvr device 1 (vr_controller_vive_1_5)
   Creating render model resource
   OpenVR: increased use count to 2
   Argument count: 1
   Searching for: vr_controller_vive_1_5
   [New Thread 0x7fffbe195700 (LWP 5188)]
   
   Thread 1 "godot" received signal SIGSEGV, Segmentation fault.
   0x00007fffed32cb98 in godot_arvr_process (p_data=0x61074c0) at src/ARVRInterface.cpp:347
   347    src/ARVRInterface.cpp: No such file or directory.
   (gdb) bt
   #0  0x00007fffed32cb98 in godot_arvr_process(void*) (p_data=0x61074c0)
       at src/ARVRInterface.cpp:347
   #1  0x000000000154e494 in ARVRInterfaceGDNative::process() (this=0x6112190)
       at modules/gdnative/arvr/arvr_interface_gdnative.cpp:211
   #2  0x0000000002df1ac1 in ARVRServer::_process() (this=0x5af5cd0)
       at servers/arvr_server.cpp:356
   #3  0x0000000002fea1a0 in VisualServerViewport::draw_viewports() (this=0x4f207b0)
       at servers/visual/visual_server_viewport.cpp:250
   #4  0x0000000002fbc351 in VisualServerRaster::draw(bool, double)
       (this=0x4f1db60, p_swap_buffers=true, frame_step=0.019463000819087029)
       at servers/visual/visual_server_raster.cpp:106
   #5  0x0000000002ff0bee in VisualServerWrapMT::draw(bool, double)
   
       at servers/visual/visual_server_wrap_mt.cpp:102
   #6  0x000000000119713c in Main::iteration() () at main/main.cpp:1877
   #7  0x000000000116a5c9 in OS_X11::run() (this=0x7fffffffdb20)
       at platform/x11/os_x11.cpp:2959
   #8  0x000000000115b82e in main(int, char**) (argc=3, argv=0x7fffffffe298)
       at platform/x11/godot_x11.cpp:55

Someone else on a project I'm working on (@KaneTW) inspected libgodot_openvr with debug symbols and found that

arvr_api->godot_arvr_set_controller_button(arvr_data->trackers[event.trackedDeviceIndex], button, true);

is what is crashing, so that this could be a bug with libgodot_openvr.

Does anyone have any thoughts about how to fix this crash?

While trying to attach a view to a Vive tracker, the rotation of the overlays seems to be inverted (or otherwise different than expected) . I might be missing something in how transformations work. When running as a normal app, the rotations seem to work just fine. I'm currently passing the global_transform from a Point3D to try and orientate an overlay with a model of a real world object.

If none of that makes sense, I can work on posting the project on github as an example.

Available from the openVR docs under the IVRChaperone class: https://github.com/ValveSoftware/openvr/wiki/IVRChaperone_Overview

This stackoverflow question asked about it:
https://stackoverflow.com/q/58456217/6618110

Hello,
maybe I do something wrong, but I am not able to compile from source. I get these errors:

PS D:\Godot\godot_openvr> scons platform=windows target=release scons: Reading SConscript files ... scons: done reading SConscript files. scons: Building targets ... cl /Fosrc\ARVRInterface.obj /c src\ARVRInterface.cpp /TP /nologo -O2 -EHsc -DNDEBUG /MD /Iopenvr\headers /I. /Igodot_headers ARVRInterface.cpp src\ARVRInterface.cpp(473): error C2065: GODOTVR_API_MAJOR: nedeklarovaný identifikátor src\ARVRInterface.cpp(473): error C2065: GODOTVR_API_MINOR: nedeklarovaný identifikátor src\ARVRInterface.cpp(489): error C2440: inicializování: nejde převést z: void *(__cdecl *)(godot_object *) na: godot_string (__cdecl *)(const void *). src\ARVRInterface.cpp(489): note: Žádná z funkcí s tímto názvem v oboru se neshoduje s cílovým typem. src\ARVRInterface.cpp(489): error C2440: inicializování: nejde převést z: void (__cdecl *)(void *) na: godot_int (__cdecl *)(const void *). src\ARVRInterface.cpp(489): note: Žádná z funkcí s tímto názvem v oboru se neshoduje s cílovým typem. src\ARVRInterface.cpp(489): error C2440: inicializování: nejde převést z: godot_string (__cdecl *)(const void *) na: godot_bool (__cdecl *)(const void *). src\ARVRInterface.cpp(489): note: Žádná z funkcí s tímto názvem v oboru se neshoduje s cílovým typem. src\ARVRInterface.cpp(489): error C2440: inicializování: nejde převést z: godot_int (__cdecl *)(const void *) na: void (__cdecl *)(void *,godot_bool). src\ARVRInterface.cpp(489): note: Žádná z funkcí s tímto názvem v oboru se neshoduje s cílovým typem. src\ARVRInterface.cpp(489): error C2440: inicializování: nejde převést z: void (__cdecl *)(void *,bool) na: godot_bool (__cdecl *)(const void *). src\ARVRInterface.cpp(489): note: Žádná z funkcí s tímto názvem v oboru se neshoduje s cílovým typem. src\ARVRInterface.cpp(489): error C2440: inicializování: nejde převést z: godot_bool (__cdecl *)(const void *) na: godot_bool (__cdecl *)(void *). src\ARVRInterface.cpp(489): note: Žádná z funkcí s tímto názvem v oboru se neshoduje s cílovým typem. src\ARVRInterface.cpp(489): error C2440: inicializování: nejde převést z: godot_bool (__cdecl *)(const void *) na: void (__cdecl *)(void *). src\ARVRInterface.cpp(489): note: Žádná z funkcí s tímto názvem v oboru se neshoduje s cílovým typem. src\ARVRInterface.cpp(489): error C2440: inicializování: nejde převést z: godot_bool (__cdecl *)(void *) na: godot_vector2 (__cdecl *)(const void *). src\ARVRInterface.cpp(489): note: Žádná z funkcí s tímto názvem v oboru se neshoduje s cílovým typem. src\ARVRInterface.cpp(489): error C2440: inicializování: nejde převést z: void (__cdecl *)(void *) na: godot_transform (__cdecl *)(void *,godot_int,godot_transform *). src\ARVRInterface.cpp(489): note: Žádná z funkcí s tímto názvem v oboru se neshoduje s cílovým typem. src\ARVRInterface.cpp(489): error C2440: inicializování: nejde převést z: godot_vector2 (__cdecl *)(const void *) na: void (__cdecl *)(void *,godot_real *,godot_int,godot_real,godot_real,godot_real). src\ARVRInterface.cpp(489): note: Žádná z funkcí s tímto názvem v oboru se neshoduje s cílovým typem. src\ARVRInterface.cpp(489): error C2440: inicializování: nejde převést z: godot_transform (__cdecl *)(void *,godot_int,godot_transform *) na: void (__cdecl *)(void *,godot_int,godot_rid *,godot_rect2 *). src\ARVRInterface.cpp(489): note: Žádná z funkcí s tímto názvem v oboru se neshoduje s cílovým typem. src\ARVRInterface.cpp(489): error C2440: inicializování: nejde převést z: void (__cdecl *)(void *,godot_real *,godot_int,godot_real,godot_real,godot_real) na: void (__cdecl *)(void *). src\ARVRInterface.cpp(489): note: Žádná z funkcí s tímto názvem v oboru se neshoduje s cílovým typem. src\ARVRInterface.cpp(487): error C2078: moc velký počet inicializátorů scons: *** [src\ARVRInterface.obj] Error 2 scons: building terminated because of errors.

Can anyone help me, please?
Best regards,
jindrichus

Complete noob when it comes to VR, but I managed to get it working fine on windows, and been trying to get it to work on Linux. Godot itself runs just fine and the basic tutorial scene im following works on windows. But Linux is my main dev station.

Here`s a terminal dump :

`Running: /home/statix/Downloads/Godot_v3.2.1-stable_x11.64 --path /home/statix/Dropbox/work/godotVR --remote-debug 127.0.0.1:6007 --allow_focus_steal_pid 18022 --position 768,420
Godot Engine v3.2.1.stable.official - https://godotengine.org
OpenGL ES 3.0 Renderer: GeForce GTX TITAN X/PCIe/SSE2

Usage count increased to 2
Usage count increased to 3
OpenVR: initialising OpenVR context

Application in scene (normal) mode.
Main OpenVR interface has been initialized
Main render models interface has been initialized.
Found base station 1 (lh_basestation_vive)
Found base station 2 (lh_basestation_vive)
Found controller 3 (vr_controller_vive_1_5)
Found controller 4 (vr_controller_vive_1_5)
Found controller 16 (generic_controller)
Controller vr_controller_vive_1_5_3 became active
Loading: vr_controller_vive_1_5
Controller vr_controller_vive_1_5_4 became active
Loading: vr_controller_vive_1_5
shaders/vulkan/distort_vs.spv
shaders/vulkan/distort_vs_layered.spv
shaders/vulkan/distort_vs_nd.spv
shaders/vulkan/distort_vs_latest_nd.spv
shaders/vulkan/distort_vs_layered_nd.spv
shaders/vulkan/distort_vs_reproject.spv
shaders/vulkan/distort_vs_reproject_nd.spv
shaders/vulkan/distort_vs_reproject_mv.spv
shaders/vulkan/distort_geom_vs.spv
shaders/vulkan/distort_geom_curved_vs.spv
shaders/vulkan/distort_geom_uvs_embedded_vs.spv
shaders/vulkan/distort_geom_curved_uvs_embedded_vs.spv
shaders/vulkan/distort_geom_ptnorm_vs.spv
shaders/vulkan/distort_geom_ptnorm_curved_vs.spv
shaders/vulkan/distort_geom_ptnorm_uvs_embedded_vs.spv
shaders/vulkan/distort_geom_ptnorm_curved_uvs_embedded_vs.spv
shaders/vulkan/distort_geom_fresnel_vs.spv
shaders/vulkan/distort_geom_vignette_vs.spv
shaders/vulkan/distort_geom_aa_lines_vs.spv
shaders/vulkan/distort_geom_aa_circles_vs.spv
shaders/vulkan/distort_geom_hard_bounds_aa_lines_vs.spv
shaders/vulkan/distort_geom_hard_bounds_aa_squares_vs.spv
shaders/vulkan/distort_geom_aa_quads_vs.spv
shaders/vulkan/distort_geom_grid_vs.spv
shaders/vulkan/distort_none_vs.spv
shaders/vulkan/distort_panorama_vs.spv
shaders/vulkan/panel_mask_vs.spv
shaders/vulkan/downsample_vs.spv
shaders/vulkan/msaa_resolve_vs.spv
shaders/vulkan/tracked_camera_vs.spv
shaders/vulkan/tracked_camera_undistort_vs.spv
shaders/vulkan/tracked_camera_edgefilter_vs.spv
shaders/vulkan/tracked_camera_reprojection_vs.spv
shaders/vulkan/tracked_camera_lines_vs.spv
shaders/vulkan/gpu_measurement_vs.spv
shaders/vulkan/frame_hallucination_vs.spv
shaders/vulkan/motion_smoothing_debug_vs.spv
shaders/vulkan/motion_filter_vs.spv
shaders/vulkan/motion_filter_early_out_vs.spv
shaders/vulkan/unlit_vs.spv
shaders/vulkan/distort_ps.spv
shaders/vulkan/distort_ps_gamma.spv
shaders/vulkan/distort_ps_layered.spv
shaders/vulkan/distort_ps_mc.spv
shaders/vulkan/distort_ps_gamma_mc.spv
shaders/vulkan/distort_ps_layered_mc.spv
shaders/vulkan/distort_ps_nd.spv
shaders/vulkan/distort_ps_gamma_nd.spv
shaders/vulkan/distort_ps_layered_nd.spv
shaders/vulkan/distort_ps_mc_nd.spv
shaders/vulkan/distort_ps_gamma_mc_nd.spv
shaders/vulkan/distort_ps_layered_mc_nd.spv
shaders/vulkan/distort_ps_scene.spv
shaders/vulkan/distort_ps_scene0.spv
shaders/vulkan/distort_ps_scene_blur.spv
shaders/vulkan/distort_geom_ps.spv
shaders/vulkan/distort_geom_multitap_ps.spv
shaders/vulkan/distort_geom_reflect_ps.spv
shaders/vulkan/distort_geom_reflect_multitap_ps.spv
shaders/vulkan/distort_geom_fresnel_ps.spv
shaders/vulkan/distort_geom_vignette_ps.spv
shaders/vulkan/distort_geom_aa_lines_ps.spv
shaders/vulkan/distort_geom_aa_circles_ps.spv
shaders/vulkan/distort_geom_hard_bounds_aa_lines_ps.spv
shaders/vulkan/distort_geom_hard_bounds_aa_squares_ps.spv
shaders/vulkan/distort_geom_aa_quads_ps.spv
shaders/vulkan/distort_geom_grid_ps.spv
shaders/vulkan/distort_none_ps.spv
shaders/vulkan/distort_none_ps_gamma.spv
shaders/vulkan/distort_none_ps_layered.spv
shaders/vulkan/distort_panorama_ps.spv
shaders/vulkan/distort_panorama_dome_ps.spv
shaders/vulkan/distort_panorama_dome_radius_ps.spv
shaders/vulkan/panel_mask_ps.spv
shaders/vulkan/downsample_ps.spv
shaders/vulkan/downsample_srgb_ps.spv
shaders/vulkan/downsample_filter_x_ps.spv
shaders/vulkan/downsample_filter_x_srgb_ps.spv
shaders/vulkan/downsample_filter_y_ps.spv
shaders/vulkan/downsample_filter_y_srgb_ps.spv
shaders/vulkan/msaa_resolve_2x_ps.spv
shaders/vulkan/msaa_resolve_4x_ps.spv
shaders/vulkan/msaa_resolve_8x_ps.spv
shaders/vulkan/tracked_camera_ps.spv
shaders/vulkan/tracked_camera_undistort_ps.spv
shaders/vulkan/tracked_camera_edgefilter_ps.spv
shaders/vulkan/tracked_camera_reprojection_ps.spv
shaders/vulkan/tracked_camera_lines_ps.spv
shaders/vulkan/gpu_measurement_ps.spv
shaders/vulkan/frame_hallucination_ps.spv
shaders/vulkan/motion_smoothing_debug_ps.spv
shaders/vulkan/motion_filter_attenuation_ps.spv
shaders/vulkan/motion_filter_median_ps.spv
shaders/vulkan/motion_filter_cost_ps.spv
shaders/vulkan/motion_filter_blur_ps.spv
shaders/vulkan/unlit_ps.spv
shaders/vulkan/unlit_sint16_ps.spv
shaders/vulkan/unlit_motion_vectors_ps.spv
shaders/vulkan/unlit_motion_cost_ps.spv
shaders/vulkan/unlit_convert_to_nv12_ps.spv
shaders/vulkan/unlit_motion_color_diff_ps.spv
shaders/vulkan/unlit_motion_vector_diff_ps.spv
shaders/vulkan/unlit_motion_attenuation_ps.spv
shaders/vulkan/distort_cs.spv
shaders/vulkan/distort_cs_mc.spv
shaders/vulkan/linepixelsim_cs.spv
shaders/vulkan/linepixelsim2_cs.spv
shaders/vulkan/testgrid_cs.spv
shaders/vulkan/motionvector_cost_cs.spv
ERROR: recover_from_penetration: Condition "shape_idx < 0 || shape_idx >= cs->getNumChildShapes()" is true. Returned: false
At: modules/bullet/space_bullet.cpp:1238.
ERROR: recover_from_penetration: Condition "shape_idx < 0 || shape_idx >= cs->getNumChildShapes()" is true. Returned: false
At: modules/bullet/space_bullet.cpp:1238.
ERROR: recover_from_penetration: Condition "shape_idx < 0 || shape_idx >= cs->getNumChildShapes()" is true. Returned: false
At: modules/bullet/space_bullet.cpp:1238.
ERROR: recover_from_penetration: Condition "shape_idx < 0 || shape_idx >= cs->getNumChildShapes()" is true. Returned: false
At: modules/bullet/space_bullet.cpp:1238.
ERROR: recover_from_penetration: Condition "shape_idx < 0 || shape_idx >= cs->getNumChildShapes()" is true. Returned: false
At: modules/bullet/space_bullet.cpp:1238.
ERROR: recover_from_penetration: Condition "shape_idx < 0 || shape_idx >= cs->getNumChildShapes()" is true. Returned: false
At: modules/bullet/space_bullet.cpp:1238.
ERROR: recover_from_penetration: Condition "shape_idx < 0 || shape_idx >= cs->getNumChildShapes()" is true. Returned: false
At: modules/bullet/space_bullet.cpp:1238.
ERROR: recover_from_penetration: Condition "shape_idx < 0 || shape_idx >= cs->getNumChildShapes()" is true. Returned: false
At: modules/bullet/space_bullet.cpp:1238.
ERROR: recover_from_penetration: Condition "shape_idx < 0 || shape_idx >= cs->getNumChildShapes()" is true. Returned: false
At: modules/bullet/space_bullet.cpp:1238.
ERROR: recover_from_penetration: Condition "shape_idx < 0 || shape_idx >= cs->getNumChildShapes()" is true. Returned: false
At: modules/bullet/space_bullet.cpp:1238.
ERROR: recover_from_penetration: Condition "shape_idx < 0 || shape_idx >= cs->getNumChildShapes()" is true. Returned: false
At: modules/bullet/space_bullet.cpp:1238.
ERROR: recover_from_penetration: Condition "shape_idx < 0 || shape_idx >= cs->getNumChildShapes()" is true. Returned: false
At: modules/bullet/space_bullet.cpp:1238.
ERROR: recover_from_penetration: Condition "shape_idx < 0 || shape_idx >= cs->getNumChildShapes()" is true. Returned: false
At: modules/bullet/space_bullet.cpp:1238.
ERROR: recover_from_penetration: Condition "shape_idx < 0 || shape_idx >= cs->getNumChildShapes()" is true. Returned: false
At: modules/bullet/space_bullet.cpp:1238.
ERROR: recover_from_penetration: Condition "shape_idx < 0 || shape_idx >= cs->getNumChildShapes()" is true. Returned: false
At: modules/bullet/space_bullet.cpp:1238.
ERROR: recover_from_penetration: Condition "shape_idx < 0 || shape_idx >= cs->getNumChildShapes()" is true. Returned: false
At: modules/bullet/space_bullet.cpp:1238.
ERROR: recover_from_penetration: Condition "shape_idx < 0 || shape_idx >= cs->getNumChildShapes()" is true. Returned: false
At: modules/bullet/space_bullet.cpp:1238.
ERROR: recover_from_penetration: Condition "shape_idx < 0 || shape_idx >= cs->getNumChildShapes()" is true. Returned: false
At: modules/bullet/space_bullet.cpp:1238.
ERROR: recover_from_penetration: Condition "shape_idx < 0 || shape_idx >= cs->getNumChildShapes()" is true. Returned: false
At: modules/bullet/space_bullet.cpp:1238.
ERROR: recover_from_penetration: Condition "shape_idx < 0 || shape_idx >= cs->getNumChildShapes()" is true. Returned: false
At: modules/bullet/space_bullet.cpp:1238.
ERROR: recover_from_penetration: Condition "shape_idx < 0 || shape_idx >= cs->getNumChildShapes()" is true. Returned: false
At: modules/bullet/space_bullet.cpp:1238.
ERROR: recover_from_penetration: Condition "shape_idx < 0 || shape_idx >= cs->getNumChildShapes()" is true. Returned: false
At: modules/bullet/space_bullet.cpp:1238.
ERROR: recover_from_penetration: Condition "shape_idx < 0 || shape_idx >= cs->getNumChildShapes()" is true. Returned: false
At: modules/bullet/space_bullet.cpp:1238.
ERROR: recover_from_penetration: Condition "shape_idx < 0 || shape_idx >= cs->getNumChildShapes()" is true. Returned: false
At: modules/bullet/space_bullet.cpp:1238.
ERROR: recover_from_penetration: Condition "shape_idx < 0 || shape_idx >= cs->getNumChildShapes()" is true. Returned: false
At: modules/bullet/space_bullet.cpp:1238.
ERROR: recover_from_penetration: Condition "shape_idx < 0 || shape_idx >= cs->getNumChildShapes()" is true. Returned: false
At: modules/bullet/space_bullet.cpp:1238.
ERROR: recover_from_penetration: Condition "shape_idx < 0 || shape_idx >= cs->getNumChildShapes()" is true. Returned: false
At: modules/bullet/space_bullet.cpp:1238.
ERROR: recover_from_penetration: Condition "shape_idx < 0 || shape_idx >= cs->getNumChildShapes()" is true. Returned: false
At: modules/bullet/space_bullet.cpp:1238.
ERROR: recover_from_penetration: Condition "shape_idx < 0 || shape_idx >= cs->getNumChildShapes()" is true. Returned: false
At: modules/bullet/space_bullet.cpp:1238.
ERROR: recover_from_penetration: Condition "shape_idx < 0 || shape_idx >= cs->getNumChildShapes()" is true. Returned: false
At: modules/bullet/space_bullet.cpp:1238.
handle_crash: Program crashed with signal 11
Dumping the backtrace. Please include this when reporting the bug on https://github.com/godotengine/godot/issues
[1] /usr/lib/libc.so.6(+0x3bd70) [0x7fca4fff6d70] (??:0)
[2] /home/statix/.local/share/Steam/steamapps/common/SteamVR/bin/linux64/vrclient.so(+0x25af12) [0x7fca28d0cf12] (??:0)
[3] /home/statix/.local/share/Steam/steamapps/common/SteamVR/bin/linux64/vrclient.so(+0x109222) [0x7fca28bbb222] (??:0)
[4] /home/statix/.local/share/Steam/steamapps/common/SteamVR/bin/linux64/vrclient.so(+0x29f230) [0x7fca28d51230] (??:0)
[5] /usr/lib/libpthread.so.0(+0x946f) [0x7fca4fc6c46f] (??:0)
[6] /usr/lib/libc.so.6(clone+0x43) [0x7fca500ba3d3] (??:0)
-- END OF BACKTRACE --`

When changing the world_scale property of an ARVROrigin and simultaneously changing its translation, the translation change seems to come into effect with a delay of one frame, while the world scale change comes into effect immediately. This leads to a jumpy image and causes nausea.

My example application (scene world_scale_translation_latency.tscn) implements a "zoom" effect, where world_scale and translation are altered together in such a way, that the ARVRCamera's global world-space position does not change. The relevant snippet in ARVROrigin.gd is:

func update_world_scale_nomove(new_scale):
	var old_scale = world_scale
	var old_campos = $ARVRCamera.translation # relative to ARVROrigin = self
	var new_campos = old_campos / old_scale * new_scale
	translation -= (new_campos - old_campos)
	world_scale = new_scale # YYY

The delay in updating translation inserts one frame where the camera position is wrong, because the world scale is updated already, but the update to translation hasn't happened yet.

In the attached world_scale_bug.zip demo project, you can try this out: With the up/down arrow keys, the world scale can be continuously in/decreased, and with right/left, the same thing can be done in single steps. (translating movement can be done with WASD)

The attached video
world_scale_bug_video.zip demonstrates this: I started by repeatedly pressing Arrow left and right (single step), and in the end I pressed Arrow up and down alternatingly.

System specs:

• HTC Vive Pro
• Windows 10 ver 1803
• SteamVR 2018-05-24 (1527117754) with Async Reprojection Enabled, Allow Reproj Yes(Good) and Force Reproj No(Good)
• OpenVR module version 1.0.3 from the Godot Asset library
• Godot Engine v3.0.3.stable.official.e649ec7

I'm just recording this to see if others experience this as well. I now have a working FPS counter in 3D (I'll add it to the demo project soon) and noticed that while the FPS starts out strong at between 75 - 90 fps it suddenly drops and gets fixed at 45fps. Rendering on the HMD however looks solid.

This makes me wonder if this is OpenVR or Oculus stepping in, possibly something like the timewarp or something. I suspect the VR SDK recognising I'm not reaching a solid 90 fps and decides to do its screen interpolation thing. i.e. we render every even frame and the SDK interpolates every odd frame. Our FPS would be 45 for this to result in 90fps on the HMD.

I don't know if this is an Oculus or OpenVR thing, it may be unique behaviour on the rift. It will be very interesting to see what others experience once I release the Sponza VR demo.

Once godotengine/godot#19171 gets merged we need to update the source code here in the same way I have done here: BastiaanOlij/ARVRSimple#4

Just a reminder to myself to play around with this:

https://github.com/ValveSoftware/openvr/wiki/IVRSystem::ComputeDistortion

Have a few ideas to see if we can speed up rendering.... May not work at all.

S.O. Windows 10 64 bits
openvr version 1.6.10
godot_openvr version from Aug 20 2019, commit: cf9948b

Hello,
in the latest version of the godot_openvr pluggin, if an HTCVive controller gets disconnected and then reconnected when the VR scene is running, the scene crashes, this occurs right after the "activated" signal is sent by the just reconnected controller.

What is suppose to happen:
the HTCVive controller should be able to get disconnected and reconnected without the scene crashing (for example the battery died and its the connected to a charging cable)

Note: if the HTCVive is disconnected when the scene is running and then is turned on, the first connection (hot plugging) works fine

Thanks in advance
Best regards

Hello @BastiaanOlij :)

You asked to test as much as possible on the actions, this is what I am doing right now. To get the idea of what the type: pose actually does i created a small image which might be useful for your wiki.

Each point-mesh visualizes one of the four poses:

caption:

• black: base
• orange: grip
• yellow: tip
• white: raw
• light-blue: a mesh as child node of the ARVRController

Accordingly, the global_transform of the ARVRController is actually the same as the transform of a pose-node of raw.

We have two viewports on the screen in our game, with the ability to instance different player scenes into each of them. A VR player can be instanced into one of the viewports, which then makes it render a mirror of what the VR player sees.

This works fine when instancing the VR player into a viewport once. However, when I delete the VR player and instance a normal PC player into that viewport, the viewport remains stretched. Of course, I set arvr to false on that viewport when deleting the VR player, and I've also tried calling Viewport.set_size_override(false) and setting the viewport size to what it was before. Nothing helped... It seems like initializing the viewport does something unexpected to the viewport it's rendering to.

I have also experienced some strange FPS drops when often initializing and uninitializing the interface into different viewports.

Also, sometimes uninitializing the interface crashes the game with drivers/unix/net_socket_posix.cpp:190 - Socket error: 10054. This seems to be related with a heavy workload (low FPS) while uninitializing, but I'm not 100% sure.

This is happening on a machine with Windows 10, a GTX 2060 and an Oculus Rift, using Godot 3.1.1 with the build from https://github.com/GodotVR/godot-openvr-asset.

Not sure if this was added later or not but when I wrote the original controller code I checked the name of the trackers to determine whether we were dealing with a controller.

This needs to change to using: https://github.com/ValveSoftware/openvr/wiki/IVRSystem::GetTrackedDeviceClass

If this returns TrackedDeviceClass_HMD or TrackedDeviceClass_TrackingReference we skip the tracker.
If this returns TrackedDeviceClass_GenericTracker we need to make sure we do not use tracker ids 1 or 2

Hi, i know this Example is meant for 3.0 but i couldn't help but notice when i built for 3.1 mono there were Lines instead of stars in the Background when playing this scene in Gles2 mode and when playing it in Gles3 there was just a Black screen. i should probably switch back to 3.0.6 in my current usecase but for future Bugfixes i wanted to note this anyway :) later might have something to do with the godot-internal VR server, also under Linux i can't get the project to open at all in 3.1 mono nor 3.1 without mono but that could just be my plain stupidity or would i have to generate new headers? ^^

Could we add some more specific instructions in the readme?

I'm running Godot 3.0.6 stable mono with an Oculus CV1 on windows with ovr_first_person.tscn from the AssetLib instanced as a node and am launching with F5 (play).

SteamVR boots and shows green and identifies the Godot executable. Rotation and position for both the headset and controllers come through great once I figured out I need to attach a script (is there a reason the launch script is not included by default in the .tscn in the AssetLib?) but the headset screens are simple black.

# attached to main scene node
extends Node

func _ready():

    print(ARVRServer.get_interfaces())
	
    var interface = ARVRServer.find_interface("OpenVR")
    if interface and interface.initialize():
        get_viewport().arvr = true

It seems like I'm missing something to trigger rendering on the headset itself. I see the readme mentions a problem with hdr support but doesn't provide instructions how to perform the recommended and it's not clear whether these issues are related.

I don't have a Mac capable of running OpenVR. Also I believe that only Vive is supported at the moment, I don't think you can run an Oculus Rift even if you have the external GPU or one of the new iMacs.

Anyway, I can't test anything on Mac but I did try to compile it just for fun. Got errors, haven't had the time to investigate. Just opening this issue as a reminder I have to find the time :)

Getting mixed responses on the rumble. I've noticed it sometimes gets ignored, don't know why yet. And for me it still has issues with strength.

hello,
I'm battling to get this working on linux, still some final things :

I can compile without problem godot and godot_openvr with a recent linux (mint18)
but when run in steamvr runtime there is an error to load either godot entirely or linking the openvr_gdnative

   At: drivers/unix/os_unix.cpp:407.
ERROR: get_symbol: No valid library handle, can't get symbol from GDNative object
   At: modules/gdnative/gdnative.cpp:346.
ERROR: init_library: No godot_nativescript_init in "res://bin/libgodot_openvr.so" found
   At: modules/gdnative/nativescript/nativescript.cpp:1016.
ERROR: open_dynamic_library: Can't open dynamic library: /media/user/c33fcc09-6632-4e4f-b5ba-0bead6f9102a/godot/godot3/godot/bin/demo/bin/libgodot_openvr.so. Error: /usr/local/lib/libopenvr_api.so: symbol _ZTVNSt7__cxx1119basic_istringstreamIcSt11char_traitsIcESaIcEEE, version GLIBCXX_3.4.21 not defined in file libstdc++.so.6 with link time reference
   At: drivers/unix/os_unix.cpp:407.

it happens the same if you build godot without adding some parameters to oblige CXX11 and run it from the steam runtime

the problem is linked to the fact that SteamVR is a chroot environment and is build on top of very old libs, based on ubuntu12.

so GCC/G++ are v.4.8 and std=c++11 max complient,

the procedure to build an application for steam(vr) seems that you create an entire chroot environment with the valve repo by
apt install schroot
getting the steam-runtime scripts here in your home :
https://github.com/ValveSoftware/steam-runtime
then running
$ (sudo) setup-chroot.sh --amd64
(it will install a chroot in /etc/schroot)

then starting the dev environment (chroot) by
~$ schroot --chroot steamrt_scout_amd64
then compiling godot and godot_openvr in your home somewhere (~/godot3 and ~/godot_openvr f.ex. :) )

but then in godot_openvr SConstruct in linux section:

-- -std=c++14
++ -std=c++11

but then :

 ~/godot_openvr $ scons platform=linux
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
g++ -o src/Image.os -c -std=c++0x -fPIC -g -O3 -std=c++11 -fPIC -Iopenvr/headers -I. -Igodot_headers src/Image.cpp
In file included from src/Image.h:8:0,
                 from src/Image.cpp:9:
src/GodotCalls.h:8:37: fatal error: gdnative_api_struct.gen.h: No such file or directory
 #include <gdnative_api_struct.gen.h>
                                     ^
compilation terminated.
scons: *** [src/Image.os] Error 1
scons: building terminated because of errors.

Is the Oculus Go supported (and if it is, the Quest will probably work as well), and if not, is it being considered doing? I want to buy a Oculus Quest, which runs a modified version of android, and make some games for it. Will I be able to use Godot?

I would like to figure out if and how it would be possible to support the new Valve Index Controller (aka Knuckles) within Godot.

If you don't know what these controllers are, you can find out more here: https://store.steampowered.com/app/1059550/Valve_Index_Controllers/

The basics are: Individual finger tracking, grip can be pressed with dynamic strength.
Joystick + trackpad, discrete face buttons.

I don't know what the best place to start would be but I imagine it should be the OpenVR plugin right here, as I think the basic ARVRController class in Godot has everything needed to make the Index controller usable in a fully featured way, even though the interface might not be very convenient.

Probable TODOs:

• separate trackpad and joystick into different joysticks with independent axis
• map face buttons and joystick click to independent button presses
• map fingers to independent additional joystick axis (rest on controller without pressure = 0.0, go positive or negative with added pressure or spread fingers)

What I'm not quite sure about is how one could identify what type of controller is used.

As I have the hardware I wouldn't mind helping in actually implementing this, with the following caveats, I am a developer but:

• only very minimal C++ experience
• no GDNative experience
• Full-time employed and constrained for time (But aren't we all?)

This is a serious offer but I would probably need some on-boarding.

Dev hardware for the index controller was shipped to a lot of VR devs so I'm looking into what to do to get some for the core developers of this module.

Issue mentioned on reddit here: https://www.reddit.com/r/godot/comments/bxxo69/rendering_freezes_in_vive_headset_in_linux_glesv2/

Need to investigate this, see if we can reproduce it

I think this is made on purpose, but I don't get why would you want this behavior.
I understand the idea for this anchor is for stuff that should be always visible on your face regardless of where you are looking at, isn't it?

I think there may be a possible issue when using this add-on in conjunction with the Vive wireless adapter. I Recently got a wireless adapter and noticed that a generic tracker is being slotted into the left hand role (controllerId:1).

Feel free to close if this is a known/configuration issue or if the issue is with the OpenVR SDK.

Specs

Processor: Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz (8 CPUs), ~4.0GHz
Memory: 32768MB RAM
Headset: 1st gen HTC Vive w/HTC wireless adapter
Card name: NVIDIA GeForce GTX 1070

Godot Version: v3.1.1.stable.mono.official
OpenVR module version: 1.0.4

Logs

godot

Found openvr device 1 (generic_tracker)
Found openvr device 2 (lh_basestation_vive)
Found openvr device 3 (lh_basestation_vive)
Found openvr device 4 (vr_controller_vive_1_5)
Found openvr device 5 (vr_controller_vive_1_5)
Found openvr device 16 (generic_controller)

in-script:

GetTrackerCount(): 4
tracker0 - index:0, GetName():generic_tracker_1, GetType():Controller, GetHand(): LeftHand
tracker1 - index:1, GetName():vr_controller_vive_1_5_4, GetType():Controller, GetHand(): RightHand
tracker2 - index:2, GetName():vr_controller_vive_1_5_5, GetType():Controller, GetHand(): HandUnknown
tracker3 - index:3, GetName():generic_controller_16, GetType():Controller, GetHand(): HandUnknown

in-script (controller context):

controller1 - GetControllerId():1, GetName():generic_tracker_1, GetHand():LeftHand
controller2 - GetControllerId():2, GetName():vr_controller_vive_1_5_4, GetHand():RightHand
controller3 - GetControllerId():3, GetName():vr_controller_vive_1_5_5, GetHand():HandUnknown