Jump to content
 

VibrantNebula

Administrators
  • Content Count

    2,581
  • Joined

  • Last visited

  • Days Won

    25

Everything posted by VibrantNebula

  1. VibrantNebula

    Rev 1?

    There currently exists only one primary production model/SKU of Cosmos that's been released as of this point. Any variation you may currently see are small things like the box color or are limited region specific things. "Rev1" isn't coming from us.
  2. @tonton, Cosmo's / Len's "Origin" home-space doesn't support custom models at this time. You could technically accomplish this in SteamVR's home but in order to do so, you'd have to publish it to Steamworkshop and then access it through there which could take some effort depending on what you're trying to bring in. Traduction automatisée: L'espace domestique "Origin" de Cosmo / Len ne prend pas en charge les modèles personnalisés pour le moment. Techniquement, vous pouvez accomplir cela dans la maison de SteamVR, mais pour ce faire, vous devez le publier sur Steamworkshop, puis y accéder par là, ce qui pourrait prendre un certain effort en fonction de ce que vous essayez d'apporter.
  3. @muella91, So ultimately there is some variation on the answer here - depending on how you're developing your project, there could be some variations on the answers: If you're developing in Unity, the SteamVR plugin automatically adjusts for the position so the developer doesn't have to retrieve the data. If you need to retrieve the data manually, you can do so via a camera object or via API. The Z-Axis direction depends on your pipeline. If using Unity, +Z is forward facing (away from the user) and is left handed coordinate system. In OpenVR's, the forward facing direction is (away from the user) is -Z because it's based on a right handed system. The X axis origin is direct between the center of the two lenses. The Y axis origin also passes through the center points of the two lenses. The Z axis is offset from a plane along the center axis' of the lenses. The offset is towards the the user and has a specific value for each HMD: The offset is 16mm towards the user for Vive The offset is 14mm towards the user for Vive Pro So overall, the image you posted turns out to actually be somewhat in the right location if you're querying via OpenVR.
  4. In most cases, it's best to restart the application after adjusting the render target multiplier. A handful of apps let you get away without restarting, but generally speaking - it's going to be far more stable to restart the target app and in some cases, it's mandatory to see a change. SteamVR's old UI used to have text recommending this but it's cleaner now.
  5. Here's where to find the room direction manual setting btw:
  6. @Nemmy1234 - We're testing a UI solution for this setting in the beta release of 1.0.10.2 beta of the Vive Cosmos software.
  7. @Diamond Vu - This is unfortunately a bit tricky as that specific UI/system is entirely a Valve managed system, it's not one of our products. I'd recommend also creating a support post or ticket with Valve as that's technically their layer of the tech stack. In the newer versions of SteamVR, the UI you're screen-shooting has been depreciated as a legacy binding UI - they have a new in HMD controller binding UI that's likely more stable. Is the issue reproducible with the newer in-HMD UI? That older UI had it's share of bugs.
  8. @TomCgcmfc, OP specifically asked for an mDP -> mDP cable so I linked one that's tested and known to work with Cosmos/Pro/Pro Eye.. I don't have firsthand experience with the dongles you've linked, I'll try to pick them up and validate them firsthand. The 3 foot version of this mDP - mDP from Cable Matters reliably works with current gen HMDs.
  9. @joellipenta Do you have any video captures of the issue? One thing I'd maybe recommend when this happens is to access the SteamVR dashboard which should allow you to see the SteamVR' compositors ordinate grid - you'll be able to see the center of the room and the floor plane and will be able to tell if SteamVR's coordinate system is getting shifted.
  10. @davide445 - We're technically agnostic on this one. One thing to keep in mind is that Steam userbase is ~ 80% Nvidia and that as a result, Nvida users generally enjoy greater VR support and more titles have Nvidia specific VR optimizations and integrated technologies like VRS. That said, AMD also has some desirable proprietary VR technologies like ReLive so it's all shades of grey.
  11. @Ninja Flame - The 3 foot version of this cable works reliably with current HMDs and is under $10. When looking for a cable, you want it to be on the short side (1-2 meters), and be rated for 4K@60fps. You want high-bandwidth cables, and ones rated for 20gbps+ are best.
  12. Warranty issues notwithstanding, removing the lenses in a VR HMD is an all around bad idea unless you happen to be doing so in a legit clean room. Dust management is super dooper hard and you'll introduce dust by opening up the optics chain unless you're operating under clean-room protocols.
  13. @Ara-Arex That one station in particularly is likely experiencing mechanical issues. If you can actually hear it making noises, it likely needs physical repair. You can confirm by powering off your second base-station and then putting the station in question into mode A via the button on the back (being careful not the disturb the station too much while it's spinning). Channel A will force it into single channel mode and you can test the tracking stability off that single station. That said, if you hear it, it's most likely a bad motor or a detected lens on one of the laser apertures. You'd likely have to create a support ticket and RMA the device via www.vive.com/support -> contact us -> contact us. If the device is within the warranty period for your country and specific device, the repair may be covered under warranty.
  14. @VARtex_0 @dagillespie Valve has not released any updates that would allow you to use more than 4 primary basestations per SteamVR instance. Valve manages and owns SteamVR tracking and the SteamVR compositor overall so these kinds of updates and features would come from them rather than Vive. The official maximum supported tracked volume remains 10x10m per Valve. Currently, you can have 4 "primary stations". Technically, SteamVR can accept additional data from additional "secondary stations" and use it for the pose estimation but all of this is highly proprietary and Valve has created no front end GUI or API access to actually manage or control the behavior.
  15. It definitely can but it depends on your overall tracking environment. I recommend using ArUco markers. They need to be kind of large to be helpful (I use the 4x4 or the 6x6 at 200mm). I maintain a VR bay where I have about 2 dozen of these markers for generic optical headsets and it definitely helps across the board with anything that's optically tracked. Not super practical for home use though.
  16. @Minh_26700 That's definitely not a standard use case, I'm not sure if anybody else has tried this specifically with Eye Pro. Generally speaking, you can't easily use SteamVR tracked HMDs without basestations and it's going to be exponentially easier to use the HMD as designed with basestation tracking and the SteamVR compositor. You can get by with a single station if you're applications design lends itself to 180-degree tracking. The need for controllers will be completely defined by what you're designing - you can definitely develop an app that doesn't use controllers but it definitely will impact what UX interactions are possible. Do you have the SR_Runtime running? What is the status of the SR_runtime (look at your tray and note the color of the eyes of the robot icon. Green = system is good, red = system is not running). Tagging additional team members for feedback. @Corvus @Daniel_Y
  17. @TomCgcmfc That's a good question, I can reach out to our product team and ask. The lens/origin setup is installed alongside the Vive console which serves as the runtime for Cosmo's tracking and IO - I'm not sure if it will ever see a more widespread release but I can ask. As far as I know, we don't intend to make current Pro HMDs tied to the Vive console.
  18. @Coryh4225 If it's a dead pixel, that's not user fixable. If it's a dust or some other flaw in the optical chain, you'll introduce even more dust if you try to open the HMD and it vastly complicates any refund or warranty situation. Dust is everywhere and it's way easy to make the situation worse. The best option is to swap via your seller if you're still in that return window. If you're out of that return window, you can file a warranty RMA and send it to back to us directly.
  19. @lamyipming - For transparencies sake, I'm comfortable sharing that the bulk of the Cosmo team's engineering resources are currently focused on tracking. Features and other UX tweaks will have higher priority once we improve a few key tracking scenarios hence why you're not seeing Vive Reality System related tweaks in the recent beta releases.
  20. @folmer The Oculus SDK has some known incompatibility issues with the WaveSDK - are you trying to build the WaveSDK and the Quest SDK into the same APK? Tagging members of the WaveSDK team into this thread for cross-team visibility.
  21. Hello @ph, There are two SDK's you could potentially use with Vive Pro Eye. Let me use this opportunity to more clearly summarize the SDK options for the community: SRanipal: This is Vive's Eye Tracking SDK and enables things like foveated rendering, gaze interactions, ect... This is a feature based SDK which licenses and incorporates Tobii's underlying technologies to provide a deployable API framework for interacting with the eye tracking features of the Eye Pro HMD. It is free for developers to integrate with your project and for the end-user to access via the SRAnipal runtime as the licensing is included as part of Vive Pro Eye hardware platform. The developer agreement is found on the SDK's download page. You're required to agree to it to access the SDK download. Here is a direct link to the current version of the developer agreement as of this post's date. Please read the agreement in full as it has important usage stipulations. From the agreement (v1.1.0.1) " This SDK contains software which collects facial images and processes those images into user facial feature data for VIVE Pro Eye or other HTC VR products. Facial feature data includes eye tracking data (such as gaze position, pupil size and eye openness), but not actual images or representations of the face, eyes or lips. Facial feature data but not actual facial images or representations are available to the SDK developer. You can also use the Vive Pro Eye with Tobii's first party XR SDK. This SDK provides a higher level of data access but the trade-off is that each studio needs to individually license the SDK from Tobii at a cost. Bare in mind, that with this higher level of data access, comes a higher degree of legal responsibility for you as a developer/publisher to safeguard user data, especially when it comes to GDPR compliance as eye tracking data is fundamentally user-identifiable biometric data. Per the documentation portion of your question, once you download the SRAnipal SDK, there is advanced documentation that is hosted as an interactive HTML document within the package. Here is an example screenshot of where to find the Unity documentation: Within that HTML resource, there is info about each class, ect...
  22. @Chain - The blog @JCSegula posted is the recommended Unity resource on this topic. The user needs to previously have cameras enabled in SteamVR settings for this to work, if they have the cameras disabled, you're out of luck.
  23. @Beta_Tester I've alerted that specific product team of your report and am awaiting feedback from them. Please bear in mind this is a beta-feature and so support is very case by case as early feedback comes in and we learn about potential issues people are encountering. They have the URL to this thread so they'll be able to see whatever you post here - they may not have direct access to the ticketing system that report issue feature feeds data into. That said, that report issue feature definitely still has a place as it collects and uploads logs. I'll report back here as soon as I hear any feedback from them.
  24. @Lionel - It's USB 3, you'd probably have to draw several hundred Mb/s to start impacting performance. That said, USB is critical for tracking data so it definitely is theoretically possible to draw enough bandwidth with that port that you start to max out the BUS, both on the HMD and the MB but I've yet to hear of a scenario where that's occurred and you'd see UI warnings. When using wireless, it will just increase your current draw which could theoretically lower your overall play time. We typically don't recommend you draw more than 900mA @ 5V from the onboard USB.
×
×
  • Create New...