Collisions: Difference between revisions

From Minecraft Parkour Wiki
Content added Content deleted
(Created page with "[WIP] Minecraft's collision physics is very simplistic in nature, yet it contains many glitches. As a reminder, Minecraft's physics is updated 20 ticks per second. The p...")
 
(Marked this version for translation)
 
(10 intermediate revisions by 2 users not shown)
Line 1: Line 1:
<languages/>
[WIP]
<translate>
<!--T:1-->
Minecraft's collision physics is very simplistic: instead of ray-tracing the collisions, the game simply moves the player sequentially along each axis.


<!--T:2-->
Minecraft's collision physics is very simplistic in nature, yet it contains many glitches.
As a reminder, Minecraft's physics is updated 20 [[Special:MyLanguage/ticks|ticks]] per second. The player's movement and collisions are updated once per tick.


As a reminder, Minecraft's physics is updated 20 [[ticks]] per second. The player's movement and collisions are calculated once every tick.




== Collision Box == <!--T:3-->
== Order of collisions and X/Z Facing ==
Movement is not checked linearly: instead, the game does # steps:


<!--T:4-->
* Move the player along the Y axis until there is a vertical collision. In that last case, if the player's Y speed is negative,
A '''collision box''' consists of one or multiple bounding boxes, which are simple cuboids define by minimum and maximum X/Y/Z coordinates.
* Move the player along the X axis until there is a horizontal collision.
* Move the player along the Z axis until there is a horizontal collision.
* If a horizontal collision was detected, we know a wall is blocking the player's path, but perhaps it's low enough that the player can simply.
** The game does another calculation to see if the player could go further when taking [[stepping]] into account.
** Otherwise, the wall is considered too tall to step onto.
* End


<!--T:5-->
Collisions usually involve an Entity and a Block: entities and blocks typically don't collide among themselves.


<!--T:6-->
== Some examples ==
* The player only has one bounding box, of dimensions '''0.6'''×'''1.8'''×'''0.6''' m<sup>3</sup>. Their position (as shown in F3) is located at the bottom center

<!--T:7-->
* Blocks have more complicated collision boxes (see [[Special:MyLanguage/Blocks|this list]]).


<!--T:8-->
Note: a "hitbox" is what the player can click on (e.g. attack an entity, press a button, open a door). It may or may not overlap with the collision box.

<!--T:9-->
[[File:Collision box (player and block).png|frameless|720x720px]]


== Collision Order == <!--T:10-->

<!--T:11-->
Every tick, after the player's velocity has been updated, the game does these steps to check collisions:

<!--T:12-->
* Move the player along the Y axis. If a vertical collision is detected while moving downward, the player is now considered to be on ground.
* Move the player along the X axis.
* Move the player along the Z axis.
* If the player is on ground and collided with a wall, they are able to step over it if it's less than 0.6m tall.
** See [[Special:MyLanguage/Stepping|Stepping]] for explanations and visuals.
** This mechanic is responsible for [[Special:MyLanguage/Blip|Blips]] and [[Special:MyLanguage/Jump Cancel|Jump-Cancel]], and their glitched variants.



== Vertical Collisions (Y)== <!--T:13-->

<!--T:14-->
Vertical movement is processed before horizontal movement. Due to this:

<!--T:15-->
* The player is able to jump one tick after running off a block. In particular, this is why [[Special:MyLanguage/Timings|headhitter timing]] works.
*To land on a block, the player's bounding box must overlap its surface on the final tick of the jump.


<!--T:16-->
[[File:Y Collision.png|frameless|720x720px]]

<!--T:17-->
When the player hits a floor or ceiling, their vertical speed is reset to 0.



== Horizontal Collisions (X/Z) == <!--T:18-->

<!--T:19-->
Due to the X axis being processed before the Z axis, corner collisions don't behave the same depending on the direction.

<!--T:20-->
This phenomenon is especially noticeable with more speed.

<!--T:21-->
[[File:XZ collision.png|frameless|720x720px]]

<!--T:22-->
It's important to distinguish "X-facing" jumps from "Z-facing" ones:

<!--T:23-->
*'''X-facing''' refers to jumps that point towards East/West. The corner is difficult to avoid, and the player may have to start jumping further back than expected.

<!--T:24-->
*'''Z-facing''' refers to jumps that point towards North/South. The corner is easier to avoid, and in particular it's possible to do a hh-timing from the front.

<!--T:25-->
The axis of a jump can be checked with [[Special:MyLanguage/Debug Screen|F3]].


<!--T:26-->
Players tend to find Z-facing neos more intuitive, but X-facing neos can actually be more lenient:

