Open
Conversation
Author
|
Actually also just realized that using a shader keyword might be better when toggling usage of travel costs in the integration shader, rather than adding that extra branch. |
Author
|
Ok found some issues in my code, my bad. I'll test it fully and fix it before re-opening. |
Author
|
Ok fixed the bug, needed to apply travel costs to the neighbor cost calculation only, and incorporate it into the flow field generation as well. |
This file contains hidden or 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
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.
I've added support for travel costs. Before, any cell with a weight other than
float.MaxValuewas essentially treated as fully walkable. However, in some games, it may be beneficial if navigation agents also took into account how much "effort" it takes to travel through a certain cell, in combination with that cell's weight.E.g. consider an environment where enemies can spend time to destroy obstacles in their path. Ideally, enemies would weigh the option of pathfinding around a destroyable obstacle against the option of destroying it and walking through. However, with the current system, enemies will only ever pathfind around impassable obstacles. Any other cell is treated as if it is completely walkable, as it always inherits its neighbor's weight directly (with the distance added).
To adapt it to this type of scenario, I've added another travel costs buffer to optionally be included in the integration step. If travel costs are used, the travel cost of a cell is added to its own minimum cost, reflecting that the benefit of travelling to this cell is offset by the cost of doing so.
Additionally (although I didn't make this change), this removes the need for the "Walkable" and "Obstacle" sentinel values. You can instead initialize all cell weights to
float.MaxValue(indicating no value), and then set the travel cost of any "Obstacle" tofloat.MaxValue. Walkable cells are simply the default, i.e. a cell with a weight offloat.MaxValueand travel cost of0.