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

Will there be a bundle with Apex path and Steer when the latter is released ?

Thanks

 

The path finder in Apex Path will certainly never issue a path that crosses over a dynamic obstacle, that would make no sense at all.
Of course paths get invalidated as dynamic obstacles move, and units will need to replan their paths.
We use what we like to call Dynamic Replanning, which means that only units affected by one or more dynamic obstacles will actually replan their path.

The interval between these replans can be controlled on the unit. Obviously the more replans the more stress on the path finder, so there is a limit. Depending on the grid size a typical path takes between 1 and 10 milliseconds to calculate, so 100 - 1000 paths per second.

Our solution is easily fast enough for your scenario. Our dynamic obstacles are fast and efficient, you can check out the advanced version, soon to hit the asset store, here.

We do not offer a free version, so you will have to rely on our descriptions and the testament of others (asset store).

 

There most likely will be, but when such a bundle will be available I cannot say at this stage.

Apex Steer has been slightly delayed and we expect a release by the end of January.

 

Ok, thanks

 

Hello,

thanks for your fast answer. This sounds really good. The update on the dynamic obstacle looks interesting i never though about predicting the grids in front of the unit. Im not sure, but this feature could probably improve pathfinding chaos with lot of units.

- I didn't find in your feature description any path smoothing/funnel modifier algorithms, do you have any? (If not, i would recommend you to implement this feature.)

- The Unity pathfinding itself doesn't provide (probably im wrong) an own steering AI. In my case i have to tell the vehicle to accelerate forward and turn left or right. In my case i have a physical based moving track-vehicle (e.g. tank), where i have to accelerate it, because if i would simply set the the speed on it, that would cause undefined behaviors...

Edited: I watched nearly all your videos, and i would assume, that i can implement my own turning and moving behavior with acceleration. I hope i don't have to exactly satisfy the desired speed for turning and moving to satisfy the local avoidance algorithm. The coding framework exists in comparism to another pathfinding solutions (i tried a lot of asset store solutions) and it looks clean, easy and well designed.

- One more question, can i define more grids on the same position, to have bigger nodes for bigger units? That means i have to assign units to a certain grid, and the affected nodes (for a dynamic obstacle) must be updated on all the grids. I need this for setting a smaller unwalkable margin for smaller units and bigger for bigger units. Do you have a better solution for this problem?

Thats all what i need, this pathfinding algorithm seems to be the right choice for me, and generally, it seems to be the most usefull solution in the Unity asset store.

Thanks for your answer in advance

 

We do have path smoothing. It is not required however, so it can be turned off for units if you want more robotic movement.
You can also turn off diagonal moves should you so please.
Finally you can easily override the default path smoothing algorithm.

Apex Path only includes basic steering, which means the steering necessary to follow a path, and basic unit avoidance.
We will release our next package, Apex Steer in the new year, which will provide more advanced steering based on vector fields. Apex Path will also have a major update released at the same time, an update that changes a lot with regards to how steering is performed at the base level.
Unless you have very specific requirements, the path steering is handled without you having to specifically do anything other than point it to where it needs to go.

Yes you can augment or completely override the way the actual locomotion is carried out. I would however recommend that you await the release of Apex Path 2.0 before implementing your own overrides, since it changes how steering works at its core.

This is a feature that we have yet to implement. Our own initial thought was to enable multiple co-located grids with different cell sizes. But that is not an optimal solution. The better solution is for the path finder to take the unit's size into consideration, however we are still working on this feature as it can cripple the performance if done wrong.
I expect we will have a solution ready soon after the release of Apex Path 2.0 in late January (current estimate).

 

Hello,

Im creating a number of grids at start using box colliders for size and position.

The pathing works fine if the point is on the current grid. However, if a point is chosen on a grid far away Apex doesnt calculate a path between grids. Am I initialising the grids incorrectly?

For each floor section (box collider) I run the following:
(please excuse hacky code)

