XR 中的房间尺度

One of the staples of XR projects is the ability to walk around freely in a large space. This space is often constrained by the room the player is physically in with tracking sensors placed within this space. With the advent of inside out tracking however ever larger play spaces are possible.

As a developer this introduces a number of interesting challenges. In this document we will look at a number of the challenges you may face and outline some solutions. We’ll discuss the issues and challenges for seated XR games in another document.

备注

Often developers sit behind their desk while building the foundation to their game. In this mode the issues with developing for room scale don’t show themselves until it is too late. The advice here is to start testing while standing up and walking around as early as possible. Once you are happy your foundation is solid, you can develop in comfort while remaining seated.

In traditional first person games a player is represented by a CharacterBody3D node. This node is moved by processing traditional controller, mouse or keyboard input. A camera is attached to this node at a location roughly where the player’s head will be.

Applying this model to the XR setup, we add an XROrigin3D node as a child of the character body, and add a XRCamera3D as a child of the origin node. At face value this seems to work. However, upon closer examination this model does not take into account that there are two forms of movement in XR. The movement through controller input, and the physical movement of the player in the real world.

As a result, the origin node does not represent the position of the player. It represents the center, or start of, the tracking space in which the player can physically move. As the player moves around their room this movement is represented through the tracking of the players headset. In game this translates to the camera node’s position being updated accordingly. For all intents and purposes, we are tracking a disembodied head. Unless body tracking is available, we have no knowledge of the position or orientation of the player’s body.

../../_images/XRRoomCenterWalk.gif

The first problem this causes is fairly obvious. When the player moves with controller input, we can use the same approach in normal games and move the player in a forward direction. However the player isn’t where we think they are and as we move forward we’re checking collisions in the wrong location.

../../_images/XRRoomWalkOffCliff.gif

The second problem really shows itself when the player walks further away from the center of the tracking space and uses controller input to turn. If we rotate our character body, the player will be moved around the room in a circular fashion.

../../_images/XRRoomRotateOrigin.gif

If we fix the above issues, we will find a third issue. When the path for the player is blocked in the virtual world, the player can still physically move forward.

../../_images/XRRoomWalkWall.gif

We will look at solving the first two problem with two separate solutions, and then discuss dealing with the third.

以原点为中心的解决方案

Looking at the first approach for solving this we are going to change our structure. This is the approach currently implemented in XR Tools.

../../_images/xr_room_scale_origin_body.webp

In this setup we mark the character body as top level so it does not move with the origin.

We also have a helper node that tells us where our neck joint is in relation to our camera. We use this to determine where our body center is.

角色移动的处理现在要分三步进行。

备注

The Origin centric movement demo contains a more elaborate example of the technique described below.

第一步

In the first step we’re going to process the physical movement of the player. We determine where the player is right now, and attempt to move our character body there.

  1. func _process_on_physical_movement(delta):
  2. # Remember our current velocity, we'll apply that later
  3. var current_velocity = $CharacterBody3D.velocity
  4. # Remember where our player body currently is
  5. var org_player_body: Vector3 = $CharacterBody3D.global_transform.origin
  6. # Determine where our player body should be
  7. var player_body_location: Vector3 = $XRCamera3D.transform * $XRCamera3D/Neck.transform.origin
  8. player_body_location.y = 0.0
  9. player_body_location = global_transform * player_body_location
  10. # Attempt to move our character
  11. $CharacterBody3D.velocity = (player_body_location - org_player_body) / delta
  12. $CharacterBody3D.move_and_slide()
  13. # Set back to our current value
  14. $CharacterBody3D.velocity = current_velocity
  15. # Check if we managed to move all the way, ignoring height change
  16. var movement_left = player_body_location - $CharacterBody3D.global_transform.origin
  17. movement_left.y = 0.0
  18. if (movement_left).length() > 0.01:
  19. # We'll talk more about what we'll do here later on
  20. return true
  21. else:
  22. return false
  23. func _physics_process(delta):
  24. var is_colliding = _process_on_physical_movement(delta)

Note that we’re returning true from our _process_on_physical_movement function when we couldn’t move our player all the way.

第二步

The second step is to handle rotation of the player as a result of user input.

As the input used can differ based on your needs we are simply calling the function _get_rotational_input. This function should obtain the necessary input and return the rotational speed in radians per second.

备注

