HackPerception

@Mr Harder In short, it has everything to do with compatibility across OEMs and the high bandwidth/low latency requirements. PCIe is about the closest thing you can find to a true universal standard when it comes to PC hardware. You can't use USB because every single OEM develops their own USB hosts and controllers and wires them in a million different ways. Laptops are wired in especially messy ways - virtually each laptop model is uniquely wired. To boot, the wireless adapter uses over 5gbps bi-directional bandwidth and so it needs to have the lowest level of access to the GPU/CPU as possible. We heavily explored USB options - it was impossible to come up with a USB option that would be compatible with any substantial fraction of motherboards/laptops.

@davide445 - This is a really clear case of incompatibility. I'm 100% sure the UHD 620 iGPU is well below the minimum requirements for PCVR. None of the integrate Intel chips will drive PCVR effectively. The UHD 620 is ~5-10x less powerful than a GTX1060 which is the absolute bare minimum req. Even the Intel NUC's that are compatible with first-gen VR have AMD Vega dGPUs rather than use Intel's iGPU solutions. You can troubleshoot USB-C ports via the PhsX page to ensure the USB-C port is connected to the dGPU. In your case though - there is no dGPU.

@RedShift Can you please PM with with more info about your project. Generally speaking, we've only seeded the lip tracker to devteams we have an established relationship with since it's pretty experimental and is strictly developer-facing at this time. Please me know in your message if you already have a Pro eye kit and what you're doing it it.

@William231 - No, that won't work unfortunately. The Elite specifically swaps out the optical tracking face plate for a SteamVR tracking (base station) faceplate. In this configuration - you need base stations for the HMD to have any images. The standard optically tracked Cosmos would be the Cosmos loadout to get if you don't want to deal with base stations. Aside from gaming - there's a tremendous number of non-gaming applications which can only be used on desktop VR currently like Google Earth VR so there's alot more to PCVR than gaming. The Original Vive and Vive Pro require basestations.

@Varnaxes - PM sent

@HSC - I haven't been able to get WebXR working with SteamVR on my test devices lately. I've been trying to hunt down some answers in the backend but WebXR is a particularly weird since so many companies are involved and that market is not really formed yet.

@Kristodian - The Cosmos has the highest display panel resolution of any Vive HMD to date - as a result it has a higher native "per application" rendering resolution You can adjust the "per application" rendering resolution or even the global setting via SteamVR -> Video. This basically adjusts what resolution the application is rendered at which in turn affects the sample that SteamVR grabs to render to the headset. This is where you can make the most difference in the visual perception of the headset resolution as an end-user. The 2D window view on the desktop is a massive resource hog. Developers often disable rendering passes, post processing, and other effects on the 2D window to redirect resources towards the HMD's render output. The "Display VR View" option in SteamVR is going to show the most accurate representation of what the VR-user sees but even then, it's more of an approximation. Framedrops are a pita to try and troubleshoot and causes not only vary from application to application but can be very hyper-system specific. There are so many factors.

As long as the environment is well lit and there are good tracking points - movement doesn't affect it too much. The ML is specifically trying to find the static tracking points in your environment to build an environment map. The roomsetup stage specifically tries to construct that map - if you have people moving around during that stage - that's when it would be most detrimental. I've used Cosmos at conventions (while those existed) and it never really had issues with crowds moving around.

@mrgykesjr - This is super weird. Haven't heard of this one before. I'd recommend trying the procedure linked below as a first step. If it were one controller - I would guess that an impact had knocked loose one of the flex connectors inside of the controller but to have it happen to both and to have it switch between working and not working like that is pretty bizarre.

Hello all - we're putting an increased focus on working 1:1 with affected users as we try to hone in on why Windows appears to be conflicting with the runtimes. If you are affected by this issue, please do the following: Attempt to launch the SR-Runtime and the eye tracking calibration process as you normally would. Be please sure to launch the runtime as an administrator. If the initialization issue occurs, please: Right, click the SR-Runtime icon in the tray and click "pack-log". Save the log somewhere accessible. Generate a SteamVR system report (SteamVR -> Generate System Report -> Save file). Save the log somewhere accessible. PM the log to myself (@VibrantNebula) and I'll forward it to the correct internal teams for further review. As stated above, it does look like reducing the UAC slider to the minimum level does appear to be a possible workaround on PC's where that's acceptable. @huiwang @corey_paganucci @andrea @aarelovich1984 @mrk88 @Nermeen @idontwantthis @PheonixLab @alwyuyang @jboss @tamu.bhp

@akaya0331 - Pm'ed you

@demonslayer I've PM'ed you with instructions on whom to contact for support

@Kaiull If you PM me your SteamVR system report I can try and see if anything stands out. Grey screen usually means tracking loss of some kind.

@Doozer The IP range on Cosmos/Elite is 62mm-72.5mm. You can be a few mm short without it causing problems but most people will start to notice blurring in one or both eyes after 3 or 4mm of offset depending on how the headset is seated on your face.

