troubleshooting_physics_issues.rst 8.6 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167
  1. .. _doc_troubleshooting_physics_issues:
  2. Troubleshooting physics issues
  3. ==============================
  4. When working with a physics engine, you may encounter unexpected results.
  5. While many of these issues can be resolved through configuration, some of them
  6. are the result of engine bugs. For known issues related to the physics engine,
  7. see
  8. `open physics-related issues on GitHub <https://github.com/godotengine/godot/issues?q=is%3Aopen+is%3Aissue+label%3Atopic%3Aphysics>`__.
  9. Looking through `closed issues
  10. <https://github.com/godotengine/godot/issues?q=+is%3Aclosed+is%3Aissue+label%3Atopic%3Aphysics>`__
  11. can also help answer questions related to physics engine behavior.
  12. Objects are passing through each other at high speeds
  13. -----------------------------------------------------
  14. This is known as *tunneling*. Enabling **Continuous CD** in the RigidBody
  15. properties can sometimes resolve this issue. If this does not help, there are
  16. other solutions you can try:
  17. - Make your static collision shapes thicker. For example, if you have a thin
  18. floor that the player can't get below in some way, you can make the collider
  19. thicker than the floor's visual representation.
  20. - Modify your fast-moving object's collision shape depending on its movement
  21. speed. The faster the object moves, the larger the collision shape should
  22. extend outside of the object to ensure it can collide with thin walls more
  23. reliably.
  24. - Increase **Physics Ticks Per Second** in the advanced Project Settings. While
  25. this has other benefits (such as more stable simulation and reduced input
  26. lag), this increases CPU utilization and may not be viable for mobile/web
  27. platforms. Multipliers of the default value of ``60`` (such as ``120``, ``180``
  28. or ``240``) should be preferred for a smooth appearance on most displays.
  29. Stacked objects are unstable and wobbly
  30. ---------------------------------------
  31. Despite seeming like a simple problem, stable RigidBody simulation with stacked
  32. objects is difficult to implement in a physics engine. This is caused by
  33. integrating forces going against each other. The more stacked objects are
  34. present, the stronger the forces will be against each other. This eventually
  35. causes the simulation to become wobbly, making the objects unable to rest on top
  36. of each other without moving.
  37. Increasing the physics simulation rate can help alleviate this issue. To do so,
  38. increase **Physics Ticks Per Second** in the advanced Project Settings. Note
  39. that increases CPU utilization and may not be viable for mobile/web platforms.
  40. Multipliers of the default value of ``60`` (such as ``120``, ``180`` or ``240``)
  41. should be preferred for a smooth appearance on most displays.
  42. Scaled physics bodies or collision shapes do not collide correctly
  43. ------------------------------------------------------------------
  44. Godot does not currently support scaling of physics bodies or collision shapes.
  45. As a workaround, change the collision shape's extents instead of changing its
  46. scale. If you want the visual representation's scale to change as well, change
  47. the scale of the underlying visual representation (Sprite2D, MeshInstance3D, …)
  48. and change the collision shape's extents separately. Make sure the collision
  49. shape is not a child of the visual representation in this case.
  50. Since resources are shared by default, you'll have to make the collision shape
  51. resource unique if you don't want the change to be applied to all nodes using
  52. the same collision shape resource in the scene. This can be done by calling
  53. ``duplicate()`` in a script on the collision shape resource *before* changing
  54. its size.
  55. Thin objects are wobbly when resting on the floor
  56. -------------------------------------------------
  57. This can be due to one of two causes:
  58. - The floor's collision shape is too thin.
  59. - The RigidBody's collision shape is too thin.
  60. In the first case, this can be alleviated by making the floor's collision shape
  61. thicker. For example, if you have a thin floor that the player can't get below
  62. in some way, you can make the collider thicker than the floor's visual
  63. representation.
  64. In the second case, this can usually only be resolved by increasing the physics
  65. simulation rate (as making the shape thicker would cause a disconnect between
  66. the RigidBody's visual representation and its collision).
  67. In both cases, increasing the physics simulation rate can also help alleviate
  68. this issue. To do so, increase **Physics Ticks Per Second** in the advanced
  69. Project Settings. Note that this increases CPU utilization and may not be viable
  70. for mobile/web platforms. Multipliers of the default value of ``60`` (such as
  71. ``120``, ``180`` or ``240``) should be preferred for a smooth appearance on most
  72. displays.
  73. Cylinder collision shapes are unstable
  74. --------------------------------------
  75. During the transition from Bullet to GodotPhysics in Godot 4, cylinder collision
  76. shapes had to be reimplemented from scratch. However, cylinder collision shapes
  77. are one of the most difficult shapes to support, which is why many other physics
  78. engines don't provide any support for them. There are several known bugs with
  79. cylinder collision shapes currently.
  80. We recommend using box or capsule collision shapes for characters for now. Boxes
  81. generally provide the best reliability, but have the downside of making the
  82. character take more space diagonally. Capsule collision shapes do not have this
  83. downside, but their shape can make precision platforming more difficult.
  84. VehicleBody simulation is unstable, especially at high speeds
  85. -------------------------------------------------------------
  86. When a physics body moves at a high speed, it travels a large distance between
  87. each physics step. For instance, when using the 1 unit = 1 meter convention in
  88. 3D, a vehicle moving at 360 km/h will travel 100 units per second. With the
  89. default physics simulation rate of 60 Hz, the vehicle moves by ~1.67 units each
  90. physics tick. This means that small objects may be ignored entirely by the
  91. vehicle (due to tunneling), but also that the simulation has little data to work
  92. with in general at such a high speed.
  93. Fast-moving vehicles can benefit a lot from an increased physics simulation
  94. rate. To do so, increase **Physics Ticks Per Second** in the advanced Project
  95. Settings. Note that this increases CPU utilization and may not be viable for
  96. mobile/web platforms. Multipliers of the default value of ``60`` (such as
  97. ``120``, ``180`` or ``240``) should be preferred for a smooth appearance on most
  98. displays.
  99. Collision results in bumps when an object moves across tiles
  100. ------------------------------------------------------------
  101. This is a known issue in the physics engine caused by the object bumping on a
  102. shape's edges, even though that edge is covered by another shape. This can occur
  103. in both 2D and 3D.
  104. The best way to work around this issue is to create a "composite" collider. This
  105. means that instead of individual tiles having their collision, you create a
  106. single collision shape representing the collision for a group of tiles.
  107. Typically, you should split composite colliders on a per-island basis (which
  108. means each group of touching tiles gets its own collider).
  109. Using a composite collider can also improve physics simulation performance in
  110. certain cases. However, since the composite collision shape is much more
  111. complex, this may not be a net performance win in all cases.
  112. Framerate drops when an object touches another object
  113. -----------------------------------------------------
  114. This is likely due to one of the objects using a collision shape that is too
  115. complex. Convex collision shapes should use a number of shapes as low as
  116. possible for performance reasons. When relying on Godot's automatic generation,
  117. it's possible that you ended up with dozens if not hundreds of shapes created
  118. for a single convex shape collision resource.
  119. In some cases, replacing a convex collider with a couple of primitive collision
  120. shapes (box, sphere, or capsule) can deliver better performance.
  121. This issue can also occur with StaticBodies that use very detailed trimesh
  122. (concave) collisions. In this case, use a simplified representation of the level
  123. geometry as a collider. Not only this will improve physics simulation
  124. performance significantly, but this can also improve stability by letting you
  125. remove small fixtures and crevices from being considered by collision.
  126. Physics simulation is unreliable when far away from the world origin
  127. --------------------------------------------------------------------
  128. This is caused by floating-point precision errors, which become more pronounced
  129. as the physics simulation occurs further away from the world origin. This issue
  130. also affects rendering, which results in wobbly camera movement when far away
  131. from the world origin. See :ref:`doc_large_world_coordinates` for more
  132. information.