Search the Community
Showing results for tags 'issue'.
Found 4 results
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
Anyone having the lag or graphics issues when in game and you click the vive symbol, opening the bubble menu (sorry that I don’t have the names for the menu options but certain everyone knows which menu I’m referring to). I noted in three different games now that opening the menu by accident or otherwise severely stalls out and/or temporary freezes the background game. A few times, it’s resolved itself with only minor screen pixelations or images/frames appearing + disappearing rapidly to the sides of the viewable area. Other times, the game stopped responding entirely and I ended up starting a different game and shutting down the frozen one. Just wondering if anyone is experiencing these issues? OR If it’s my new computer? >my computer specs< Intel Core i5-9400f 2. 9GHz 6-Core | Intel B360 Chipset | 8GB DDR4-3000| 1TB HDD | Windows 10 Home 64-bit AMD Radeon RX 580 4GB Video Card | 1x DVI | 1x HDMI | 2x DisplayPort 5 x USB 3. 1 | 2 x USB 2. 0 | 1x RJ-45 Network Ethernet 10/100/1000 | @stvnxu
One thing I haven't noticed other users bringing up as much - is how much light leaks into the HMD! I am lucky to see any at all on my original Vive - but on Cosmos light leaks from below where the rubber flap is meant to conform to users nose(?) I guess that's what it is meant for. Light leaks in through there from beneath...doesn't on Vive. From top it seems to leak right in onto the LENS?!? how did that get missed? it somehow comes in from behind if there is a light source above and behind you from something like ANY ceiling light you might be standing under or behind you. Has anyone mitigated this somehow?