Alex_HTC

Cosmos controller profile should work, as well as vive controller

@위대한코끼리 Go to library, click the upper right button, and you should see options, including 'unknown sources'. https://www.vive.com/us/support/vive-xr/category_howto/accessing-apps-in-library.html Thanks for asking!

Howdy @cheesepants It looks like the interface has changed a bit, depending on the unity version. Is the current equivalent drop down if you're using our openxr 2.0 package here https://developer.vive.com/resources/openxr/unity/tutorials/how-to-install-vive-openxr-plugin/ Likely older versions of the openxr plugin would work, but we do fix things when we make these updates 🙂 Likely this is just the ui change in unity, depending on your unity version. Regardless, we'll take a look at this - I appreciate the feedback! -Alex

Can you also try the face gym sample for reference? https://github.com/ViveSoftware/FaceGym

@Ilia Howdy, I'm inquiring further, but I believe eye tracking with the focus 3 is a fairly common configuration. 1) What version of the focus3 system software are you on? 2) What version of VBS are you currently on? Can you try accepting the eula by launching sranipal app instead of modifying the configuration? There have been a few updates where you may need to be on newer vbs and system versions I'm unsure if it works in the editor, so can you try a pc build (with wave enabled on both android and pc) and tell me if you get the same error? Thanks, Alex

@MiyiiCan you help me understand why it would say that it thinks that the headset is not plugged into the same graphics card as your primary monitor?

@jbossThe android manifest issues you're seeing are from using wave 3.x features in the manifest. I'm guesing you got a manifest from an old version of the manifest guide, as the current one is using the 4x features and uses the theme android:theme="@style/Theme.WaveVR.Black". This gets auto-added to your manifest by current apis, and the only thing you should need to add for store submission are the controller section: <!-- Disable Controller Pairing (set to 'true' to skip controller pairing dialog) --> <meta-data android:name="no_controller_pairing" android:value="false" /> <!-- Documentation: https://hub.vive.com/storage/app/doc/en-us/ConfigureAppCapabilities.html --> <!--Please consider the DoF support of HMD and controller individually for your content.--> <!--Set value “3DoF” if your content only considers the rotation pose. --> <!--Set value “6DoF” if your content considers both rotation and position pose. --> <!--Set value “3,6DoF” if your content is capable of supporting both 3 and 6 DoF playing. --> <meta-data android:name="com.htc.vr.content.NumDoFHmd" android:value="3,6DoF"/> <meta-data android:name="com.htc.vr.content.NumDoFController" android:value="3,6DoF"/> <!--The value could be 0, 1 or 2. Use comma(,) between value if your content can support multiple cases.--> <!--Set value “0” if your content supports gaze mode only. --> <!--Set value “1” if your content only supports playing with one controler. --> <!--Set value “1,2” if your content supports playing with either one controler or two controlers. --> <!--Set value “0,1,2” if your content supports all cases, which mean user can play by gaze mode, one controller or two controllers. --> <meta-data android:name="com.htc.vr.content.NumController" android:value="1,2"/> <!-- The maximum Wave SDK API level which your app uses, default value is 1. --> <!-- https://hub.vive.com/storage/docs/en-us/Sdk_WvrVersionCheck.html --> <meta-data android:name="minWaveSDKVersion" android:value="1" /> For development, you shouldn't need to add the manifest, so deleting it for now will work fine.

@Ronan13 Howdy! I'm guessing there's a button mapping issue? What button or action causes you to get to the next screen? I believe I had success running https://github.com/GodotVR/godot-xr-template Two thing to check: 1)Turn off meta plugin compatibility - as the xr loader for meta causes havoc with other xr plugins. you may need to restart steamvr 2)Try changing to steamvr openxr runtime(or visa-versa)

@ruiyingWhat link did you use to buy the eye tracker that's being used with the flow? If my memory serves me, we only have an eye tracker accessory for the focus3 and not the flow.

@ruiying this is the section that shows the eye tracker setup is in the menu What link did you use to purchase the eye tracker? This might help me understand if there is some other issue.

@ruiying The ipd is set on the headset, to be clear not the unity project (unless doing multipass rendering). So try single pass rendering, otherwise your ipd won't match your physical ipd. The eye calibration I was referring to previously will be under settings->inputs->eye tracker. A more full list of steps is here https://business.vive.com/us/support/focus3-eye-tracker/category_howto/calibrating-eye-tracker.html

@ruiying Have you run the eye calibration? This likely would be a little weird without it. Are you on single pass rendering? In multi-pass rendering, the eye distance is set by the developer by manually moving the two cameras apart, but this is an unusual configuration In single pass rendering, it is my understanding that this is set by the system IPD settings and the eye calibration setup

@weigo Hi, Ideally, the developer opts in to the vive business app store when releasing the product, this is done on https://developer.viveport.com/console/ The developer then need to check this box: And then it will go through QA and review. You can contact the company at https://www.seevividly.com/contact In addition, with some effort there may be a way to sideload the application You could always try to side load the application using adb or sidequest advanced installer. -Alex

