WaitGetPoses without any delay

[slavaman]

We are developing special software for Vive in extended mode and it needs WaitGetPoses without any additional delay to get data immediately.
It would be perfect to have such option in SteamVR settings config file.
Is it possible to get such feature or is there any documentation/information how to get data from WaitGetPoses immediately?

Thank you!

[TheWhiteAmbit]

Why wait, why don't you call the proper function to only get the current poses? Did you even search that documentation for 3 minutes before posting? It is out there...

[slavaman]

Thanks a lot, issue closed

[slavaman]

The question is reasonable and I posted the issue because of lack of information and noone could assist. Now I handled my needs in another way, not settings zero-wait time. Anyway, thanks for reply!

[TheWhiteAmbit]

The required GetLastPoses method is right below the WaitGetPoses in the header file, why do you need assistance for this - except you are to lazy to invest any of your own time?

[slavaman]

No, I understand GetLastPoses exists, but the question was about WaitGetPoses. Sorry for bothering you, issue closed.

[TheWhiteAmbit]

Ok if you want WaitGetPoses to do exactly what GetLastPoses does, but you still want to use WaitGetPoses and not GetLastPoses... I guess nobody can help you then.

[slavaman]

Thanks for help. Issue closed.

[spayne]

I like questions about poses. They are the new thing in vr and discussing them helps understand the openvr interface structure.

TrackedDevicePose_t appears in multiple interfaces. You can find them in the compositor interfaces and the system interfaces, and the event interfaces. the word pose itself is --- man --- almost every second line in the openvr.h header. Everyone sees WaitGetPoses first because that's the one that's in helloworld and because it's required for the compositor to function correctly. For more info, on the compositor interaction see the comments on PostPresentHandoff.

....I'm guessing presumably me and everyone else learns by experiment that it's a blocking call. Maybe if they called WaitGetPoses "BlockHereToSyncWithTheCompositorAndWaitForNextFramePoses" :) I'd have noticed it on first reading. Most of the openvr api calls are responsive, so this one always stands out as an exception.

Since you have WaitGetPoses in your render loop it's the best one to start with. And then add the other pose queries to the subsystems that require them as the need arises:

• When you want non-blocking poses using the latest information, add calls to IVRSystem::GetDeviceToAbsoluteTrackingPose. Note that here you are asking the IVRSystem for a pose.
• When you want prediction, then feed IVRSystem::GetDeviceToAbsoluteTrackingPose with a future value
• When you want poses synced up with button presses, then use IVRSystem::PollNextEventWithPose
• When you want poses synced with controller state then use IVRSystem::GetControllerStateWithPose
• When you want poses synced with the compositor AND non-blocking then use IVRCompositor::GetLastPoses. Here you are asking the IVRCompositor for a pose.

Regarding your idea about making blocking a configurable setting for WaitGetPoses doesn't sense because that blocking behaviour is its defining purpose. The other apis are intended to cover the other cases.

[slavaman]

Thank you much, it is great answer I really appreciate. Thanks again.

[echuber2]

What are you trying to do? Sounds similar to something we faced last year. We wanted to customize the prediction amount.

[TheWhiteAmbit]

The "Wait" as part of the name intends the blocking. But this call is not as well designed as in LibOVR (while they redesigned the same API call multiple times, but that's another topic). In LibOVR there is exact control from frameIndex rendered to presentation on the hmd including assumed position and rotation. The timewarp from the real physical data/prediction always kicks in simply from the last frame submitted in LibOVR with the positional data transfered on submit. The main difference is, no call to something like WaitGetPoses is needed then. So I am with you about finding the need to call this at all strange. I guess it was somehow intended to wait until the best moment, when your rendering should start - but It is not very good at this for me. Also some strange timing/prediction issues still appear on transition to a single timewarped frame, making this worse.
PS: Or is there any way to submit framebuffers, without calling WaitGetPoses?

[natevm]

@spayne Thanks!! This really cleared things up for me.

[spayne]

@n8vm. You are welcome. I wrote that awhile ago. 2017.

My 2019 update would include two background points about Waiting and Poses:

1. Waiting. This talk about poses and waiting is currently an important topic to OpenXR because other VR platforms do this differently and OpenXR will have to figure out what they are going to make consistent. Kaye Mason at Siggraph 2018 gave some examples. She said (emphasis mine):

We all block very differently in our frame loops

• for Daydream we block on the acquisition of a buffers to draw in
• for Oculus they block on submit
• and Valve blocks on the acquisition of input because they think that is an important time and they want to minimize latency.

It's an important performance detail part of that presentation. https://www.youtube.com/watch?v=FCAM-3aAzXg&t=4h12m16s Later in that presentation was a demo which showed how they might be making the frame loops consistent as well as some details on Epic's multithreaded render loop.

2. Poses. Maybe a small point, but lately I don't use the word Pose by itself like I used to because its more ambiguous now that hand poses have been added into the api (https://github.com/ValveSoftware/openvr/wiki/SteamVR-Skeletal-Input). I use TrackedDevicePoses or "Controller Localization" to refer to TrackedDevicePose_t and HandSkeletonPoses for hand skeletons .

[GilesBillyGoat]

Hi,
new to the party but with some questions, some of which I'll add here.

Ok I DID TRY this

void VIVE_Driver::OtherWayToGetPoses()
{
// for somebody asking for the default figure out the time from now to photons.
float fSecondsSinceLastVsync;
m_pHMD->GetTimeSinceLastVsync(&fSecondsSinceLastVsync, NULL);

float fDisplayFrequency = m_pHMD->GetFloatTrackedDeviceProperty(vr::k_unTrackedDeviceIndex_Hmd, vr::Prop_DisplayFrequency_Float);
float fFrameDuration = 1.f / fDisplayFrequency;
float fVsyncToPhotons = m_pHMD->GetFloatTrackedDeviceProperty(vr::k_unTrackedDeviceIndex_Hmd, vr::Prop_SecondsFromVsyncToPhotons_Float);

float fPredictedSecondsFromNow = fFrameDuration - fSecondsSinceLastVsync + fVsyncToPhotons;

m_pHMD->GetDeviceToAbsoluteTrackingPose(vr::ETrackingUniverseOrigin::TrackingUniverseSeated, fPredictedSecondsFromNow, m_rTrackedDevicePose, 1);

}

And replace the WaitGetPoses() with that.

Problem : "compositor complains it does not have the application focus", tried all I could think of and could NOT find a way/proper way to "give it the focus" , what mysterious function should be called then ?