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
Controller tracking is not as responsive as the default empty SteamVR environment #1794
Comments
Pausing the debugger, I am seeing the following values in that time calculation:
These values all seem plausible. However, even if I set fVsyncToPhotons to zero, with the above code, the tracking results are awful and lurching around. In fact, even if I use 0 for the fPredictedSecondsToPhotonsFromNow argument, the orientation still lurches around drunkenly, even though the docs say the result should be the orientation at the exact time of the call. Clearly something is wrong here.
|
You should uses the poses returned by WaitGetPoses for rendering controllers as well (instead of calling GetDeviceToAbsoluteTrackingPose yourself). |
I don't understand this statement. Can you explain? We are not supposed to call GetDeviceToAbsoluteTrackingPose? What? |
The tracking on my headset and controllers in my application is pretty good but not perfect. When I enable the SteamVR dashboard, the controller model that is visible in that interface does look perfectly smooth, and I would like my application to behave the same.
I'm following the examples and calling WaitGetPoses() before sending data and drawing:
My CPU and GPU timing look great.
I found the GetDeviceToAbsoluteTrackingPose command, and used the timing code from the documentation, but the results look like the headset is overshooting the target orientation, and I am not sure if I am using this correctly:
Am I doing something wrong?
The text was updated successfully, but these errors were encountered: