How to prevent delay/lag between ARVR Camera and ARVR Origin?

The Noob is HereThe Noob is Here Posts: 4Member
edited September 2021 in 3D

Hello! I've encountered strange lag with the VR Camera. I'm working on a VR Tank Game where you're inside of the turret as a crewmember. When I rotate the turret using Turret.rotate_y(value), the ARVRCamera lags behind a little. The VR player is a child of the turret. The effect is quite noticeable and leads to slight motion sickness. Is there any way to remove or at least minimize this effect?

Video showing the effect: https://drive.google.com/file/d/1KjrNci7Ta2v_iUTIjR8xyy48fHB1Iij7/view?usp=sharing

Edited to be clearer to what the issue is.


Tags :

Best Answer

  • The Noob is HereThe Noob is Here Posts: 4
    Accepted Answer

    It took me a while but after searching through the source code, after looking through several other issues related to mine and reading up on everything, I finally found the cause and a fix.
    First, why does this happen?
    This issue is caused by the decision made by Godot's team to get tracking information immediately prior to rendering, in the visual_server_viewport source file in the Godot engine code, in the function draw_viewports, it checks if ARVR is enabled then calls it's process function.

    This means that the information we get in script and for physics processing is actually from the last frame, causing the frame delay that I saw. This is actually a good decision, because it means that for most VR games, where you're not moving the origin node like I am, it keeps the tracking information up to date for rendering, where it is most important, to minimize any lag one might feel in VR.

    The Fix.
    Someone had opened a ticket on the OpenVR Godot Github issue tracker who had a similar issue with the VR stuff being a frame behind, they proposed this work around:

    self.notification(NOTIFICATION_INTERNAL_PROCESS)
    for c in [ $OVRController, $OVRController2, $OVRController3, $OVRController4 ]:
        if (c.get_controller_name() != "Not connected"):
            c.notification(NOTIFICATION_INTERNAL_PROCESS)
    

    Throwing this in the _process function in the ARVR Origin node forces the VR stuff to update, removing the problematic delay.

Answers

  • cyberealitycybereality Posts: 5,318Moderator

    AFAIK, there is no delay with child/parent transforms. At least I've never seen that. If there is, it is probably some artifact of how the VR player is implemented.

  • Through further testing, I confirmed that normal parent-child transforms are unaffected, which makes the issue specific to having the ARVROrigin parented to a node, perhaps the ARVRCamera isn't being synced to the origin right away? Unsure, requires further testing.

  • AzedaxenAzedaxen Posts: 59Member

    I've noticed this too when trying to use a KinematicBody with an ARVROrigin as a child, the origin seems to lag behind the body, which of course is not something that should ever happen with parented spatial nodes. I have no idea what the issue is. Out of curiosity, what VR headset are you using? Are you using the OpenVR or the OpenXR plugin?

  • I'm using the OpenVR plugin and I use the Valve Index.

  • TwistedTwiglegTwistedTwigleg Posts: 5,344Admin

    It might be worth opening as an issue on the OpenVR Godot GitHub repository, if there is not one already, as it sounds like it could be a bug.

  • The Noob is HereThe Noob is Here Posts: 4Member
    Accepted Answer

    It took me a while but after searching through the source code, after looking through several other issues related to mine and reading up on everything, I finally found the cause and a fix.
    First, why does this happen?
    This issue is caused by the decision made by Godot's team to get tracking information immediately prior to rendering, in the visual_server_viewport source file in the Godot engine code, in the function draw_viewports, it checks if ARVR is enabled then calls it's process function.

    This means that the information we get in script and for physics processing is actually from the last frame, causing the frame delay that I saw. This is actually a good decision, because it means that for most VR games, where you're not moving the origin node like I am, it keeps the tracking information up to date for rendering, where it is most important, to minimize any lag one might feel in VR.

    The Fix.
    Someone had opened a ticket on the OpenVR Godot Github issue tracker who had a similar issue with the VR stuff being a frame behind, they proposed this work around:

    self.notification(NOTIFICATION_INTERNAL_PROCESS)
    for c in [ $OVRController, $OVRController2, $OVRController3, $OVRController4 ]:
        if (c.get_controller_name() != "Not connected"):
            c.notification(NOTIFICATION_INTERNAL_PROCESS)
    

    Throwing this in the _process function in the ARVR Origin node forces the VR stuff to update, removing the problematic delay.

  • cyberealitycybereality Posts: 5,318Moderator

    I see. Thanks for following up with the solution.

Leave a Comment

BoldItalicStrikethroughOrdered listUnordered list
Emoji
Image
Align leftAlign centerAlign rightToggle HTML viewToggle full pageToggle lights
Drop image/file