Code (csharp):

1.  
2. IEnumerator InitializePathingGrid (BoxCollider collider){
3. //resetbool
4. initGrid = false;
5. float multiplier = 1/Level.GridSize;
6. GameObject gameWorldObject = GameObject.Find("Game World");
7. Apex.WorldGeometry.GridConfigcfg = newApex.WorldGeometry.GridConfig();
8. cfg.friendlyName = "Floor " + floorNumber.ToString() + " : " + collider.bounds.ToString();
9. introundUpX = (int)(Mathf.Ceil((float) (collider.bounds.size.x * 1.1f ) / 10) * 10);
10. introundUpZ = (int)(Mathf.Ceil((float) (collider.bounds.size.z * 1.1f ) / 10) * 10);
11. cfg.sizeX = (int) (roundUpX * multiplier);
12. cfg.sizeZ = (int) (roundUpZ * multiplier);
13. cfg.cellSize = Level.GridSize;
14. cfg.origin = newVector3 (collider.bounds.center.x, floorPos, collider.bounds.center.z);
15. cfg.generateHeightmap = false;
16. pathingGrid = Apex.WorldGeometry.GridComponent.Create(gameWorldObject, cfg);
17. pathingGrid.Initialize(8, (ignored) => initGrid = true);
18.  
19. while (initGrid == false){
20. Debug.Log ("Waiting for " + collider.transform.gameObject.name + " ...");
21. yield return null;
22. }
23. Debug.Log ("Done!");
24.  
25. initGrid = false;
26. }
27.  

Any help greatly appreciated

Rob

 

Apart from obstacle sensitivity range and subsections, which you might also want to set explicitly, the grid creation itself is fine.

However there are two ways by which unit can move from one grid to another.

The first is called off-grid navigation, which allows units to move in the space between grids.
The way this works is as follows:
The unit's path will consist of several segments. The first moves the unit off the first grid, the next moves the unit between the grids (off-grid) and the last moves the unit to its destination on the second grid.

Long story short. Off-grid navigation is only intended for use in scenarios where two or more grids exist with a large obstacle free area between then, e.g. a scene with two cities in each corner with the rest being desert.
If grids are adjacent or close to each other off-grid navigation will not work consistently.

The second and recommended option is to use connector portals.
Connect each grid to its counterpart using a GridPortal in connector mode using the PortalActionNone as the action.

Code (CSharp):

1.         GridPortalComponent.Create<PortalActionNoneComponent>(
2.             host,
3.             PortalType.Connector,
4.             gridOnePerimeterBounds,
5.             gridTwoPerimeterBounds);

where host is the game object on which the portal will be parented and the two bounds are the perimeters (or part thereof) of the two grids to connect.

When using portals, it is recommended to check the 'prevent off-grid navigation' on the unit's steer for path component.

I hope that helps, otherwise let us know.

 

Hi team. Thank you for your understandable tutorials.

by the way, I found probably a bug on Moving Platform scene.
I add a agent with navigation unity with selection quick starts.
in other words, 2 units exist on game ground.
then, units fly out of the platform and stop in the air.

look a image.
this state happened when I had arranged the orange unit on up riverbank and the green on down riverbank.
I had directed that the green go to up and the orange go to down.
and units fly out.

 

Ok thanks for reporting this, we will have a look at it.

 

Very helpful, thank you!

I'm assuming portals don't play nice with overlapping grids?

 

Thanks for your anwers!

This is a problem for me. An RTS game cannot work without that. I guess, i will check Apex Path 2.1 later. I don't understand why we need a better steering algorithm, in my case i use my own and i don't belive that you can satisfy my needs. I myself working on an error free/low and fast collision avoidance (independently of any pathfinding solution) since 3 weeks again, and i dropped away my old solution. This is something what is very special and complicated, and also complicated to setup (tank track, vehicle with wheel) for different situations.

