HackPerception

@AirMouse We tend not to release any sort of first party performance benchmarks as the VR community tends to operate on an outrage by default model - we'll leave benchmarks to independent sources. Vive wireless is CPU heavy and you will see a spike in CPU resources being used. With an 9800k you won't be bottlenecked. On some setups, it helps to go into BIOS and disable Intel Speedstep. On other MBs, it can be helpful to also disable hyperthreading if CPU resources become an issue. These can both reduce your CPU load but it's very system specific. I'll ask about the battery perf difference for Pro Eye - I'm not sure if I'll get a sharable response back from R&D. The lion's share of the power consumption goes to the display so any additional consumption by the IR system will still be a fraction of what the Displays and wireless eats up.

@Rosieox - The copy you linked are VRFocus' conclusions about SDE, not ours. As I've said previously, there is definitely a reduction in SDE from the higher resolution panels which means the pixel elements are packed together more tightly (448 PPI for OG Vive vs 615 for Pro; a 37% increase in pixel density). The 78% resolution bump is actually really significant for rendering text and small details- there's alot of small details which are indistinguishable on first gen HMD's that are only visible in higher resolution HMDs such as text on dials and gauges on flight sims. As Jakey alluded to, a huge portion of the final quality that you see rendered out on the HMD will be GPU dependent and mediated by ensuring all of the ergonomic adjustments have been calibrated to you and most importantly by the supersampling (resolution multiplier) settings on the "video" page of SteamVR's video settings. Try going in and setting custom values for your applications; if you're overriding the settings there is going to be some trial and error as you figure out which value works best for your specific GPU. The resolution multiplier is the key setting to controlling the resolution of the content displayed on the HMD - this setting is where you'll have the greatest affect on the quality you see. If you have a weak GPU and are using automatic settings, there's a pretty good chance that you're rendering below 100% SS; going above 100% SS on a higher resolution display makes a huge difference in what you experience but you need a powerful GPU to drive increased resolutions. Between the 78% display resolution increase and higher resolution multiplier values, there is actually quite a substantial difference between the precieved quality you can experience on a Pro vs an original Vive, there are over 2 million additional pixels to work with on the Pro. It is definitely an iteration on the original Vive and was the highest quality panel we could source at the time of release. Past a certain point, there needs to be a new generation of panel technology that's specific to VR displays to see things like SDE more fully eliminated. We specifically switched to LCD on the Cosmos in-part so we could leverage the tighter pixel arrangement to reduce precieved SDE, but each panel technology has pros and cons. Things like screen door effect however are hardware dependent - that's not something you can change via firmware as it's specifically dependent on the arrangement and size of the pixels on the panel.

@Sjunin, the stock cable is currently the only cable type for Cosmos (excluding the short version for wireless). VR tethers are currently on the thicker side because they combine high-bandwidth MiniDisplayport, USB, and power cables all into a single tether. There's a lot going on inside of there and the jacket itself needs to be fairly durable as the tether gets twisted and stepped on.

@stonedwalljack92 This specific compatibility issue is limited to FO4 & Skyrim and is related to the fact that the content was developed in Bethesda's proprietary Creation engine. It affects other newer controller types such as the Index controllers as well. The workaround linked above is currently your best bet - a true fix would require an update from Bethesda.

@Nipah Those are data cables (as an intended use-case is updating firmware). They're just kind of short.

@Rosieox - Which press release are you referring to? I don't see the screen-door effect mentioned in any of our first party press releases (announcement release). We marketed Pro primarily around resolution. The primary reduction in screen door effect on the Pro is that the pixel pitch (the distance between the pixels) is smaller due to there being 78% more pixel count overall compared to the Vive. That said, the Vive Pro uses a pentile OLED arrangement, there are limitations to screen door effect due to that specific type of pixel arrangement. You may be confusing Pro for Cosmos - we specifically are marketing Cosmos as having lower screen door effect, not Pro. This is because Cosmos has switched out OLED panels for LCD panels that have more uniform pixels and smaller spaces between the pixel elements which leads to minimized perceived screen door effect.

@Nipah - Yes, you can use a microUSB data cable in-lieu of a dongle for both the original tracker and tracker (2018). It just sends tracking data back over USB. I use this as my standard setup for mixed reality filming. The key is that it needs to be a data cable, not just a charge cable. I'm sure you can mix and match - you'd probably want to pair the ones you're using wirelessy first and then plug in the wired ones afterwards. I've done this using the original trackers; I haven't tried it with 2018 but I'm sure it will work the same way.

