HackPerception

@DAN_di_WARhol you get it from within the Vive Console (which installs from the standard installer: https://www.vive.com/setup)

@jboss I'm not positive about Android - I switched over to iOS for privacy. I could be totally wrong on this, but I think the community prefers Lighthouse Power Management on Android.

@Thor777 - Options are far more limited on 1.0 basestations. They don't have to be diagonal per say, but that's highly recommended to maximize the playspace and tracking quality. They definitely have to be overhead for the most part unless you're doing specific things with the sync cable. Are both stations working properly and on on chans B/C? If both were working correctly - a device houldn't have any issue with pulling from just one of the two stations.

@jboss The only thing in SteamVR that will partially adress what you're seeking is the "Exit SteamVR After" setting in Startup/Shutdown. This will automatically close SteamVR after it sits idle for a specified period, and when SteamVR is shutting down - it will power down the basestations if you have power management turned on. That said, SteamVR must shut down to send the signal to the basestations. If you close your laptop lid, SteamVR never gets a chance to send out the shutdown command. I personally use the app BS Companion because it's simply more reliable than SteamVR.

@SUPERLUMEN for 4.25??? Or 4.26?

@Thor777 - Depends on if you've squeezed the most of our your current 1.0 basestations needed to be mounted in opposite diagonal corners above head level. 2.0 basestations have none of those limitations. You can move the stations around in whatever way you find maximizes their 120 degree FOV covering as much of your space as possible. In fact, if you mount a 2.0 basestation in a right angle corner - you're actually wasting 40 degrees of it's FOV (see how the stations are inset in the last photo) Adding a third station would probably help if occlusion is right and truly your problem; but maybe first experiment to see if reposition your two stations helps. Also be sure to use base station power management, especially if you add a third station. It will prolong their lives greatly. I use an app called BS Companion on iOS since I have multiple HMD.

@hrheiberger - I'm not personally in the know about any projects which have combined the two SDKs. I think everyone who has licensed from Tobii goes all in on their SDK. SRAnipal is a wrapped version of Tobii's runtime with a white label API that provides access to a subset of the Tobii XR APIs. There might be a conflict at the runtime level if you have both runtimes going and API calls to each environment.

@gran00 I'm not 100% sure on this use case, but there is a device called a "Headless Ghost" that you might be able to use to trick the PC into thinking you have another physical monitor plugged in when you don't. I've seen these used by arcades but never to add a second monitor to a virtual desktop application.

@grano00 You can't power the headset directly like a windows monitor because a headset needs weird optics to work with your brain and eyes. One of the primary roles of SteamVR is distorting the image for display on the panels so that the image isn't distorted when you look through the lenses. You can only tools like Remote Desktop, SteamVR's built in Desktop Tool, Desktop + (free), OVRDrop, or Bigscreen. These take your monitor's signal and runs it though SteamVR and maps it in 6DoF with all of the distortion corrections. The limitation with these, is that they can usually only duplicate a monitor that you actually physically have plugged in. This is because these applications simply read and copy from your GPU's framebuffer from that monitor and display that data in VR instead.

@dslnc - We officially recommend treating each HMD individually. When you do roomsetup for a specific HMD, only have the 4 basestations plugged in that you want to pull data from. At trade shows, we literally unplug every unnecessary basestation when we're running roomsetup and strictly have the 4 plugged in that we want used for that headset. This ensures things don't get messed up when you start getting into really complex setups. Sounds simple, but it's a lifesaver IRL

@cees What's your frame timing and SS value. "Screen door effect" is baked into the headset and has to do with the distance between the pixel elements, and the overall density of the pixel elements. It's a fixed thing that's based on the physical hardware - it won't "change when you move your head" although it might be more noticeable. You're probably noticing some other type of artifacting or compression behavior.

@dslnc That's official per Valve. In reality, the tracking behavior is much more complex IRL - but for all commercial and consumer usage, 4 base stations supporting 10x10m is the official support usage case.

@A2597 Like - standby mode as in SteamVR is open and SteamVR's standby mode is specifically enabled; or standby mode as in SteamVR's process completely shutdown and the headset just being plugged into your PC.

@Sum Dum Guy - VR Developers individually decide what happens with the Desktop. A handful of games do eliminate it completely to add a few percent of performance but the developer decides if the game engine renders a camera the monitor (unless you use SteamVR's mirror). What you're describing doesn't sound normal. Is this with a specific game? Games from Steam?

Do you mean like mixed reality @chenwang? The easiest solution would be to use the Liv SDK. https://www.liv.tv/ You can also just do various production tricks with a green screen to achieve the desired effect.

@dburne I ship alot of stuff with FedEx and their delivery estimates have been all over the place the last month in the US as things reopen. Unless it specifically says "on vehicle for delivery" or something similar, you might want to temper your hopes. I personally shipped three headsets last week and all of the delivery estimates were off by a day.

@TrigenThe error code you're not seeing is specific to a Vive API - the error you're seeing is originating from the Nvidia API: NVAPI_MAX_DISPLAY_LIMIT_REACHED. As I explained, this isn't something limited to VP2 - there are other enterprise headsets in market with similar limits. VP2 is just specifically the first headset to integrate Display Compression Steaming to help make more GPUs compatible with the bandwidth requirements of the HMD. That said, this isn't related to DCS so much as it's a headset bandwidth thing. DCS is required for backwards compatibility - it's not really related to the Display limit. HDMI/DVI lend themselves to being disabled in Windows Settings virtually but the way the Displayport standard works, if the cable is plugged in and low voltage power is detected - it "ennumerates" on the GPU even when it's disabled in Windows.

We unfortunately have no stake in this behavior - this limitation is put in place by Nvidia and is not something that you can modify beyond the user-settings. The error message your seeing is actually from the Nvidia API - not from a Vive API. NVAPI_MAX_DISPLAY_LIMIT_REACHED Simply stated - driving a bunch of external monitors starts bumping up against the limitations of what GPUs and framebuffers can accomplish while also supporting a direct uncompressed stream to an HMD. Multi-monitor setups beyond 3 monitors are not a supported use-case at the GPU level when using this headset due to the bandwidth requirements. Vive is unfortunately unable to alter this behavior on our side.\\ I would not be surprised if you saw the exact same limitation on most other 4K+ headsets over the coming year or two. I'm think the Pimax headsets have had similar constraints since the beginning and think Varjo may have a similar thing. What sucks is that Displayport often won't let you just turn off the monitor within Windows Settings and you'll may asked to physically disconnect the Displayport cable. That's just a function of how the Displayport standard works. Adding to the complexity, modern GPUs and headset OEMs are stuck in between a generational divide with Displayport 1.2 vs Displayport 1.4. These type of high resolution headsets ideally would get hooked upto a shiny Displayport 1.4 but realistically you couldn't launch an HMD in the current market without Displayport 1.2 back-compatibly because a huge portion of users only have DP1.2, especially laptop users. Displayport 1.2 legacy/cross-compatibility is going to be an major industry topic for the next year or two. Backwards supporting DP 1.2+ requires a bunch of fancy optimization tricks, namely such as Display Stream Compression to be feasible. Another thing to keep in mind is that VR-fullscreen/mirroring doesn't work the same as traditional 3D fullscreen in terms of how the draw-calls and framebuffers resource usage plays out. The headset is driven directly off the GPU in a way that doesn't happen with monitors - they're different outputs that need to be rendered in the GPU. You can't recycle from the buffer to drive a full-screen render/mirror on the monitors like you can with standard flatscreen 3D content - it's an additional viewpoint that needs to be rendered in addition to the VR output. It may only hit you a few percent - but if you're maxing our your card, a hit is a hit. Hope some of this makes sense as to what's happening and to Vive's constraints around this topic.

@phibbs What device are you working on? Focus Plus?

@Phillrb The deprecation of these APIs for WaveSDK 4.0 was a security requirement for many of our key enterprise partners and customers to even be allowed by their organization to work with Focus 3. If you are a Focus 3 developer, speak privately with your account manager about your situation and use-case. If you have a previous WaveSDK version in a Focus/Focus + project that you had working - remain on the working version of the WaveSDK for the time being while options are explored. Most of the updates in the new SDK. We're still exploring a long term set of solutions for the security challenges posed by pass-through on the new device.

@EricD The button on newer link boxes is a physical power button. That button should power the entire headset on/off and the bluetooth circuitry in the link box. On some models of linkbox like Vive Pro, the bluetooth module used to communicate with the basestations is embedded in the Linkbox. Those situations are the only ones in which the linkbox's power state would affect Bluetooth (Pro/Pro 2). That said, the linkbox was off, the entire headset should be off as well unless you're using Vive wireless. I highly recommend using this app if you're iOS: https://apps.apple.com/ca/app/bs-companion/id1533473030

@Black yell I've generated a support ticket with your email address so you get on care team's radar. If anybody else is reading this and has the same issue - you can submit a support ticket for quickest response. SUBMIT A VIVEPORT SUPPORT TICKET

Pro 2 only additionally requires the "Vive Console" - it's just a piece of middle wear that bridges the hardware with SteamVR. If you're using Pro 2, the only difference is that the Vive Console Runtime launches alongside SteamVR. Otherwise the behavior with wired/wireless is identical to Pro 1/OG Vive Wireless. Vive Wireless is somewhat hot swappable but it's a bit goofy. If the system detects a linkbox with the Displayport cable plugged in, it assumes you want to use a wired connection and you simply plug in your wired headset (with the wireless console closed). If you have a linkbox plugged into the PC with just power and USB but you leave the displayport cable unplugged, it assumes you're doing a wireless setup. That said, having the linkbox plugged in is the only way to enable Bluetooth power management of the basestations. So when you're using a wireless headset, have your Linkbox's displayport cable unplugged and wireless will work. To switch to wireless, simply fully plug in your wired linkbox and plug in your tethered HMD (with the wireless app closed). @MixedupJim @JohnDoh Wow - this stuff is getting confusinggg 😅

@smsmsmsm - Nah, that's too large of a tracking volume. With four of the 2.0 basestations, you're maxing out at 10x10m. The accuracy and precision is usually millimeter accurate or so as long as you don't have any reflective surfaces in the environment. Robotics is especially challenging because SteamVR products use IMUs to help provide data for a sensor fusion based approach to provide faster pose estimates for rotation than you could get from the basestations alone which operate at 120hz interleaved. Robotics are really hit and miss with SteamVR tracking because if the G-force is too great, the tracking system can't make sense of the data and you'll get tracking loss. If you're dealing with anything moving fast or coming close to humans, you may be forced to use more expensive optical tracking.

@Aeternus2 Contact a car team specific to your region (www.vive.com/support -> contact us -> contact us). They'll ensure you get the discount applied.