Open FOKSlab opened 6 years ago
Have you tried moving the WaitGetPoses() call to the start of the render loop? From what I've read, you want the time between WaitGetPoses() and Submit() to be as short as possible, because it uses these two calls to measure the render time and "forecast" where all of the trackable devices will be for the next WaitGetPoses() call.
https://github.com/ValveSoftware/openvr/wiki/IVRCompositor_Overview
while Running: WaitGetPoses Render Left and Right cameras Submit Left and Right render targets Update game logic
I tried to move the WaitGetPoses as you advised me but the isuse is still there :( (using the openGL sample - which should be the reference to develop with the API - and increasing artificially the time of rendering for a frame shows it pretty well). I am still searching for the best way to deal with that. So if someone has got another idea and can help me I would be grateful And if I find the solution first I'll post it in this thread ;) Best Regards, Marc
Hi,
I have developped an OpenGL program with OpenVR. It is perfect using HTC Vive but when using it with Microsoft Mixed Reality HMD it generates "jerky images" sometimes, as if the compositor was doing wrong an optimization (reprojection ?). Displaying the textures submitted in companion window, I can check that tracking is working pretty well and rendering is OK, so I think I am doing something wrong in OpenGL or setting a state before calling submit I shouldn't have to. In the documentation glBindTexture is given as "OpenGL dirty state", what does this mean ? I tried with the OpenGL sample and everything works fine (even while adding a Sleep call to slow the application at 10 fps). I followed the rendering process and I cannot see what is done wrong since the generated texture before submitting are OK. Here is the rendering process used (the one given in the sample):
vr::VR_Init(&error,vr::VRApplication_Scene); vr::VRCompositor(); // I create 2 FBOs to render scene into textures submited next to OpenVR ... // In the Render loop // Render scene twice in textures // render into companion window // submit to HMD vr::VRCompositor()->Submit(vr::Eye_Left,&myLeftTexture); vr::VRCompositor()->Submit(vr::Eye_Right,&myRightTexture); // call the WaitGetPoses method asap vr::VRCompositor()->WaitGetPoses(m_myPoseArray, vr::k_unMaxTrackedDeviceCount, NULL, 0); // Swap the companion window and go the beginning of the loop
Is there any known bug with OpenGL in some cases (I saw and tried the glFinish hack but it did not solve my issue) ? Which states must I set before calling the Submit method ?
When profiling with SteamVR UI I get this result : blue items match the issue behaviour in the HMD.
And there is a detailled graph (not for the same time sequence but showing the issue too):
Added : test on Oculus Rift I have tried on Oculus Rift (deactivating Asynchronous SpaceWarp using Ctrl+numPad 1) and same effect can be seen but not as often as with Mixed Reality HMD. Oculus Rift produces the issue even with OpenGL sample : adding a Sleep(100) after swaping helps to understand what I am talking about.
So to summarize : Compositor issue is rised when using Oculus on OpenGL sample & custom OpenVR app, when using WMR on custom OpenVR app. Wow ... not easy to identify from where the issue is coming from ! I hope you would be able to help me. Best regards,
Marc