-
Notifications
You must be signed in to change notification settings - Fork 433
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adds config option for including static objects during navmesh construction #2104
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -248,7 +248,11 @@ def _config_pathfinder(self, config: Configuration) -> None: | |
f"Recomputing navmesh for agent's height {default_agent_config.height} and radius" | ||
f" {default_agent_config.radius}." | ||
) | ||
self.recompute_navmesh(self.pathfinder, needed_settings) | ||
self.recompute_navmesh( | ||
self.pathfinder, | ||
needed_settings, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So weird that this isn't in the navmesh setting struct... There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Actually, don't we need to change the if statement above this to always recompute the navmesh if include_static_objects=True, since we can't guarantee that the navmesh setting caching will work in that case? This code will not be run currently if a navmesh computed with include_static_objects=False is cached as part of the dataset, right? |
||
include_static_objects=self.config.sim_cfg.include_static_objects_in_navmesh, | ||
) | ||
|
||
self.pathfinder.seed(config.sim_cfg.random_seed) | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am sure there is a good reason, but why isn't this a navmesh setting? It requires a reconstruction of the Navmesh which we check by seeing if the new navmesh settings equals the old. Feels more naturally to live in there, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point.
Currently, NavMeshSettings only includes recast-level parameters. The mesh joining triggered by this flag happens before the nav module is ever invoked, so it is really a Simaultor flag at the scene level.
I think there could be a valid argument to add this to the NavMeshSettings and then pivot off of that in recompute_navmesh directly instead of treating it separately. That would be a breaking change across the stack.