-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't use GetDeviceToAbsoluteTrackingPose() to replace WaitGetPoses() #64
Comments
you should be able to use vr::VRCompositor()->PostPresentHandoff(); for this, but it does not work either, if vr::VRCompositor()->WaitGetPoses(...) is not called |
Thanks for the reply! |
Did not find any way, but pushing data is running in a separate dedicated thread in my environment. So I just don't have to care about wasted wait-time. You may also try disabling v-Sync. |
Thank you very much TheWhiteAmbit :) |
I am developing an app using OpenVR sample named 'hellovr_opengl' as the base code. The API call WaitGetPoses() drops the FPS to 45 or so. I have few questions to solve this problem properly. Note: Vsync has been turned off. Any kind of help or suggestions will be greatly appreciated! :) |
I was not able to fully solve the problem and we eventually used oculus instead, but here is what we learned from our experience.
|
Thank you so much, mintslime! :) I will give it a try soon... |
|
Thank you for the reply @TheWhiteAmbit ! I tried to do what was suggested like having two threads( main thread and render thread). Main thread just calls WaitGetPoses and keeps looping and render thread gets the poses by calling GetLastPoses and calls OpenGL commands and then submits both the eye textures to the compositor and call PostPresentHandoff and then call the swapbuffer method. Since both the threads are using compositor object pointer they have to wait on the mutex, which makes the framerate to drop to the extremely low value. Am I missing anything here? How to solve this WaitGetPoses issue? |
Can a Valve developer comment on this? I also want to know what is the best way to deal with calling WaitGetPoses if manual calls are being made to GetDeviceToAbsoluteTrackingPose (for whatever reason). I don't want to post a duplicate issue, but our project calls for manually adjusting the prediction intervals, and we need total control over the latency. Aaron Leiby also directed developers on Steam to consult the following link for details about order of calls, but the page seems to be blocked. https://steamcommunity.com/groups/steamworks/discussions/20/357288572132086689/ |
It seems I've had some success with following an obligatory WGP call with a GDTATP call of my own, but it's hard to tell if I'm not doing it wrong. I'm still somewhat confused about what is the correct way to use PostPresentHandoff to achieve different results, as alluded to by @aleiby here: http://steamcommunity.com/app/358720/discussions/0/405691491122676152/#c405691491129025734 |
Since I need the renderings of another renderer-thread, I am forced to do the two thread approach. You are correct on the mutex eliminating possible advantages. However, timing on the image-rendering thread can be still varying from multiple images per frame to none. Since it is possible to have very exact control over provided calls in hmd-thread, I played a little bit with the OpenVR-API. If you don't submit new frames at all while calling WaitGetPoses() there seems to bee some perfect rotating timewarp function (maybe it is even async, but this does not really matter). Just one thing is odd with this, the rotation on quad-overlays is inversed, position correct. Also the edges are not clamped to black, so some strange effects happen at ~90° off center. I still have some odd timing behavior of OpenVR occuring.. |
I was trying to use GetDeviceToAbsoluteTrackingPose() instead of WaitGetPoses() to increase FPS and get rid of the stall, however, nothing is rendered on the hmd. It seems like the application is not even trying to render anything, I don't see any greyish flash or blinking graphic, only the default scene.
I used another render target and rendered the left eye camera to my screen window to confirm the head pose is correct.
Do we have to keep WaitGetPoses() in the application even when it is decreasing the FPS quite a bit?
The text was updated successfully, but these errors were encountered: