HackPerception

- The Vive has actually dropped $200 in price since it's launch. - There are far too many laptop SKUs to make individual suggestions. Here's a rough list of general reqs: 20xx laptops are still in early days. If you can afford one, it couldn't hurt but I wouldn't pass over a good deal on a 1070 laptop. You'll need a minimum of a 1070/2060 for Vive Pro If aiming for current gen HMDs (Vive Pro, Index, Rift S, Pixmax, ect...) you need to ensure that it has a MiniDisplayport/USB-C port that can output Displayport 1.2+ signaling. These HMDs require this to function. If VR is your goal - just get one with a dedicated MiniDisplayport so you don't have to worry about compatiblity and adapters and whatnought. Our internal teams primarily use Razers for internal use and MSI laptops for loaners and events. Razers are dope if you can afford them. MSI is a good value option but the build may not suit your needs. A 1060 is fine for the original Vive and will handle most games but not all Avoid the 1050Ti at all costs!!! The GTX1650 is probably good for Vive. We haven't gotten test laptops from OEMs to validate on Vive Pro. Dave2D (David Lee) is my go-to guy for Laptop reviews: https://www.youtube.com/channel/UCVYamHliCI9rw1tHR1xbkfw If your GPU says "Max-Q" it means that it's less powerful than the desktop version of that card. A 1060 Max-Q for instance is underpowered for VR.

- I'd recommend contacting Vuforia & posting in Vuforia's HTC Vive Developer Portal. Vuforia is by definition a third party SDK and thus the third party is responsible for supporting their SDK. As far as I'm aware, none of our developer relations staff have deep experience with Vuforia on Vive - it's outside of the scope we work with on a regular basis and any MR we're doing with the HMD we're doing with the SRWorksSDK and OpenCV. Vuforia is an awesome product - they just are heavily skewed towards AR and thus there isn't as much Vive development with it as opposed to VR specific SDKs.

- I'll flag this to a hardware team manager for follow up. To have this happen multiple times is a decent indicator that the root problem is not within the HMD's HDMI port but rather somewhere else in the tech stack. Before a unit leaves an authorized service provider it gets run through both a physical checklist as well as a automated diagnostics which would validate the HDMI port's connectivity digitally and provide a resulting pass/fail.

- You've purchased a TB2 certified cable - TB certified cables are not compatible with DP native HMDs. Thunderbolt ≠ Displayport. Cross-compatibility between the two standards is both hardware and software dependent but in any case, you cannot use a native TB certified cable to connect a Pro. I would recommend using this cable; it meets the requirements for the HMD. In the US we have 1 and 2M variant; I think this 2M variant is equivalent to the SKU in the US and that it should work but I'm not 100% able to confirm that this is the cable available in the US. We recommend the 1M variant as Displayport doesn't handle distance well. A downstream issue I can see you hitting is that you're attempting to power a higher resolution HMD off of a 1060. Due to the thermal throttling and overall decrease in preformance in mobile architecture, you generally need a fully powered 1070 to power a Pro at 100% SS on a laptop. It's super laptop specific as there's such a huge variation in what OEMs integrate into consumer laptops.

- there aren't really reliable options to extend the cable. This is one of the first WiGig products which have come to market and in doing so, it has overcome many of the major barriers with working with the signal type but given how the tech works there isn't any room in the specs for mods as VR is already a very demanding use-case for WiGig. In short, one of the hardest parts of bringing this to market is the coax cable - it needs to meet very specific criteria to work (signal to noise, latency, impedance, bandwidth (>5gbps)). You can't reliably extend the cable because the additional run of wire acts as an antenna and will pick up environmental RF interference and you blow out your signal to noise ratio. We've made the cable as long as can be reliably supported per the tech's current parameters. The 2M version of this cable is the only extension the community has reported any measure of success with. It's not 100% reliable and introduces a whole subset of potential troubleshooting scenarios but it does work for some users. We've tested the 19.6ft version - it's far too long and doesn't work at all. Overall, this is considered out of the product's use-case as well as it's scope of support. The option I linked is the only one I've seen people report reproducible success with but having tried it firsthand I can say that it isn't as reliable - your results will vary if you decide to attempt this. We'd recommend that you move your PC - it's way easier and more reliable than attempting to modify the system in the majority of cases.

- Your laptop has a 1050 Ti which is a notorious edge case in VR. I'd generally recommend all 1050Ti users to avoid Vive as your technically ~20-30%$ below the minimum reqs but it's super case by case as some laptop users are able to get it to boot. There was actually a meme that got posted in a popular subreddit this weekend that is super accurate: https://www.reddit.com/r/pcmasterrace/comments/ccml2m/no_not_the_1050ti/