For our example we are going to keep this simple and straight forward. We are not going to worry about comfort features such as snap turning and applying a vignette. We highly recommend implementing such comfort features.

  1. func _get_rotational_input() -> float:
  2. # Implement this function to return rotation in radians per second.
  3. return 0.0
  4. func _copy_player_rotation_to_character_body():
  5. # We only copy our forward direction to our character body, we ignore tilt
  6. var camera_forward: Vector3 = -$XRCamera3D.global_transform.basis.z
  7. var body_forward: Vector3 = Vector3(camera_forward.x, 0.0, camera_forward.z)
  8. $CharacterBody3D.global_transform.basis = Basis.looking_at(body_forward, Vector3.UP)
  9. func _process_rotation_on_input(delta):
  10. var t1 := Transform3D()
  11. var t2 := Transform3D()
  12. var rot := Transform3D()
  13. # We are going to rotate the origin around the player
  14. var player_position = $CharacterBody3D.global_transform.origin - global_transform.origin
  15. t1.origin = -player_position
  16. t2.origin = player_position
  17. rot = rot.rotated(Vector3(0.0, 1.0, 0.0), _get_rotational_input() * delta)
  18. global_transform = (global_transform * t2 * rot * t1).orthonormalized()
  19. # Now ensure our player body is facing the correct way as well
  20. _copy_player_rotation_to_character_body()
  21. func _physics_process(delta):
  22. var is_colliding = _process_on_physical_movement(delta)
  23. if !is_colliding:
  24. _process_rotation_on_input(delta)

备注

We’ve added the call for processing our rotation to our physics process but we are only executing this if we were able to move our player fully. This means that if the player moves somewhere they shouldn’t, we don’t process further movement.

第三步

The third and final step is moving the player forwards, backwards or sideways as a result of user input.

Just like with the rotation the inputs differ from project to project so we are simply calling the function _get_movement_input. This function should obtain the necessary input and return a directional vector scaled to the required velocity.

备注

Just like with rotation we’re keeping it simple. Here too it is advisable to look at adding comfort settings.

  1. var gravity = ProjectSettings.get_setting("physics/3d/default_gravity")
  2. func _get_movement_input() -> Vector2:
  3. # Implement this to return requested directional movement in meters per second.
  4. return Vector2()
  5. func _process_movement_on_input(delta):
  6. # Remember where our player body currently is
  7. var org_player_body: Vector3 = $CharacterBody3D.global_transform.origin
  8. # We start with applying gravity
  9. $CharacterBody3D.velocity.y -= gravity * delta
  10. # Now we add in our movement
  11. var input: Vector2 = _get_movement_input()
  12. var movement: Vector3 = ($CharacterBody3D.global_transform.basis * Vector3(input.x, 0, input.y))
  13. $CharacterBody3D.velocity.x = movement.x
  14. $CharacterBody3D.velocity.z = movement.z
  15. # Attempt to move our player
  16. $CharacterBody3D.move_and_slide()
  17. # And now apply the actual movement to our origin
  18. global_transform.origin += $CharacterBody3D.global_transform.origin - org_player_body
  19. func _physics_process(delta):
  20. var is_colliding = _process_on_physical_movement(delta)
  21. if !is_colliding:
  22. _process_rotation_on_input(delta)
  23. _process_movement_on_input(delta)

以角色身体为中心的解决方案

In this setup we are going to keep our character body as our root node and as such is easier to combine with traditional game mechanics.

../../_images/xr_room_scale_character_body.webp

Here we have a standard character body with collision shape, and our XR origin node and camera as normal children. We also have our neck helper node.

Processing our character movement is done in the same three steps but implemented slightly differently.

备注

The Character centric movement demo contains a more elaborate example of the technique described below.

第一步

In this approach step 1 is where all the magic happens. Just like with our previous approach we will be applying our physical movement to the character body, but we will counter that movement on the origin node.

This will ensure that the players location stays in sync with the character body’s location.

  1. # Helper variables to keep our code readable
  2. @onready var origin_node = $XROrigin3D
  3. @onready var camera_node = $XROrigin3D/XRCamera3D
  4. @onready var neck_position_node = $XROrigin3D/XRCamera3D/Neck
  5. func _process_on_physical_movement(delta) -> bool:
  6. # Remember our current velocity, we'll apply that later
  7. var current_velocity = velocity
  8. # Start by rotating the player to face the same way our real player is
  9. var camera_basis: Basis = origin_node.transform.basis * camera_node.transform.basis
  10. var forward: Vector2 = Vector2(camera_basis.z.x, camera_basis.z.z)
  11. var angle: float = forward.angle_to(Vector2(0.0, 1.0))
  12. # Rotate our character body
  13. transform.basis = transform.basis.rotated(Vector3.UP, angle)
  14. # Reverse this rotation our origin node
  15. origin_node.transform = Transform3D().rotated(Vector3.UP, -angle) * origin_node.transform
  16. # Now apply movement, first move our player body to the right location
  17. var org_player_body: Vector3 = global_transform.origin
  18. var player_body_location: Vector3 = origin_node.transform * camera_node.transform * neck_position_node.transform.origin
  19. player_body_location.y = 0.0
  20. player_body_location = global_transform * player_body_location
  21. velocity = (player_body_location - org_player_body) / delta
  22. move_and_slide()
  23. # Now move our XROrigin back
  24. var delta_movement = global_transform.origin - org_player_body
  25. origin_node.global_transform.origin -= delta_movement
  26. # Return our value
  27. velocity = current_velocity
  28. if (player_body_location - global_transform.origin).length() > 0.01:
  29. # We'll talk more about what we'll do here later on
  30. return true
  31. else:
  32. return false
  33. func _physics_process(delta):
  34. var is_colliding = _process_on_physical_movement(delta)

