HackPerception

@binarymushroom At a high level, the problem with any hardware based solution is that it introduces both hardware and software based dependencies and that it needs to work with a decent portion of the global population in terms of ergonomics, weight limit, sizing, ect (usually targeting the 95th percentile). To launch any hardware based solution is a huge effort that requires hundreds of developer teams to update their software for compatibility and in many cases, program in support for their app or completely change their UX. While I think you're idea is pretty solid and way more feasible than most other external locomotion solutions I've seen - I personally think that the VR industry as a whole is still struggling with basic IO and IO fragmentation is going to be a key topic in 2020-2023. It's going to simply take time for the VR industry to figure out hands and as other hardware companies comes online, they'll have a different schema for hands requiring developer buy in. Hands are by no means a solved problem still - locomotion is probably a more medium to long term thing due to the complexity.

@Phr00t - Calling them "SteamVR controllers" implies driver level support within SteamVR. The implementation is not driver support, it's SDK-based support which means that developers have to integrate an SDK into their individual project to enable the feature set meaning that it's per-application support rather than global SteamVR support. Quest's handtracking is also SDK-based but they've launched with some basic handtracking in first party apps and the core OS - with SteamVR however it's more difficult to do that because SteamVR is an open platform/ecosystem that services numerous headsets rather than being a closed platform like Quest. It's worth noting too, that handtracking is currently further along on Pro because it's a more mature platform.

@Nic111, I'd add that beyond the SRAnipal runtime, Nvidia's VRS shading technology which drives foveated rendering as well as a bunch of other related VR-specific shading technologies are all Windows only. PCVR is 99% Windows based - all of the tools, rendering technologies, and runtimes are Windows ecosystem based.

@@Fink Sorry for the confusion, let me rephrase it. You're more than welcome to post this kind of stuff (and encouraged if it's accurate and not misleading). I however have rules and legal requirements on my side that make that kind of stuff difficult to post on my side because anything I post on this account may be considered an "official" advice based on my credentials so I have to take extra care with my posts because there are downstream implications. I have to wear my Vive hat - I'm a huge VR fanboi which is why I joined Vive. Spam and inaccurate or misleading posts are subject to moderation; all other dialog is healthy and why we host forums. To that point actually, @coleco, in your opening post, you mentioned scorn for asking this question. Quite the contrary - this is a difficult question with no easy answer. Consumer super VR is early days, you're always welcome to post here to try and leverage our platform for solutions to problems. 🙂

Thanks @Fink - I haven't tried that .dll firsthand and I can't make those types of recommendations from an HTC employee account - liability and so on. Really appreciate you posting that here - I believe this is the best methodology. @coleco I hope you have some luck with that methodology - as I said in my earlier post, FO4 and Skyrim are actually two worst case scenarios for SteamVR input remapping overall because they're using Creation engine. Virtually any other SteamVR title has a better outlook when it comes to remapping support. Please note that if you encounter a SteamVR title that doesn't have proper input mapping for Cosmos - you can try going into the Controller Settings for that tile and checking to see if there is a already a community made binding configuration for that game - we've published a bunch for popular games and other community members have also published them as well.

@Electron I unfortunately don't understand this question fully - there may be a language barrier here? What do you mean on "the windows glasses" - do you mean Windows Mixed Reality HMDs are are you talking about the IR windows over the sensors on a SteamVR HMD. The lighthouse system works on ~850nm near IR (I believe you'd spec ~825-870nM transparency in your material selection). This is the most detailed public explanation of how basestation tracking works - I recommend anybody working with SteamVR tracking to watch it: https://www.youtube.com/watch?v=75ZytcYANTA (@TomCgcmfc you'd probably find this interesting)

Skyrim and Fallout are specifically bad examples because they're made using Bethesda's custom engine which brings with it a ton of complexities. In short, neither app is super great with Index or Cosmos controllers currently to my knowledge. Most apps that don't have native support can use SteamVR's remapping but the custom engine here breaks alot of that. I'll ask about the current status but I don't think Bethesda has added native support yet

Public release means the client will prompt you to update the device and the runtime. I'd recommend taking note of the advisory in this specific release note to minimize any risks from updating the software.

@Hooflee @zig11727 is correct (thanks!). That setting is talking about the rate of your countries' electrical grid. The HMD strictly outputs 90Hz - there is no way to alter the refresh rate of the panels. We strongly believe 90Hz is the minimum required for a motion-sickness free VR experience when it comes to DesktopVR. @Hooflee - The Cosmos uses optical tracking - please see the video below for why this setting is very important. It's really trippy to think that entire city streets are actually strobbing between dark and light but due to persistence of vision, our visual systems blends it all together. LED lighting doesn't do this because the AC gets converted to DC.

