|
|
|
 |
Reply From: |
Zylann |
I think this should be something you can use in a thread, but I can’t confirm that.
However, Navigation
is a node, and the scene tree API is known to not be thread-safe. So it boils down to a few questions:
- Is the navigation modified during the game?
- Is the search algorithm using non-thread-safe APIs? (engine side)
- Is the threaded code YOU wrote accessing nodes from its thread?
If you are accessing nodes from your thread, change that. Make sure the thread logic is isolated, and use call_deferred
or Mutex
to push the result back to the main thread.
If the problem still occurs, the first two could be the subject of a Github issue because that’s a legit use case, I don’t see why you shouldnt be allowed to use threads here, despite the fact it’s the API of a node.
Another question I’d have, is why is it taking 100ms? This is quite a long time, is your navigation mesh really complex?
Navigation Node is not modified in any way. It’s used only to run get_ simple_ path() function.
To update BadGuy path I call this from a thread:
call_ deferred(“update_path”, newpath)
so it updates on the main thread with the data from thread.
I don’t know what you mean with “search algorithm”.
Map is pretty simple, but it takes over 100ms because I have to calculate path for not one but for many BadGuys.
Can a thread create a duplicate() of the Navigation Node to store it locally, to be 100% sure, that it did’t read anything from the active node tree?
P.S. Your height-map terrain plugin is awesome!
Skipperro | 2019-07-29 13:28
I guess you are then running all pathfindings in the same thread then?
What I mean by “search algorithm” is basically pathfinding, what the engine does.
Note that changing the position of navigation occluders could do modifications.
I’m not sure if Navigation still works if duplicated outside the tree… but IMO you should not need to do this, get_simple_path()
must be thread-safe because otherwise it becomes a hassle. You could reproduce this in a simple project to show your problem, and post a Gitgub issue explaining what you need.
Zylann | 2019-07-29 13:55
Yes, currently I’m running all pathfinding on one dedicated thread, but I’ve done many variants of this including one where each BadGuy started his own pathfinding thread. It was even worse, since by having more BadGuys than CPU cores it started to take computing power from the main thread and added overhead from the threads themselves.I couldn’t find the way to let only few of them calculate and force others to wait their turn. But this is other, design-related topic.
My current project is way to big for posting, but if I don’t find a solution I will recreate it on a small scale and post as issue.
Skipperro | 2019-07-29 14:12