HackPerception

Double checked vRAM usage. I only get to 5.5gb of vRAM usage with SteamVR home enabled but that's with a 100% out of the box config. If you had other assets such as environments or collectables, that number would increase. I have to open a really heavy VR app to start getting past 8gb.

@Amorgeddon - Vive wireless is a CPU based system - it will increase your CPU demand rather than your GPU demand. SteamVR home (i.e. SteamTours) is a fully rendered out environment with physics, lighting, spatialized audio, 3D assets, ect... so it actually makes sense that it's pulling your GPU resources more than a blank compositor environment. I tested on a wired and wireless Vive Pro with a GTX2080Ti and got consistent GPU utilization rates between wired and wireless. SteamVR home is a heavy application - I personally disable it on all of my workstations because it does add rendering cost. SteamVR home disabled: SteamVR home enabled:

@TtGamer123 - Unfortunately, no. The cosmos controller supports optical (visual) tracking only. The Cosmos controller does not have the embedded sensors on it required to detect signals from a basestation like the OG Vive or the Vive Pro HMD and controllers.

@KKB - I can quickly scan your SteamVR system report logs if you PM them to me.

@lamyipming You'll need the Cosmos-specific 21W battery that comes with the Cosmos wireless attach kit to power the Cosmos. Quick charge is an intelligent charging system - the device and the host communicate with each other to negotiate current. If the host cannot supply the requested current, the system generally kills power flow between the two devices. If using an underrated battery, the HMD should shut down or not start at all (the behavior may vary a bit depending on the specific battery).

@aarelovich - They tend to work in two cases: The USB-C port must be able to output a Displayport 1.2+ compatible signal via the dedicated GPU. If you have an Nvidia GPU, the best way to check this is to go into Nvidia's control panel, go to the PhysX panel, and it will show the mapping for your system. As you can see in my case that I posted below, my laptop's USB-C port isn't hooked up to the Nvidia card and thus wouldn't be compatible with any sort of adapter . I can't speak to that specific adapter. The key requirements are that it must support 4K @ 60Hz, must support Display 1.2+, and must be able to transmit ~20Gbps of bandwidth. Here is an example of a cable known to work: https://www.amazon.com/dp/B0777RKTJB/ref=twister_B077GCMQXJ Here is an example of a converter known to work: https://www.amazon.com/CAC-1507-DisplayPort-Adapter-Chromebook-Thunderbolt/dp/B018AX3HJO/

@JuicyJimme That's awful! I'm very sorry to hear that! I frankly have never heard of anything like this before surrounding VR - I can't provide any useful advice here except to say that if you're having reactions this adverse to a VR device, that I'd strongly recommend that you stop using your HMD any further and that you avoid all VR & AR products now and in the future until you qualified medical staff weigh in on what's happening. Feeling a bit weird after a VR experience isn't unheard of - what you're describing is well beyond that and VR simply isn't worth your health and well-being. Hope you're feeling better soon!

@Zepps It shows up bundled with all Vive software installed on the PC as an entry called "Vive software" within Window's remove programs UI. You uninstall that to uninstall the console.

@Zerax Please contact MSI support and let us know what they say. This isn't specifically limited to Vive Cosmos - it affects other Vive HMDs as well as HMDs from other companies as well.

@Kovatch This is unfortunately one of the harder types of problems to troubleshoot as it could be due to a SteamVR update, a GPU update, a windows update, or it could be related to something much deeper in your PC. If you share a SteamVR log, I can take a look to see if anything stands out. Do SteamVR apps when played in the Rift S have the same FPS drop (using SteamVR, not the Oculus-native runtime)? Generally in these cases it may be helpful to: Roll-back your GPU driver a few versions Reinstall SteamVR Adjusting SteamVR's video settings to see if enabling/disabling features like motion smoothing affect the behavior Reinstall Windows ***nuclear option***

