HackPerception

@Nemmy1234 - the cable is about 4.67m (~184 inches) from the linkbox to the cable guide at the back of the headband, and then another ~.25 meter or so from where the cable meets the headstrap to where it actually plugs into the HMD. Much like the Vive Pro and other current gen headsets - aftermarket extensions are not something that falls within our primary scope of support due to the specifications and constraints of the Displayport 1.X protocol. Displayport 1.x has length restrictions (which are mediated by bandwidth and latency). Extensions will fall into "mod" territory - advanced users will likely be able to find solutions for some use cases but overall it's not within the offical scope of support. Consumer HMD's push Displayport to the spec's limits. Our product teams are still finalizing some of the details on the Cosmos wireless attach kit - more info on that will come very soon.

@arupmassmotion - The SteamVR/OpenVR SDK is pretty fluid in the last few months due to Index's release. As it's a Valve managed SDK - I'd recommend posting a detailed issue report in the "Issues" section of the OpenVR Github and x-posting to Valve's SteamVR discussion board. That said, I'm a little confused by this report - it sounds like the runtime updated but not the SDK/plugin and you're getting an engine error rather than a runtime error. The return code for that error is copied below - it's referring to the assets in your scene - it may be that you now have an asset that's incompatible rather than being due to a change in the SteamVR SDK/runtime. - TextureUsesUnsupportedFormat (scene textures must be compatible with DXGI sharing rules - e.g. uncompressed, no mips, etc.)

@vasanthkalai - Lastly what's your SteamVR plugin version? That should be enough info to get the VIU team off on the right track?

Hello @vasanthkalai - I've tagged a member of the VIU team onto the thread for assitance. Can you please confirm your target hardware (as VIU supports multiple hardware platforms)?

