My computer has 4 physical cores, but uses hyperthreading for a total of 8. As you can see in the graph, I can manage to get it to run as much as 3.75 times faster than with a single thread! The speedup is linear at the start, but gets smaller when the number of threads increase above the number of physical cores. Memory usage increases linearly at about 2mb per added thread (for the 200*200 grid graph I’m testing on).

The only major drawback that I can see is that it will be slower to update the graphs. When a graph is updated, pathfinding must not be searching the graph at the same time, that could lead to weird errors. When not using multithreading, the function can simply update the graph (if needed) between calculating paths. Almost as easy when using a single thread, but then it must stop for a bit to let the Unity thread update the graphs since many things such as raycasting must be called from the main Unity thread. When using more than one thread, every thread must finish calculating the current path they are calculating, stop and then notify the unity thread that it can proceed with updating the graphs. This can lead to a decrease in performance because the threads spend much time idling. One way to solve this is to group graph updates together in chunks for example every 0.2 or 0.5 seconds to avoid stopping the threads too often when updating the graph a lot.

Anyway, I’m happy with the transition. I could also simplify many functions to use more advanced atomic operations instead of custom written lockless queues and stuff. When I get around to rewriting the GraphUpdateObject system for this I can also make sure it does not block the unity thread waiting for the pathfinding threads to stop, but it simply notifies the pathfinding threads that they should pause. And when they have, the unity thread, some frames later, can update the graphs. The previous approach could lead to lag when updating graphs if the pathfinding thread was calculating a really long path.

I’m a bit concerned for the mobile development though with the increased memory usage. It is not really much though. I built two tests, one with the original code (similar to latest release) and one with the new code. Both using a 200*200 grid graph. The new code used 6mb according to GC, and the old code used about 5 mb (I only had 1mb precision). But what’s interesting is that the old code had about 1.5 mb allocation per second, but the new code allocated practically nothing (0.0 to 0.1). I don’t know if that is something relevant, or if it just is GC acting odd. But it was repeatable at least. With 4 threads it peaked at 13mb, though it started at 8 or something. I don’t know much about C# internal memory management, so I usually just measure the peak allocated memory after 20 seconds or so when it has stabilized.

I have tried to implement that at least 3 times, every time I have got results which I haven’t been totally happy with. So today I decided to brush up some old scripts and see if I could make them better. Turns out it was quite easy to get them working and generate good looking graphs.

Here’s a demo video:

Click here to view the video on YouTube.

Hopefully this feature will make it to the 3.1 release of the A* Pathfinding Project.

I got some stuff to implement before it is finished though:

• Funnel algorithm support
• Graph update support
• Linecasting (maybe I will skip that though)
• Erosion

The background is that, even though it in the Unity docs appears to be supported, the System.Guid class isn’t supported on IOS. The A* Pathfinding Project uses that class for saving an ID for each graph.

In all graphs there is a variable initialized to new Guid () (in the base.cs script). This will, since it is not supported, crash the application.

For 3.1 I will write a replacement class for the Guid class, until then, here are two different workarounds.

Option one: In the player settings (Project Settings -> Player Settings) there is an option to catch all exceptions or crash on exceptions (the crash option yields faster applications).  If you set it to catch all exceptions, I think it will run ok.

Option 2: One variable almost at the top of the base.cs script is initialized to new Guid (). You can comment out that variable (it’s obsolete anyway). And it will hopefully not crash again.

Note that you will not be able to create new graphs during runtime even with these changes applied, that will create a new Guid and crash the application.

Hope it will work for all of you

Ways to improve it would probably be to tag the elevator nodes with certain tags which tell the AI to stop at the first one and then wait for it to move to the next instead of trying to walk towards it. That would free the elevator script from having to lock the AI from moving. It would be better in that the current system can fail if the AI walks too fast.

Here’s a video of what it looks like at the moment. Oh, and also, I have written a new AI script which has much better movement behavior than the previous AIFollow script, the one in the video is the new script, a bit modified to be able to animate the legs of the robot properly and to create a particle effect when it reaches the end of the path.

Click here to view the video on YouTube.

I’ve been working on some stuff recently for the upcoming A* Pathfinding Project 3.1 release. Many of you have probably been a bit annoyed by the amount of work needed to change tiny details in the graph, for example making some nodes unwalkable. Well, that problem is soon over.
I have created a new script which is called GraphUpdateScene. It collects a number of useful changes you might want to do to a graph such as, as mentioned before, making some nodes unwalkable, or perhaps adding a high penalty to an area (making the area harder to traverse, so units will avoid it).
You can even set the tags of the nodes, which is another new feature I have developed. It is used to define which units can walk on what ground.
Imagine for example that you have some critters, a player and some AIs in your world. Both the AIs and the critters pathfind randomly around in the world but you wouldn’t want the critters to enter houses (they make such a mess). Then tagging is a great way to solve it. If you tag all indoor areas with a tag named for example “Indoors” and make sure no critters can walk on those nodes, that would be it!
Oh, and did I mention that you are no longer restricted to axis-aligned rectangular areas, you can use any polygon shape you want!

Anyway, it’s tedious to describe stuff using text, so here’s a video for you showing both of these features:

Click here to view the video on YouTube.

The major feature for this version is the beta of the Local Avoidance which I have been working on, it is included in the Pro version of the system. If you haven’t seen it, check out this video on youtube!
Great news for those of you who have the free version is that you can now save graphs to files, including nodes!

As many of you probably have seen, the developer preview of Unity 3.5 (with built-in pathfinding), was released a few days ago.
What this means for the continuing development of this project is not certain yet, but I will not likely stop all development.
The Unity pathfinder has a number of advantages, and a number of drawbacks compared to my system, I haven’t been able to explore it very much though since it only seems to be available for Unity Pro users (which is the first drawback), I cannot edit any pathfinding settings anyway.
First of all, the Unity pathfinder has only support for navmeshes, not grid graphs or list (point) graphs. This is probably the feature most people will miss with the Unity pathfinder, especially makers of TD and RTS games as grid graphs are the primary choice among them. It doesn’t seem very expandable from what I can see in the docs, I haven’t even found a class for nodes. On the advantage side though, can be mentioned that it does have more advanced local avoidance (from recast, mine is still under development, but it’s getting there), and better support for off-mesh links, and also it seems to have support for partial paths (something I have chosen not to implement since paths are returned within a few milliseconds anyway). It does not seem to use time splicing (i.e calculating over multiple frames) as there is a function in the docs which returns paths instantly, this does in turn mean that it is not multithreaded (except for the generating of the navmesh, which can be run async), but I can be wrong about that.
The path layers they are using for the bridge and door scenes in the examples is another difference, however I have an early implementation of it in 3.0.8 (check out the “Door” scene which is included, only for pro users though as it is based on a recast graph, but the functionality is present in the free version as well, check out the DoorController.cs script in the example scripts folder).

Please comment if I have got something wrong about the unity pathfinder.

Now go ahead and download the latest version: http://arongranberg.com/unity/a-pathfinding/download/
Changelog can be found here

As an extra christmas present, I will give you a 10% discount until the 1st of January on the Pro version!
Just use the promo-code: Christmas2011

Merry Christmas!

-Aron Granberg

Check it out here: http://www.arongranberg.com/forums/forum/pathfinding-project/

Worth to note is that the agents don’t use any physics for collision, collision avoidance is purely done by the local avoidance.

Click here to view the video on YouTube.