Aron Granberg
|
Graph updates are not that heavy. But it depends on which type of graph, and what settings on the Graph Update Object you are using. Firstly, do you need updatePhysics, if you are just updating penalty you can set it to false to save processing power (I haven’t timed it, but I think it would use the bulk of the time required).
Also, every time a graph update object is called it needs to pause pathfinding, something which can cause a bit of lag if you use it really often when using multithreading (need for lock statements). Therefore I have included the ability to limit graph updates to only a certain amount of times per second. Go to the A* Inspector –> Settings and you will see it.
The best way, is to first call update graphs for all units, then call their paths, it shouldn’t affect much, but as I have built the system, why not give you every advice I have.
|
msleeper
|
Thanks for your reply Aron. I’ve tried doing basically what you said at the end, updating the graph for all of the units once rather than having them update individually. There is still a very slight delay, I will try disabling UpdatePhysics since it is not needed.
A question about the graph limit rate – what happens when pathfinding is waiting for that delay? Say I set it to 5 seconds, will my script wait until it’s allowed to update the graph or will it use whatever graph information is already stored?
Thanks again!
|
Aron Granberg
|
The Graph Update Objects will be put in a queue and processed when the delay has elapsed (i.e there has been a longer delay since the last graph update than the minimum delay specified in the settings).
So paths processed in between will use the old data.
|
Aron Granberg
|
5 seconds sounds a bit much btw, 0.2 or something is more practical since you will probably not notice the delay, and it can still group updates together to improve performance. (note that non-multithreaded is barely affected by this performance boost, only the multithreaded, as its actually stopping multithreading from slowing things down rather than boosting the speed).
|
Aron Granberg
|
How large areas are you updating? And how large is this lag exactly?
|
msleeper
|
The “5 second delay” was just hypothetical, I’d never set it that high in a real environment, haha.
I don’t have my project in front of me, I can get specifics if you need them. But definitely on the large end – the game world is a flat 1024×1024 terrain, and my units that are moving around are only 3-5 units in size. It’s an RTS style game, so I’ve had to set the graph to be fine so they can navigate between user placed structures.
|
Aron Granberg
|
Hm, and about how many units are you calling this for at the same time?
|
msleeper
|
Even just doing 1, there seems to be a noticeable but short lag spike when it calculates a path with penalties, as opposed to one without. I’m about to do some testing, I’ll see if I can get some exact information on penalty delays I’m seeing.
|
Aron Granberg
|
It just struck me, you said you were using a 1024*1024 graph, right?
Then the part taking such a long time is definitely the flood fill, it is done once per graph update chunk (i.e a group of graph updates processed at one time). On a 1024*1024 graph it could take some time… So I’m implementing a way to bypass that check. In the next version, you will be able to set a parameter on the GUO specifying if it will change graph connections, tags or walkability (I cannot make it fully automatic since users may create overridden types). If it doesn’t (such as when only updating penalty), you can set it to false and no flood fill will be done.
If you want to disable flood fill without waiting for me to update the project. You can comment out the line which says “FloodFill ();” at the end of the DoUpdateGraphs function in AstarPath.cs.
|
