HackPerception

@Castana - I've sent you a PM

@AmandaBruh You're technically now able to request a free miniDisplayport Adapter via www.vive.com/support -> Contact Us -> Contact Us Otherwise, I would recommend the 3 foot version of this cable. It is known to work with Pro/Cosmos and is under $10 USD. This may be a faster option depending on where in the world you are. On that specific laptop, you need to disable "Discrete Thunderbolt support" in the BIOS. Please see this post for instructions. If you don't disable this option, headsets will not work. I have the 2070MQ version of this laptop and can confirm that you still need to disable Discrete Thunderbolt Support.

@DanDudeAmiga @bym051d @VividDori - There isn't alot of info here indicating at which stage the hand is occurring but generally when people refer to hanging with this installer, it's Steam downloading something massive in the background. If you already have SteamVR installed, I'd recommend using this installer for Pro eye - it contains all of the req'ed runtimes and tools required to drive Pro eye.

@wilz In your specific case, I would recommend copying your query to support.enterprise@htc.com - this certainly falls under their domain of support. In some cases, the UAC requirements may be out of our domain and may actually be a result of 2nd party requirements. The Wireless adapter is a partnership product with 2 other companies (Intel, and Displaylink) - sometimes what happens is that these 2nd party runtimes/tools can have installers or components which require UAC permissions that extend beyond what our installer/wrapper/runtimes require. Enterprise support would have the best answer for you.

@_Olsson_ - Please contact support via the instructions on my post above. A blinking red light on the 2.0 stations indicates a mechanical issue that requires physical servicing. Given your purchase date - the station will likely be covered under warranty.

@TechNein Basestations are mechanical devices that have motors that spin at over 200,00+ rotations per hour - the trade-off with using basestation tracking is that you get higher fidelity tracking but have to deal with the fact that it's a mechanical device. Unplugging the stations when they're not in use or using base-station power management to put the stations into sleep when they're not in use is the best way to maximize their lifespan. The Valve index the same constraints since it relies on basestation tracking. if you want to avoid this wholesale in the future, you'd need to opt for an optically tracked headset - the tracking quality isn't as good on them but there's no moving parts to wear down or break. The repairs are costly because you basically need to rebuild the entire station when something breaks - or they just replace the whole station if the station is not salvageable. It's a very manual process using expensive parts - it's not something we profit off of - the parts and labor is expensive.

@frostymm - Displayport is a very loose standard - it was primarily designed to be used to drive UHD television signals at a length of under 2M and it notoriously bad at long distance runs. VR pushes it to it's absolute limit since the headset tether is 5M (6+ if you count the length the the linkbox). You start getting into all sorts of latency and impedance issues when you try to shove that much bandwidth down long runs of copper cabling. The only real brand that works for long distance the Lindy Chromo line - upto the 5M length. It doesn't work with all GPUs and isn't 100% as reliable as the properly spec'ed out length. At the end of the day, it's not really a supported use case. You may have success with a Lindy Chromo cable but it's not guaranteed because you're trying to push the hardware further than Displayport can handle and you may have to adjust your setup to fall within what the hardware can handle. All Displayport driven headsets have this constraint - it's not limited to Vive Pro. More advanced enterprise headsets use expensive fiber optic tethers because you can only get so far with copper cabling.

@Tektolness - Hey, good news. I was actually wrong about this. In the latest versions of OVRDrop, you can achieve this with any type of window/feed by setting the option in the bottom lefthand corner (highlighted in yellow) to "screen". I played around with this for a few hours tonight and it works great 🙂 You use the sliders above it to adjust for the position and size. If you're an end user - I would wholeheartedly recommend this option. If you're a developer and are trying to integrate this natively, I'm not quite sure how they accomplished this but it shows it can be done within Unity.

