Jump to content
 

VibrantNebula

Administrators
  • Content Count

    2,476
  • Joined

  • Last visited

  • Days Won

    17

VibrantNebula last won the day on December 10

VibrantNebula had the most liked content!

Community Reputation

55 Excellent

4 Followers

About VibrantNebula

  • Rank
    Respected Contributor

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @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
  2. @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.
  3. @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.
  4. @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.
  5. @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.
  6. @@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. 🙂
  7. 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.
  8. @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)
  9. 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
  10. 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.
  11. @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.
  12. VibrantNebula

    90hz

    @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.
  13. 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.
  14. @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.
  15. @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.
×
×
  • Create New...