@harf4ng If you're using 1.0 stations, the two stations need to pointed roughly towards one another for the optical sync system to work. 2.0 stations have more flexibility because they don't use optical sync. I'd mount one of the stations on the lefthand wall (lined up where your chair will be so the chair is dead in the middle of the FOV) mounted high and pointed more downward. This will nail down tracking for your cockpit. I don't know what the rest of the room looks like - if you can mount one in a opposite corner 3-5m away, that's most ideal. Otherwise, mount it in a location that enables as much overlap with your first basestation and your desired tracked volume. The stations have a 110x110 FOV so a little wider than a right angle. With 1.0 stations, mounting them diagonally is simply how they were engineered to be used. If you mount them in other locations, bear in mind that your 360 tracking may be impacted. The stations do need to be pointed generally towards on another for you to use optical sync, if you mount them in a way where that's not possible, you'll need to use the massive sync cable and set the stations to channels A + B for wired sync mode. The new 2.0 stations are a godsend for enterprise and advanced use-cases, especially if you're doing multi-HMD setups or setting up at conferences. That said, the added benefit is pretty minimal in the typical in-home use-case and most content that's developed for in-home VR is optimized for 3x3m playspaces. You're not missing out on much unless you have a more advanced deployment scenario.

@Nickman I'm converting your post into a support ticket so I can directly connect you with our arcade team.

@harf4ng Are these 1.0 or 2.0 stations? Do you plan on using roomscale VR at all or will this strictly be for seated sim experiences? If using 1.0 stations, the best solution in the mast majority of deployments is to use the recommended setup of installing the two stations ~6-8 feet off of the ground about 15 feet (~4.5M) diagonally across from one another. This setup is recommended because it maximizes the tracked volume, minimizes occlusion (ensuring the HMD always sees a station), and allows the two stations to see one another to enable "optical sync" which lets them sync up with one another wirelessly without having to use that giant "sync cable" that ships with the kit.

@JuicyJimme - There's not a ton of academic studies into this kind of phenomena. Realistically, the human brain, the body, and consciousness itself are all so complex, it would be rather difficult to come up with firm conclusions on this kind of phenomena without a very comprehensive study. Anybody using VR currently should be taking regular breaks during usage as VR is more than just visual but also heavily incorporates your body and it's other senses. When I first got reliable VR access at home, I had a very similar experience. My dreams the first few weeks were very lucid and super sci-fi as a bonus. Long term VR immersion definitely still affects how I consciously experience real-life and makes me acutely aware of how my brain constructs my projection of reality around me and how my brain makes tons of interpolation mistakes and then patches them up as new sensory data fills the data gap. I have 4000-5000 hours in an HMD - it's still something I personally experience if I use an HMD for hours on end or if I try a very intense experience whose visuals don't match up to my embodied experience. VR exploits your biology but by no means is your body or your brain evolved to spend time in virtual spaces. Taking regular breaks is an important part of self-care and safe and healthy usage. Your case sounds a little intense - please err on the side of always taking 15 minute breaks for every 30-45 minutes of usage in the future and avoiding straight binging. I'd also recommend being extra careful if you're a neurodiverse individual as your brain may process the stimuli very differently than other users which could compound the problem. VR is very intense on your body and your psyche - most people coming over from the gaming community underestimate how much stimuli you're processing. Gaming in VR is not directly comparable to flat screen gaming and it will take a while for everybody to better understand what's happening when we immerse ourselves in VR for too long.

@Annabell Can you elaborate more? I'm not sure I follow based on SteamVR's technology. The "action" is defined by the developer and then mapped to a physical input either via the default binding configuration or a user-generated binding file https://valvesoftware.github.io/steamvr_unity_plugin/tutorials/SteamVR-Input.html.The controller input remaps around a-pre defined action - a controller's I/O is heavily customizable by the end user but only to the extent that it can work within the actions defined within the integration of the SteamVR/OpenVR plugin/SDK. I.E. you can remap a system button to report itself as any other input but it won't do anything unless there is an action in place for that input to map to. Here's a video tutorial:

@Sweet - Unfortunately I'm not able to understand this translation. Are you trying to develop some sort of virtual desktop application? With #2 it sounds like you're saying that when a person exits the application, OpenVR is also closing preventing you from accessing the desktop dashboard? I'm not really sure. Generally speaking - when working with OpenVR - you need to refer to their API documenation https://github.com/ValveSoftware/openvr/wiki/API-Documentation. It's all C++ and within these API's there's a number of different ways to launch or close applications or SteamVR itself. For instance, below is how to trigger a compositor shutdown via an HMD driver:

This is very complex. HTC has been a longstanding OEM - we worked with Google to release the first Android phone and at one point, one in every 5 smartphones globally was an HTC phone. In 2015, our former Peter Chou was leading our future developments lab when he helped establish a partnership with Valve around their SteamVR technology stack.

+1 on contacting MSI support on this. There are some VBIOS issues with some more recent models - we'd differ to MSI on this cluster of issues as it's very model and version specific.