In essence the code above will move the character body to where the player is, and then move the origin node back in equal amounts. The result is that the player stays centered above the character body.

We start with applying the rotation. The character body should be facing where the player was looking the previous frame. We calculate our camera orientation in the space of the character body. We can now calculate the angle by which the player has rotated their head. We rotate our character body by the same amount so our character body faces the same direction as the player. And then we reverse the rotation on the origin node so the camera ends up aligned with the player again.

For the movement we do much the same. The character body should be where the player was standing the previous frame. We calculate by how much the player has moved from this location. Then we attempt to move the character body to this location.

As the player may hit a collision body and be stopped, we only move the origin point back by the amount we actually moved the character body. The player may thus move away from this location but that will be reflected in the positioning of the player.

As with our previous solution we return true if this is the case.

第二步

In this step we again apply the rotation based on controller input. However in this case the code is nearly identical to how one would implement this in a normal first person game.

As the input used can differ based on your needs we are simply calling the function _get_rotational_input. This function should obtain the necessary input and return the rotational speed in radians per second.

  1. func _get_rotational_input() -> float:
  2. # Implement this function to return rotation in radians per second.
  3. return 0.0
  4. func _process_rotation_on_input(delta):
  5. rotation.y += _get_rotational_input() * delta
  6. func _physics_process(delta):
  7. var is_colliding = _process_on_physical_movement(delta)
  8. if !is_colliding:
  9. _process_rotation_on_input(delta)

第三步

For step three we again apply the movement based on controller input. However just like at step 2, we can now implement this as we would in a normal first person game.

Just like with the rotation the inputs differ from project to project so we are simply calling the function _get_movement_input. This function should obtain the necessary input and return a directional vector scaled to the required velocity.

  1. func _get_movement_input() -> Vector2:
  2. # Implement this to return requested directional movement in meters per second.
  3. return Vector2()
  4. func _process_movement_on_input(delta):
  5. var movement_input = _get_movement_input()
  6. var direction = global_transform.basis * Vector3(movement_input.x, 0, movement_input.y)
  7. if direction:
  8. velocity.x = direction.x
  9. velocity.z = direction.z
  10. else:
  11. velocity.x = move_toward(velocity.x, 0, delta)
  12. velocity.z = move_toward(velocity.z, 0, delta)
  13. move_and_slide()
  14. func _physics_process(delta):
  15. var is_colliding = _process_on_physical_movement(delta)
  16. if !is_colliding:
  17. _process_rotation_on_input(delta)
  18. _process_movement_on_input(delta)

玩家走到不应该抵达的位置时

Think of a situation where the player is outside a locked room. You don’t want the player to go into that room until the door is unlocked. You also don’t want the player to see what is in this room.

The logic for moving the player through controller input nicely prevents this. The player encounters a static body, and the code prevents the player from moving into the room.

However with XR, nothing is preventing the player from taking a real step forward.

With both the approaches worked out up above we will prevent the character body from moving where the player can’t go. As the player has physically moved to this location, the camera will now have moved into the room.

The logical solution would be to prevent the movement altogether and adjust the placement of the XR origin point so the player stays outside of the room.

The problem with this approach is that physical movement is now not replicated in the virtual space. This will cause nausea for the player.

What many XR games do instead, is to measure the distance between where the player physically is, and where the players virtual body has been left behind. As this distance increases, usually to a distance of a few centimeters, the screen slowly blacks out.

Our solutions up above would allow us to add this logic into the code at the end of step 1.

Further improvements to the code presented could be:

  • allowing controller input as long as this distance is still small,

  • still applying gravity to the player even when controller input is disabled.

备注

The movement demos in our demo repository contain an example of blacking out the screen when a user walks into restricted areas.

进一步的改进建议

The above provides two good options as starting points for implementing room scale XR games.

A few more things that are worth pointing out that you will likely want to implement:

  • The height of the camera can be used to detect whether the player is standing up, crouching, jumping or lying down. You can adjust the size and orientation of the collision shape accordingly. Extra bonus points for adding multiple collision shapes so the head and body have their own, more accurately sized, shapes.

  • When a scene first loads, the player may be far away from the center of the tracking space. This could result in the player spawning into a different room than our origin point. The game will now attempt, and fail, to move the player body from the starting point to where the player is standing. You should implement a reset function that moves the origin point so the player is in the correct starting position.

Both of the above improvements require the player to be ready and standing up straight. There is no guarantee as the player may still be putting their headset on.

Many games, including XR Tools, solve this by introducing an intro screen or loading screen where the player must press a button when they are ready. This starting environment is often a large location where the positioning of the player has little impact on what the player sees. When the player is ready, and presses the button, this is the moment you record the position and height of the camera.

Previous Next


© 版权所有 2014-present Juan Linietsky, Ariel Manzur and the Godot community (CC BY 3.0). Revision b1c660f7.

Built with Sphinx using a theme provided by Read the Docs.