<!--T:27-->
*Z-facing neos are very similar to linear jumps (assuming optimal movement). To convert a neo, simply add 1.2 to its distance and increase its [[Special:MyLanguage/Tiers|tier]] by one. For example, a triple neo is equivalent to a "4.2+0.25" (which cannot be built, but this sort of comparison is useful for analysis)
*X-facing neos don't have a linear equivalent. Compared to Z-facing neos, they are "shifted" by 1 tick (wall collision begins and ends 1 tick earlier). This shift reduces the momentum, but makes it more efficient as the player typically has more speed at the end of a jump than at the start.

<!--T:28-->
Some jumps are only possible when facing one axis or the other (for example, a [https://youtu.be/apWPY4_-Qbg 2bm triple neo] is only possible X-facing)



== 1.14+== <!--T:29-->

<!--T:30-->
In 1.14, the collision physics were updated. The collision order now depends on the player's velocity:

<!--T:31-->
*If the player has more Z speed than X speed (in absolute value), the collision order is '''Y-X-Z'''.
*Otherwise, the collision order is '''Y-Z-X'''.

<!--T:32-->
In most cases, all collisions now resemble X-facing. Some jumps which involve cutting corners may be very different compared to pre-1.14.
</translate>

Latest revision as of 08:15, 14 November 2021

Other languages:

Minecraft's collision physics is very simplistic: instead of ray-tracing the collisions, the game simply moves the player sequentially along each axis.

As a reminder, Minecraft's physics is updated 20 ticks per second. The player's movement and collisions are updated once per tick.


Collision Box

A collision box consists of one or multiple bounding boxes, which are simple cuboids define by minimum and maximum X/Y/Z coordinates.

Collisions usually involve an Entity and a Block: entities and blocks typically don't collide among themselves.

  • The player only has one bounding box, of dimensions 0.6×1.8×0.6 m3. Their position (as shown in F3) is located at the bottom center
  • Blocks have more complicated collision boxes (see this list).


Note: a "hitbox" is what the player can click on (e.g. attack an entity, press a button, open a door). It may or may not overlap with the collision box.


Collision Order

Every tick, after the player's velocity has been updated, the game does these steps to check collisions:

  • Move the player along the Y axis. If a vertical collision is detected while moving downward, the player is now considered to be on ground.
  • Move the player along the X axis.
  • Move the player along the Z axis.
  • If the player is on ground and collided with a wall, they are able to step over it if it's less than 0.6m tall.
    • See Stepping for explanations and visuals.
    • This mechanic is responsible for Blips and Jump-Cancel, and their glitched variants.


Vertical Collisions (Y)

Vertical movement is processed before horizontal movement. Due to this:

  • The player is able to jump one tick after running off a block. In particular, this is why headhitter timing works.
  • To land on a block, the player's bounding box must overlap its surface on the final tick of the jump.


When the player hits a floor or ceiling, their vertical speed is reset to 0.


Horizontal Collisions (X/Z)

Due to the X axis being processed before the Z axis, corner collisions don't behave the same depending on the direction.

This phenomenon is especially noticeable with more speed.

It's important to distinguish "X-facing" jumps from "Z-facing" ones:

  • X-facing refers to jumps that point towards East/West. The corner is difficult to avoid, and the player may have to start jumping further back than expected.
  • Z-facing refers to jumps that point towards North/South. The corner is easier to avoid, and in particular it's possible to do a hh-timing from the front.

The axis of a jump can be checked with F3.


Players tend to find Z-facing neos more intuitive, but X-facing neos can actually be more lenient:

  • Z-facing neos are very similar to linear jumps (assuming optimal movement). To convert a neo, simply add 1.2 to its distance and increase its tier by one. For example, a triple neo is equivalent to a "4.2+0.25" (which cannot be built, but this sort of comparison is useful for analysis)
  • X-facing neos don't have a linear equivalent. Compared to Z-facing neos, they are "shifted" by 1 tick (wall collision begins and ends 1 tick earlier). This shift reduces the momentum, but makes it more efficient as the player typically has more speed at the end of a jump than at the start.

Some jumps are only possible when facing one axis or the other (for example, a 2bm triple neo is only possible X-facing)


1.14+

In 1.14, the collision physics were updated. The collision order now depends on the player's velocity:

  • If the player has more Z speed than X speed (in absolute value), the collision order is Y-X-Z.
  • Otherwise, the collision order is Y-Z-X.

In most cases, all collisions now resemble X-facing. Some jumps which involve cutting corners may be very different compared to pre-1.14.