godotvr / godot_openvr Goto Github PK
View Code? Open in Web Editor NEWGDNative based Open VR module
License: MIT License
GDNative based Open VR module
License: MIT License
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):
This is on an HTC Vive with two vive controllers.
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.
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? ^^
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 --
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.
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:
Accordingly, the global_transform of the ARVRController is actually the same as the transform of a pose-node of raw.
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
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
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.
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.
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 am running the godot_openvr demo in Linux with the following branches:
[Sub-]Module | Branch |
---|---|
godot-openvr | master (default) |
godot-cpp | master (reversion) |
openvr | 93df072 (default) |
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'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.
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.
Usage of ARtoolkit (https://artoolkit.org) instead of apple's arkit since the former is open source
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
I'm running Godot w/ARVR support on Ubuntu (19.04) + HTC Vive (generation 1). The crash pattern is:
Launch Godot w/o controller(s)
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
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 --
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?
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:
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?
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.
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
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?
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:
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:
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.
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).
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.
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 :)
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:
Hey @BastiaanOlij -
I got a Windows MR headset for Christmas. Does OpenVR for Godot support Windows MR headsets?
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.
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'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:)
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 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.
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
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
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?
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.
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.
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:
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 (?)).
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:
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?
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.
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.
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
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 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?
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.
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.
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.
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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.