Jump to content
 

Search the Community

Showing results for tags 'tracking'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • VIVE
    • Vive Community Forums
    • Vive Technical Support
    • Developer Forums

Blogs

  • Viveport Blog
  • Viveport Reviews
  • Viveport SDKs and Downloads
  • Developer Blog
  • Vive Blog

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


About Me

Found 15 results

  1. I got my Vive roughly two weeks ago, and have already come across an issue. Starting two/three days ago, upon connecting the power, the light turns green. Good. Then, upon starting up any program, the light goes red, and the display remains black. However, looking through SteamVR's VR view, the tracking is running flawlessly. leaving the headset perfectly still for a while prompts the screen back into life, but moving it shuts it down again. I have: Checked all cables are secure. Updated AND rolled back windows and drivers Attempted various methods of restarting the computer, SteamVR, and the Vive. Re-installed SteamVR AND Viveport and a lot more. I'm unable to check any cable-based issues due to being a jobless, social drop-out 15 year old who's broke after buying the Vive. @Synthesis @VibrantNebula
  2. Went to beta release last night 1.0.10.4 to check and see if the tracking is improved, can confirm it is not! The headset will not track my hands when playing boxing games, the boxing gloves drift in front of my vision obscuring what I can see. The tracking is also way too slow, when the HMD looses tracking of the controller often times when it reorients the gloves it's too slow and I miss my target. There is also too much drift in this HMD device, this is especially noticeable when playing games and standing still. Both the controllers and the HMD drift when standing still. Coming from the original Vive I know what is possible, this is a terrible state to be in, hire somebody if you can't figure this out.
  3. Hello everyone, new cosmos user here. Does anyone else here find that crouching down (especially with the headset facing the ground) completely messes up tracking? My tracking is completely unusable when I crouch, and still messed up for about 20 seconds after.I find myself completely unable to play stealth games such as Budget Cuts, or play other multiplayer games stealthily because of this. Is there a fix? Or is this just another Cosmos tracking error that I'm going to have to wait months for a patch.
  4. So due to the way the vive cosmos tracks the hand controllers, pretty much every Archery game experience is awful now. The sniper games are awful as well. When I go to use the bow or sniper rifle, it loses accurate tracking because i'm so close to my face. Using the other two HTC VR headsets, this was not an issue. Both were excellent experiences. However, to play archery and use a bow properly, i can't find a way for this to work. Any suggestions?
  5. Hi folks ! When I run Room setup and pull triggers, i need to scan my surroundings. My problem is that "Scanning" is stuck at 0% no matter where i look. It happened after last update (approx 2 hours ago) and I can't continue. Help me please
  6. I received the Cosmos on Friday, set it up and played a few hours with it and everything went perfectly. Yesterday, I went to use it but couldn't get the cosmos to track at all. Its almost as if the cameras wont turn on. Doing room setup just shows a black screen behind the instructions and if I follow instructions it gets to the scanning phase and then stays there at 0%. While Room Setup is running SteamVR says headset and controllers are tracking but when room setup isn't running they flash not tracking. On the VIVE Console, they are always not tracking. I've tried the "reset headset and settings"and the "clear the environment information" options in troubleshooting multiple times. Ive tried rebooting the PC, restarting Steam, restarting SteamVR and Vive Console, restarting the LInkbox, moving USB cables around. I'm probably just missing something simple but I don't know where to go from here. Any suggestions on how to fix this are welcome. @stvnxu
  7. Hello folks, I am running into a problem interfacing with the OpenVR SDK when using two trackers with one controller. Specifically, the IVRCompositor::WaitGetPoses( ) function will sometimes return incorrectly transformed matrices to my C++ application. I was wondering if anyone has experienced a problem like this before, or if there is a known solution. The scenario: I place two VIVE trackers about 1 foot apart from one another, facing the same direction. I would expected that the matrices of each tracker (stored in TrackedDevicePose_t -> mDeviceToAbsoluteTracking) will be very similar. If I power up in this order - Tracker 1 On, Tracker 2 On, Controller On - the matrices of both trackers are indeed almost identical. However, if I power on in a different order - Controller On, Tracker 1 On, Tracker 2 On - The matrices of one of the trackers will be rotated exactly 90 degrees from what I would expect. The other tracker still retains the correct values/orientation as before. So now, even though both physical trackers are sitting in similar positions and orientations in the real world, their matrices returned by the VIVE SDK's WaitGetPoses( ) are different. In the same session, I can power on/off the controllers in different orders to change whether I get the correct or incorrect matrix values from the tracker. I am certain this is not a problem with my tracked device indices, nor a problem with overflowing array bounds, because the XYZ Position of the "Bad" Tracker is always correct - it is only the rotation of the tracker about that position in space that changes. So at least one value in every row in the matrix is what I expect. The correct Tracker[index == 3] 4x4 matrix (left) vs. the incorrect Tracker[index == 3] matrix (right) [ -0.99, 0.00, -0.17, -0.20 ] [ 0.99, -0.05, -0.12, -0.20 ] [ 0.00, 1.00, 0.00, 0.72 ] [ -0.01, 0.00, -0.99, 0.72 ] [ 0.01, 0.00, -0.99, 1.38 ] [ 0.05, 0.99, 0.00, 1.38 ] [ 0.00, 0.00, 0.00, 0.00 ] [ 0.00, 0.00, 0.00, 0.00 ] To specify the configuration I am using, my OpenVR SDK is version 1.0.10, my VIVE trackers are the newer model with the blue triangle, and my base stations are the older model. If anyone knows of a fix, workaround, or simply something to try, I would be very grateful for the help! Right now I am thoroughly stumped! Thanks! @chengnay
  8. Hi, I try to install the plugin of ViveHandTracking but doesnt work. When started the Engine Unreal 4.20 or 4.22 appear this mesages that could not be compile and try rebuilding from source manually. I try to install in Unreal 4 and use Vive pro. What i can do ?
  9. I want to get the position of the headset in order to decide if someone nodded or shaked his/her head. Anyone has any idea how I get the position data/values of the headset? Do I need any specific gameObjects?
  10. Hopefully this isn't a duplicate So I purchased 3 Vive Trackers a few months ago or so and everything seemed to be fine until recently. I've noticed when I'm in the SteamVR home area (Where you can look at settings, desktop and steam) I keep seeing the tracker around my waist freaking out. For example: tracker starts to float away, tracker starts to show signs of vibration and shaking a lot when standing completely still, etc. It's only the one that I put around my waist. I've seen that covering the tracker completely makes it behave that way but it still happens regardless. Things I've done- - Tucked shirt in and made sure nothing is covering/around the tracker -Switched the trackers around to see if it was just that one tracker -Updated them to the current versions -Moved around the noggle things (forgot the name) And about the update, It seems as though whatever version they were on previously seemed to be better before updating them. Not sure if it's just the timing or if it really did something. I also live in a flat matte style room with no reflective surfaces, not even tiny areas. As well as playing at night so my window is covered (heard that was an issue for some people before). If anyone could provide any help or suggestions It'd be greatly appreciated. Thanks @VibrantNebula @jagibson
  11. My new issue, Loss of tracking , so floating image in the cosmos then grey image, and the headset is crashing and needs to restart any idea? @stvnxu
  12. There has been quite a bit of speculation on the types of cameras used on the Cosmos. Windows Mixed Reality and Oculus headsets reportedly use IR cameras, while the Cosmos uses RGB cameras. IR cameras are known for better low light performance. Many report poor exposure and dynamic range with the Cosmos RGB cameras while using them as a passthrough, which may explain why the headset has so much trouble with lighting conditions. If the root problem is the type of cameras used, then this can't be solved by software fixes, correct? Is there anything the team can say to assuage worries that core problems with Cosmos tracking can be resolved via software fixes, specifically addressing the types of cameras used on the Cosmos?
  13. SDK contains methods to check eyes blinking state: Is there some way to track each eye position separately? For now, the result is "combined": @Corvus
  14. Hello, I'm having trouble with tracking when I have more than 2 VIVE TRACKERS connected. Tracking becomes very poor, I experience a lot of jitters. It''s actually unusable. I think it has something to do with bluetooth connection quality and I seek any helpful tips how to improve it. Here is what I have already tried: 1. I have no reflective surfaces in the room. I've even had to replace my wardrobes as those had reflective doors :-). My windows are completely covered. 2. I have tried a couple of setups with base stations. I used 2x VIVE Base Stations 2.0, 4x VIVE Base Stations 2.0, 2x VALVE Index Base Stations 2.0 and finally 4x VALVE Index Base Stations 2.0. Multiple positions were tested. The results didn't vary much. After connecting 4 - 5 VIVE Trackers, I get very poor performance on some of them. And of course - it's random - most of the times one or two trackers has tracking issues, sometimes the controllers start to jitter. 3. I've noticed that when I connect 2 VIVE Trackers wireless with dongles and 3 VIVE Trackers with USB cables, tracking is good or perfect even. To connect the tracker with an USB cable, you need a little trick - first you have to plug in a dongle to an USB port, pair the tracker to that dongle and then remove the dongle and connect the tracker to the same port with USB cable. 4. I've tried turning off my WIFI router as it sends 2,4 GHz signal and can interfere with Bluetooth connections (at least in theory). 5. The trackers aren't placed near any metal objects that could interfere with their antennas. I use the TrackStraps and TrackBelt from the VIVE US store. Do you have any ideas or tips, what else I could test to have good quality, full wireless tracking with two controllers, and 5 VIVE Trackers?
  15. I've recently purchased a VIVE Pro with the wireless kit. I originally installed the WiGig card into a PCIe 1x slot. Upon encountering rather random (yet frequent) watchdog violations, I decided to try switching to a the second 'large' (16x?) PCIe slot. According to my mobo's manual, all 1x PCIes are only 2.0, while the two larger ones are both 3.0 (AB350 Pro4). However, the WiGig does not get recognized in this slot, even after cleaning, checking connections, etc. ('Please shut down your pc an d make sure the WiGig PCIe card is properly inserted'-error). No idea why, no change in bios settings seems to make the card recognizeable to the system. When I slot it into the 1x PCIe, it gets recognized without a problem. In both slots, the card is powered (blue LED glowing). My question is the following: is it even true that you need PCIe 3.0? I haven't actually heard any official statement to this effect. I.e.: should I try to somehow connect the WiGig to a PCIe 3.0-like slot (e.g. via an M.2 adapter) or is this likely not the issue at all? If it's the latter, I'd just try and solve the issue whilst using the PCIe 2.0 slot (where the HMD actually works most of the time). That said, so far all watchdog bsods happened during intensive first-time asset load events (i.e. they didn't occur during subsequent loadings of the same app, typically). This suggests that the watchdog violation has something to do with bandwidth bottlenecks. But that's just guesswork at this point :( Any suggestions? Any surefire ways to make my mobo recognize the WiGig in the 3.0 slot? Any reassurances that PCIe 2.0 is perfectly okay for the WiGig, bandwidth-wise? Specs: Motherboard: AB350 Pro4 CPU: Ryzen 5 1600, 16 gigs of RAM GPU: Radeon RX 580 Bios fully updated, new AMD chipset drivers, Ryzen gaming mode activated, SATA AHCI controller drivers updated, gfx drivers updated, UEFI reset to defaults.
×
×
  • Create New...