Apex Path v2.0 [RELEASED] - High Performance, Easy to use dynamic Pathfinding

I'm curious about what sized grid apex path currently supports with decent performance? I'm interested in using in for something such as an rts game with random maps where I don't think I can get away with using multiple grids with portals. I've actually written my own hierarchical pathfinder (for XNA) and I'm trying to decide if its worth porting it across or use another solution such as apex path which looks promising.

Also regarding the current steering implementation, I realize that there are only basic steering behaviors so far, but do you currently provide proximity data about neighboring agents so I could write my own complex behaviors?

 

It is difficult to give you an exact number since it depends on the platform / device, how many units are requesting paths at the same time etc.

But in practice you will not hit a performance boundary with the path finding. What limits the grid size is the initialization time and memory consumption of the height map. Depending on the required granularity, a size of 200 x 200 to 500 x 500 with a cell size of 2 is probably where the grey zone starts.

 

v 1.2.1 Patch 1 Released
New Features:

• The GridManager now has methods to get references to GridComponents given a position or bounds struct.
• A new message 'GridStatusMessage' is sent when grids do runtime initialization or are disabled.
• New factory methods enable runtime instantiation of grids and portals
• The GetCell method on IGrid now has an overload that allows to adjust the position to the grid bounds, i.e. find the closest cell on the grid if the position is outside the grid.

Breaking Changes:

• The Disable method on the GridComponent now requires an argument specifying the maximum milliseconds to use per frame. This is related to the changes/fixes below.
• IMoveCost signature changed. Unlikely to affect anyone, but a breaking change nonetheless.
• IPortalAction's GetActionCost now takes a IMoveCost argument to allow for better cost calculations.

Bug Fixes:

• Windows Store App and WP8 Apps no longer throw exceptions on compilation.
• The editor for attributed components no longer fails if no attribute set is defined.
• Portals now respond to grids being initialized / disabled at runtime and no longer cause exceptions when placed on grids where automatic initialization is turned off.
• Dynamic obstacles now have an option to support dynamic grids, i.e. initialization / disabling at runtime. Set this to true if you initialize / disable grids at runtime.
• The callback argument in the Initialize method on the GridComponent can now be null if you don't require a callback.
• Basic avoidance will no longer throw an exception if a unit being avoided, is destroyed

Improvements:

• The 'Navigate to Nearest if Blocked' setting now also applies to actual blocked cells.
• Changed the Mac Support of the default input receiver. It now has a 'Right Click Supported' property instead. If your Mac is not set up for right click support, uncheck that option.
• Grids not set to automatic initialization are now drawn semi transparent.
• Movement across stitched together grids is now smoother.

Known issue: The dynamic obstacles in the wander performance example scene do not block as they should.
This is due to them being spawned outside the grid. If you wish to fix this, you can simply set the grid's upper boundary to 30 instead of 10.


The Apex Team
www.apexgametools.com
Apex Path Q & A
Support forums

Follow us and get all our news, updates, tutorials, etc.

 

I updated to the version 1.2.1, and i found in the scene' Flee DynamicObstacle', there is a very serious problem.
I even opened 'supportDynamicGrids' option of the ExampleDynamicObstacle prefab , still can not see the effect of the previous version?Agents like a fool is ExampleDynamicObstacle Cube beating, instead of taking shelter, there is no path, I have opened 'supportDynamicGrids' option of the ExampleDynamicObstacle prefab. No Patch,No AI????
What I have done wrong? Or do you have the latest version of the problem?

Looking forward to your reply

 

Its just an example, but yes since 1.2.1 introduced a different mechanic for dynamic obstacles, it broke two examples.
Just adjust the upper boundary of the grid to 30 and it will work just like is used to.

The problem is that dynamic obstacles spawned outside the grid, will simply not initialize, since they assume they are on an inactive grid that has yet to initialize.

 

For no particular reason we chose to comment out part of the Win8 app fix in 1.2.1.
So if you are experiencing compile errors when building for win8 app or wp8, then please uncomment the following line in PathService.cs

Code (CSharp):

1. #if NETFX_CORE
2.     //using Windows.System.Threading;
3. #endif

 