- I'll add some context into this thread which may help the situation. We offer replacement facepads for first generation headsets but there really isn't consumer demand for them. For Pro, as the install base is smaller, the demand for replacement first party foam is even smaller and it's difficult to support a global distribution of a SKU that approaches zero volume. What demand exists for replacement covers, VRCover pretty much monopolizes that market. They make a great product - we would recommend using them (facepads, headstrap kit). The key difference between the two offerings is the material. Our facepad is more durable in the long term and machine washable which is why it's the material we ship with. A consequence of the change in materials is that our foam specifically wicks sweat which help reduce chance of sweat ingress into the HMD's shell. VRCover facepads are made of a PU material that's less durable but you can "wipe" these pads down and use some types of antimicrobial agents on them (no bleach!); you may have to replace these if you're rough to em which is one reason don't ship PU. When using PU replacements, we'd generally recommend you to be more mindful to wipe your forehead occasionally if you exclusively sweat whist in an HMD.

- That's a very acute statement - I assume you work professionally in tech :D? That's more or less the situation here - feature sets like this are found in more mature stores because you have to align your entire DRM and SDK architecture to support something which ends up as a simplistic UX feature on the front-end. Many VR studios are new to shipping software, it's super wild west as to how their builds generate things like their own registry entries and it can be hard to encapsulate and repair them. After talking with our PC client team, we believe we have a workaround: Using Windows Explorer, move the application folders to the newly desired destination Start the Viveport application as an administrator. Next, remove the app within the Viveport client. No files should be deleted because they'll have been moved to a place the PC client can't see them. Go into the client’s settings page & change the download path to location where you've relocated the contentWhen dealing with app on an individual basis, you could opt within the settings to not use the same folder for all downloads which will cause the client to instead display a confirmation dialogue at the start of each download where you can manually confirm the DL pathway. In the client, attempt to “redownload” the app. The PCclient should see that the program files for that app exist in the new location and no major network activity should result. This is probably easiest if you move your entire library but it is also likely feasible in theory for individual apps

- You cannot interface with SteamVR hardware at that low of a level because what you're describing are Watchman level systems within of the tech stack. Please refer to the video by Alan Yates as well as CNlohr's projects for context on how the Watchman tech stack works. You may be able to accomplish some level of access with a SteamVR HDK but I'm honestly not 100% sure, that's a bit in the weeds for me. You wouldn't be able to get that low on Tracker in any case. In the case of a Leap Motion, there's simply overlap in the range of IR emissions. Leap Motion projects a"curtain" of structured light in near-IR. You can't simply exclude sensor hits because the output on these kinds of depth sensors is persistent and not acute. The first generation of SteamVR sensors (Vive, Vive Tracker 2017) have different sensitivities and compatibilities than TS4231 based products. 1st gen sensors tend to do better with Leap Motion & Hololens specifically (both of which emit IR curtains of structured light) but it really is use-case dependent.

, You can capture and record the pose for any SteamVR tracked device via SteamVR -> Settings -> Developer -> Record Tracking data. It's a specialized binary format, most people who have tried to mess with this data end up having to write custom code to parse the data into something human readable or have opted to write custom code which queries the OpenVR APIs to write an output log in a desired format. "RAW" sensor data cannot be accesed per say. It's all in Valve's proprietary watchman format. The only project to actually make headway on hacking it was CNlohr's projects. You'd want to target the OpenVR layer. is the best publicly available explanation about how lighthouse tracking works. I'd recommend all SteamVR developers watch it. Brekel OpenVR Recorder is a paid solution that we've seen customers and developers report success with - it will likely be far less resource intensive that developing a custom solution depending on your development team. The .FBX export makes this super handy. This data is super niche and thus this is really the only built out solution to access data. Here's an example of someone who wrote a custom OpenVR solution - the code is a little old, not sure if you can dupe it successfully with modern SteamVR versions. Here's an additional example of a custom OpenVR solution

, Usually we'd recommend a GTX1070 for laptops for Pro, this is an edge case because it would appear that that laptop has a full GTX1060 and not a MAX-Q edition (MAX-Q is weaker). It has native MiniDisplayport support you'll require which is good (use this cable). There's a good shot that this will boot a Vive Pro but you may need to undersample in order to achieve framerate simply because Laptops have thermal constraints which make their perf not equivalent to desktop architecture.

- This is a result of the DRM system Viveport uses which is driver based and differs in architecture from the other platforms you've listed. I am flagging this to Viveport's product leads to see what the current outlook is on this specific feature request.

