Problems with ARVROrigin movement [Godot 3.3]

[dedm0zaj]

Hello!

I have problems with ARVROrigin movement.
I've tried moving the ARVROrigin in _process() and _physics_process().

1. When I move the ARVROrigin in _process(), the controllers run away in the direction of movement.

controllers_move.mp4

2. When I move the ARVROrigin in _physics_process(), the controllers move correctly. But due to the desynchronization of the frame rate and the frequency of the physical process, the world is twitching.

Making the physics rate equal to the frame rate is a bad decision, as helmets now have very different frame rates.

Is there any solution possible?

Upd:
This issue is also relevant for Oculus plugin and mobile Oculus plugin

[Calinou]

Making the physics rate equal to the frame rate is a bad decision, as helmets now have very different frame rates.

As a workaround, you can expose a setting that changes the physics step between common values found in HMDs (72, 90, 120, 144). The setting should change Engine.iterations_per_second when configured.

[dedm0zaj]

@Calinou This is a bad decision. Physics in the game will work in different ways. I am looking for other solutions.
First, I will try to compensate for the movement of the controllers.

P.s. Unity had the same problem (controllers movement), but now everything is fine there. I don’t know how they did it.

[Calinou]

This is a bad decision. Physics in the game will work in different ways. I am looking for other solutions.
First, I will try to compensate for the movement of the controllers.

If you use delta consistently, physics will behave in a similar way (although not identical due to floating-point precision issues). I don't think it's really a problem unless you are working on a highly competitive game. Physics in Godot aren't deterministic in the first place anyway.

[dedm0zaj]

I solved the problem. I move the controller the same amount as the ARVROrigin. Only in the opposite direction.
It turns out that when drawing the controller, a pose is taken from the future frame. Or the previous frame is taken for rendering.
For comparison, the left controller is left unchanged.

controllers_move_2.mp4

extends ARVROrigin

var contr_right: ARVRController
var contr_left: ARVRController

const SPEED = 5.0

func _ready():
	
	contr_right = $ARVRControllerRight
	contr_left = $ARVRControllerLeft

func _process(delta):
	
	var stick_left_x = contr_left.get_joystick_axis(JOY_OPENVR_TOUCHPADX)
	var stick_left_y = contr_left.get_joystick_axis(JOY_OPENVR_TOUCHPADY)
	
	var move = Vector3(0, 0, 0)
	
	move.x = SPEED * stick_left_x * delta
	move.z = -SPEED * stick_left_y * delta
	move.y = 0.0
	
	global_translate(Vector3(move.x, move.y, move.z)) # translate ARVROrigin
	
	contr_right.global_translate(Vector3(-move.x, -move.y, -move.z))
	#contr_left.global_translate(Vector3(-move.x, -move.y, -move.z))

	pass

[BastiaanOlij]

I don't get this, I've moved the origin point from the day that I build the first iteration of this plugin to create player movement and I've never experienced this issue. Even the demo project in this repo has done this since the start.

The camera and controller nodes are all children of the origin node so everything moves in unison. There has to be more going on here then meets the eye.

Are you running in multithreaded mode? Multithreading in Godot 3 is broken as .....

[dedm0zaj]

@BastiaanOlij
The same problem was present in older versions of Unity 2019. Most likely this is a feature of VR.
Controllers run forward exactly one frame (if the movement is done in a function _process())

Are you running in multithreaded mode? Multithreading in Godot 3 is broken as .....

I don't quite understand about multithreading. In the settings like this:

and I've never experienced this issue

I looked at your examples. There, the movement is done in a function _physics_process() and there are no problems with running away the controllers. But this option does not suit me, since the desynchronization of the frame rate and the physics rate makes the world jitter.

P.S. For myself, I solved the problem. Issue can be closed.

[Calinou]

P.S. For myself, I solved the problem. Issue can be closed.

Out of curiosity, how did you solve the issue? Other people may be having the same problem, so make sure to document this 🙂

[dedm0zaj]

@Calinou #124 (comment)

[BastiaanOlij]

@dedm0zaj you're using single threading mode which should be safe.

I really don't get that fix, that should move the controller backwards in respect to the players position. So if I move forward I would see my hands go backwards.

Everything is relative to the origin point so if you move the origin point, the camera and the controllers move equally in space. The relative position between camera and controllers remain unchanged so they appear exactly where they are supposed to be.
All the tracking happens in relation to the origin point in local space, so again it should not be effected by translating the origin point, your entire VR playspace moves in unison.

It is true that when the _process function on ARVROrigin runs, we haven't run the _process function on the ARVRController nodes so it hasn't updated the tracking on the controller nodes. The only thing I can imagine going wrong here is that once the tracking updates the local position of the controller node is updated and it results in the global position of the controller being calculated based on the OLD global position of the origin point. If that is what is happening here that is a mayor bug in Godot itself.

For me this does not happen because I do all movement logic on a function node attached to the controller I use for movement so my movement code is executed after all tracking has been processed. (see https://github.com/GodotVR/godot-xr-tools/wiki/DirectMovement )

I do want to change the way tracking works in Godot 4 and provide a mechanism for more directly updating tracked nodes before the process loop starts.

[dedm0zaj]

@BastiaanOlij I looked at the code DirectMovement (https://github.com/GodotVR/godot-xr-tools/blob/master/addons/godot-xr-tools/functions/Function_Direct_movement.gd)

The move is done in a function _physics_process. When the move is done in a function _physics_process, the controllers do not run away. But this option does not suit me, since the frame rate (72fps, 90fps, 120fps, 144fps) and physics rate (60fps) are different. And when the player (ARVROrigin) moves, the world jerks.

If that is what is happening here that is a mayor bug in Godot itself

Yes, since the problem occurs for all VR plugins (OpenVR, Oculus, Mobile Oculus)

I found a solution anyway. Issue can be closed.

[BastiaanOlij]

Oh right, yeah I perform all the movement actions in physics indeed. I also sync up the physics update rate to a multiple of the headsets refresh rate. With OpenVR unfortunately its a bit of a gamble but some of the others you can determine what the headsets refresh rate is.

I am planning to do things differently in Godot 4 so if my suspicions are right this will be solved. It is still a little weird though.