Add support for holes when triangulating HeightMapShape3D for navigation #101380
+21
−7
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
NavMeshGenerator3D will no longer not attempt to generate triangles touching points where the heightfield value is either NAN (represents a hole in GodotPhysics3D and Jolt) or FLT_MAX (represents a hole in Jolt only afaik) when triangulating StaticBody3Ds. Solves an issue that has complicated navmesh generation on complex landscapes for a while now. Attempting to generate navigation using a HeightMapShape3D with holes in it would quietly fail.
|
While I am in general ok with adding "hole" support this needs to be sorted first on the physics end and HeightMapShape3D to have one single definition for heightmap shape "holes" that is always the same no matter what physics backend is used. We are not adding hacks to the navmesh generator that run different ideas depending on whatever physics backend the user project has decided to switch to. Things need to keep working with an unknown physics backend. |
|
Both backends work w/NAN (the Jolt integration explicitly implements it) so removing the FLT_MAX checks, maybe? Though I'm not sure whether it's an implementation artifact or an undocumented feature on GodotPhysics' end, tbh. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
NavMeshGenerator3D will no longer not attempt to generate triangles touching points where the heightfield value is either NAN (represents a hole in GodotPhysics3D and Jolt) or FLT_MAX (represents a hole in Jolt only afaik) when triangulating StaticBody3Ds that use a HeightMapShape3D for collision.
Solves an issue that has complicated navmesh generation on complex landscapes for a while now. Attempting to generate navigation using a heightfield with holes in it before this would quietly fail.
Example of navigation generated over a heightmap collider:
