Make proper use of WaitGetPoses #141
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ame for controllers and head position
Collaborator
|
Very cool! Gonna have to give this a spin soon :) |
Contributor
|
@vilhalmer Is this still relevant? |
Collaborator
|
I have no idea, I'm hoping to go through the remaining PRs after I get my last set posted which should be very soon now that #169 is in. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The function
WaitGetPosesreturns two sets of tracking data. Tracking data for the current frame, and predictive tracking data for the next frame.We call, as we should,
WaitGetPosesas close to when we render as possible, however we do not update the positions of our node until we process the next frame.This PR ensures that our head position for rendering uses the most up to date tracking data as we currently do, but we now use the predictive tracking data for the next frame when positioning nodes.
Now Godot 3 still processes this data within
_processso we do not have the nodes in the correct position until after that nodes_processhas run, but this can be dealt with. This is something that has been improved in Godot 4.But with this fix it should ensure that controller positions no longer seem to be a frame behind and more importantly, that nodes childed to the ARVRCamera will appear in the correct position.