HackPerception

@yetimadness - we don't manufacturer 2.0 base stations but resell units we purchase from Valve. If an update caused the unit to brick that update would have come from Valve, not HTC. Basestations spin at ~3600RPM and have to having timing accuracy within 1/1000th of a second for tracking to function - they have pretty narrow operation constraints. Valve manages all of the SteamVR tech stack - they haven't created a GUI to determine firmware version but you can usually see the firmware version by running C:\Program Files (x86)\Steam\steamapps\common\SteamVR\tools\lighthouse\bin\win64\lighthouse_console.exe. That said, it doesn't really matter that much because from Valve's prospective, only the current firmware version is accessible and there is no way to downgrade the firmware to a previous version. That said, you think this was instigated by a firmware update, you can go into SteamVR -> Devices -> Basestation Settings -> Recover from Incomplete Update to attempt a firmware recovery. There is one place for hardware support and it's accessible from all of our support pages www.vive.com/support/contactus. That said, by purchasing a 2.0 station through HTC you get 2 year warranty on that attestation rather than a 1 year warranty if you purchased through Valve.

Hello @cusa123, Per 1) Headset manufacturers fix these values per the developer ecosystem. In short, developers want to "color grade" their scenes so they render reliably the same experience across all units of given HMD. For instance, some devs don't want you to be able to see in dark environments by turning up the gamma. Color grading across different HMD displays is an extremely frustrating thing for developers since each HMD uses different panels and having a fixed value helps them control the variability a little bit. Beyond SteamVR's night mode setting, I think you can use OpenVRAdvancedSettings to modify some values. 2) I don't believe it's possible to turn off haptics globally. Having a good set of rechargeable batteries is the best option. I recommend these for all electronic devices. 3) Are you saying that you see new aberrations? As far as I can tell, the update was a windows OS update. It doesn't look like a SteamVR update 4) Which environment are you talking about? We launched a new Viveport environment last week that's a giant cityscape

@Pachuco - So it appears that only one of the USC-C ports on that laptop supports Displayport. I wasn't able to find a diagram which shows which one of those ports is the one that supports Displayport - the manufacter may be able to tell you which of the two USB-C ports it is. Next, the USB-C port actually needs to be wired up to talk to the Nvidia GPU. On many laptops, OEM cut costs by having the USB-C ports only talk to the integrated graphics and not the dGPU because wiring it to the Nvida card increases manufacturing costs and complexity. You can get a rough idea of your port mapping status by going into the Nvidia PhysX panel - you'd see a type C icon under your Nvidia GPU if the wiring is correct. Your OEM may need to confirm Lastly, I don't have any experience with that USB-C adapter. You basically want one that supports 4K@60hz and >15gbps bandwidth. This is an adapter that's known to work well with most current VR devices. If your USB-C port that support Displayport can't talk to your Nvidia card - your laptop is incompatible with all current gen Displayport driven headsets (Index, Rift S, Cosmos, Pro, etc...)

@RazerCicak - Newer SteamVR hardware tends to be a little pickier as the updated SteamVR sensor ASICs have different requirements due to their support of 2.0 basestations. I find that all 2.0 enabled gear (both from Valve, HTC, etc...) can be a little more sensitive to environmental reflections and sensor occlusion in general. Also, 1.0 tracking is now 5+ years old and the algorithms are have matured more.

@Wailyem, I believe your assumption is correct, it doesn't look like the USB port supports the dedicated GPU. I would verify with your laptop manufacturer's using the specific model number of your unit to get an understanding of what the port mapping and wiring look like. I would generally advise against using eGPUs. It's a completely nightmare to deal with drivers and compatibility and even the most optimized eGPU setups only are able to provide ~80% of the power of the GPU. I can only recall a handful of times in the past few years were I've seen people have success with eGPUs (usually with Razers and Razer core) and it sounded stressful to set up. When you get into less brand specific eGPU solutions, the hardware and driver compatibility get insanely complex.

