Ability to lean over stuff.

[pietru2004]

As you might know player body can't lean over stuff like tables and railings. I make this issue to be a thing to keep in mind that not all movement is entering walls, and sometimes we might want to allow player to lean over stuff...

[pietru2004]

this could be worked around by adding arena node and checking for collisions in the direction of new movement and adjusting playerbody collision_node offset backward till limit, when body can fully move to player location then it would recenter collision node

[GeminiSquishGames]

Noticed this as HMD position moving rigid objects or pushing self away from static collision rather than looking over things, but same problem. It's free room-scale movement though. Your solution might sorta work (probably don't have to offset collision, simply stop HMD position from moving collision) but then if you are doing very slight steps in physical room-scale movement, it won't move until it reaches that area node threshold. So you have to tell the difference between looking over something (maybe HMD looking down) and stepping slightly. OR maybe the player would just get used to that movement? Hard to say without a working example. Could also simply have an animation for looking over something that temporarily offsets the camera, depending on how necessary looking over things are. I notice many games have this problem, but generally just ignore it. It's pretty annoying in Primitier.

[pietru2004]

ok so I think of something like this Were picture at bottom is like max distance allowed from the body

[GeminiSquishGames]

A spring joint may help. The camera would also require a collider so you couldn't use it to peek through walls and things too tall to look over.

On Sun, Oct 15, 2023 at 2:55 AM pietru2004 @.***> wrote:

[image: obraz] https://user-images.githubusercontent.com/51274570/275311377-e8191e43-2f00-4fb7-897e-69a24fe7009b.png ok so I think of something like this Were picture at bottom is like max distance allowed from the body

— Reply to this email directly, view it on GitHub https://github.com/GodotVR/godot-xr-tools/issues/481#issuecomment-1763310846, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHE6ADYDAPTQYEXS4XTV2DX7OJGNAVCNFSM6AAAAAA2PDIHCOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRTGMYTAOBUGY . You are receiving this because you commented.Message ID: @.***>

[fangzhangmnm]

A simpler fix is to disable the collision of the table with the player lol

[firescaleVR]

I've been thinking about this and realized that you may not want to implement this because if the player hits rotate while they are 'leaned over', they will spin off axis and the effect may be worse than being pushed back.

[FrankRuis]

This is something that annoys me a lot in games, especially if the body collider is so far forward that you can't even grab something that is on top of a table without getting pushed back.

I liked the way half-life alyx did this, which felt similar to what pietru2004 and GeminiSquishGames suggested. Though in half-life alyx you can move arbitrarily far away from your body, e.g. walking 2 meters past a static obstacle, and then they simply teleport your camera back to the point where your physical body first collided with a static body as soon as you perform any kind of direct input such as movement or turning with the joystick. The screen fades to black when attempting to walk through a wall.

I'd be willing to contribute to this, if people feel something like my own approach is sensible, since I already implemented something like the sketch below in my own game:

• The head has a sphere collider with the same radius as the player radius, and sits on top of the player collision capsule, centered on the camera origin - eye offset.
• The screen fades out when moving the camera through an obstacle to prevent peeking.
• I found the teleport on turning in half-life alyx quite jarring, so I move the XR origin with the head instead of the body, allowing regular turning while over the table without rotating off-axis or teleporting back.
• The head and body are connected via a Generic6DOFJoint, with linear limits for the ground plane set to max_head_distance * (1 - (1 + camera_look_direction.dot(camera_to_body_direction)) / 2).
  • The idea is that the body should stay behind the camera, so you can "lean" forward the most, a bit less to the sides, and not at all backwards.
  • The joint also allows the body to gently push away rigid body obstacles instead of getting stuck on them.
  • My own character's body is a RigidBody3D, so a joint was the easiest way to implement this, but with a CharacterBody3D we can probably just move_and_slide?

On room-scale movement:

• Do a shapecast with the body collider shape to check if we can move the body back below the head:
  • If there is no obstacle: teleport the body back below the head.
  • If there is an obstacle: move the body in the direction of the head until the obstacle is reached (handled by the joint between the body and head)

When moving outside of the "cable slack" area with room-scale movement, there could be configurable options:

• immediately move the camera back to the nearest point within the limit (as shown in the sketch)
  • could be quite jarring, personally really dislike when this happens in games where I try to lean over a table for example.
• allow the player to move as far as they want, like in half-life alyx
• start fading the screen to black when reaching the edge of the limit

On explicit user input (moving with the joystick, or optionally when turning with the joystick):

• Do a shapecast with the body collider shape to check if we can move the body back below the head:
  • If there is no obstacle: teleport the body back below the head.
  • If there is an obstacle: teleport the head and camera back above the body.

[pietru2004]

that feels/is similar or we might have been thinking about that but in this step it should move camera to last position it could be furthest from body