I followed the quick start tutorial on Youtube. I made a terrain a unit, and assigned the layers to the gameWorld. I'm able to draw a marquee but my unit won't select and won't move.

 

Hello,
I have a small question about that product. Is it possible to use that on a 4x4 km real world based terrain for detailed pathfinding on a whole map ? Is it even possible to bake so big grid to cover this area ?

Thanks
M.

 

v 1.2.2 Patch 2 / Minor feature release

New Features:

• ISteerable now has a finalDestination property
• A new request type CallbackPathRequest was added. This allows for interaction with the path finder without having to implement INeedPath
• All request types now have a 'type' property. Currently two types are available, Normal and IntelOnly, the latter being an optimization for AI use.
• SteerForPathComponent now implements IInjectPathFinderOptions which allows for having custom requests injected with the path finder options assigned to a unit
• Path results now include a 'pathCost' property which represents the length of the path and the cost of its individual nodes.
• Paths are now represented by the Path class. It derives from the StackWithLookAhead and thusly is not a breaking change. It is simply more clear and adds some additional possibilities, e.g IMovable.MoveAlong(...).
• A SimpleQueue was added to data structures
• A new Example scene 'Item Pickup' was added, showing some of the new features.
  

Breaking Changes:

• RepetableAction is now correctly named RepeatableAction. Simply search and replace.
• The ManualPath and the matching IMovable.MoveAlong method felt clumsy and have been deprecated. Instead use the new Path class and the matching IMovable.MoveAlong methods.
• Cleaned up the IPathService interface to only expose methods intended for use outside the framework. Not likely to affect you.
• Cleaned up the IPathRequest and its implementation. Not likely to affect you.

Improvements:

• StackWithLookAhead now has an indexer and implements IIndexable
• The currentPath and currentWaypoints properties of ISteerable are now indexable
• Connector portals now produce smoother paths (even more so than 1.2.1)
• Shortcut portals covering multiple cells will now correctly choose entry and exits points that result in the shortest path.
• IUnit now also implements IHaveAttributes

Bug Fixes:

• Windows Store App and WP8 Apps no longer throw exceptions on compilation, for real this time.
• Fixed a nasty bug where units would increase their speed in certain scenarios, especially obvious when issuing manual paths.
• Two examples that broke in patch 1 are now back in operation.
• The path finder and path smoother, now properly respects the custom cost of individual grid cells.

The Apex Team
www.apexgametools.com
Apex Path Q & A
Support forums

Follow us and get all our news, updates, tutorials, etc.

 

And still no Dynamic Waypoint?

 

First of all, sorry for the late response, for some reason we missed a few entries here. But since you have since posted a few things on the forum, I assume you already found a solution?

 

First of all, sorry for the late response, for some reason we missed a few entries here.

One big grid would not work, it would use too much memory, too long to path find etc.
However grids can be sticthed together and initialized dynamically so it is definitely possible to create large worlds.

You mention baking. There is no requirement to bake grids, it is a possibility that can improve performance in scenarios where all terrain / level geometry is defined at design time.

 

I am assuming you mean Point Graphs, so I am afraid nothing has changed there.
Our solution is grid based, and we have no current plans of introducing Point Graphs.

 

Alright, I'm having odd behaviour when baking a grid.

I set up my grid and everything looks groovy - cells show as pathable or blocked as expected while I'm playing around with values.

However, when I hit either bake or play, the blocked cell detection seems to jump up about 6 feet into the air. They both detect and display in the wrong spot, as in the included image.

That's with an Upper Boundary setting on the Grid Component set to 5. If I set that to a smaller number such as 1 it seems to work as intended. Playing around with it, the boundary value is 2... if I set the value to 2 or less, it does what I expect. If I set it to 2.01 or more the blocked cells jump 2 meters off the ground.

Have I missed something?

 

The upper and lower boundaries basically control what is considered to be inside the grid, and when ray casting for obstacles at start-up the rays are cast from the upper boundary to the lower boundary.

Cells at any given spot have a height (y-position) matching the highest terrain element at that position, and the grid visualizer draws the 'blocked indicator' at the height of the cell.