It is interesting to see that the 2 most important pathfinding solution have very different approaches, you try to restrict and make the pathfinding more helpful for certain problems (for what i was looking at the beginning), the another one told me, i provide you with a stable/good/fast/optimized pathfindig solution and you can do what you want with, but have to reinvent the wheel again.

 

Overlapping grids are only supported when used to create different floors, e.g. the floors of a building, you cannot have overlapping grids at the same height, or you will see weird behaviour.

You can however use portals with overlapping grids, in fact using portals is the way to connect different floors.

 

It is true that writing a generic steering solution that fits the needs of all is practically impossible, however we strive to release a solution that is usable by many. After all most game devs would rather work on their core game instead of having to worry about vector fields and avoidance algorithms.

We try to offer default solutions to most problem areas while still keeping the API open such that pretty much anything can be overridden and replaced by your own logic.
So which parts do you feel are restrictive?

 

Hi,

I'm wondering how to visualize the path BEFORE actually moving a unit. I mean, i want to show the path and if i like it, then i click to move the unit. The path parameter of PathResult doesn't give the points, right? On Update i request a new path based on the mouse 3dWorld position. The Path visualizer script takes the path from the unit, so if i'm not moving the unit yet, how can i get the currentWaypoints of the calculated path?

Also, i have a little problem with the mecanim integration. I've set up a script similar to the tutorial one, to make my character move but without computing angles. The problem is when he arrives the destination point, he jump when stops. Some times forward, some times backwards. I assume this is to match the exact point, but it looks horrible. Any idea of how to prevent this?

Thanks a lot!!

 

Hello,

i don't have your pathfinding solution yet, but i saw your tutorial videos.

In my case, i have my pathfinding state-machine in the lowest level (find path, repath and not much more). Above is my steering state-machine (drive backward if the aim is behind the vehicle in a certain distance and angle (else, turn to the aim), slow down fast moving vehicles in curve (they must be able to follow the path), and more...). Above is then my collision avoidance state machine, which provides some attributes to influnce the behavior and provide also more avoidance solutions, and also prove the collision situation to decide what avoidance is the right one. On the top of this are then the special controller with certain AI purposes. Example: Get milk from fabric and transport it to the shop, but the shop unload area cannot be targetet by the pathfinding solution, there i have to create a fake path and add the points manually to the path. (Not that you think that im trying to influence your new steering solution )

I have to admit that the collision avoidance doesn't looks optimized, but it has a good stability. All what i use is, pathfinding with dynamic obstacle, just repath if necessary, and a collision avoidance but (no modern kind, i belive that they are not working with physical steering vehicles).

I know that i can override the locomotion behavior and the turning behavior, but im not sure that all what i described is possible in your solution.

 

Every single thing you described is possible .

 

You can easily request a path, process it and then ask the unit to move along it.

Simply issue a CallbackPathRequest and do whatever you need to do in the callback.

Code (CSharp):

1. Action<PathResult> callback = (result) =>
2. {
3.     //If a path was not found....
4.     if (result.status != PathingStatus.Complete)
5.     {
6.         return;
7.     }
8.  
9.     var path = result.path;
10.     if (DoesPathFitMyNeeds(path))
11.     {
12.         unit.MoveAlong(path);
13.     }
14. };
15.  
16. var req = new CallbackPathRequest(callback)
17. {
18.     ...
19. };
20.  
21. GameServices.pathService.QueueRequest(req);

Unfortunately the core problem here lies with mecanim, since transitions between moving and idle states may result in a unit going idle at a moment its right foot was raised (as an example) and hence the animation will 'jump'.

That being said, the problem is quite noticeable in the current version of Apex Path due to the way units slow down.
In the upcoming Apex Path 2.0 this changes and the transition from moving to idle will be smoother.

 

Thanks Germinior!

Great news! Any date for the release?

 

From your snippet, how can i get the vector3 of each wp? Before moving the unit?

 