@paco67 - Tobii's native documentation is not really applicable to this product (Vive Pro Eye) in terms of the SDK/APIs. As this is a collaboration between Tobii and HTC there's a complex series of legal agreements which dictate how their underlying technology can be licensed and used, what data is available to developers, and how the developers access that data (via API's/SDKs). We're using an encapsulated version of their SDK which overall has different developer functionalities and a different legal framework around it (and it also ties into Nvidia's VRS and associated rendering technologies). I'd recommend specifically referencing our documentation and developer agreement in regards to Vive Pro eye as what you're reading for the Tobii native SDK isn't accurate for this specific Tobii hardware integration and you may get the wrong idea about what's possible if you strictly reference their native SDK documentation and their implementation instructions are for native (standalone) hardware, not integrated hardware.

@Isari_Chan - Thanks for writing in with your idea. I've passed this around internally and we all think this would be a really neat idea - implementing something like this would be a monster at this stage of XR deployment but may be something that's feasible in the medium-term. The challenges are twofold - first there's the data privacy issue as you'd essentially be monitoring users with ML algorithms which opens a huge can of privacy worms and we're leaning towards a lean data collection approach. The secondary issue that's more challenging is that our hardware makes its way all across the globe and it would be rather difficult to integrate into countries emergency services - there's a huge technical and legal hurdle here, it'd be a multi-year sort of rollout. Accessibility features like this are definitely on our radar - it's simply going to take some time as getting VR to reliably work for the 95% percentile is the current goal of the industry at large so we can create the runway required to sustainably flush out deeper levels of interaction like this. It's a complex balancing act because you can't get too deep into your development cycle without at least putting placeholders for accessibility features down the line. I've also seen a user have a seizure in social VR - it was rather haunting and definitely informs my view on VR and accessibility. The more consumers we have requesting the features vocally - the sooner we're likely to see them at the platform and ecosystem level 😄

Hello @paco67, The manuals are contained within the downloadable SDK package - it's contained in the download itself because the assets of the entire package fall behind the SDK's developer usage agreements. First, navigate here, review & accept the click-through agreement, and on the next page download the SRanipal_SDK_1.1.0.1.zip package. Unzip it, and you'll find some high level documentation at the root of the package. Once you select the Unity or Unreal SDK, there will be a documentation folder in each of them with HTML documentation. Below, you can see the Unity eye tracking's HTML documentation is within SRanipal_SDK_1.1.0.1\SRanipal_SDK_1.1.0.1\02_Unity\Document\Eye and you click the "document_unity" shortcut to launch the interactive SDK documentation. The interactive HTML documentation contains specific info about the classes, data structures, ect... SRanipal_SDK_1.1.0.1\SRanipal_SDK_1.1.0.1\02_Unity\Document\Eye

@Leo_BH - I've gotten some more information. Apparently the limiting factor between converting the Pro kit to a Cosmos HMD is the battery rather than the cabling (as the Pro and Cosmos use the same cabling). The Cosmos has a higher voltage requirement than the Pro/Original Vive; higher than the specifications of the battery that shipped with the original wireless kit. The product team is still finalizing wireless support for Cosmos and will announce additional information on the subject as launch approaches.

@InfiniteJest It's worth noting, what's occurring here is because base stations are mechanical devices. A 1.0 base-station has two rotors, each spinning at 3600RPM. That equates to over 200,000 rotations per hour, per rotor, all of which need to occur with very high timing precision. A station can accumulate a pretty large number of rotations in it's lifetime - the best way to extend their lifespan is by using BT power management to power down the stations when not in use. The trade-off for external tracking is that you can get higher precision tracking but need external tracking elements, which in the case of base-station tracking means high speed mechanical devices which are subject to wear and tear. You're going to see these sorts of issues with base-stations regardless of the manufacturer and design as long as base-stations are mechanical and not solid-state; moving parts = potential for mechanical issues. Index base-stations are privy to the same sorts of issues as they're mechanical - if you search around, you'll see customers with similar issues on 2.0 stations manufactured by Valve. Cosmos uses inside-out tracking as it's default tracking mechanism which eliminates the need for external base-stations but brings with it a different set of pro's and cons.

@Leo_BH, I've reached out to our product team for more information about wireless and Cosmos and what that support will look like at the HMD's launch. The Cosmos uses the same data cable as the Pro so I think the issue would mostly be a mismatch on the padding rather than the cable. There may also be some software/firmware updates that need to occur to support wireless. I'll circle back with what I discover.

@Kennybo00 - I reached out to our sales team to see if I can track down any information about potential financing options with Cosmos

@sbouilland, Can you please attach a few screenshots which shows how the object is set up in Unity and the object's hierarchy?

Battlewake just launched this week and is available to Viveport Infinity subscribers 🥰 https://www.viveport.com/apps/bae792a4-78a1-4a45-b078-1d5cfadedf0f/Battlewake/

@Tannin - It may be cheaper to find an aftermarket solution than use our repair swap. The HMD itself is more durable than the other kit components - I generally would recommend against purchasing used Vive base-stations and controllers.

@jinrey2 - This is not an error I've heard before. How are you connecting to the internet? Are you using a USB-based WiFi/Ethernet adapter? I'm not aware of any other cases which I could reference which cite this as a issue. If I had to guess, you launching into VR may be causing some background network usage (such as Steam workshop downloads) which is competing for bandwidth. I'd recommend opening task manager and seeing what your network usage is. Another thought is that you're possibly maxing out your USB or motherboard bandwidth or maxing out your CPU or another resource but overall this is a pretty weird case. What is your testing protocol? Are you in a blank SteamVR compositor environment? Is your app open when testing? Another guess is that your app is taking up the majority of your 2.5mbit pipe and so your testing protocol may only be capturing the bandwidth that's available after the other processes. The majority of apps can't support multiplayer/VoIP on 2.5mbit - usually 20mbit is required for those types of use-cases.

@Beep2Bleep - I've generated a support ticket with the email address associated with your account so I can connect you with a member of our content operations team.

@Tannin - So you've isolated it to either the HMD or the cable. If you still have access to the other Vive, you could try plugging in your friend's known working cable into your HMD which will isolate it even further to either the cable or the HMD. In any case though, it sounds like a hardware fault in either the HMD or the cable at this point and you're able to generate a repair RMA via www.vive.com/support -> contact us -> contact us. The repair outlook will depend on what's actually wrong with the HMD and your warranty status.

@kai2ser - I've tagged a few members of the SRWorks/Vive Pro Eye team to the thread for official comment. That said, I'd state that overall, SteamVR and SteamVR hardware is still considered to be in a "pre-developer" state on MacOS and Apple hardware. Apple and Valve have not made any recent announcements on the status of SteamVR on MacOS since their initial announcement and while a MacOS branch of SteamVR is accessible via the beta menu, overall support is still in early days and is very limited overall. VR development is currently centered around the Windows ecosystem - it's where all of the resources, tooling, drivers support, ect is focused.

@Amorgeddon - That's definitely not a behavior you want to see in a station. I'd recommend collecting the serial number off of the back of the unit and going to www.vive.com/support -> contact us -> contact us and requesting a repair RMA. There isn't alot of components in the station that can come loose like this - my best guess is that it's one of the "lenses" that covers one of the laser apertures but it's impossible to fully ID without inspection of the station or internal photos that show the loose components. You can theoretically use the other station in single channel mode (ch A) while the suspicious unit is under repair - it's going to work best for seated apps as you won't have the same 360 coverage provided by two stations. It's worth taking this opportunity to note to anybody else who may be reading this that moving a base-station while it's plugged in and spinning is the easiest way permanently damage a station.

@FlavorousBOB - Thanks for sharing with such detail. Are you seeing any weirdness when you open the wireless companion app and try to initialize the wireless linkbox or is it working straight away?

@Spicy Tofu - This is a pretty old thread. In many cases, we've repaired the headband component using a redesigned mechanism under warranty. Warranty situations can be a little complex with the Focus devkit as there are several different types of warranty situations. I'm sending you a PM of who you can email for support on this.

@mocaper - Alot can happen from when a device leaves a production facility to when it's delivered to you - the devices often shipped thousands of miles, usually by ground transport. If you purchased the units through Vive via the Vive Pro Full Kit - the repair/swap is covered under our warranty. You'd collect the devices serial numbers from the back of the units and navigate to www.vive.com/support -> contact us -> contact us to request a repair RMA from a live chat agent. If you purchased the units directly from Valve, you'd need to go through Valve's warranty process.

@insevin - The bluetooth module that connects with the basestations is within the linkbox so if you need to use BT power management, you'll need to have the linkbox connected via USB and powered on for that functionality to be available (there are ways to bypass the linkbox such as with Vive Wireless).

Hi @jdissle, Welcome to the party! Here are some of my favorite apps that I'd recommend trying: Google Earth VR Superhot VR Moss Museum of Other Realities Hellblade (if your PC is powerful enough) Irrational Exuberance Prologue Rec Room The Talos Principal Duck Season The Gallery Ep 1 & 2 GORN If you're a new Vive owner, your Vive comes with a hardware-bundled free trial to Viveport Infinity - it will allow you to access hundreds of apps and titles so you can dive into the VR catalog and try a bunch of games at your own leisure.

@Alleluia - It sounds like you've confirmed it's a hardware issue, as Jagibson said above, we would recommend navigating to www.vive.com/support -> contact us -> contact us and request a controller repair RMA. The trackpad on the original Vive wands has a rubber membrane "button" underneath it; based on your description, this membrane may have become unseated and has shifted.