@AirMouse Sweet. Avatars definitely get brought to life with eye tracking. The only other thing I'd comment is that the wireless adapter is a CPU dependent solution so the faster your CPU the better. When using eye-tracking, the SRAnipal also needs to be running under an admin.

@AirMouse - No, the system is pretty well tuned and depending on what you're doing is a huge UX boost. A weird unintended side effect I've personally experinced and have seen co-workers experience is that one you go wireless, going back to wired can be very difficult as you move much more naturally in VR when using wireless and if you try moving the same way with a wire, you get wrapped up or step on the tether. I'm going to take the opportunity to gently advise you that the Pro Eye HMD is for enterprise and development only. If you're an end-user, there is only a handful of store applications which have integrated the SDK into their public build (most notably L.A. Noire). At this time, there is very limited value to the Pro Eye for consumer users - it's intended as a development and research platform.

@AirMouse - Vive Pro Eye works with the wireless adapter - I use eye tracking functionality with wireless regularly at my test bench.

@aortiz268 - We have a hand tracking SDK that's currently in early access that is compatible with Cosmos and other Vive HMDs. The accuracy is currently best on the Vive Pro. As it's an SDK, developers would need to integrate it into their project to enable the functionality. It's not designed for use with the controllers - it's more for simple interactions such as navigating menus without controllers. The Index's tracking is a hardware based solution - hardware based tracking is simply going to deliver higher fidelity and accuracy than optical based solutions as the hardware is specifically designed to track hands. https://developer.vive.com/resources/knowledgebase/vive-hand-tracking-sdk/

@Jakey - The Vive Pro cable is the same as Cosmos; you'll be able to get ahold of this style of cable well into the foreseeable future. @Juggoire, They're currently in stock in most regions and are only out in a handful of regions. They are expected to be replenished but specific details will vary by region. If you need one now - you can contact our care team to arrange for one.

@Dusky - The chaperone grid should never move - if that moves it's a good sign there is a physical tracking issue. What's confusing about this situation is that they'll work for a while and then break. If something is making SteamVR think the HMD is suddenly high off the ground, it's weird that the controllers stay in the correct relative position (hence the super long arms). SteamVR can dynamically change a configuration and do things like adjust the floor - what's confusing though is that the controllers should be the same relative distance from the HMD when it makes these changes.

@omarabuasbe, Can you please describe a in more detail what errors you're encountering and how you're trying to implement stuff? I see this as two distinct clusters: Vuforia: Are you still trying to use Vuforia? If so, the Vive/Vive Pro are not supported officially by Vuforia. SRWorks: Please post a screenshot of the error messages you're seeing In regards to the camera output, that can be a bit system dependent. In many cases, if you go into SteamVR -> Settings -> Camera and disable it, it will free the camera up to be accessed like a regular webcam with the two images stacked on top of one another. If you're using something like SRWorks however, you'd need this enabled within SteamVR for the SDK to view it. How'd you'd potentially access this webcam in your project would depend on what you're trying to do with the feed most likely.

@Dusky Revisiting this with fresh eyes, I'm now curious if you're entire worldspace moves when this happens. I initially read this as a rendering issue but it could be more of a tracking related issue. Does your SteamVR chaperone move at all or do the walls and floor remain stationary? Maybe the headset is getting some weird tracking data (due to something like a reflection) and it solves the headset position as being in a really weird position (say 15 feet higher than it is) and the game engine doesn't know how to handle it.

@cmunn - The Vive Pro eye has the correct hardware for this type of use case - the limiting factor here however is that the eye-tracking features of this headset are SDK-dependent which means that each and every individual application needs to download and implement the toolkit and specifically program functionality around it. In other words, you can't currently purchase it and start interacting with software - no common public apps will have support. The focus of the Pro Eye is enterprise developers and advanced developers - this is the type of kit that helps pave way for more widespread support a few years down the road by enabling access to developers today. It is definitely not a consumer facing product and there currently exists no middle-wear software or SteamVR tooling which would allow the headset to drive generic eye-tracking based interactions across the app ecosystem. While eye-tracking will certainly find use-cases for the types of scenario your describing with your father; the hardware and software ecosystem simply isn't there yet and we're still in the research and experimental implementation stage of the rollout of the technology. There exists no turn-key commercial solutions for medical use cases like this right now and I'd unfortunately strongly recommend against purchasing a Vive Pro eye for your father as there simply won't be any functionality for him to leverage at the current time.