@DarkSlice - There's no difference in either of these SKUs between US and EU; they're the same hardware and all watchman enabled gear (Trackers, controllers) use standard bluetooth RF (~2.45Ghz). The real difference here is that if you buy a unit in the US the warranty is tied to the US and our EU based care team can't process any warranty related RMAs as the unit will be out of region and not visible in their database. That's the real disadvantage from purchasing while in a foreign country.

@Electron I can officially confirm a 150x150 degree FOV on the PC-side wireless transceiver (same on vertical and horizontal) with a rated range of 6m. You can definitely mount from overhead if you can also overhead mount the PC's (as you can't really reliably extend the wireless linkbox) - in fact, that's actually the best way to try and achieve occlusion free ranges that approach the ~10x10 meter range of BS2.0. 60Ghz is a "bouncy" frequency rather than a penetrating frequency - the behavior is very complex and unique to each environment but keep in mind that to an extent, signal bounce plays into the occlusion modeling and is actually partially how the system works.

@MrGedeon With all 8 of the stations powered on, go into basestation management via SteamVR -> Settings -> Basestation -> Configure Base Station channels and use automatic configuration to ensure every basestation is on a unique channel. If you don't have each station on a separate channel, tracking will go haywire. Only 4 stations are supported at time per HMD/SteamVR instance. We recommend that when you're running roomsetup for a given HMD, due to the lack of advanced UI/UX within SteamVR, that you run roomsetup for a given HMD with only the 4 stations powered on that you specifically want that headset tracked by that way your roomsetup configuration is specifically tied to the 4 stations you want that specific HMD to be tracked by. This is generally the easiest way to ensure a correct setup.

@Roboman14107 - That's a really complex question. In short, VR has been a thing researchers has been experimenting with since the 1950's and 1960's. The thing about VR is that it's a cluster of technologies that when combined into one package - produce a compelling immersive experience. A VR headset at it's core is a very sophisticated sensor array that senses head motion combined with technologies like displays, lenses, audio, ect... so it actually takes advancements in a wide range of technologies to be combined together to make a good VR headset. I would recommend you listen to this podcast about this early history of VR: https://voicesofvr.com/139-henry-fuchs-on-the-early-history-of-virtual-reality-with-ivan-sutherland-the-sword-of-damocles/ That podcast overall is the best learning resource I can think of when it comes to VR. The key importance of Vive historically is that we were the first headset to launch to consumers in 2016 with fully tracked motion controllers and sub-millimeter tracking precision beating out Oculus' touch controllers by a number of months. It was a partnership with Valve but overall VR has taken the work of tens of thousands of researchers and engineers over the last few decades spread across a very wide spectrum of disciplines. Prior to Vive in 2016, VR headsets were very primitive and limited to use in research and defense and they cost hundreds of thousands to millions of dollars for a comparitivley low quality VR experience. Valve's advanced SteamVR tracking technology was a key innovation which spurred a ton of VR development and GPU's also started getting fast enough to do VR around the same time. I hope this gets you off in the right direction @Roboman14107

@HUYA, There is a visual indicator scheme: If the Vive controller is black, it's SteamVR 1.0 sensor enabled gear and can't detect 2.0 basestation signaling. If the controller is blue, it is SteamVR 2.0 sensor enabled gear and it can accept signals from both 1.0 and 2.0 basestations. If a Vive tracker's logo is blue it's 2.0 enabled, if it is grey/black it is 1.0

@Annabell Networking is way outside of my experience set so I'd defer to another staff member for feedback. I will however say that I've seen several projects accomplish this sort of use-case using OSC and websockets although I can't speak to their specific tech stacks or implementations. @Corvus

@Phr00t It was never integrated into SteamVR main branch though before Leapmotion's techology portfolio was purchased - this is something an end user has to manually install and enable which can't scale and the solution also requires the end-user to download and install an additional runtime which carries with it additional EULAs. With the SDK based solution, the user doesn't need to install an additional runtime in many cases because that support can be wrapped into the executable binary. OpenVR is highly flexible - it's why it's my VR runtime and development platform of preference and you can definitely go create your own drivers. That said, getting a tech stack fully aligned and the driver integrated into the SteamVR main branch for scalable support is a complex and lengthy process. It's all very complex logistically - only a few companies have gotten their drivers added to SteamVR main branch. There are major advantages to both SDK-based approaches and major advantages to driver level approaches - it's not exactly clean cut and with SDK based approaches you control the release and update schedule rather than relying on a 3rd party platform mediator.