godot/doc/classes/NavigationMeshGenerator.xml

<?xml version="1.0" encoding="UTF-8" ?>
<class name="NavigationMeshGenerator" inherits="Object" deprecated="" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../class.xsd">
	<brief_description>
		Helper class for creating and clearing navigation meshes.
	</brief_description>
	<description>
		This class is responsible for creating and clearing 3D navigation meshes used as [NavigationMesh] resources inside [NavigationRegion3D]. The [NavigationMeshGenerator] has very limited to no use for 2D as the navigation mesh baking process expects 3D node types and 3D source geometry to parse.
		The entire navigation mesh baking is best done in a separate thread as the voxelization, collision tests and mesh optimization steps involved are very slow and performance-intensive operations.
		Navigation mesh baking happens in multiple steps and the result depends on 3D source geometry and properties of the [NavigationMesh] resource. In the first step, starting from a root node and depending on [NavigationMesh] properties all valid 3D source geometry nodes are collected from the [SceneTree]. Second, all collected nodes are parsed for their relevant 3D geometry data and a combined 3D mesh is build. Due to the many different types of parsable objects, from normal [MeshInstance3D]s to [CSGShape3D]s or various [CollisionObject3D]s, some operations to collect geometry data can trigger [RenderingServer] and [PhysicsServer3D] synchronizations. Server synchronization can have a negative effect on baking time or framerate as it often involves [Mutex] locking for thread security. Many parsable objects and the continuous synchronization with other threaded Servers can increase the baking time significantly. On the other hand only a few but very large and complex objects will take some time to prepare for the Servers which can noticeably stall the next frame render. As a general rule the total number of parsable objects and their individual size and complexity should be balanced to avoid framerate issues or very long baking times. The combined mesh is then passed to the Recast Navigation Object to test the source geometry for walkable terrain suitable to [NavigationMesh] agent properties by creating a voxel world around the meshes bounding area.
		The finalized navigation mesh is then returned and stored inside the [NavigationMesh] for use as a resource inside [NavigationRegion3D] nodes.
		[b]Note:[/b] Using meshes to not only define walkable surfaces but also obstruct navigation baking does not always work. The navigation baking has no concept of what is a geometry "inside" when dealing with mesh source geometry and this is intentional. Depending on current baking parameters, as soon as the obstructing mesh is large enough to fit a navigation mesh area inside, the baking will generate navigation mesh areas that are inside the obstructing source geometry mesh.
	</description>
	<tutorials>
		<link title="Using NavigationMeshes">$DOCS_URL/tutorials/navigation/navigation_using_navigationmeshes.html</link>
	</tutorials>
	<methods>
		<method name="bake" deprecated="This method is deprecated due to core threading changes. To upgrade existing code, first create a [NavigationMeshSourceGeometryData3D] resource. Use this resource with [method parse_source_geometry_data] to parse the [SceneTree] for nodes that should contribute to the navigation mesh baking. The [SceneTree] parsing needs to happen on the main thread. After the parsing is finished use the resource with [method bake_from_source_geometry_data] to bake a navigation mesh.">
			<return type="void" />
			<param index="0" name="navigation_mesh" type="NavigationMesh" />
			<param index="1" name="root_node" type="Node" />
			<description>
				Bakes the [param navigation_mesh] with source geometry collected starting from the [param root_node].
			</description>
		</method>
		<method name="bake_from_source_geometry_data">
			<return type="void" />
			<param index="0" name="navigation_mesh" type="NavigationMesh" />
			<param index="1" name="source_geometry_data" type="NavigationMeshSourceGeometryData3D" />
			<param index="2" name="callback" type="Callable" default="Callable()" />
			<description>
				Bakes the provided [param navigation_mesh] with the data from the provided [param source_geometry_data]. After the process is finished the optional [param callback] will be called.
			</description>
		</method>
		<method name="clear">
			<return type="void" />
			<param index="0" name="navigation_mesh" type="NavigationMesh" />
			<description>
				Removes all polygons and vertices from the provided [param navigation_mesh] resource.
			</description>
		</method>
		<method name="parse_source_geometry_data">
			<return type="void" />
			<param index="0" name="navigation_mesh" type="NavigationMesh" />
			<param index="1" name="source_geometry_data" type="NavigationMeshSourceGeometryData3D" />
			<param index="2" name="root_node" type="Node" />
			<param index="3" name="callback" type="Callable" default="Callable()" />
			<description>
				Parses the [SceneTree] for source geometry according to the properties of [param navigation_mesh]. Updates the provided [param source_geometry_data] resource with the resulting data. The resource can then be used to bake a navigation mesh with [method bake_from_source_geometry_data]. After the process is finished the optional [param callback] will be called.
				[b]Note:[/b] This function needs to run on the main thread or with a deferred call as the SceneTree is not thread-safe.
				[b]Performance:[/b] While convenient, reading data arrays from [Mesh] resources can affect the frame rate negatively. The data needs to be received from the GPU, stalling the [RenderingServer] in the process. For performance prefer the use of e.g. collision shapes or creating the data arrays entirely in code.
			</description>
		</method>
	</methods>
</class>