FOV is really zoomed in on certain games?
Whenever I play some of my games, they are really zoomed in. And I don't mean that they’re huge or small areas; I mean that everything is zoomed in on the screen. It's basically if the edges of the screen were cut off and the rest of the screen was stretched to fit the rest of the area. It's really uncomfortable, and it's impossible for me to change it. HOWEVER, it only applies to games ran on OCULUS. If I were to run the same game on SteamVR, it's just fine because I can actually change the FOV and world scale in the Steam menu (not that I needed to in the first place). What do I do about this?
Every third frame is frozen (sometimes two out of every 3 frames)
My OpenGL application is an emulator that displays on a virtual cinema screen. The emulated game runs on a different thread and OpenGL context than the VR cinema. It works perfectly (looking around the virtual cinema with a blank screen) until I start the emulated game while wearing the Rift. But from then on, 1 (or sometimes 2 if I'm really unlucky) of the 3 frames in the VR swapchain are frozen to whatever they were displaying at that point and locked to my face. The remaining 2 (or 1) frame(s) render as normal and respond to head-tracking. Once it gets into this state, it never recovers, no matter what I do, until I close my application and restart it. But if I take off the Rift to start the emulated game, then put the Rift back on again after the game has started, everything works perfectly (looking around the virtual cinema with a screen displaying the emulated game). This only happens when I use the Oculus API. It works fine using the Rift with the SteamVR API. One of two bugs in the Oculus SDK must be happening: 1. Extra load on the CPU/HardDisk/GPU during emulated game startup while calling the Oculus SDK functions is causing the Oculus SDK to malfunction. 2. Some OpenGL initialization I'm doing on the other thread (with shared display lists) while calling the Oculus SDK functions is causing the Oculus SDK to malfunction.Oculus Rift S Controller bug on Unity?
When I use OVRInput.Get(OVRInput.Axis2D.SecondaryThumbStick) it usually returns the position of the SECONDARY Thumb stick but sporadically return the PRIMARY controller at other times. The same problem occurs with the Oculus Demo 'Distance Grab' should be easily reproduced. I'm using Oculus Integration 12.0 with Unity 2019.3.0f6 on the Oculus Rift S with the Touch Controllers,
Cannot add test users
Hello, I am experiencing blocking problems with the test process. I cannot seem to be able to create test users at all. I also tried adding my own account. I always receive the following message: "Sorry, we couldn't locate the user that you were looking for." Conversely, the page accepts IDs that are not emails (such as "aaa"). I can see those fake users in the list, but obviously I have no way of using them. Please help.
ovr_CreateTextureSwapChainGL() failed
So every tine I attempt to create the swap chains, I got the error code ovrError_InvalidParameter == -1005 with the following message returned by ovr_GetLastErrorInfo(): BindFlags not supported for OpenGL applications. I am using Oculus DK2 with the SDK 1.20 and latest NVidia drivers. This issue started many months ago, probably since 1.12 or so. The code is a direct copy-paste from the OculusRoomTiny (GL) sample, or from the Texture Swap Chain Initialization documentation: ovrTextureSwapChainDesc desc = {}; desc.Type = ovrTexture_2D; desc.ArraySize = 1; desc.Format = OVR_FORMAT_R8G8B8A8_UNORM_SRGB; desc.Width = w; desc.Height = h; desc.MipLevels = 1; desc.SampleCount = 1; desc.StaticImage = ovrFalse; desc.MiscFlags = ovrTextureMisc_None; // Tried a direct assignment, but still fail desc.BindFlags = ovrTextureBind_None; // Tried a direct assignment, but still fail ovrResult res = ovr_CreateTextureSwapChainGL(session, &desc, &swapTextures); // res is always ovrError_InvalidParameter The initialization sequence is following (I am skipping error checks for clarity): ovr_Detect(0); ovrInitParams params = { ovrInit_Debug | ovrInit_RequestVersion, OVR_MINOR_VERSION, OculusLogCallback, 0, 0 }; ovr_Initialize(¶ms); ovrGraphicsLuid luid; ovr_Create(&hmdSession, &luid); //------------------------------------ // in the function called at WM_CREATE message: <Create core GL context, make current> <init GLEW library> //------------------------------------ hmdDesc = ovr_GetHmdDesc(hmdSession); ovrSizei ResLeft = ovr_GetFovTextureSize(hmdSession, ovrEye_Left, hmdDesc.DefaultEyeFov[0], 1.0f); ovrSizei ResRight = ovr_GetFovTextureSize(hmdSession, ovrEye_Right, hmdDesc.DefaultEyeFov[1], 1.0f); int w = max(ResLeft.w, ResRight.w); // 1184 int h = max(ResLeft.h, ResRight.h); // 1472 for (int eyeIdx = 0; eyeIdx < ovrEye_Count; eyeIdx++) if (!eyeBuffers[eyeIdx].Create(hmdSession, w, h)) // this function's code is provided above { ovr_GetLastErrorInfo(&err); log_error(err.ErrorString); // "BindFlags not supported for OpenGL applications." } So according to the error message, SDK thinks that I am assigned something to desc.BindFlags, while I am not. I tried to directly assign ovrTextureBind_None value to it (which is just zero), but still no success. I traced all variable values in debugger, they are the same as is the OculusRoomTiny (GL) sample. The only difference in my code that I can see is that I am using GLEW library to handle OpenGL extensions, while sample uses OVR::GLE. It initializes it immediately after wglMakeCurrent(): OVR::GLEContext::SetCurrentContext(&GLEContext); GLEContext.Init(); Can this be the cause? But I don't want to switch to Oculus' extensions library. My project is not Oculus-exclusive, it supports Vive and non-VR modes as well. If it is a bug inside libovr, I request Oculus team to fix it!
Unity Camera Preview different than Rift view (bug?)
I'm making a multiplayer Unity game using Photon Unity Network to handle the multiplayer. I can re-create this issue by making a Room with one player (P1) (their camera loads into position and rotation correctly, even if they load in off kilter). Then a 2nd player joins the Room (P2), but they load in with their Rift pointing at an odd angle (physically pointing the HMD off center or even sideways) (not straight forward and level). Their "center" for their camera will be that off kilter view instead of a level view. I have no idea why this is. (I'm able to re-create this on my own computer starting up 2 versions of my game. And on 2 separate computers loading the game with 2 HMDs.) There is only one OVRManager in the scene (each player loads in their own, but the OVRManager is not networked). The other players only load in the graphics of their player Avatar with their camera disabled so there isn't any conflicts. What I find odd is that if I do this in the Unity editor and I click on the P2 active CenterEyeCamera the "Preview" for that camera is correct and level, but what's piped out to the Game Window and Rift is off kilter. Even the CenterEyeCamera rotation is level. It's like it got off sync somehow with the camera in game. Is there any way to access what the camera is outputing to the Rift and get that object's rotation? Or manually recenter (other than UnityEngine.VR.InputTracking.Recenter(); as this just puts the CenterEyeCamera back to where it should be, but doesn't fix the off kilter output). Would it be better to manually add the Camera onto the CenterEyeCamera rather than just disabling/enabling? Or is there some special magic that Unity and the Rift do to get it to output to the Rift display that's embedded into that camera's settings (i.e. what settings do I need to set for a camera object)? Apologies for the vague questions, but I'm not sure how else to debug this issue.
CV1 Bug relative tracking in fullmotion rigs
Not sure if this is the right places for Bugs, but anyhow: Since DK2 the tracking has changed and now i got this two Bugs: - If CV1 CAM is mounted on a motion rig and roll angles exeed 10°, the Cam looses tracking every few seconds (vertical/horizontal offset flickers). - CV1 can´t be setup with relative tracking (mounting sensor on moving part of rig), because roll, yaw and pitch vectors are tracked by the HMD only. - A workaround like disable/config the internal sensors is not possible in CV1 SDK All things as far as i know. Any hints, clues, solutions?