Can you check the network signal strength using a tool like wifi analyzer https://play.google.com/store/apps/details?id=com.farproc.wifi.analyzer and maybe alter the channel that your router is on in response to one with less interference?

@aaaqw wave: https://hub.vive.com/storage/app/doc/en-us/UnityXR/UnityXREyeTracking.html https://developer.vive.com/resources/vive-sense/eye-and-facial-tracking-sdk/videos/intro-vive-eye-tracking-sdk/ https://hub.vive.com/storage/app/doc/en-us/UnityXR/UnityXREyeExpression.html openxr: https://developer.vive.com/resources/openxr/openxr-mobile/tutorials/unity/getting-data-eye-gaze/

@unityKingMy first step would be to eliminate the adaptive quality settings, both by removing that option from newer versions of urp and by removing all other quality settings. When it comes to other optimizations, the specific subsystems impacted woudl be teh start - is it extra memory, too much cpu, etc Links for relevant resources are in the above post as well. Those would be a starting point before the unity forums or other urp-adjacent tech communities like the urp forum would be able to help. Thanks, Alex

@AndyKorth Great question! I have been meaning to refine my own techniques in this regard, as I tend to look at a lot of logs 🙂 Maybe someone else can chime in with additional tricks/etc, but here are a few top-level ones: 1) Filters on adb - both the in-unity logcat logger and cli support high-level filters to ignore system processes. If you're not seeing some odd behavior that involves the system(in which case, i tend to use as-unfiltered as possible), this is my default filter string. adb logcat -s Unity ActivityManager PackageManager dalvikvm DEBUG I also wrap it up in a bat or bash file in my path so i can run it more easily as well. And you could probably remove a few of those as well, since for 90% of the time Unity is the only relevant tag. 2) Filters on the wave logging. Thankfully, there's a feature on the projectSettings WaveXRSettings that allows you to adjust the logging to your taste. It's not Microsoft.Extensions.Logging (which is not yet appropriate for all sdk-level unity logging) but it's fairly configurable. 3) Make your own tag, and filter on that - i think there may be a cleaner way to do this, but I've used similar code to this fellow dev AndroidJavaClass logClass = new AndroidJavaClass("android.util.Log"); logClass.CallStatic<int>("v", "Test", "Log.v"); logClass.CallStatic<int>("d", "Test", "Log.d"); logClass.CallStatic<int>("i", "Test", "Log.i"); logClass.CallStatic<int>("w", "Test", "Log.w"); logClass.CallStatic<int>("e", "Test", "Log.e"); Debug.Log("Debug.Log"); Debug.LogWarning("Debug.LogWarning"); Debug.LogError("Debug.LogError"); I get Test V Log.v Test D Log.d Test I Log.i Test W Log.w Test E Log.e Unity W Debug.LogWarning Unity E Debug.LogError Thanks for the feedback, it helps us honest!

When updating, i believe there are a few key steps - #1 remove old plugin, use new plugin https://developer.vive.com/resources/openxr/unreal/unreal-download/latest/, and clean project before building check relevant upgrade guide if relevant: https://developer.vive.com/resources/openxr/unreal/unreal-upgrade-guide/unreal-upgradeguide-mobilevr/ https://developer.vive.com/resources/openxr/unreal/unreal-upgrade-guide/unreal-upgradeguide-pcvr/

@unityKing Howdy! It is always frustrating dealing with performance issues. The hardest part is isolating a specific portion of your code that responds to changes. Looking quickly, my guess is that either adaptive performance or some detail of the upgrade instructions across these versions of urp need to be followed: https://docs.unity3d.com/Packages/com.unity.render-pipelines.universal@16.0/manual/upgrade-guides.html Ok, so now you've identified unity and perhaps versions as a variable! So we have some clues that point to the URP and it's dependencies(ie render pipeline, burst, or the project version shaders/effects themselves on rare occasion. So it looks like unity's been changing things for the past 3 years, let's see just for the universal pipeline: https://docs.unity3d.com/Packages/com.unity.render-pipelines.universal@16.0/changelog/CHANGELOG.html Looking at just 'performance' related issues, adaptive performance was added - so may want to make sure this is 'off' in newer versions to rule this out as a factor. First off, let's look at some potential issues that could happen when auto updating: https://docs.unity.cn/Packages/com.unity.render-pipelines.universal@12.1/manual/known-issues.html and let's make sure that the shaders/related ifdefs/etc are updated when changing the versions (as the auto-updater may change and/or add fixes as well) https://docs.unity3d.com/Packages/com.unity.render-pipelines.universal@10.0/manual/upgrading-your-shaders.html and https://docs.unity3d.com/Packages/com.unity.render-pipelines.universal@16.0/manual/features/rp-converter.html if we look at https://docs.unity.cn/Packages/com.unity.render-pipelines.universal@12.1/manual/requirements.html we can see that the relevant urp versions are directly related to the editor version. 2020.3.12 - Urp package version range: 10.x 2022.3.5 - URP package version 14.0.x 2023.1.10f1 - URP package version 16.0.x There is instructions for updating across versions here https://docs.unity3d.com/Packages/com.unity.render-pipelines.universal@16.0/manual/upgrade-guides.html that goes in detail for each version, these may be different and require re-running across new versions. Other tools to figure out performance issues Profiler - See what is different at a high level - cpu, gpu, etc. this points to where the bottleneck may be at a high level Memory profiler - overview - with different versions may come different usage of temporary buffers/etc. shuffling bits around is expensive - this can point to mis-matched texture sizes Frame debugger - let's see exactly how the rendering is different if that's the issue https://docs.unity3d.com/Manual/FrameDebugger.html Other resources Other potential factors - what version of the wave or openxr sdk is being used across these different versions as well -double check the same quality settings are being used across projects (as this is also how the adaptive performance stuff worked, this seems likely - removing all other qualtiy settings would likely help eliminate this factor) -does this also happen if the project is on the built-in render pipeline? -other dependencies of the rendering pipeline and their related changes