@Sara You can use/license our SRAnipal SDK to gain feature data. If you need deeper hardware access such as access to the actual imagery - you need to license the TobiiXR SDK/Runtime from Tobii. Bear in mind, you need to have privacy policies in place to deal with data from either of the two SDKs. From the SRAnipal License agreement: This SDK contains software which collects facial images and processes those images into user facial feature data for VIVE Pro Eye or other HTC VR products. Facial feature data includes eye tracking data (such as gaze position, pupil size and eye openness), but not actual images or representations of the face, eyes or lips. Facial feature data but not actual facial images or representations are available to the SDK developer. Information about how this SDK collects and processes facial feature data that the SDK developer can collect and use can be found in the Vive Eye Tracking section of the HTC Learn More page.

In years past, we had content specific forums but they were extremely unused and led to increased fragmentation of the forums. Our statistics have been pretty steady for the last 3 years. About 70-80% of posts are hardware support related, and about 20% are developer focused and any changes we've made on our side don't really drive impact towards shifting the focus. We do have a secondary forum for Viveport that's specifically hardware agnostic and intended for content-related posts. There's lot alot of places to talk content - there are fewer places to get Vive-hardware or Vive-SDK specific support where Vive staff can directly weigh in.

@coolwipmrk If using 2.0 stations, there are three potential causes: Broken Base station. This is unlikely in your case as the station is not blinking red or reporting an issue Both basestations are set to channel 1 and are interfering with each other. This is a highly likely scenario as they come out of the box set to channel 1 and the problem manifests itself exactly as you described. To check/fix this scenario, enable Bluetooth management via SteamVR -> Devices -> Bluetooth Settings. Next go to SteamVR -> Devices -> Base Station Settings -> Configure Base Station Channels. Just hit automatic configuration and it will resolve any conflicts. While here, I recommend enabling power management settings. I'd recommend setting this to "sleep" - it will fully power down the basestation when you're not using SteamVR which will have dramatic effects on the lifespan of your basestation. If it's not a channel conflict, it may be an environmental reflection. The easiest way to verify a reflection is via the method below. To detect reflections, generate a system report or open up the SteamVR web console and search for the term "back-facing". Here's an example of what a reflection that would cause the issues you describe look like below. Sun Jun 26 2016 23:02:09.676 - lighthouse: LHR-4E8EF209 H: Dropped 32312 back-facing hits, 2069 non-clustered hits during the previous tracking session

@troublemaker_na, this is tricky but Cosmos Elite (and the original Vive) ships with 1.0 controllers compatible controllers and are not compatible with 2.0 basestations. If the controllers are black - they're compatible with 1.0 only. If they're blue, they'll work with 2.0 and 1.0 stations. The 2.0 stations lack the required optical sync LEDs to drive 1.0 tracking. The only controllers compatible with 2.0 stations are the blue "Vive Pro" controllers, Index controllers, and then a handful of peripherals like Tracker 2018 and the Logitech stylus.

@SpudTheCat - Shipping lookup is here We contract with regional fulfillment centers for order fulfillment. That tool doesn't get updated with info until the fulfillment center sends an update to our system. The info in this system is generally the most updated info our live chat agents will have. Monday was a business holiday in a number of countries (i.e. Memorial Day in the US) Global logistics are slower overall due to COVID I'd contact support if the tracker doesn't update in a few days, otherwise everything is probably fine and you'll get an update when it ships.

@akaya0331 - I have a bunch of these caps in the SF office I might be able to send to you. It's tricky though since our office has been under mandatory closure for 72 days. I'll see if I can get in this week or ask our Seattle team if they can ship a pair out.

@Smikey_YT The guide they posted is not a valid way to fix base stations. The earliest firmware versions did not have self-diagnostic reporting. This "fix" basically takes the firmware and reverts it to an early version which is unable to detect or report itself as being broken. As a result - it can spew out bad tracking data leading to erratic tracking. As soon as you upgrade to newer firmware, the station can report back to SteamVR that it's not functioning correctly. The station is broken in both scenarios - it's just a matter of it's ability to self-report back the fact that it's broken. These types of things require physical servicing since it's a mechanical problem.

@akaya0331 - What country are you in?

@hammer_on_llc - That's not actually a fix unfortunately. It's a huge misconception within the Vive community - you're basically just rolling back the firmware to an earlier version which lacked self-diagnostics. It doesn't actually fix that your station has a mechanical issue - it just prevents the station from self-reporting that it's broken and in many cases it can allow the station to spew out bad tracking data into your environment causing erratic tracking.

@AppleParfait - No, you can mount 2.0 stations are pretty much any angle you want. Just as long as you do roomsetup with the stations in their final place - you should be fine. The position solve may be inaccurate due to something like an environmental reflections for instance if you have a shiny floor. If you're mounting them straight down - a potential reflection has a lower angle of incidence and directs straight back rather than at an angle so reflections can be more dramatic. Is each of the station on a separate channel? Another cause of this is if the stations are duplicating their broadcast channel.

@Marvel_II - Dell just resells our wireless adapter. The wireless adapter is compatible with Pro Eye but there's a special attachment kit required for Pro since it uses a proprietary cable due to the higher bandwidth.