@Chris1000000 - You can isolate it from being on the screen and being on the lens but putting the headset on and using your hands to wiggle the HMD back and forth. If the damage is on the lens, you'll see the aberration move in the foreground against the background (VR scene), if it's the LCD, the damage will be fixed on the display panel and won't really shift around. Kind of hard to describe in words but you should be able to tell what focal plane the defect is on by wiggling the headset a little so the angles in the optical path shift around. edit: Yes - it looks like the LCD was exposed to direct sunlight which has caused a burn on the LCD. Imagine a magnifying glass and an ant. If you take closer photos of the single lenses, I can get a closer look.

@Chris1000000 - I think you got scammed and would attempt to reverse/challenge the purchase. It's hard to tell from these photos but my best guess is that this is sun damage. The lenses in VR headsets act as magnifying glasses and focus the sun into a laser beam that can burn the screen. It's not something that's covered under warranty and if our repair system accepts it - it would cost a fair amount to repair. Here are some examples but the damage could vary a bit.

@Castana - Index does not have any wireless solution (as of this post. No 1st or 3rd party solution) but you can use a Wireless Vive Pro with Knuckles. This is a setup I personally use often when testing

@Castana It's theoretically possible but you'd like need an external PC, a bunch of custom software, and more "workarounds/hacks" (i.e. OpenVRSpaceCalibrator) than would ever really be stable for real-world usage/scalability. A SteamVR update could break everything overnight. Your fighting both runtimes and firmware restrictions. You'd be better off using PCVR and using a Vive Pro with a wireless adapter and knuckles or just sticking to the limitations of the optical-based Oculus hand tracking. If you're attempting to use Oculus with patients - I'd also recommend being sure that you can meet HIPPA compliance or whatever similar compliance standard exists for your country. In some regions - it's an uphill battle to use a Facebook device for medical. As someone whose hybridized SteamVR devices with non-SteamVR tracked devices - I can speak from experience when I say that it was extremely frustrating and eventually made me rage quit. Definitely possible if you have a lot of patience, budget, and free time but not recommended professionally. Doing it with Quest is an order of magnitude harder than with Rift S/Rift if you're trying to run a mobile executable rather than a PC executable via Link/VirtualDesktop.

@d_boss_mx Happy to help. The original controller uses an early ~2015 version of the SteamVR sensor and only works with the original base-stations. The newer, bluer Vive Controller 2018 is an updated revision that has updated tracking sensors which can work with both 1.0 basestations and the newer 2.0 basestatoins (e.g. Valve Index base stations). If you try to use the original controller with the new basestations, they won't track at all. The price difference comes from the fact that Valve has licensed us to manufacturer all of the 1.0 gear in our own factories but the licensing is different for 2.0 gear and they've retained many of the manufacturing rights requiring us to purchase parts for integration. There are some other slight revisions but what I've just said are the primary drivers.

@hubbahubba In order to use any SteamVR tracked device, it's a hard requirement per Valve that you use the SteamVR runtime. You must use the OpenVR/SteamVR SDK to interface with the runtime and decode the tracking data and query a pose estimate. You cannot interface with the hardware directly as the entire SteamVR tracking tech stack is proprietary to Valve - usage of the SteamVR/OpenVR SDK is required. Valve provides native C++ libs if you want to attempt a native integration into a custom app. Please see this guide from Triad Semiconductor for an example on how to use the tracker without an HMD. These days, you could also theoretically try to use OpenXR as your framework in early access (different from OpenVR) but it's still really early days with OpenXR. Please note: From a Vive prospective, we do not officially support the usage of tracker without an HMD and we are unable to provide technical support for these advanced setups. Valve has designed the entire SteamVR UI/GUI is all designed around having an HMD at a bare minimum and things like roomsetup require at least an HMD but ideally an HMD and controllers. Point blank, you're going to save yourself so much time and frustration by having at least and HMD/Controllers and overall you have the added benefit of getting to play with VR. I recommend anybody attempting to use SteamVR tracking professionally watch this video. Please see my more detailed responses in the following threads:

@par - The problem is pretty obvious here. You're exceeding your polycount budget many dozens of times beyond your budget. You desperately need to optimize your scene and assets. VR can display a few hundred thousand to a few million environmental tris within your scene depending on your target hardware and what rendering techniques you're employing. Even with culling, you still need to keep within polycount budget within your frustrum and your overall scene because all of these assets need to live in memory somewhere. You couldn't run this in standard flatscreen at 90fps on any modern hardware, let alone in VR and as you can see in the screenshot, your in-engine framerate is 2.4fps. It's taking almost half a second to render a single frame (425ms) when it should be taking below 0.011 seconds (11ms). Your setpass calls should be ~1000 for PCVR and 100-200 for mobile - you're sending far too many drawcalls to your GPU by a factor of over 100. You will need to study performance optimization and make very significant changes to your project if you ever want to hit a usable framerate. It doesn't sound like you're LODing your assets and are just dumping high-polycount assets into your scene. Beyond polycount, your texturing and lighting are also likely extraordinarily heavy a huge portion of your drawcalls may be due to how you're texturing. Based on the few frames I can see in the video - I'm not sure where all of your polybudget is going, many of the walls and columns I see in that scene can be represented by a handful of tris/quads because they're flat walls are are essentially primitives.

@ReheLab Per your first question, SteamVR devices employ sensor fusion between the basestations and an integrated IMU. The IMU has a faster refresh rate than the basestations can deliver and the IMU allows you to create approximate pose estimates for frames where you don't have enough optical samples for a proper pose estimate. I recommend anybody interested in learning how SteamVR tracking works to watch this video. Per the second part, I'd tag in @MariosBikos_HTC

@par This is called the "compositor fallback screen". This occurs when your application is rendering under 45fps. It falls back to the SteamVR home screen in order to prevent motion sickness. If you're hovering right between 40-50ms, it can flip back and fourth like you see in your video. If you look at your frame timing graph, you can see, you're frame timing is really bad - it should be around 11.1ms to correspond to 90FPS. You can disable this feature via Settings -> Video -> Fade to Grid on App hang but doing so is highly unrecommended because you're opening yourself upto severe motion sickness. Are you developing this application? If so, you really need to optimize it to get below 11.1ms on an average GPU. If you're an end-user, you can try to increase your performance by going into Video -> per-application video settings and lowering the value below 100%. Or you should consider getting a more powerful GPU if you have a low end.

@StevenStrick369, unfortunately a blinking red light on a 2.0 base-station indicates a mechanical problem within the device. Due to being a high-speed precision mechanical device, you can't repair these in-home as repair requires precise machinery and parts. Your device is likely covered under warranty. To start a repair ticket, please capture the serial number off of the back of the unit, and start a live chat via www.vive.com/support -> contact us -> contact us. The best way to maximize the lifespan of a base-station is to enable base-station power management within SteamVR's device settings and force the devices into "sleep" mode so they power down when not being used.

@CrakeJ - Sorry - we don't believe that it's a good idea to host rumors or other unconfirmed info on our official forums. It causes confusion and drives questions towards our teams. I hide the post after getting questions about the post from several developers. Was 100% unrelated to the Cosmos criticism.

@razgour - That is correct. 2.0 base-stations only work with the newer revision of the Vive controller that's blue (pictured below). The original black Vive wands have sensors which predate the technology used within 2.0 basestations and they're 100% incompatible with 2.0 stations. Devices with the newer sensors (knuckles, the 2018 revision of the Vive wand) work with both 1.0 and 2.0 stations.