So I assume that your air plane is in the terrain layer, and therefore it draws those cells as blocked since they are inaccessible from all directions.

I do agree that it looks weird having those red squares in the air, but that is where the cells are, and we have yet to find a better way to visualize it.

I hope that makes sense, otherwise let me know.

 

Yeah, that makes sense and it also makes me realise that I showed an image of the least helpful spot in the room - all of the blocked areas were showing at that height, including stuff not actually at that height. All of my terrain is at floor height, all of the objects in that room are marked as blocks.

I'm just booting up to check now, but I'm pretty sure that the actual issue is that I've got a trigger collider in there and I bet I accidentally turned it onto the wrong layer at some point... in which case, oops!

Edit: Yep, that was the issue. I'd accidentally moved a trigger into the terrain layer.

So, here's another question. I might change how I'm doing this*, but at the moment I'm hiding objects in my scene by moving them to a layer that's not included in my camera's mask. Can you think of a way to make this concept play nicely with Apex Path?

* I'll ideally enable and disable renderers, provide fade in/out effects, etc. but since I'm still prototyping I've taken the least-effort route and am a fair way from needing more.

 

Do you mean that you will be hiding static obstacles at runtime?

In that case what you would want to do is to call Update(bounds) on the grid, to update the area where stuff was hidden.

Code (CSharp):

1. var grid = GridManager.instance.GetGrid(positionOfObject);
2. grid.Update(boundsToUpdate, 4);

 

I want to hide them (no longer render them), but stuff off-screen should still take them into account when doing pathfinding. My question would have been better worded as "will changing the layers of things mess with the pathing system, and if so do you have any suggestions?"

I *think* I've solved it, though. I'm making a top-down game in a multi-floor building, so I want to hide the floors above the player and didn't want to spend time making a complex system that tracks what is enabling/disabling what renderers. However, I've whipped up a super simple solution that should work for my prototype and am going to call it done for now.

Thumbs up for the fast responses, by the way!

 

Ok good you found a solution. But just for good measure let me answer your question.

Since the static obstacle layers are only used when the grid is initialized or when Update(bounds) is explicitly called, changing the layer of an obstacle, after grid initialization, will work ok. That is provided the grid is not reinitialized / Update()'ed, but I assume you will not be doing that on hidden floors anyway.

But one way to make it work even with reinitialization / runtime updating, is to have a separate 'hide' layer for static obstacles, and then map both on the Layer Mapping Component on the game world.

So you would need two hide layers, one for obstacles and one for everything else.

 

I suspected that was the case, but didn't want to assume it just in case something elsewhere in the system also relied on the layers.

I did think about extending my previous layer-based solution, good to know your system has the flexibility to support that.

 

Thanks for the reply.

 

Hello,

Quick question : is it possible to rotate a grid graph? I have an isometric layout so everything is at 45 degrees. (for technical reasons the world must be rotated, not the camera)

Cheers

Rob

 

Great package,

A quick question:

If I have a scene like the example MultiStoryGeometry and would like my character to crawl up the stairs instead of walking. How to best do something like this.

Cheers.

 

I am afraid that is not currently possible, the grid is married to the world xz plane.

It is a feature we have in our back log, but it isn't exactly a trivial thing to do, so I cannot say when or even if it will be implemented.

 

One way to do it is to add trigger colliders at points where you want your character to change its movement animation and/or speed.

 

Is it necessary that the 'terrain' be a single gameObject, or can it be made up of many gameObjects that visually form a cohesive 'terrain' (think building with Lego)

Thank you!

-Steven

 

Hi, I'm getting two very strange behavior.

1. Often times the ray tracing doesn't work correctly, I have to click on/off the agent a few times in order to make it go to where I want it to go.
2. I tried making the 3rd level using the multi-level example. Copied the stair case and setup everything as in the first and 2nd level. The Gravity switch doesn't seem to work with this copied staircase.

Here's a video.

https://dl.dropboxusercontent.com/u/48378123/ApexMultiLevelProblems.mp4

 

The terrain can be made up from any number of building blocks. The terrain is simply identified by being in the layer(s) mapped as being terrain.

 