@bbirbo - This can be a very complex task depending on which technology layer you consider "direct access". In short, the controller (and all SteamVR tracked devices for that matter) are built around something called a watchman core module - it's a specialized system board that ties together all of the I/O and does a bunch of proprietary black magic required to be tracked by Valve's proprietary base-statation technology. You're not exactly able to directly interface with the hardware per say, everything is mediated by the Watchman via the OpenVR SDK which serves as the official I/O pathway for interfacing with SteamVR hardware. Trying to interface directly with the hardware would fundamentally require some reverse engineering as the system is all inherently designed around proprietary technologies like the core module. You'd get controller event actions via querying OpenVR APIs. The part of the documentation you need to focus on is specifically around vr::IVRSystem. In most cases, you'd either integrate the SteamVR/OpenVR SDK, either by enabling it in UE4 or integrating a plugin into Unity. For projects in custom engines, you'd integrate OpenVR's C++ native libraries. In both cases however, you'd need to have the SteamVR compositor acting as your runtime to pull the controller activity via API. Edit: It sounds like you're also trying to skip using an HMD. SteamVR does support this technically (via a null driver) but the bigger issue here is that the bluetooth receivers that connect the controller to the PC are within the HMD. You'd either have to use the controller wired in via a MicroUSB data cable or you'd need to get ahold of a Steam controller dongle and modify the firmware to allow it to work with the controller (there isn't a ton of community resources around this as it's not a common use-case).

@Dusky That's super weird - I've never heard of anything quite like this. My initial guesses based on your description would be: Your hardware is hitting some sort of thermal limit and your GPU or CPU begins overheating Your GPU has a physical hardware issue Your GPU has a driver or memory issue (you can try downgrading the GPU driver) You power supply may be under-supplying your GPU mid-load? Some other weird OS-specific thing (which you can attempt to isolate/solve via a Window Clean Install which is a nuclear option) Your talking about apps that are made in both Unity and Unreal so it's not engine specific.

@Azkeeh - We sell first-party certified pre-owns that come with a full warranty. If you go this route, you have some level of coverage for if a station fails within the warranty period: https://www.vive.com/us/product/certified-pre-owned/vive/

@Azkeeh I can't speak to that specific seller but I can speak about used Vive's overall. Vive 1 uses external tracking - it comes with these external basestations that shoot out high speed laser pulses. These basestations are mechanical - they spin around at 3600RPM. Because of this, I would advise against buying a used Vive kit under almost all circumstances unless it specifically has a warranty because you don't know the health of the basestations and if one of them fails, it will not be covered under warranty. Buying a used kit only to have a station fail on you would be a huge bummer and it's really not worth the risk.

@Juggoire - I'll ask our product team what the plan with this specific accessory is. That said, the OG Vive is end of life overall. It's not that we're trying to push new users to things like wireless, it's that all of this stuff has to be manufactured and establishing that manufacturing line requires specialized tooling and technicians. Modern manufacturing is an economy of scales, it becomes impractical to produce an item and distribute it internationally unless there is enough demand to offset the manufacturing overhead.

@Kay2029 - The 3 foot version of this is what we unofficially recommend. It works across all HMD's we've tested with. If unavailable in your region, try to source a cabel that meets the following reqs: Shorter than 2M ~20Gbps data transfer Specifically 4K compatible at @ 60Hz.

@Amorgeddon - 1) I'm referencing the percentage of GPU compute resources that are being utilized via the task manager. If you go to the "performance tab" you can see memory usage. My general gist was that SteamVR home is a fully rendered out 3D environment with physics and so it makes sense that it takes up a bunch of resources. This being Valve, I'm sure SteamVR is probably using some rendering technologies to balance load against hardware. 2) SteamVR -> Settings -> General -> SteamVR Home

@Lightningfighter , We unfortunately don't make release note available for wireless. If there was ever a major release, we'd likely make a vive.com blog post to alert users.

@aarelovich - Yes! A laptop with native DP/miniDP support is 100% always the best option (although you still need to source an mDP cable or converter). This requirement is not specific to Vive, all current generation HMDs require DP 1.2+ (Rift S, Index, Pimax, ect...) So here's an expanded idea of what's happening. In order to have a USB-C port talk to the GPU, it costs the OEM extra $$$ to wire the motherboard to support the communication between that header and the dedicated GPU. That's why support is so hit and miss - some laptop models don't support this because it costs alot more to manufacturer. MiniDP on the other hand is a pretty common port - there is a pretty robust ecosystem on the OEM side to support that standard and port into a laptop. Alot of people use DP for 144hz 4K displays - it has alot of usage outside of VR hence why it's more common on laptops.