@razgour - 1.0 basestations max out at about a 4.5m max distance between the two units diagonally. You can try to squeeze out a little extra distance by using the sync cable but your results will vary by environment. Basestation 2.0's should be no more than 5.5m apart from one another under a standard use case. Exceeding this distance will result in SteamVR displaying error messages and tracking degradation. You can use upto 4, 2.0 stations in a space to attempt to achieve upto a 10x10m playspace if you place the units strategically but your headset tether length starts to become a limitation. When using 2.0 stations, don't place them in corners - you'll cannibalize their ultrawide FOV by putting them in a right angle corner.

@U2andki This is a budget laptop that isn't compatible with current gen headsets. You may be able to use some first gen, HDMI driven headsets but none of the Displayport dependent headsets (Cosmos, Pro, Rift S, Index, etc...) will work on this HMDI. The GTX1050 and the 1050Ti are not VR compatible but the 1050Ti is a notorious edge case that will drive first gen headsets in some configurations but not all.

@SanityGaming DLC is a case by case basis. In many cases, only the "base app" is in Infinity and DLC access is treated as normally paid DLC because the developer wants to optimize revenue but there have been a handful of examples where the base app and the DLC are all Infinity. It really upto the developer but it will generally skew towards DLC being paid.

Cosmos, Cosmos Elite are not End of Life are are still mid-life. We are not proceeding forward with a launch of a "Cosmos Play" SKU.

@sashanos A white screen specifically indicates a loss of tracking. It could be due to a environmental reflection or your body positioning. If it's happening at a somewhat regular time interval, it may indicate that another device on your home's electrical grid is switching on/off and causing a momentary fluctuation in the quality of the power delivered to the basestations (similar to lightbulbs will dim/flicker when a high draw device is switched on). We've seen this reported before with high draw devices like air conditioners and refrigerators but lower draw devices like your monitor going into power savings mode could cause it as well depending on the quality of wiring in your building. Reflective surfaces" in practice are extraordinarily hard to track down without specialized equipment because materials interact differently with IR light than optical light. A material may not be reflective in the visible spectrum but may be highly reflective in the IR spectrum; the same is true with opacity, some visibly opaque materials will be complete transparent in IR and vice versa. To detect reflections, generate a system report or open up the SteamVR web console and search for the term "back-facing". I'll post an example of what a reflection looks like in the logs below. Sun Jun 26 2016 23:02:09.676 - lighthouse: LHR-4E8EF209 H: Dropped 32312 back-facing hits, 2069 non-clustered hits during the previous tracking session

@Tango87 - You might need to replace your USB-A -> USB-A cable eventually. The one that ships with the wireless adapter is flexible but sort of thin and can wear with use. You can purchase other aftermarket USB-A -> USB-A cables that are thicker and less flexible (you may feel the cable more as well) with the tradeoff that they're a little more resistant to damage from bending/flexing. In our office (in the olden days when those used to be a thing), the stock USB-A cable would only last a few months due to heavy usage and due to people yanking of the cable and loading the entire weight of the battery on the cable.

@Esch, This is a pretty weird error. I saw a similar report on Reddit this morning that I can't see an obvious cause for either which mean indicate it's a SteamVR thing. I'd recommend trying to rule out reflections via the SteamVR logs. The way to confirm if you have a reflection issue would be to create a SteamVR system report, save the file, then open the file in a text editor and use Ctrl+F to search the document for the following term: back-facing. You can also use try viewing the logs in real-time in the webconsole which can sometimes be more intituve since it's real-time: http://localhost:27062/console/index.html If you see a high number of back-facing hits, it's almost certainly a reflective issue. Here's an example output that shows a clear-cut case of reflection-based interference: Sun Jun 26 2016 23:02:09.676 - lighthouse: LHR-4R8EF209 H: Dropped 322312 back-facing hits, 2069 non-clustered hits during the previous tracking session

@Prawnman69 Unfortunately, to my knowledge the Half Life Alyx bundle offer ended on ~7th, September 2020 in most global regions.