@jazfree - Our desktop Vive products are SteamVR/OpenVR headsets. There is no way to use these headsets without SteamVR. If the headset doesn't work on a second PC, that's a good indication that it's a problem with the HMD, assuming the second PC is VR-compatible. The result is invalid if the other PC isn't VR compatible. If it's a first gen-Vive, I generally recommend trying a "linkbox bypass" as a first step. Basically you take the orange HDMI leads from the headset's 3-in-1 and instead of plugging them into the linkbox, you plug them in directly to the GPU/motherboard while keeping the power plug connected to the linkbox. This solves alot of issues. I also recommend sliding back the cable cover on the top of the HMD and unplugging and reseating all of the cables to ensure they're plugged in properly.

@Edward117, Blinking red lights on 2.0 stations indicate the base-station has a mechanical issue. Your unit would be covered under warranty at that age - the best thing to do is to go to get the serial number off of the back of the affected base station and then navigate to www.vive.com/support -> contact us -> contact us to request a repair RMA from an agent specific to your region. If you purchased the station through Valve/Steam - you need to contact Valve. There are no user-side fixes for mechanical failures on base stations.

@darkfyrealgoma - We're currently in the process of relocating servers to resolve this. The entire backend system that drives Viveport was updated about a month ago and introduced this problem for some regions in real-world deployments.

@ordivergens you're entitled to both. I converted your post into a support ticket with the email address associated with your account. If you reply to that ticket with your bundle code, they can fix it in the backend.

@stu81ffm If you have a tracker on hand - you can use a paperclip to bridge one of the input puts into ground so you can test to see how it works and test the input's behavior within your engine. Here's a helpful tutorial on using SteamVR 2.0 input with tracker via Unity.

@onslovo I'd recommend posting in the SteamVR bug community. This is a system entirely managed by SteamVR that's fairly independent from the headset so wireless shouldn't matter. It basically affects a parameter value that OpenVR communicates to the game engine. You can try using the global value override to see if that has any affect.

@Kristodian - Basically. The HMD/panels are a fixed resolution. The content can be rendered at varying levels (most of the time, not always) and that output gets "sampled" and interpolated/scaled to fit the native resolution of HMD. You often have to restart the application (but not SteamVR) for the changes to take full effect. The ability to enable/disable the 2D mirror varies by content. VR is a wild west and it's PC gaming - every single app will have different settings. That said, the effect should only be a few % of perf either way; it's not going to make a world of difference in the same way that the application resolution is.

On that motherboard, it depends on if those front expansion ports are connected to JUSB1/2 or JUSB3. You'd probably only want to use them if they're on JUSB3. That said, plugging into the motherboard headers is always better than using an expansion connector on high-performance applications because there's simply less copper the signal has to travel through (and potentially be attenuated by EMI). It's a little vague but it seems like they're all using Intel's controller as far as I can tell. You'd probably want to

I'd recommend posting to the FB group: 360 video professionals. That's probably the most active 360 creator group out there. Most creators here are working with 6DoF content by pure virtue of the hardware.

@stu81ffm - You could theoretically do this depending on what types of outputs your camera flashlight has. Basically - you could wire some sort of circuit so when the flashlight is one, it also completes a circuit between one of the PoGo input pin's and the PoGo's ground. It's a pretty simple system - if there is a closed circuit between one of the PoGo's input pins and the ground - it registers that as an input. I think in this case, wiring your lighting source to open/close that circuit would be the hard part. You could always just wire a simple switch instead.

@DustProductions Can you please send me the logs? Those really are our best bet at this point. We haven't heard of USB-bandwidth being an issue at this point but USB isn't really universal when you dig down into it. At a high level, there are two kinds of USB controllers xHCI and OEM proprietary ones. The xHCI ones are usually decoded by the CPU - the OEM proprietary ones (i.e. Asusmedia on Asus boards) are a total nightmare when it comes to VR devices and we've seen issues with these going all the way back to the launch of the first Vive in 2016. In most cases, you can look up your motherboard's documentation and figure out which ports are controlled by which controller and always opt for the xHCI on your high performance devices. Inateck cards have long been the most reliable USB cards for SteamVR devices and have solved thousands of people's motherboard compatibility issues. That said, that's been entirely for base-support of the HMD and not for eye-tracking. The Tobii devices probably have a completely different set of USB-constraints completely independent from watchman devices. We've already processed logs in the last week from a few folk in this thread - one common issue we've found is that if you have drivers for other Tobii devices on your device - it may cause a conflict.

