Romain

Hi @VIVE_chengnay, Thank you for the answer. For the controller pose issue, should the controller recover after one reboot ? Because on my end I have to turn on/off the controller several times, sometimes 7-8 times. So if there is anything I could do to make sure the controller always recover after the first reboot that would be nice. Thanks,

Hello, I recently updated the Wave XR Plugin to version 5.6.0 (I was previously on version 5.2.1). Since I did the update when my app opens after leaving sleep mode the controllers position and rotation is not updated anymore as you can see in attached video. If I turn on and off the controllers repetitively they eventually work back correctly but it takes a lot of attempts. I checked the logs but I don't see any specific error logs when the issue happens. I'm pretty sure the issue is related to the XR Interaction toolkit and the use of Action Based XR Controllers because I did the Wave XR Plugin update on several projects that are not using XR Interaction toolkit and everything work fine on them. I initially though this was related to the error below that I had in the editor, but I fixed the error by uninstalling the OpenXR package that was creating the confusion between UnityEngine.InputSystem.XR.PoseControl and UnityEngine.XR.OpenXR.Input.PoseControl and I still got the issue. ArgumentException: Expected control 'pose' to be of type 'PoseControl' but is of type 'PoseControl' instead! Parameter name: path UnityEngine.InputSystem.InputControl.GetChildControl[TControl] (System.String path) (at Library/PackageCache/com.unity.inputsystem@1.4.3/InputSystem/Controls/InputControl.cs:667) Wave.XR.ViveWaveWristTracker.FinishSetup () (at Library/PackageCache/com.htc.upm.wave.xrsdk@5.6.0-r.10/Runtime/ViveWaveWristTracker.cs:125) UnityEngine.InputSystem.InputControl.CallFinishSetupRecursive () (at Library/PackageCache/com.unity.inputsystem@1.4.3/InputSystem/Controls/InputControl.cs:937) UnityEngine.InputSystem.Layouts.InputDeviceBuilder.Setup (UnityEngine.InputSystem.Utilities.InternedString layout, UnityEngine.InputSystem.Utilities.InternedString variants, UnityEngine.InputSystem.Layouts.InputDeviceDescription deviceDescription) (at Library/PackageCache/com.unity.inputsystem@1.4.3/InputSystem/Devices/InputDeviceBuilder.cs:60) UnityEngine.InputSystem.InputDevice.Build[TDevice] (System.String layoutName, System.String layoutVariants, UnityEngine.InputSystem.Layouts.InputDeviceDescription deviceDescription, System.Boolean noPrecompiledLayouts) (at Library/PackageCache/com.unity.inputsystem@1.4.3/InputSystem/Devices/InputDevice.cs:898) UnityEngine.InputSystem.InputManager.RecreateDevice (UnityEngine.InputSystem.InputDevice oldDevice, UnityEngine.InputSystem.Utilities.InternedString newLayout) (at Library/PackageCache/com.unity.inputsystem@1.4.3/InputSystem/InputManager.cs:663) UnityEngine.InputSystem.InputManager.RecreateDevicesUsingLayout (UnityEngine.InputSystem.Utilities.InternedString layout, System.Boolean isKnownToBeDeviceLayout) (at Library/PackageCache/com.unity.inputsystem@1.4.3/InputSystem/InputManager.cs:555) UnityEngine.InputSystem.InputManager.PerformLayoutPostRegistration (UnityEngine.InputSystem.Utilities.InternedString layoutName, UnityEngine.InputSystem.Utilities.InlinedArray`1[TValue] baseLayouts, System.Boolean isReplacement, System.Boolean isKnownToBeDeviceLayout, System.Boolean isOverride) (at Library/PackageCache/com.unity.inputsystem@1.4.3/InputSystem/InputManager.cs:473) UnityEngine.InputSystem.InputManager.RegisterControlLayout (System.String name, System.Type type) (at Library/PackageCache/com.unity.inputsystem@1.4.3/InputSystem/InputManager.cs:321) UnityEngine.InputSystem.InputSystem.RegisterLayout (System.Type type, System.String name, System.Nullable`1[T] matches) (at Library/PackageCache/com.unity.inputsystem@1.4.3/InputSystem/InputSystem.cs:239) UnityEngine.InputSystem.InputSystem.RegisterLayout[T] (System.String name, System.Nullable`1[T] matches) (at Library/PackageCache/com.unity.inputsystem@1.4.3/InputSystem/InputSystem.cs:260) UnityEngine.XR.OpenXR.Input.OpenXRInput.RegisterLayouts () (at Library/PackageCache/com.unity.xr.openxr@1.5.3/Runtime/input/OpenXRInput.cs:141) UnityEngine.XR.OpenXR.Input.OpenXRInput.<RegisterFeatureLayouts>g__OnFirstFrame|7_0 () (at Library/PackageCache/com.unity.xr.openxr@1.5.3/Runtime/input/OpenX Do anyone already had this issue and found a way to fix this ? Here are the unity and package version i'm using: - Unity: 2021.3.13f1 - Wave XR Plugin: 5.6.0-r.10 - XR Interaction Toolkit: 2.0.4 - XR plugin management: 4.2.1 Thanks, Duat_ControllerIssue.mp4

A little update on this, since the release 5.3.0 (https://hub.vive.com/storage/docs/en-us/ReleaseNote.html#release-5-3-0) of the Wave XR Plugin, the main thread is no longer stopped when the user remove the headset which solve my initial issue. Regarding the OnRenderingToBePaused/OnRenderingToBeResumed events since 5.3.0 I think they are no longer triggered since the rendering is no longer Paused when the headset is removed. The weird thing is that, also since 5.3.0, CommonUsages.UserPresence is no longer supported to know when someone is wearing the headset, so there is no longer a way to know when the screens are on or off. For now, I found a workaround by using this asset (https://assetstore.unity.com/packages/tools/integration/pa-proximity-25685#description) but it would be nice to be able to get the userPresence out of the box.

Hello, Just a little update to say that the sample code doesn't seem to work with the latest version of the WaveXRPlugin, however the asset shared by @thylaxene (https://assetstore.unity.com/packages/tools/integration/pa-proximity-25685) still works perfectly. Also I found this post by looking for a replacement for CommonUsages.UserPresence since it's not supported anymore since the release 5.3.0 of Wave XR Plugin and I wondered why it's no longer supported ? Was it replaced by something else I didn't found ? Thanks,

Hey, I had the same issue but this has been fixed in the release 5.3.0 (https://hub.vive.com/storage/docs/en-us/ReleaseNote.html#release-5-3-0) of the Wave XR Plugin so if you still have issue with the main thread being stopped when the headset is removed, try to update to latest version of the Wave XR Plugin. However, there is a small downside to note, since 5.3.0 CommonUsages.UserPresence is not supported anymore if you need to know when a player wear/remove the headset, which is really weird. You can use this asset https://assetstore.unity.com/packages/tools/integration/pa-proximity-25685#description as a workaround. Have a great day.

Hi @JulienActiveMe, Sorry, I just saw your message. Yes I managed to catch OnRenderingToBePaused event, you can using SystemEvent.Listen() from Wave.Essence.Events namespace. Here is an example: private void Start() { // Add the listener SystemEvent.Listen(WVR_EventType.WVR_EventType_RenderingToBePaused, OnRenderingToBePaused); } private void OnDestroy() { // Remove the listener when object is destroyed SystemEvent.Remove(WVR_EventType.WVR_EventType_RenderingToBePaused, OnRenderingToBePaused); } private void OnRenderingToBePaused(WVR_Event_t systemEvent) { // Function triggered when the event is listened }

Hello, I'm working with a Vive Focus 3 and for one of my projects I need to keep the Update running while the screens are off when a user remove the headset. To be precise I need to keep the update running from when the user presence switch to false and the Wave WVR_Event OnRenderingToBePaused is called until the activation of the sleep mode after the duration that we can set in the headset advanced settings. My understanding was that using android wake lock and acquiring the wake lock before the screens turn off would keep the main thread running while the screens are off but in practice the Update still stops to run even if I’m acquiring the wake lock at the start of the app and never release it. I acquire the Wake Lock using Unity AndroidJavaClass and I added the wake lock permissions in the android manifest. To be sure I correctly acquired the wake lock I also used adb dumpsys on the power service and everything seems alright, I see the wake lock on my app. Has anybody already achieved to do this successfully? Does the headset itself prevent you to do that and it’s impossible to keep the Update running when the user is not present or am I missing something? For example, if the main thread continue to run, should I still received event like OnRenderingToBePaused ? It sometimes feels like Wave SDK is forcing to pause everything. Thanks!

Hello, I'm working with Vive Focus 3 and Unity and the fact that the Unity Update function stops to run as soon as the user remove the headset and the screen is turned off is a bit problematic for me. During my experimentation I saw that threads are still running when the screen is turned off so to understand better what happens when the screen is turned off I tried to use WVR_PollEventQueue in a thread to see what events where triggered. My expectations according to the WVR_Event documentation were that when the screen is turned off I should receive the event WVR_EventType_RenderingToBePaused and when the screen turns back on the event WVR_EventType_RenderingToBeResumed but these events are never triggered or at least they never appear when I log the events queued in WVR_PollEventQueue. I am able to log other event like WVR_EventType_DeviceStatusUpdate or WVR_EventType_BatteryStatusUpdate so I know that some events works well but I never receive the event I was expecting. Am I missing something, is this normal I never see these events ? I also saw in code comments that the events WVR_EventType_DeviceSuspend and WVR_EventType_DeviceResume that are obsolete were also triggered by removing and putting on the headset. Since, they are now obsolete my guess was they have been replaced by RenderingToBeResumed and RenderingToBePaused but I also saw that there is a call WVR_IsDeviceSuspend in the native SDK so I tried to use it thinking that it would return true when the user take off the headset but it always returns false. Is WVR_IsDeviceSuspend also obsolete ? If it's not the case when should it's value be changed from false to true ? Thanks and have a great day !

Hello, Is there any news regarding this ? I am working with Vive Focus 3 headsets and I would like my Unity app to continue to run after the user take off the headset and the screen are turned off during the delay before the headset switch to standby mode. From my current experimentations, the Unity Update function stops to run as soon as the screen are turned off and the only way to run something when the screen is off is to start a thread. A thread will continue to run as long as the headset does not switch to standby mode but this is still an issue for code that need to run on the main thread. Thanks !

Thanks for the explanation @smeer !

Hi @smeer, thanks a lot the workaround B is working perfectly on my side. I just have a question to understand better how the layout works, in the functions FinishSetup(), when we get the childControl GetChildControl<ButtonControl>(path) what does the argument path refer to ? It does not seems to be a specific path that lead to specific controller data so I was wondering how the layout link the controller inputs to a specific InputControl ? I don't know if it really clear 😅 but I mean how does the layout know that the ButtonControl primaryButton must get the data from the A/X buttons and the ButtonControl secondaryButton the data from the Y/B buttons for example ? Regarding the workaround A, on my side I was already using the common usages and the position and rotation of the headset was working well but I had nothing on the controllers side : no button inputs and the position, rotation were not updated.

Hello, I have the same issue that @aseton is describing. I'm porting a prototype from that work well on Quest 1 & 2 and Pico Neo 3 on the Focus 3 but we are using the Action-based XRController and like aseton said with it we don't have any positional, rotational or buttons inputs generated. On our side the main advantage of using the Action-based XRController is to take advantage of the new inputs system and its link with XR Interaction Toolkit. All of our interactions are based on the Action-based XRController so having only one type of VR Rig that works the same way with every different headsets is a huge advantage for us. Adapting all our interactions to the device-based XRController for the Focus 3 is definitely possible but it seems like a lot's of work when it works out of the box with the other headsets 😄. Best,