-
-
Notifications
You must be signed in to change notification settings - Fork 21.7k
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
Improve support for directed graphs in A*; docs update included #30556
Conversation
8cbc7a3
to
2cad664
Compare
Does |
Thanks for pointing out! Taking performance and memory use into account, now I think it's better to return to the |
Hi! Worked intermittently on this and I think it's good now. I have added both manual tests and random batch tests, hope they are strong enough 😝 |
9638b33
to
9a1bc0b
Compare
core/math/a_star.cpp
Outdated
Set<Segment>::Element *element = segments.find(s); | ||
s.direction = bidirectional ? | ||
Segment::BIDIRECTIONAL : | ||
(s.u == p_id ? Segment::FORWARD : Segment::BACKWARD); |
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.
Can't this expression be replaced with if (bidirectional) s.direction = Segment::BIDIRECTIONAL
?
Also, segments.find(s)
should probably be moved to after fixing the segment direction.
core/math/a_star.cpp
Outdated
const Set<Segment>::Element *element = segments.find(s); | ||
int direction = bidirectional ? | ||
0 : // Use 0 to accept any existing segment | ||
(s.u == p_id ? Segment::FORWARD : Segment::BACKWARD); |
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.
Can't s.u == p_id ? Segment::FORWARD : Segment::BACKWARD
be replaced by s.direction
?
Apart from those comments, I think it is good (assuming it works). |
9a1bc0b
to
2e9df83
Compare
Thanks for your careful review! I have pushed changes and re-run tests.
Currently the list of neighbours are checked, and that should be enough for now since |
d377dbb
to
76cc331
Compare
I have added an intensive stress test against Floyd–Warshall, which has helped to catch a little bug (diff: original and current). I also manually merged changes in #30708 and fixed a compilation error on CI. (All changes are amended onto their respective commits and the codebase is kept from one stable state to another.) Hope it's ready now 🚀🚀 (Update: fixed CI warnings again) |
76cc331
to
3d4a93c
Compare
Just 1 tiny little error in documentation, all good otherwise for docs. |
3d4a93c
to
ac67fd7
Compare
@kawa-yoiko I just happened upon this PR that would be quite nice to have indeed, there's some conflicts with changes I've made since but the tests you've written especially would be amazing to have around! Any chance you'll pick it back up? |
@profan Sure! I probably will check this |
@kawa-yoiko Heh, yes this is part of what I was afraid of, that there would be things that are still subtly broken.. (OAHashMap is after all only employed in A* and the Godot CSG stuff and then basically nowhere else) so it has had quite little testing overall.. and hopefully the current OAHashMap bugs are not of my doing when trying to fix it last time 🤣.. a robust set of tests is probably necessary there too (in the sense that the current ones pass, but given that your astar one here does not means there must be a problem still) |
@kawa-yoiko I'm gonna take a look at your rebased branch now btw and try to fix it (OAHashMap), hopefully won't take longer than the weekend, with your battery of tests hopefully it can be worked out 👍 |
@profan Such a coincidence that I was just looking into it yesterday and had managed to fix the problem! Will push very soon 😊 |
The fix → #32230. Let's wait for that first and rebase from there, so that the engine is 'brought from one stable state to another' 😝 |
ac67fd7
to
ba6436a
Compare
ba6436a
to
0c35994
Compare
Rebased and all tests are passing now. |
CC @akien-mga |
@@ -227,10 +250,13 @@ PoolVector<int> AStar::get_point_connections(int p_id) { | |||
return point_list; | |||
} | |||
|
|||
bool AStar::are_points_connected(int p_id, int p_with_id) const { | |||
bool AStar::are_points_connected(int p_id, int p_with_id, bool bidirectional) const { |
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.
Should be p_bidirectional
.
ERR_FAIL_COND(!segments.has(s)); | ||
|
||
segments.erase(s); | ||
void AStar::disconnect_points(int p_id, int p_with_id, bool bidirectional) { |
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.
Same here, p_bidirectional
.
We're passed release freeze now, but since it was well reviewed and includes tests, I guess we can make an exception to still merge this. I left a nitpick about the naming of a parameter, but let's merge as is to get more extensive testing as early as possible. |
Thanks! |
Ohh glad to see this finally settled! Should there be further issues spotted I shall still be ready to help >ᴗ< As for parameter naming, will the maintainers team fix it or do I open a new simple PR? |
There are quite a few occurrences where the convention is not well respected, so we'll do a pass at fixing everything while refactoring code for 4.0 I think. |
Closes #30520. A
bidirectional
parameter is added to methodsare_points_connected()
anddisconnect_points()
. The documentation has been updated to match current method signatures and to be more specific. (ref: #8146)Current implementation takes about 2x memory for storing edges. This can be optimized if concerns arise on memory usage.
I have usedFixed by usingERR_EXPLAINC
to report warnings, but don't see them anywhere.DEBUG_ENABLED
is defined. Is that normal?WARN_PRINT
, rebased already.Here is a test. Should it be added to main tests?
Would love to hear opinions ^ ^