@stu81ffm - The trackers use the tracking universe and parameters that are defined by the roomsetup procedure. The tracker's can't be miscalibrated per say - it would be the entire roomsetup that would be mis-calibrated. One thing that can cause offset is if you floor is somewhat polished/reflective which can cause the controllers to "jump" around and judder when you place them on the floor during the calibration step. You should be able to easily test this by placing the controllers on the floor as if you were doing room setup and seeing if the virtual representation of the controller is firmly anchored in the virtual SteamVR environment or if it's bouncing around. If they don't stay anchored firmly in place, it's a reflection issue from the floor. OpenVRAdavncedSettings has a floor fix option that's super useful. Sometimes it's the virtual environment that's miscalculated. Developers sometimes don't set their floor height correctly in their app or the offset the floor height upward so you can pick stuff up off of the ground without your controller bashing into it. Always use a blank SteamVR compositor to troubleshoot this stuff (i.e. no app running, SteamVR home disabled). The stations do not need to be at the same height. With 2.0 stations it doesn't really matter. WIth 1.0 stations, both stations need to be .25-1.5 meters overhead of the player and pointed towards each other for the optical sync system to work.

@Kristodian - Some games let you turn off the 2D display - others don't. It's a mixed bag. VR is newish - there's not really alot of standards. The headset renders at a locked resolution - the OpenVR/SteamVR compositor samples the application and then transforms and alters the image to be displayed on the headset. That resolution slider affects what resolution the application renders at - which is then sampled by SteamVR. If you render at a higher resolution than the headset can natively display, it's called "supersampling" and it can improve clarity a number of different ways, especially when dealing with aliasing. If you go under 100%it's called under-sampling - things will get blurrier, both in flatland and in the HMD because the source (game/app) is rendering less pixels out. If the headset is flicking on all games or in a blank SteamVR compositor, there's an issue with your PC or the headset. If it's only doing it in one game - then it's an issue with that specific piece of software. NMS is a port of a 2D game which complicates that particular situation.

@LuckDrvien07 - outside in (optically tracked) headsets all have the sensors in one tightly packed location (the headset). Inside-out tracked headsets like basestation tracked headsets have sensors on every single device (a dramatically higher surface area) and thus Outside-in headsets use machine learning models to make up for their physical limitations. They basically make educated guesses about where the controllers and headsets are when the sensors can't provide good data. Rift S and Quest had the exact same issues at launch - this video does the best job at explaining what I'm talking about. Both Rift S and Cosmos have received numerous updates to the ML algorithms since launch - Rift S has been on the market longer than Cosmos though. Every single headset that uses onboard tracking cameras have these physical limitations and relies on machine learning to smooth out the experience. Basestation tracking has a completely different set of drawbacks - primarily that you get far higher resolution tracking at the expense of having to have external base stations that you have to mount and that that can wear down break due to being mechanical devices. Basestation tracking breaks down if you have large reflective surfaces like mirrors. Optical is convenient and lightweight but has limitations and privacy implications. Basestation tracking is far more robust but is bulky and more expensive.

Base station tracked devices don't have that kind of occlusion issue if the stations are deployed properly. This issue happens because on an inside out tracking headset, all of the sensors are bundled into the headset and so line of sight is more important. It's much harder to occlude with outside-in (basestation) technology, especially if you're using more than 2 2.0 stations.

@Raz - Our forums are under attack by a sophisticated spam bot. We're working with the forum vendor to try and resolve it.

@SanityGaming - They're still not accepting stock from us - I can ask again but it's really a one way communication type of scenario at their scale.