[Vive Open XR documentation and forums outdated]

Cosmos controller profile should work, as well as vive controller

[HOW TO Installing 3rd party APK on Flow NOW]

On 1/9/2024 at 8:13 PM, 위대한코끼리 said:

But in case of VIVE Flow, apps installed from unknown sources are not displayed.

So, after installing apk, I can't run the app installed with adb install, so Please tell me how to run it on VIVE Flow.

Thanks.

@위대한코끼리
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!

[Vive Open XR documentation and forums outdated]

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

[2 issues with Vive Focus 3 and eye-tracking on PC]

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

[2 issues with Vive Focus 3 and eye-tracking on PC]

@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

[Issue：Htc vive pro eye + OpenXR + Unity, Hmd cant display]

@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?

[Wave getting started info missing]

@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.

[Issue with OpenXR and godot (vive pro 2)]

@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)

[what SDK for VIVE Flow]

@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.

[what SDK for VIVE 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.

[what SDK for VIVE Flow]

@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
 

[what SDK for VIVE Flow]

@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
 

[Focus 3的軟體商店(VIVE Business AppStore)軟體上架問題?]

@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

[XR Elite Streaming Extreme Stutter when Focus 3 is fine]

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?

[How to get eye tracking data in unity]

@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/
 

 

[FPS issues depending on unity version when using vive pro2]

@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

[Reduce Unity Wave SDK logging]

@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!

[Unreal WaveVR 5.4.0 package error "MeshCardRepresentation"]

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/

[FPS issues depending on unity version when using vive pro2]

@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

1. Profiler - See what is different at a high level - cpu, gpu, etc. this points to where the bottleneck may be at a high level
2. 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
3. Frame debugger - let's see exactly how the rendering is different if that's the issue https://docs.unity3d.com/Manual/FrameDebugger.html 
4. 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

 

[PLS HELP! Can't use installed APK software(]

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

[htv vive pro, does it support unreal engine 5.3 playback in VR mode?]

@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.

[Aruco marker json file error]

@ε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

[Vive Focus 3 with Tracker 3.0 as head tracker]

@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

[Vive Focus 3 with Tracker 3.0 as head tracker]

@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/

 

[Vive Focus 3 with Tracker 3.0 as head tracker]

 @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