Code (CSharp):

1. foreach(var p in path)
2. {
3.    var pos = p.position.
4. ...
5. }

or without alloc

Code (CSharp):

1. for(int i = 0; i < path.count; i++)
2. {
3.    var pos = path[i].position;
4. }

And just for clarity, in our terminology each element in a path is called a node whereas waypoints are what you use to define multiple path segments, e.g. shift + right mouse click with default input receiver.

 

Nice, thanks for clarify!

 

Christmas Break

Apex Game Tools will be taking a break for Christmas, but we will be back on the 5th of January 2015.

A merry Xmas and a happy New Year to all.

 

Hey, Hope you you guys had a great Christmas and new year! I'm beginning to push forward on a project and moving over to Unity 5 Beta. Running out of things to do other than implementing features that can't yet work in Unity 5. Was wondering if you guys have any ETA on supporting it (I know it's only beta but I figured best to keep up to date early on). Also I can't wait for Steering! =D It will be a no brainer purchase for me as soon as you guys bring it out.

 

Apex Path 2.0 will support Unity 5, and we expect to release that sometime within the next two weeks. In the mean time you could just let the API upgrade tool in Unity 5 do its thing. The only additional thing you would need to do is to run the UnityWrappers.tt to generate the wrappers in the context of Unity 5.

Apex Steer should follow closely after the release of Apex Path 2.0, so 2-3 weeks from now if everything goes to plan .

 

Awesome, looking forward to it. You guys are the backbone of my solo project.. I wouldn't be very far without the Apex system so looking forward to updates;

 

Is is possible to stop the unit using IMovable and recalculate a new path?

 

Well yes and no. The thing is that in the current version the Stop method resides on the IMovingObject interface, so you have to get a reference to that in exactly the same way you would get the IMovable reference.

This changes in Apex Path 2.0 soon to be released. In 2.0 all interfaces plus a few additional methods and properties are exposed via a single facade called the UnitFacade.

 

Hey,

I need a pathfinding AI for destructible world. Is the apex path tutorial avilable now? I can't find it on tutorials page of your website.

 

I am afraid we never got around to making that video, we have been hard at work on our steering package.

The way it works is fairly simple though. If you destroy or build new elements in a scene that will impact movement, you simply call a single function to update the affected area of the grid. This update is load balanced and will complete over a number of frames depending on the parameters passed to the function call.
Once the update is complete, meaning that the grid now knows about the changes, you will be notified via a call back.

Code (CSharp):

1. var grid = GridManager.instance.GetGrid(position);
2. grid.Update(area, allowedTimePerFrame, callback);

 

Hey Geminior! Just picked up your Dynamic Obstacles Add-On and got the following error (twice):

and

Thank you!!

-Steven

 

Our Advanced Dynamic Obstacles asset is an Add-on to Apex Path, so you need to make sure you import that first.

 

Haha, you don't say Geminior!?!

Yes of course I have the latest Apex Path installed and those are the errors I am receiving...

 

Ok I see, wrong conclusion on my part. The problem you are seeing is caused by the fact that Apex Path changed its file structure in version 1.2.5. You have to completely remove the earlier version of Apex Path before installing 1.2.5.

 

Thanks for replay

I have another question. How can I verify that the object has completed a path?

 

Units report when they arrive, have a look at this video to see the details.

 

Yea shoot now I'm getting a straight CTD with no information as to what is causing it...

...a new project install is fine apparently, so I'm not entirely sure how to approach fixing this...

Raargh

-Steven

 

Okay I managed to install both packages...

...in reverse. I installed Apex Dynamic Obstacles first, and THEN I installed Apex Path and Unity did not crash.

Is this okay or is the order of installation important? Stupid I know but again, this did work.

Thanks Geminior

 

Thanks I was looking for it on your Youtube channel, but I didn't find it. I'am really pleased that you sent this link because it helps much. But I would like to ask about how to find a nearest node in graph when the transform.position is out of them?

 

Ok that sounds odd. The install order is not important, only if you install the Dynamic Obstacles first Unity will complain that it cannot compile for obvious reasons, but installing Apex Path after will fix it.

So yeah either way should work.

 

I am afraid I don't quite understand your question, can you elaborate?

 

In my level, Some of the enemies have a Dynamic Obstacle Component. Main character is calculate a path to the nearest enemy. When path is reached, character is start playing animation.

When the enemy is walking, he is blocking some parts of navmesh grid. In the moment when main character is calculate a path I get in the Debug Console: "StoppedDestinationBlocked", because I get the transform.position of the enemy which is busy in the graph.

To sum up, I seek the nearest point to point which don't belong to grid.

 

Looking forward to this. I ended up pulling Apex out of my project because while I liked it I also felt the integration was a bit messy with all the interfaces I needed to implement and components to manage just for my fairly modest but specific pathfinding requirements. However my pathfinding needs are getting more complex so I was thinking of giving Apex another shot and I'll wait for 2.0 if it simplifies things.

 

Ok, well let me start by saying that using Dynamic Obstacles on enemy units is not really the intended usage, at least not if it is done to solve a steering problem such as avoidance.

Now the behaviour you are seeing is the default behaviour of units when their path is blocked or the destination is otherwise inaccessible. The unit simply stops.
There are a number of ways to change the default behaviour. The simplest is to check the check box labelled 'Navigate to Nearest if Blocked' located on the SteerForPath component in the current version (1.2.5).
This will basically move the unit as close as it can get to the intended destination if the actual destination is blocked.

A more advanced approach, which allows you to have full control, is to implement a result processor, there is a video explaining that here.

For the purpose of finding specific cells in the grid, the grid itself has numerous methods to get specific cells or a selection of cells. One of these is called GetNearestWalkableCell. This is an extension method so you need to ensure you have a 'using Apex.WorldGeometry' statement in your code file.

 

We do have a lot of components for sure, and that will still be true in 2.0.
While we do want our product to be easy to use, we also want them to be highly configurable and extensible, and that is a bit of a balancing act.
But yes parts of the API that was kinda clunky before, has been streamlined in 2.0, so you don't have to worry about what interface this or that method belongs to.

 

Thanks, It was helpful

 

Dear experienced users or author:

I'm considering using this package for my multiplayer RTS game that is built on a deterministic lockstep system. From the example and demos I've seen, it looks very promising. I have a question about a possible feature that I need for my game.

Is your system synchronous and deterministic? Not regarding floating point imprecision, can your navigation system find the same path and get there the same way multiple times? This means that units would have to calculate the same paths given the same circumstances and do something with the paths at the same times over multiple trials and computers. If by default it cannot, can this be implemented and how?

Note: My game runs at 10 fixed frames per second and users will often only have 1 to 2 fixed frames to calculate paths before any lag masking measures have to be taken. Thus, units will have at least 100 milliseconds to prepare for movement then synchronously move on a given frame.

 

The path finding in Apex Path is an asynchronous operation. You issue a path request and you will then get the result by way of a callback, once the path finder has completed its task.

The path finder is deterministic, there are no random elements.

With regards to the time needed by the path finder, this of course depends on the length of the path. The longer the path, the longer the path finder will use.But since it is an sync operation which by default runs in a separate thread, it does not impact the frame rate.
Unless you have a very large complex map, you will not need more than 100 ms for any path request, just be sure to use the Jump Point Search algorithm instead of the basic A*.

 

Oh, thanks a lot for the information. I have one other question. Is Apex Steering going to be an add-on or a separate asset? I don't need any pathfinding for my game but the steering and crowd control is very important.

 

Apex Steer is an add-on to Apex Path. Not that the path finding itself is required to take place in Apex Path, but the steering foundation is part of Apex Path.