It's not really appropriate for me to comment on the tracking quality beyond the official statements, especially as I don't work on a hardware team. Improving tracking is something that's being worked on with a high degree of priority. I would ambiguously reference other recent HMD launches. Modern hardware simply isn't what you get when you unbox it on day - the nature and quality of the product evolves over time with FW and SW updates. With the release of the external tracking faceplate - you can have the flexibility to have basestation tracking quality when and if you need it but also the convince and low barrier of entry of optical for when you want that. As someone who travels with HMDs - I'm actually really excited about hybridized tracking systems like this. @Serhii - The Cosmos is not a commercial facing product and unfortunately isn't hardware that's intended for use in an arcade. It's simply not designed for commercial abuse, it doesn't have a commercial EULA (only a consumer EULA), doesn't have a commercial warranty. Outside of tracking issues, there are a range of other barriers beyond tracking that will come from using a consumer-facing product in a high-intensity business use case. Vive Pro is our current arcade/enterprise offering - Cosmos unfortunately designed, marketed, or sold for your use case.

@Knight_Ex - Yes, we've released several major updates which have improved tracking scenarios and there are dedicated teams working on making iterative improvements to the tracking UX. We actually did a series of side by side videos for the 1.0.7.1 release which shows the improvements in action - compared against earlier versions. I'll try to figure out which team made these videos and ask if they plan to produce similar videos in the future so there's a more visual frame of reference for the improvements as it can be a little abstract without a visual.

@Fhreed - Unfortunately the Cosmos controllers do not have the sensors required to detect signals from a basestation - they're strictly optically tracked by the cameras on Cosmos. The Valve Index controllers are the only other productized type of SteamVR controller that would be compatible with your headset and basestation tracking (as well as your content). Unfortunately, the stock situation and overall availability with Index controllers is variable on your region and they're currently unavailable in some places due to last week's Half Life announcement.

@Zacware - I'm sorry, I was actually wrong on this one. We sell replacements for the OG Vive but apparently it's a more involved system with the Pro; I simply was incorrect with my statement and I apologize for the confusion. Please reach out to the support inbox that Jaggibson recommended - that's an advanced support team that will give you the most accurate information possible about your specific case. @TomCgcmfc - Apparently the Vive Pro nose guard actually makes internal contact with the device, it's not just a surface mounted thing. I have never actually seen a detached nose guard IRL so I'm simply out of my element here - I'm a developer and the forums aren't actually my primary role at Vive - I'm just a strong advocate for community. You're very correct that adhesive tape is going to carry far less risk - thanks for pointing that out!

@TomCgcmfc - I believe that's the current standby behavior. Valve has pushed quite a few updates to the base-stations in the last 45 days that I'm not personally familiarized with yet including a completely new behavior (v1.8.20 notes below). You can't use power management in places with more than 1 HMD and thus we need to keep power management disabled in-office or it wreaks havoc so I haven't tested the new behaviors firsthand. I'm currently traveling abroad otherwise I would test at home to verify. As long as the rotors start and stop according to your usage - I'd imagine everything is working correctly. The overall key with BT power management is that it's mediated by commands outputted by the compositor - if you abruptly stop the compositor (like a hard PC reboot) or it crashes - you may need to cycle SteamVR to re-sync everything.

