Collisions: Difference between revisions

From Minecraft Parkour Wiki
Content added Content deleted
(completed text, visuals needed)
(Marked this version for translation)
 
(8 intermediate revisions by 2 users not shown)
Line 1: Line 1:
<languages/>
Minecraft's collision physics is very simplistic, yet it contains many glitches.
<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-->
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 [[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 updated once per tick.




== Collision Box == <!--T:3-->
== Order of collisions ==

<!--T:4-->
A '''collision box''' consists of one or multiple bounding boxes, which are simple cuboids define by minimum and maximum X/Y/Z coordinates.

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

<!--T:6-->
* 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:
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 when falling, the player is now considered to be on ground.
* 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 X axis.
* Move the player along the Z axis.
* Move the player along the Z axis.
* If the player is on ground and collided with a wall, perhaps they could step on top of it (e.g. if the wall is just a slab).
* 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.
** See [[Special:MyLanguage/Stepping|Stepping]] for explanations and visuals.
** This mechanic is responsible for [[Blip|Blips]] and [[Jump Cancel|Jump-Cancel]], and their glitched variants.
** This mechanic is responsible for [[Special:MyLanguage/Blip|Blips]] and [[Special:MyLanguage/Jump Cancel|Jump-Cancel]], and their glitched variants.



== Vertical Collisions ==

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

<!--T:14-->
Vertical movement is processed before horizontal movement. Due to this:
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 [[Timings|headhitter timing]] works.
* 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 must be above its surface on the final tick of the jump.
*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-->
== X/Z Facing ==
The axis of a jump can be checked with [[Special:MyLanguage/Debug Screen|F3]].
Due to the X axis being processed before the Z axis, they are fundamentally asymetric: it's important to distinguish "X-facing" jumps from "Z-facing" ones.


* '''X-facing''' refers to jumps that point towards East/West.


<!--T:26-->
* '''Z-facing''' refers to jumps that point towards North/South.
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-->
Players tend to find Z-facing neos more intuitive, but X-facing neos can actually be a bit easier:
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)


* Z-facing neos are very similar to linear jumps. To convert a neo to its equivalent, simply add 1.2 to its distance and increase its [[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 their jump than at the start.


Some jumps are only possible when facing one axis or the other.


== 1.14+== <!--T:29-->
The axis of a jump can be checked with [[Debug Screen|F3]].


<!--T:30-->
== 1.14+ ==
In 1.14, the collision physics were updated. The collision order now depends on the player's velocity:
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, the collision order is '''Y-X-Z'''.
* Otherwise, the collision order is '''Y-Z-X'''.
*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 become very different compared to pre-1.14.
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.