- If the base station was vended as part of a Vive Pro Full Kit, there's really two warranties at play here: Valve's manufacturer warranty (which is independent of us), and the limited warranty on the full kit offered by Vive. Valve has denied your claim under their manufacturers warranty it seems. In this case, I would recommend that you contact our live chat via www.vive.com/support -> contact us -> contact us and request an RMA repair under the limited warranty offered by Vive as the reseller. Please have your base station's SN and a proof of purchase handy. If any complications arises during the repair process, Valve actually quoted you the price of a new station ($149) - they've been made available for direct purchase through the Steam store (link) within the last few weeks.

, There are several years worth of models for this laptop - I assume you mean the 2019 version. This spec page says that the USB-C port supports DP signaling but doesn't state which standard (1.1, 1.2, 1.3, ect). I would formally recommend that you contact MSI and ask them if the port on your specific model is A) Connected to the dedicated GPU and not just the onboard graphs & B) That it can support DP 1.2+. Alot of budget laptops save on build costs by keeping the USB-C port wiring simplified. That said, I think there's a good shot it will work based on their specs page. Here is a USB-C -> DP adapter that we've tested and have confirmed works with Pro. I'd recommend using this solution since it's proven to be reliable. I unfortunately don't know off of the top of my head of any direct USB-C to MiniDP cables that we've directly tested. We've tried some USB-C -> MiniDP adapters but I don't think we've directly tested cables.

- You should be able to use any USB-C to HDMI 2.0 adapter that is 4K compatible on paper. I haven't been able to reference any internal resources on an adapter that would work because we only see questions about USB-C -> DP. The following adapter (link) meets all of the criteria on paper and is a trusted brand for adapters for Vive Pro; I don't see why this model wouldn't work for Vive CE via HDMI. As I alluded to above, the key with USB-C ports is that the USB-C port needs to be wired to the dGPU in order for this to work. Alot of budget laptops cut costs by keeping the USB-C port only connected to integrated graphics.

- We haven't launched a "home" app - that's the SteamVR home which is a Valve creation. You can disable it via SteamVR -> Settings -> General or can lower the application resolution for SteamVR home via SteamVR -> Settings -> Applications. In any case, that would be more of a hardware dependency on your GPU than with the signal chain you're using to get to HDMI.

- Following up on your post - we reached out the developers of Racket Fury to inquire about the version differential that you've flagged. They report that they're currently wrapping up work on an updated cross-platform build and they've stated that they will push an updated Viveport build as part of that build's release cycle.

This post has been moved. Follow the link to the new location. Thanks!

- I'll check with our content operations team to see if they've received an updated build from the publishers of Superhot - if we have, it would likely be in a QA queue. If not, we may have to reach out and request that the developer shares an updated build with us.

- I've flagged our content operations team about your post for follow up with the developer/publisher. Platforms like Steam and Viveport are self-submission platforms, developers submit updates to us and then we publish and distribute it after a QA pass and thus the build published on the store is the latest that's been provided to us. In some cases, store based SDK features will vary by platform. When you say "full Oculus support" - what are you referring to? Oculus SDK Native support or are you encountering issues launching the title via SteamVR?

- Is windows making the hardware add/remove sound? It's hard to describe - . My first guess would be that it could be related to the teather but normally it takes more than a few seconds for the headset to reinitialize from a hard disconnect - the SteamVR compositor doesn't do well with hard disconnects at all. I would recommend doing the following: First, reseat the HMD teather to ensure it's fully plugged in and then test . I copied some instructions below. If the above doesn't help, take an opaque piece of tape and cover up the sensor in between the two lenses to trick the HMD from going into standby. Start SteamVR, establish that the HMD is working, and then see if manipulating the cable causes a disconnect. If it disconnects, it's a very good indicator that there is a short or break in the cable. If none of these work, you'll probably want to generate a SteamVR system report and contact us to parse it and see if there's any output lines in the logs which stand out.

, Can you please post a screenshot of the advanced frame timing graph? We're seeing users report issues with the latest Nvidia driver - some users are having luck reverting to driver 417.71.

, This sounds super funky. I would recommend powering off one station, putting the other station on "channel A" and testing if the HMD can track in single station mode; once you test with one, test with the other station. This should allow us to ID which of the two stations is being funky. I'm almost certain that the station with the flashing light has a mechanical issue that requires servicing. Based on your report, it sounds like you did the "recovery" method that people on forums inaccurately share as being able to "fix" a station. In reality, what it does is flash the firmware to a previous version of the firmware that lacked the internal diagnostic tool that enables a basestation to report it's health. It may be spinning but one or both of the rotors may not be outputting valid tracking data.