Also try looking in the 'unknown' or '2d apps' areas of the launcher (there's a filter tab in the upper right).

@RickyYe Howdy, Great question! We fully support unreal 5.3 - first, one needs to install our openx plugin, starting here: https://developer.vive.com/resources/openxr/unreal/unreal-tutorials/viveppenxrplugininstallation/ Openxr requires a vendor-specific plugin at the moment for each platform, and they 'load' the openxr runtime in incompatible ways. This feels silly for developers and it is something that we're working with the openxr committee to address.

@εscape howdy, There is a syntax error in the file, likely due to some input errors. In the json, a period character is expected to be used between whole and fraction numbers, ie 0.0 . In the linked file, a comma is used, which causes a syntax error

@OneBonsai Another line of thinking -- configuration other than just firmware and environment: If unity: Don't forget to check the 'move deadzone' and 'drag threshold multiplier' settings here and tune as appropriate https://docs.unity3d.com/Packages/com.unity.xr.interaction.toolkit@2.5/manual/ui-setup.html and if using interactables, then there are a number of smoothing/damping options that would cause this as well https://docs.unity3d.com/Packages/com.unity.xr.interaction.toolkit@2.5/manual/general-setup.html Other folks seem to report having general success at getting updates from these at 90hz as well (and are able to swing this on a rope around their head at high speed and get reliable updates) So another approach would be to look at the debugger and log the behavior https://docs.unity3d.com/Packages/com.unity.xr.interaction.toolkit@2.5/manual/debugger-window.html

@OneBonsaiI'd be remiss if i iddn't mention the developer guidelines which may help with some of the orientation/etc questions https://developer.vive.com/resources/hardware-guides/vive-tracker-developer-guidelines/ Along with another great overview here: And perhaps some other ways to offset position and set the role using other mechanisms https://forum.htc.com/topic/9821-tracked-object-orientation-problem-htc-vive-tracker/#comment-41135 https://forum.unity.com/threads/how-to-flip-vive-tracker-from-horizontal-to-vertical-zero-position.879517/

@OneBonsai Howdy! 🙂 Thank you for sharing the specifics of your setup and the challenges you're facing. It's clear that maintaining a high level of immersion is crucial for your training simulators, and every detail counts. Regarding the use of the head position as the position of the puck, I understand that this approach is intended to optimize tracking accuracy and reduce latency. This decision appears to be driven by the need for precise, real-time tracking, which is essential in your use case. The differences between the head and puck in terms of tracking behavior, such as default polling frequency and interpolation settings, could indeed play a significant role in the performance you're observing. To delve deeper into this, it would be helpful to know more about the technical environment of your setup: Engine and SDK Details: What game engine are you using, and which version is it? Are you utilizing our native 'Wave' SDK, OpenXR, or another SDK? Knowing the version of the SDK and, if applicable, the version of the XR interaction system in Unity, will be crucial. These details are important as the solution might involve tweaking engine settings or modifying how data is polled from the input system. Physical Environment Considerations: Reflective surfaces and physical obstructions in the tracking environment can affect tracking quality. Evaluating these factors could provide insights into the discrepancies you're experiencing. Firmware of the Trackers: Ensuring that all trackers are updated to the latest firmware is essential. Here's a link for reference and guidance on updating the firmware: Vive Tracker Firmware Update. OpenXR Backend: Are you using the Vive or Steam runtime backend for OpenXR? Switching between these might resolve some tracking inconsistencies. How to setup correct OpenXR runtime https://service.viveport.com/hc/en-us/articles/4423262844813-How-to-setup-correct-OpenXR-runtime Finally, revisiting the initial configuration and recalibration of devices could be a necessary step. In some cases, recalibration can significantly improve tracking performance and accuracy. We're always excited to hear about more great realistic training simulations, and your persistence is commendable. I'm eager to assist in resolving these challenges. Any additional information you can provide regarding the above points will be instrumental in finding a suitable solution. Thanks, Alex