Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by VibrantNebula

  1. 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
  2. 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.
  3. @Beta_Tester Ditto on this - I haven't seen a report of a noisy fan on Cosmos; we specifically sourced a specialized fan that's extremely quite. I didn't even realize Cosmos had a fan until a pretty late stage because I never heard it in the early test units. If you're hearing the fan - I'd recommend contacting support. Sending you a PM of who to message.
  4. VibrantNebula


    @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.
  5. 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.
  6. @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 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.
  7. @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.
  8. @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!
  9. @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.
  10. @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.
  11. @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).
  12. @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:
  13. @Fporter - We generally don't release CAD files for our desktop HMD's due to the prevalence of clones devices from Asian markets. As far as I'm aware, we do not have plans to allow developers to have access to the IO connector that drives the faceplates - it's a proprietary connector. If this is for personal usage, it will unfortunatly likely fall fall below the requirements for it to be feasible for us to devote engineering resources to partner with you That said, the Cosmos has an onboard USB-C port that you can use for general IO and modification. I'd recommend PM'ing me if you'd like to share more details about what you're trying to accomplish in both scenarios so I can give you a more specific answer or try to connect you with other resources within HTC. Depending on your specific scenario - we can NDA if required.
  14. @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.
  15. @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!
  16. @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 🙂
  17. @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.
  18. @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.
  19. @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 😛
  20. @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.
  21. @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.
  22. @EvanU5 - The base-station issue that's most feasible to self-repair is re-gluing a detached lens from the laser aperture - you can usually hear that lens floating about the device. Most other types of repairs require specialized equipment and usually requires the station to undergo a precision re-calibration process. @TomCgcmfc - That "fix" isn't really a fix. It simply reverts the firmware of the station back to an earlier version that lacks self-diagnostics and internal error reporting features. The issue will still be be present - it just doesn't get reported. In some failure states, this "fix" will an allow a rotor to emit bad sweep data rather than cutting power to the affected rotor/diode which can more negatively impact tracking than if only one of the rotors was outputting sweeps. The Valve employee who initially shared that procedure has publicly posted about regretting that they shared that procedure due to how much confusion it's caused on the care side. Most people who are using this "fix" still actually have an issue with their station but it certainly can help in some cases where firmware becomes corrupted or an update fails.
  23. @TomCgcmfc You're partially correct here - I am typoing w to v. The requirement is 21w for Cosmos, 17w for Pro/Vive. Thank you for pointing out my error. That said, you're also partially incorrect - 5v is the standard potential for the USB standard - QC3.0 is a proprietary USB fork. QC charge devices dynamically vary the supply voltage based on a real-time negotiation that occurs between the host and the device. You can't use other rapid charge technologies with the Vive Wireless Adapter because it's specifically based of Qualcomm's technology and the device and the host need to be able to handshake, authenticate, and intelligently negotiate the supply voltage.
  24. @SimonBritto - Reflections are the top cause for grey screens which usually indicate a tracking issue so you'll first you'll want to rule them out. To do so, generate a system report via SteamVR -> Generate System Report. Save it as a .txt, then open the document in notepad (or SteamVR's system report viewer) and search for the following term "back-facing". Here's what a reflection problem looks like in a system report: 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 You'll also be able to scan through and look for other tracking error messages - if something's wrong, you'll usually see the message repeated a bunch indicating it's a problem. If that doesn't shed light on anything, you'll want to look at where your antenna is pointed. It should be at least 3 feet off of the ground and pointed toward your playspace. It has a 150x150 degree FOV and a range of ~6m. You'll also want to check to see if the basestations are going into standby. Sometimes the stations will go into power management mode and shut off leading to a grey screen. If you plug in the linkbox's power and connect it via USB to the PC (without the HMDI/DP) you'll enable SteamVR to communicate with your basestations via bluetooth in wireless mode for station management. You can try going into the task manager and seeing if your CPU/GPU constrained when the grey screens occur - you'll be able to tell by the utilization being over 96%. @TomCgcmfc - is right about overclocking and voltage control, it is known to increase instability with VR hardware, specifically the wireless PCI-E card.
  25. @EvanU5 - Basestations are high-precision mechanical devices that spin around at high-speeds. Each rotor in a basestation rotates at ~3600 rpm (~216,000 rotations per hour) so depending on your usage and a handful of other factors, they can eventually encounter wear and tear and other mechanical issues which can only be fixed by physically servicing them. It's simply a trade-off of being a mechanically based tracking system (with the benefit being higher fidelity tracking than other consumer systems). The newer 2.0 basestations are mechanical devices and thus share very similar constraints - issues just report under a different error code (usually a flashing red light) and there is one rotor rather than two. This is actually why we went with optical tracking as the default tracking mechanism for Vive Cosmos. Although optical tracking currently not as precise as basestation tracking, it doesn't rely on expensive mechanical devices such as base stations and offers an overall lower barrier of entry and maintenance than current externally tracked solutions Warranties very by country so I can't speak to your specific case. I'll PM you an address you can email for a second opinion.
  • Create New...