That sounds peculiar, and I am afraid it is not something I can reproduce. Is this something you are seeing in general or just in your scene?
Perhaps you can post a small project to allow us to reproduce it, if so post it to our support(at)apexgametools.com.

The Gravity Switch is just a simple behaviour, so it needs a little help to function. You have to adjust the gravity height on it so that it knows when to switch it on. A value of 8 should work, basically just needs to be a y-value in between the two floors.

 

Wonderful!

Thanks Gemi!

-Steven

 

Hi,
I updated Apex Path.
Then, the following error message was displayed. How can I correct it?

Assets/Apex Path/Apex/Editor/MenuExtentions.cs(25,29): error CS0246: The type or namespace name `GameWorldQuickStart' could not be found. Are you missing a using directive or an assembly reference?​

Thanks.

 

Are you using ProBuilder?
Try to reimport the Apex Path package.

 

Thank you for the answer.
Yes, I began to use ProBuilder recently.
I did a deletion and re-import of Apex Path as your advice showed.
Then, the error was not displayed.
I wish to express my gratitude for your quick advice.

 

Hello, after updating from 1.1, apex path stopped working on my project. I have a prefab with grid component and I instantiate it everytime game level changes, set grid size and origin, then call Initialize. On apex 1.2. when I look at the editor with grid visualizer turned on after instantiating the prefab, the grid looks "empty"(no blues or reds or cell outlines) and I just see the outline of the grid component. Could you help me with this?

 

The grid visualizer was changed to only display the detailed gizmos when zoomed in a certain amount.
The reason is that drawing tons of gizmos can completely shut down the editor.

You can change the range you need to be zoomed in using the 'Draw Distance Threshold' on the Grid Visualizer.

 

Thanks but it wasn't gizmo problem. But using GridComponent.Create() to add RuntimeGridComponent rather than adding the GridComponent component to prefab itself seems to have fixed the problem.

 

Ok that sounds odd. It really does sound like it's a visualizer problem, was the visualizer on the same prefab or did it have its Draw All Grids set to true?
I will have a look to see if I can reproduce it.

 

Yes, the visualizer was on the same prefab/gameobject but I don't remember if it was set to Draw All Grids(Though, it must had been since I've tried everything on the inspector).

 

Is there an easy way to get the status and the result of a path request sent to pathservice queque? Status like the request has been processed or not, and the result like if the path was reachable or not. And also is there a method to immediately check if a certain path(from a to b) on a grid is reachable or not?

 

Currently there is no way to query a request sent to the path service to see its status, e.g. if it is waiting to be processed.
But basically if you haven't received a result you can assume that it is waiting, once it is being processed it will be so fast that it wouldn't really make sense to have a 'being processed' status.

With regards to issuing manual path request, you have a few options. The original option of implementing the INeedPath interface is shown in this video.

In the latest version we also added a new option, the CallbackRequest that enables you to issue a request directly and get the result back in a callback. I will show how this is done below.
However since the path finder runs in a separate thread by default, you do not get the result back synchronously. The result is returned in the callback once the path finder has processed the request.
The callback is also invoked on the path finder thread (since it is the one doing it) and unfortunately Unity does not provide a way to marshal a call back onto the main thread, which makes the implementation more complicated than we would have liked.

We will try to come up with an easier way, and we may even add a synchronous option.
Of course you may opt to simply run the path finder on the main thread, in which case all of this goes away, but at the cost of using frame time for path finding.

And so for the example:

Code (CSharp):

1.  
2. private readonly object _lock = new object();
3. private PathResult _pendingResult;
4.  
5. private void CheckPath(Vector3 from, Vector3 to)
6. {
7.     //The result callback for use with our path request
8.     Action<PathResult> callback = (result) =>
9.     {
10.         //Since the request was issued as Intel only the result will not actually contain a path but only
11.         //contain the status and the cost (length + arbitrary cost) of the path
12.         if(result.status != PathingStatus.Complete)
13.         {
14.             return;
15.         }
16.      
17.         //It is vital to note that since the path finder operates on a separate thread (be default),
18.         //the callback is also executed on that thread.
19.         //This means that two things. First of all you are cannot call various Unity methods here since they require the Main thread.
20.         //Second, and equally important, you do not want the path finder thread to carry out all sorts of other logic, so just assign the result
21.         //to a variable and then process it somewhere else, e.g. in the update method, a coroutine or a loadbalanced action.
22.         lock(_lock)
23.         {
24.             _pendingResult = result;
25.         }
26.     };
27.  
28.     //The request
29.     var req = new CallbackPathRequest(unitRadius, callback)
30.     {
31.         from = from,
32.         to = to,
33.         type = RequestType.IntelOnly
34.     };
35.  
36.     GameServices.pathService.QueueRequest(req);
37. }
38.  
39. private void Update()
40. {
41.     PathResult result;
42.     lock(_lock)
43.     {
44.         result = _pendingResult;
45.         _pendingResult = null;
46.     }
47.  
48.     if(result != null)
49.     {
50.         Debug.Log("A path was found with a cost of " + result.pathCost);
51.     }
52. }

You can see another example of this request in the 'Item Pickup' scene in the example project and the supporting scripts found in the Apex Examples/Scripts/Steering folder.

 

Thanks for the response

I've modified the default SteerForPath component to expose the result from path request( which probably isn't recommended). Well...whether the request is processed in one frame or two, I still need to check the status for scripts to properly work. On the other hand, the Callback request sounds really nice even though the said difficulty. Looking forward to seeing more of those updates! Now off to learn from examples

 

What is the best way to make agents treat other agents as obstacles?

I have several agents wandering through a set of narrow hallways, and they frequently run into each other and get stuck.
I would normally fix this by making each agent a dynamic obstacle, but Apex Path doesn't seem to have anything to make agents ignore dynamic obstacle scripts attached to themselves.

I'm aware that you guys don't support perception yet, but it seems like having some options for ignoring specific obstacles (particularly self obstacles) when pathfinding should fall firmly within the realm of reasonable.

 

As you are aware, what you are seeking is in the realm of steering, and it is something we will handle in the upcoming Apex Steer package.
It is not intended and hence not recommended to assign navigating units to be dynamic obstacles, it will cause all sorts of problems, constant replanning, self avoidance etc. to name a few.
The local avoidance component is meant for unit avoidance, but it is rather basic and hence it will not suffice to sort out any sort of advanced situations.

What you should do is implement some custom steering (or wait for Apex Steer). But narrow hallway steering is not trivial since it involves queueing or maybe even complete avoidance, i.e. find a path a round a congested hallway instead, and is best solved using density fields.

 

Is there a way to rescan GridComponent grids(also changing grid size/boundary) on the fly or do you simply Destroy the old one and make a new one?

 

You could do a Reset or Disable, followed by setting new values, followed by Initialize.
But whether you do that or go with a Destroy, Create instead is down to personal taste; allocation wise they should be practically identical.

 

I see. I was doing "Destroy and Create" but wanted to make sure if I'm not doing something wrong. Also I didn't know grids can be initialized again. Thanks!

 

I've just purchased Apex Path, and unfortunately it's full of compiler errors (using Unity Pro 4.5.5f1). Most of them are related to Unity not allowing default values to be set for variables when defining a function, but I also got a " type or namespace name 'Common' does not exist in the namespace 'Apex' " error. Is there a way to fix these?

 

While we have not tested Apex Path on Unity 4.5.5, I kinda doubt that it would introduce such errors.
I will upgrade to 4.5.5 later and see if I get any and then get back to you.

What platform are you compiling for?

Update: I have tested against Unity 4.5.5 but have not been able to reproduce what you are describing. Please send an email to support(at)apexgametools.com describing the problem in more detail.

 

I did a little digging since then. For anyone encountering the same issue: you need to set all your assemblies to target the .Net 4.0 framework (Project > Assembly-CSharp options). The issue I described happens when targeting .Net 3.5 .

Thanks for the quick response!

 

Are you referring to MonoDevelop settings? It sounds quite strange since it should use the Unity 3.5 .net assemblies.
We do not use MonoDevelop so I am unfamiliar with its setup.