@Jakey - Sorry for the delayed reply, we're seeing the peak of our yearly inquires due to Black Friday/Cyber Monday. The standby mode depends on your SteamVR settings - if you enable basestation power management within SteamVR's settings, when you shutdown the SteamVR compositor a bluetooth broadcast is sent out as part of the shutdown process. It's not a timeout thing like it is with the controllers - it's an actual command sent out by the compositor so while it's generally reliable, it sometimes can trip up if the compositor crashes or you hard reboot the PC without shutting down SteamVR. Don't use this if you're using more than one HMD in the same space. First go to SteamVR -> Settings -> Bluetooth and ensure it's enabled (you'll need to be using a linkbox for this to work). It may prompt you to install a driver. Next go to SteamVR -> Settings -> Basestation and click Power Management to access the correct interface page. Yes - since the basestations are mechanical devices, if you leave them plugged in without power management enabled and they stay fully powered on and spinning - that uptime will count against the unit's lifespan. Each rotor in a basestation rotates over 200,000 times per hour so it's definitely recommended to either use bluetooth power management or unplug the devices when not in use to ensure the maximum lifespan. You can definitive tell if a basestation's rotors are spinning and emitting data if you can see the faint circles from the 9 sync LEDs on 1.0 stations or the two laser sources on a 2.0 station (final two pics). You can use a smartphone camera to see the IR sources inside the station if you can't quite see it with the naked eye.

@Dickytwo - Just for full transparency - the faceplate incorporates TS4231 sensors. That means you can use either SteamVR 1.0 base-stations and controllers, or 2.0 base-stations and controllers (including knuckles). The real key with base-station compatibility is that if you're using 2.0 stations, you need to ensure your controllers have the updated TS4231 sensors - for instance you can't use 2.0 stations with the controllers from the original Vive because the sensors on the original Vive controllers can't detect 2.0 signals (this is the main scenario you need to look out for).

@johnx65 - As @T said, this has to do with a flag on the website trying to launch SteamVR in order to drive a WebVR/WebXR experience. It's not specific to the Cosmos - it's a general WebVR/WebXR behavior that will occur if you have SteamVR installed, regardless of your headset of choice. WebXR is still in early days - there's some major UX gaps in how it's been implemented on some sites as you've discovered firsthand. If you're using Chrome rather than Firefox, you'd want to navigate to type chrome://flags in your address bar and then find the "webvr" on the resulting page and set that flag to disabled. Chrome: Firefox:

@AndyRog12 - The Cosmos uses camera based inside out tracking to facilitate and easier setup and reduce the number of cables and other external devices required to get into VR. The HMD has 6 onboard cameras in it's default configuration which track the position of the HMD and the controllers. In Q1 2019 - we'll ship a first party modification that will enable you to remove the front cover of the Cosmos and replace it with a SteamVR sensor enabled faceplate so you can use 2.0 basestation tracking and controllers whenever you'd like. With that you can use two 1.0 stations to create a 4x4 meter high precision-tracking playspace or you can use upto 4 2.0 basestations to get upto 10x10m space.

@tstark - It really depends on what your target ultimately is. Generally speaking - we'd recommend developers use the Vive Pro (full kit with 2.0 tracking) due to the higher precision tracking and because it's simply designed for a much larger range of use cases. It has more ergonomic adjustments so you can fine tune the HMD to yourself and you can use the HMD natively alongside other SteamVR devices like the Index controllers (knuckles). It's also important to keep in mind that the bulk of Vive owners are using Vive wands and so you'll want to ensure you have a pair of wands to calibrate your input mapping. The SDK situation is very project dependent. At a high level: You'll need to integrate or enable the OpenVR/SteamVR SDK/plugin in your project to drive any sort of input or output to any Desktop Vive HMDs (Original Vive, Pro, or Cosmos). You'll also need to integrate this SDK to drive IO to other SteamVR devices. There's a high level overview of our Vive SDK's here. There is some hardware dependency https://developer.vive.com/resources/ None of them are flat out required but they can bring out specific hardware dependent features The Vive Input Utility can be very helpful for input mapping https://assetstore.unity.com/packages/tools/integration/vive-input-utility-64219 If you have any specific questions - feel free to post here and I'll try my best to answer your questions or connect you to a subject matter specialist. Regards!

@okocha1337 I'm honestly not sure if this is an Blender -> Unity workflow or a SRWorks thing. I have quite a bit of experience creating 3D models in the context of photogrammetry and I always struggled with getting remotely accurate scale when processing modelings in Blender - I never really cracked that workflow and Blender is quite an expansive tool. I know others in the 3D scanning community have shared similar challenges with scale. This may be worth a try: https://blog.mattnewport.com/fixing-scale-problems-exporting-fbx-files-from-blender-to-unity-5/ I think an important question here is generic assets such as a 1x1x1m test cube is rendering at the correct real-world size in SRworks so you can isolate it to your custom asset or the SDK/Unity scene. P.S. Thanks for contributing @JCSegula - I appreciate it 🙂

@Jakey - Sorry for the delayed replied for this, alot of our forum staff was spending time with our families for the Thanksgiving holiday in the US. @TomCgcmfc is 100% correct about this - this is actually a very difficult thing for us to advise on from a self-repair standpoint as many glues such as cyanoacrylate glues (super glue) contain solvents whose fumes that will chemically react to the plastic lenses causing them to "fog" up or become brittle. You also risk getting the adhesive itself on the lens - either directly, or via the fumes. We sell replacement nose guards with pre-filled adhesive strips which is the "safest" and lowest risk option. If you'd like to attempt self repair - I can't safely point to a specific adhesive type due to the risks laid about above - we wouldn't want you to damage your lenses based off advice from us. That said, I would recommend covering your lenses with something like a strategically positioned microfiber cloth to ensure they're as isolated and protected as possible from any adhesive. Avoid super glue. I'll ask around to see if we have any recommendations internally.

@JonathanFernas I'm not sure I 100% follow this - especially the grey screen part. Perhaps the grey screen was caused by a voltage spike to the USB controller or some protection mechanism. Grey screen usually means loss of tracking - if the tracking data was prevented from getting to the PC you may see a grey screen but you'd probably also hear the Windows USB device connect/disconnect sound in that type of scenario. Overall, if you absolutely must - the best UX is to get an external battery pack and put that in your pocket so you only have a short cable from your pocket to the controller and not some massive 15 foot cable back to your PC. You can run controllers indefinitely like this and I've done this before at trade shows and festivals. You don't need a massive or expensive battery back to do this. The controllers have a 960mAh capacity so you can use that to guesstimate what an external pack will net you but realistically you're going to get physically tired before you use more than 2000mAh of controller time. You could theoretically use the USB expansion port on the HMD also - and I've seen that done - but I'd recommend against that as it can put alot of ware and hear on the HMD since the cable will by nature get yanked around and putting strain on that port.

@Cappy1 I unfortunately think you're confused about the current status of WebXR/WebVR. The Vive has full WebVR/WebXR support via Chrome, and Firefox - and has enjoyed WebVR support for almost 2+ years since the very first beta releases. We've collaborated with both organizations since before the release of the first Vive to help pioneer VR web browsing. You can go and try WebVR today with Chrome or Firefox on any desktop Vive - I recommend trying Sketchfab.com as it has over 1 million scenes to explore. Firefox Reality is a VR native web browser which is wholly developed by the Mozilla Foundation (although we partner with them). It currently is only available on mobile devices - they haven't released it for any desktop headset regardless of the manufacturer. We were proud to partner to be the first HMD/platform that the mobile version of Firefox Reality was released on and we're proud to have Firefox Mobile ship as our default browser on all of our mobile devices globally. In other words, we're a very proud partner of Mozilla Reality. Only Mozilla can make decisions about how their product is released - in this case the SteamVR/Desktop release of Firefox Reality. Creating a web browser that is fully security compliant and enjoys steady updates is a very laborious process - the VR component adds to that complexity. In this case, we'll be deferring to both Google and Mozilla and their expertise in Web browsers as they'll be able to produce a very high quality deliverable. The Oculus web-browser is a fork of Chromium. In other words - Oculus entirely relies on Google's expertise in creating web-browsers. Their browser experience suffers from from some UX limitations (see below). Using the Oculus browser by definition opts you into Facebook's data collection practices 😉 There are very very real limitations when it comes to browsing the web in VR right now - especially around input - text input is pretty frustrating. There is lots of advancements in input and UX that will need to be ushered in to make it a compelling experience and websites simply aren't designed to be experienced in VR or AR currently. There is currently very little WebVR/WebXR content due to the very real limitations of OpenGL rendering, especially on mobile chipsets. It doesn't make financial sense for most developers to develop for WebXR quite yet. You can always use Virtual Desktop to get a pretty decent 2D browsing experience that has the full capabilities and featureset of a modern desktop browser. @Cappy1 - Please keep it civil - if you're going to going to come here to make a point, at least back it up with facts so you further the dialog for everyone . I'm one of the biggest VR nerds you'll never meet but I'm going to wait until Mozilla and Google irons out some of the UX and does a proper desktop release before I expose myself to unoptimized UX, especially when I have a killer experience already browsing the web on multiple monitors at 144hz & 4K or on a multi-meter sized projector screen with a mouse and keyboard. The wait will be worthwhile 😛

@RVal - I strongly suspect that this is related to your GPU. Since you've tested on another PC, it's a pretty good sign that the issue is localized to your PC. The SteamVR log is showing a ton of errors referencing an "invalid FrameIndex" but there's no indication before or after the message gets spammed out that it's getting tripped up at a specific step. This is an advanced problem - I'm not sure I personally have the skills to fully debug this remotely without physically accessing the PC but here are a few ideas that come to mind: This could be related to interpolation - try disabling motion smoothing and all reprojection via SteamVR's setting pages and see if it alters the behavior. Is your GPU overclocked? Are the operating temperatures within an acceptable range? Do you have a strong enough power supply to power your GPU at full load? You possibly could have a bad GPU - do high demanding 2D games render properly after heavy load for extended periods? Based on your overall description - I think a bad GPU is a very strong suspect here. You could have your GPU mounted in your motherboard on a weird slot or your BIOS settings could be limiting it's performance. You could try clean installing windows to start from scratch to try and eliminate any issues specific to your current OS setup. I personally recommend reinstalling windows every few months for best performance. I'd also recommend X-posting in the SteamVR forums as the folk over there may have some additional input.

@nancy.albornoz@critertec.c - The input system differs from the original Vive wands as there are additional buttons and a joystick rather than a trackpad. The best way to ensure you support Cosmos and other modern HMD's is to update to the current beta branch of the SteamVR plugin - it will easily allow you to generate native mapping for the Cosmos controllers via UI: https://github.com/ValveSoftware/steamvr_unity_plugin/tree/beta. Currently this native support is only hosted in the beta branch. If you're unable to update your SteamVR plugin but are on a 2.x plugin version, you can also generate a manual binding file and include it alongside your binary - let me know if that applies to you and I can provide some guidance on how to do this.