navigation_using_navigationservers.rst 10 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220
  1. .. _doc_navigation_using_navigationservers:
  2. Using NavigationServer
  3. ======================
  4. 2D and 3D version of the NavigationServer are available as
  5. :ref:`NavigationServer2D<class_NavigationServer2D>` and
  6. :ref:`NavigationServer3D<class_NavigationServer3D>` respectively.
  7. Both 2D and 3D use the same NavigationServer with NavigationServer3D being the primary server. The NavigationServer2D is a frontend that converts 2D positions into 3D positions and back.
  8. Hence it is entirely possible (if not a little cumbersome) to exclusively use the NavigationServer3D API for 2D navigation.
  9. Communicating with the NavigationServer
  10. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  11. To work with the NavigationServer means to prepare parameters for a **query** that can be sent to the NavigationServer for updates or requesting data.
  12. To reference the internal NavigationServer objects like maps, regions and agents RIDs are used as identification numbers.
  13. Every navigation related node in the scene tree has a function that returns the RID for this node.
  14. Threading and Synchronization
  15. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  16. The NavigationServer does not update every change immediately but waits until
  17. the end of the **physics frame** to synchronize all the changes together.
  18. Waiting for synchronization is required to apply changes to all maps, regions and agents.
  19. Synchronization is done because some updates like a recalculation of the entire navigation map are very expensive and require updated data from all other objects.
  20. Also the NavigationServer uses a **threadpool** by default for some functionality like avoidance calculation between agents.
  21. Waiting is not required for most ``get()`` functions that only request data from the NavigationServer without making changes.
  22. Note that not all data will account for changes made in the same frame.
  23. E.g. if an avoidance agent changed the navigation map this frame the ``agent_get_map()`` function will still return the old map before the synchronization.
  24. The exception to this are nodes that store their values internally before sending the update to the NavigationServer.
  25. When a getter on a node is used for a value that was updated in the same frame it will return the already updated value stored on the node.
  26. The NavigationServer is **thread-safe** as it places all API calls that want to make changes in a queue to be executed in the synchronization phase.
  27. Synchronization for the NavigationServer happens in the middle of the physics frame after scene input from scripts and nodes are all done.
  28. .. note::
  29. The important takeaway is that most NavigationServer changes take effect after the next physics frame and not immediately.
  30. This includes all changes made by navigation related nodes in the scene tree or through scripts.
  31. .. note::
  32. All setters and delete functions require synchronization.
  33. 2D and 3D NavigationServer differences
  34. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  35. NavigationServer2D and NavigationServer3D are equivalent in functionality
  36. for their dimension and both use the same NavigationServer behind the scene.
  37. Strictly technical a NavigationServer2D is a myth.
  38. The NavigationServer2D is a frontend to facilitate conversions of ``Vector2(x, y)`` to
  39. ``Vector3(x, 0.0, z)`` and back for the NavigationServer3D API. 2D uses a flat 3D mesh
  40. pathfinding and the NavigationServer2D facilitates the conversions.
  41. When a guide uses just NavigationServer without the 2D or 3D suffix it usually works for both servers
  42. by exchange ``Vector2(x, y)`` with ``Vector3(x, 0.0, z)`` or reverse.
  43. Technically it is possible to use the tools for creating navigation meshes in one dimension for the other
  44. dimension, e.g. baking a 2D navigation mesh with the 3D NavigationMesh when using
  45. flat 3D source geometry or creating 3D flat navigation meshes with the
  46. polygon outline draw tools of NavigationRegion2D and NavigationPolygons.
  47. Any RID created with the NavigationServer2D API works on the NavigationServer3D API
  48. as well and both 2D and 3D avoidance agents can exist on the same map.
  49. .. note::
  50. Regions created in 2D and 3D will merge their navigation meshes when placed on the same map and merge conditions apply.
  51. The NavigationServer does not discriminate between NavigationRegion2D and NavigationRegion3D nodes as both are regions on the server.
  52. By default those nodes register on different navigation maps so this merge can only happen when maps are changed manually e.g. with scripts.
  53. Actors with avoidance enabled will avoid both 2D and 3D avoidance agents when placed on the same map.
  54. .. warning::
  55. It is not possible to use NavigationServer2D while disabling 3D on a Godot custom build.
  56. Waiting for synchronization
  57. ~~~~~~~~~~~~~~~~~~~~~~~~~~~
  58. At the start of the game, a new scene or procedural navigation changes any path query to a NavigationServer will return empty or wrong.
  59. The navigation map is still empty or not updated at this point.
  60. All nodes from the scene tree need to first upload their navigation related data to the NavigationServer.
  61. Each added or changed map, region or agent need to be registered with the NavigationServer.
  62. Afterward the NavigationServer requires a **physics frame** for synchronization to update the maps, regions and agents.
  63. One workaround is to make a deferred call to a custom setup function (so all nodes are ready).
  64. The setup function makes all the navigation changes, e.g. adding procedural stuff.
  65. Afterwards the function waits for the next physics frame before continuing with path queries.
  66. .. tabs::
  67. .. code-tab:: gdscript GDScript
  68. extends Node3D
  69. func _ready():
  70. # Use call deferred to make sure the entire scene tree nodes are setup
  71. # else await on 'physics_frame' in a _ready() might get stuck.
  72. custom_setup.call_deferred()
  73. func custom_setup():
  74. # Create a new navigation map.
  75. var map: RID = NavigationServer3D.map_create()
  76. NavigationServer3D.map_set_up(map, Vector3.UP)
  77. NavigationServer3D.map_set_active(map, true)
  78. # Create a new navigation region and add it to the map.
  79. var region: RID = NavigationServer3D.region_create()
  80. NavigationServer3D.region_set_transform(region, Transform3D())
  81. NavigationServer3D.region_set_map(region, map)
  82. # Create a procedural navigation mesh for the region.
  83. var new_navigation_mesh: NavigationMesh = NavigationMesh.new()
  84. var vertices: PackedVector3Array = PackedVector3Array([
  85. Vector3(0, 0, 0),
  86. Vector3(9.0, 0, 0),
  87. Vector3(0, 0, 9.0)
  88. ])
  89. new_navigation_mesh.set_vertices(vertices)
  90. var polygon: PackedInt32Array = PackedInt32Array([0, 1, 2])
  91. new_navigation_mesh.add_polygon(polygon)
  92. NavigationServer3D.region_set_navigation_mesh(region, new_navigation_mesh)
  93. # Wait for NavigationServer sync to adapt to made changes.
  94. await get_tree().physics_frame
  95. # Query the path from the navigation server.
  96. var start_position: Vector3 = Vector3(0.1, 0.0, 0.1)
  97. var target_position: Vector3 = Vector3(1.0, 0.0, 1.0)
  98. var optimize_path: bool = true
  99. var path: PackedVector3Array = NavigationServer3D.map_get_path(
  100. map,
  101. start_position,
  102. target_position,
  103. optimize_path
  104. )
  105. print("Found a path!")
  106. print(path)
  107. .. code-tab:: csharp C#
  108. using Godot;
  109. public partial class MyNode3D : Node3D
  110. {
  111. public override void _Ready()
  112. {
  113. // Use call deferred to make sure the entire scene tree nodes are setup
  114. // else await on 'physics_frame' in a _Ready() might get stuck.
  115. CallDeferred(MethodName.CustomSetup);
  116. }
  117. private async void CustomSetup()
  118. {
  119. // Create a new navigation map.
  120. Rid map = NavigationServer3D.MapCreate();
  121. NavigationServer3D.MapSetUp(map, Vector3.Up);
  122. NavigationServer3D.MapSetActive(map, true);
  123. // Create a new navigation region and add it to the map.
  124. Rid region = NavigationServer3D.RegionCreate();
  125. NavigationServer3D.RegionSetTransform(region, Transform3D.Identity);
  126. NavigationServer3D.RegionSetMap(region, map);
  127. // Create a procedural navigation mesh for the region.
  128. var newNavigationMesh = new NavigationMesh()
  129. {
  130. Vertices = new[]
  131. {
  132. new Vector3(0.0f, 0.0f, 0.0f),
  133. new Vector3(9.0f, 0.0f, 0.0f),
  134. new Vector3(0.0f, 0.0f, 9.0f),
  135. },
  136. };
  137. int[] polygon = new[] { 0, 1, 2 };
  138. newNavigationMesh.AddPolygon(polygon);
  139. NavigationServer3D.RegionSetNavigationMesh(region, newNavigationMesh);
  140. // Wait for NavigationServer sync to adapt to made changes.
  141. await ToSignal(GetTree(), SceneTree.SignalName.PhysicsFrame);
  142. // Query the path from the navigation server.
  143. var startPosition = new Vector3(0.1f, 0.0f, 0.1f);
  144. var targetPosition = new Vector3(1.0f, 0.0f, 1.0f);
  145. Vector3[] path = NavigationServer3D.MapGetPath(map, startPosition, targetPosition, optimize: true);
  146. GD.Print("Found a path!");
  147. GD.Print((Variant)path);
  148. }
  149. }
  150. Server Avoidance Callbacks
  151. ~~~~~~~~~~~~~~~~~~~~~~~~~~
  152. If RVO avoidance agents are registered for avoidance callbacks the NavigationServer dispatches
  153. their ``velocity_computed`` signals just before the PhysicsServer synchronization.
  154. To learn more about NavigationAgents see :ref:`doc_navigation_using_navigationagents`.
  155. The simplified order of execution for NavigationAgents that use avoidance:
  156. - physics frame starts.
  157. - ``_physics_process(delta)``.
  158. - ``velocity`` property is set on NavigationAgent Node.
  159. - Agent sends velocity and position to NavigationServer.
  160. - NavigationServer waits for synchronization.
  161. - NavigationServer synchronizes and computes avoidance velocities for all registered avoidance agents.
  162. - NavigationServer sends safe velocity vector with signals for each registered avoidance agents.
  163. - Agents receive the signal and move their parent e.g. with ``move_and_slide`` or ``linear_velocity``.
  164. - PhysicsServer synchronizes.
  165. - physics frame ends.
  166. Therefore moving a physicsbody actor in the callback function with the safe velocity is perfectly thread- and physics-safe
  167. as all happens inside the same physics frame before the PhysicsServer commits to changes and does its own calculations.