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

I'm turning my player by triggering an animation (like this

).
It plays the turn animation if the destination angle is greater than 90 degrees when walking/running or 45 when at idle.

Is there a correct way to pause Apex path during the turn animation? (Ideally this would be a on 'per frame' basis rather than asking it to wait for X time)

Cheers

Rob

 

I assume that you are triggering this animation in addition to the standard locomotion and turn logic of Apex Path?

If so what you likely want to do is override these defaults of Apex Path.
In the current version this is done as explained here and here.

We will be releasing a tutorial very soon, that shows how you can control mecanim characters in Apex Path using root motion.

Finally I should point out that the way locomotion and especially turning is implemented will change in the Apex Path update that will come in preparation of the release of Apex Steer. However this is still a month or two away.

 

Hi,

What is exactly the 'Off grid navigation'?

 

Off grid navigation simply mean the ability to move outside a grid.

Lets say you have a fairly large scene with a building on each corner, where the terrain between the buildings is obstacle free.
You can then choose to only have grids where the buildings are (where actual path finding is needed) and leave the rest of the terrain without a grid.

Off grid navigation then refers to the ability of units to move from a grid onto an area where no grid exists and potentially onto another grid.
Off grid navigation obviously does not have any path finding so only use this for parts where path finding is not needed.

I hope that makes sense.

 

Ok. Makes sense.
I suppose there is no avoidance obstacle detection in the 'Off grid'?

 

Correct since obstacles need the grid to actually be seen as obstacles. Since Apex Path does not include obstacle avoidance as a steering behaviour.

It should be noted that Off grid navigation is a rather exotic feature and in most cases you will get better results using portals and setting the 'Prevent Off grid Navigation' on the units.

 

Thank for the reply Geminior.

 

New Release 1.2.3
Contains 5 New Features, 3 Breaking Changes, 10 Improvements, 8 Bug fixes!

v 1.2.3
New Features:

• Obstacle Sensitivity Range is now in effect for Dynamic Obstacles similar to static obstacles. Options exists to use the Grid's setting or a custom one.
• Added a simple utility to create and edit an Attribute set.
• Added a marshaller that allows marshalling actions from another thread onto the main thread. This is now used by the CallbackPathRequest, hence callbacks will now be made on the main thread.
• Added automatic update checking and a Products window for Apex products to give an overview of installed / available packages.
• The grid component now has an 'offset' property when 'Link Origin to Transform' is checked. This allows the grid to be offset some amount in relation to its transform.

Breaking Changes:

• ISteerable has been deprecated and merged into IMovable. The distinction between these two really caused more confusion than clarity.
• The currentDestination property on IMovable has been deprecated and is now called nextNodePosition instead. The property has always returned the location of the next node along the path being travelled, but its name suggested otherwise.
  It is now also a nullable Vector3 instead of an IPositioned, to align it with the finalDestination property.
• RectangleXZ is now a struct.

Improvements:

• Dynamic Obstacle performance improved by approximately 400%.
• The PathResult's properties are now writable so that result processors can change them.
• The Grid Field tool has moved to the Tools menu.
• The UnitNavigationEventMessage NodeReached event is now raised after the next node has been resolved, so that nextNodePosition will return the expected next node rather than the one already reported as reached.
• The path service now exposes a property that makes changing the cost provider to use easier than before.
• Portals now have an option to be treated relative to their transform, i.e. the end points will use local space. This means portals can work properly in prefabs.
• The 'currentPath' property of the IMovable is now of type Path instead of the previous less helpful IIterable<IPositioned>
• The grid visualizer will now update if the transform, on which the grid resides, is moved.
• Minimum required Unity version to download from the Asset Store is now 4.3 instead of 4.5
• Improved a few component editors.

Bug Fixes:

• Corrected a multithreading issue involving dynamic obstacles with frequent updates.
• Corrected a few labels on attributed components in the Unity editor.
• Fixed the PortalActionTeleportComponent, it was teleporting units into the terrain.
• Fixed a bug where runtime initialization of a grid with a portal already on it would only partially initialize the portal.
• Fixed a bug where static obstacle detection would detect obstacles outside the boundaries on elevated terrain.
• Terrain checking will no longer fail to detect terrain at the joint points of terrain pieces.
• Fixed a bug with the Navigating Unit with Selection quick start in Win8 / WP8 apps when a custom input receiver is defined.
• Fixed a bug with manually initialized grids, where loaded at runtime and moved to position before initialization would not move the grid accordingly.

 

Can I use apex for strategy game?
I need to find paths for many units in one request for i.e. Squad of RTS game or just many selected units on map.

What apex have for me and what I need to write myself?

 

Cool, thanks for the updates.
Apex is moving foward.
Btw, does this update have a fix for the vertical movement?

 

Apex Path is the path finder portion of the product line, and presently the only released product in that line.

You can visit our web page at apexgametools.com where you will find the full product description, example and tutorial videos.

But to answer your specific question, yes you can use Apex Path for an RTS game and assign paths to both individual and groups of units.

Later this year we will release Apex Steer, which is the steering portion containing various steering behaviours and grouping strategies. We will release a teaser video of the current progress soon.

 

This update does not provide any changes to height map navigation I am afraid.

We have an upcoming release, which will be launched prior to the release of Apex Steer, which includes a lot of changes to movement in general, part of which is height map navigation.

The precise date of this release is still unknown, but the hope is that it will be ready within a month or so.
Development is practically complete but we still have some testing and tweaking to do.

 

If possible, please make it sooner rather than later. Perhaps some features could be added in increment instead one big release.

 

I would like to use Apex in a 2D maze project in unity and wondering if it's possible. I'm using an ortho cam pointing at the maze on the XY plane. A similar question for A* path finding : http://arongranberg.com/vanillaforums/discussion/1104/rvo-with-unity-2d-top-down-x-y-setup

Edit: Please correct if wrong. If the height map for vertical movement is fixed, then in theory the maze on the XY plane should work. If this were to be true, then solving the height map issue also enables Apex to be used with Unity 2D.

 

It is not as simple as that unfortunately. Everything to do with path finding and steering is married to the xz - plane, with the y-axis representing height.

We do want to support 2D at some point, but for the moment we are engaged with steering.

One can always create 2D using the xz-plane, but of course not the new Unity 2D.

 

Geminior,

Let me ask the question in another way. Say we have a vertical wall and on this wall I have various obstacles, would Apex be able to properly plan a path on this wall ?

 

Hi Geminior,
i'm very interested in this Apex Steer package! Will it be possible to handle a group of enemies moving to a point, and eventually evade to a near location if this point is already blocked? Also will it handle local avoidance?

thank you

 

No path finding only takes place on the xz-plane.
A vertical wall will itself be considered an obstacle that the unit will then scale if the max scale height is set to a value higher than the wall.

 

It will provide group movement yes. With regards to avoidance, units will avoid areas blocked by obstacles automatically.
If what you mean is areas blocked by other units, then we aim to include that as well, so that groups take the unit density at any given area into consideration.

It will also have local avoidance for both units and spherical obstacles (obstacles that can be represented by a radius).

 

Ouch, this is a bummer.

 

This sounds great! Can't wait for the release of Apex Steer!

 

Right now if "Navigate to nearest if blocked" is enabled, no check is done to ensure that the alternate destination has line of sight to the original one. This means that it's possible (and very likely with certain settings) for a unit to decide that the closest point to a blocked destination is on the other side of a wall.

This is really something that should be handled by the package itself, but for my own edification, what would I have to do in order to modify this behavior such that only alternate destinations that have LOS to the original are considered valid? ie. Which interface would I implement and which function would I override?

 

As I read it, your problem seems to be that your walls are not seen as obstacles. You need to either adjust your grid's obstacle sensitivity or move/scale the walls so they get closer to a cell center.

So the alternate destination will always be valid seen from the path finder's view, but if something is blocking the way that the path finder does not know about, then well...

 

So there's no way to interject a validity check into the process? That's unfortunate.

Adjusting the obstacle sensitivity was one of the first things I tried but it's not useful due to the extremely limited range of allowed values. If I wanted walls to be detected from over half a cell away or even over multiple cells what's stopping me other than an arbitrary limitation?

Changing the walls themselves is obviously not a reasonable option. Every time I have to painstakingly adjust a wall to ensure that Apex likes it, the real solution begins to look more and more like "Find a better pathfinding engine". Not to mention that the potential for having dynamic obstacles is the only reason I'm not just using Unity free's pathfinding implementation in the first place, which I've found to be superior in every other way, at least for my needs.

 

Hi,

The tutorial page on the support website is 404.
Is there a reason?
http://apexgametools.com/tutorials/apex-path-tutorial-setting-scene/

Thanks.

 

Apex Path is based on a grid, which holds the data needed for the path finder to navigate.
If a cell is not seen as blocked, it is, not surprisingly, seen as walkable.
So the validity check is exactly that, checking if a cell is walkable.
If you place obstacles in a way that the cells they occupy do not detect them, well then these cells will be considered walkable and the path finder will end up suggesting paths that go through these walls.
Obstacles are only obstacles if the grid knows about them.

The uniformness of a grid does impose certain requirements on the level geometry, this is the price one has to pay for all the advantages a grid provides.

The limitation on obstacle sensitivity is not arbitrary, it is very well defined. It is half the cell size.
The reason for this is that cell define the smallest unit of a grid, and hence units that want to navigate the grid should fit within a cell. If it does not, it cannot rely on the path finder to find paths for it.

So why is it that you would want to detect walls further away than half a cell length?

It may well be that Apex Path does not fit your needs. If you feel a grid based solution is not for you, then you will have to look elsewhere. Unfortunately I predict that, if you try a Nav Mesh solution, you will run into far more problems.
You are of course free to use whatever solution you please, but it may be more beneficial to you to suggest product enhancements. We have after all implemented a fair range of user suggested features since the release 3 months ago.

 

The site is undergoing some restructuring at the moment, and apparently someone forgot to move some links around.
Thanks for pointing this out, I will see to it that it is fixed as soon as possible.

 

Yes, I understand that it checks for validity using the grid. What I'm asking for is a way to add a user defined sanity check to the process that could make use of information outside of the grid. That way I could decide for myself whether a destination is valid and tell the pathfinding engine to keep looking if it's not.

I would like to add a buffer zone around the walls to prevent units from pathing too close to them. Not only would this help resolve issues like the one I mentioned in my first post, but it would stop units awkwardly sliding against them as they do now. Unity offers exactly this as an option called "radius" when baking navmeshes. If there's no technical reason why increasing the sensitivity isn't possible (for all I know there could be) then I would definitely call that an abitrary restriction.

I apologize if I've come off as rude. I'm just a little frustrated at having a lot of trouble getting Apex to work with my game in the first place (in stark contrast to Unity's solution, which took a fraction of the time) only to run into serious issues when I finally did (again, in contrast to Unity which gave me no trouble other than the $1.5k pricetag for dynamic terrain). However, I'm going to stick with it for now and try to resolve the issues if I can.

As such, I have two feature requests:

1. A "Validity Check" function exposed in the API that would allow the user to audit the destination by their own criterion in cases where it is altered by Apex. In addition to the sanity check I proposed above, this could have any number of uses - say, to prevent the altered destination from being on top of a dynamically placed land mine, to pull an example of out of my hat.

2. Some way to increase the "Thickness" of walls as the grid sees them, whether by allowing for higher obstacle sensitivity or by whatever other method you deem appropriate.

Thank you for your time.

 

There are already a number of ways that you can intercept and react to a path returned by the path finder.
One way is to implement a Result Processor. This applies when using the MoveTo method to move units (which is also used by default when issuing movement commands via mouse input).
Another way is to issue the path request yourself using the CallbackPathRequest and then once you get the result you can modify the path to suit your needs and pass it on to the unit via the MoveAlong method.

It is important to understand one of the differences between a Nav Grid and a Nav Mesh.
A grid consists of uniformly sized cells which are either blocked or walkable, they cannot be partly blocked / walkable.
So it is not possible to have a radius in the same sense as with a mesh. If a wall is placed such that it does not cover the entirety of a cell, there will be an implicit buffer from the wall to the edge of the cell. If however you want this buffer to be larger it would have to grow by a full cell width, i.e. it would also block the adjacent cell.

That said the reason why the obstacle sensitivity is restricted to a max of cell radius has to do with the fact that it is expected that units fit inside a cell, which led us to conclude that allowing a higher sensitivity would lead to confusion.
However now that you have explained your use case, I can't see any reason not to allow higher values, so it will be added to the suggested improvements list for the next update.

 

So... I foolishly bought your asset without even checking what kind of graphs it works with, and obviously not so happy to see that it only works with grids =/ Because from my (inexperienced but somewhat educated) point of view it seems that it's pretty much inconvenient to apply grid-based solution to even slightly complex world. Probably I just don’t know how to do it properly.

So I decided to try to implement pathfinding in a multistory building… but found some troubles already on the first floor.

I obviously don’t want to waste any space by having partially blocked cells, so I made cells size of a wall, 0.2 units. But, given the way your system works, I cannot have cells that small, because this happens. Adjusting obstacleSensitivityRange had no effect, so I looked into the code and found this line:

Code (CSharp):

1. var blockThreshold = Mathf.Min(Mathf.Max(_obstacleSensitivityRange, 0.1f), _cellSize / 2.0f);

So, for some reason minimum obstacleSensitivityRange is 0.1, there is no way to change it in editor, and moreover it’s a magic number, though this particular line of code occurs 3 times. But this is just the part of the problem, since with 0.2 size cells obstacleSensitivityRange of 0.1 is a bare minimum for obstacle that fit cell perfectly to not block adjacent cells, but it still blocks them. Changing 0.1 to 0.0 and making obstacleSensitivityRange to be less than 0.1 solved the problem. Comments please?

And another problem I found is off-grid navigation not working properly. In “MultipleGrids” example, when you do this, nothing happens. And besides of that, after some time units being off-grid can start to completely ignore grids, so you cannot move them on a grid. In one case unit was completely stuck on edge of a grid.

 

There are indeed some key differences between a Nav Grid and a Nav Mesh, as I explained in the post just before your own. It is fairly clear from the numerous game titles, both AAA and Indie that use grid based navigation, that it is certainly viable to use grids for both navigation and AI purposes.
The thing is that due to the restrictions a grid puts on level design, you have to take the grid into consideration when constructing levels. So one of the grid's main advantages is also its greatest weakness.

A cell is the smallest unit of measure in a grid. In Apex Path (at least in the current version) the size of a cell needs to be such that it can contain the largest unit (or agent) that is to navigate the grid.
So if your largest unit has a radius of 1 the grid's cell size must be at least 2. This requirement is only problem if you have units of very different sizes, and it is something we plan to address in the future.

So if your walls are only 0.2 thick and your units are bigger, then you will have some padding on the sides of the walls that units cannot walk on, since a cell is either blocked or it isn't.
Nav Meshes do not have this restriction, but then they also do not have well performing dynamic updates, dynamic obstacles, dynamic replanning and more. So in the end it is a question of what feature set best matches your game.

Now regarding the specific limitation on the obstacle sensitivity range. This was already pointed out in the post before your own, and it is something we will look at. Obstacle sensitivity is also strongly related to unit size. If set to a value less than the radius of the largest unit, it will be possible to have gaps in walls that are not blocked but that are also not wide enough for the unit to pass through, and hence it will get stuck.
So we basically agreed that a unit size less than 0.1 would not make sense and therefore that is currently the lowest allowed value.

Off grid navigation is a rather exotic feature, but of course it should work as expected, and I will look into the issues you describe.
However for most scenarios you will get better results in every way by using portals to define cross grid navigation.

 

Yes, this looks like what I want. However, in order to implement my example and have Apex do the heavy lifting of finding the nearest valid cell (eg. by calling GetNearestWalkableCell), I would need a way to manually mark a cell as invalid for the duration of the current path request so that Apex would know to look for other cells instead. Is this possible?

Yes, I understand the basics of grid based navigation. What I have always wanted was a way to make walls occupy more cells. Allowing for higher obstacle sensitivity would achieve that, so thank you. I look forward to the next update.

 

Yes, you can set the isPermanentlyBlocked property of the cell to true.
You will probably want to test if it is true already so that you don't set actually blocked cells back to false.

 

Using this I was able to resolve my issue with AI pathing to the wrong side of walls when blocked. Thank you for the help.

 

Hello, I just purchased the Apex Pathfinding and I am very happy so far with what I have seen.

I have a couple of questions, when do you think you will release Advanced Dynamic Asset and Apex Steer?
Will they be cheaper for current owners of Apex Path?

Is Apex Path fully tested for Unity 5?

Thank you.

 

Apex Path v1.2.4 Released
Improvements:

• Replaced the AsyncFailed event of the Path Finder Service with a callback to fix a problem with AOT compilation.
• Portals editor has been changed, which should hopefully make it easier to set up portals.
• Portals can now be either one- or two-way.
• Prepared for Advanced Dynamic Obstacles release
• The max constraint on Obstacle Sensitivity on the Grid has been removed. This may lead to some funky behaviour if set to an unreasonably high value.
• The original constraint is still applied when processing height settings for cells.

Bug Fixes:

• Again a few win8 specific errors had crept in, they are now fixed.

 

Our Advanced Dynamic Obstacles package is planned for release next week.
Apex Steer is planned for release by the end of the year, but due to a few issues it may be slightly delayed.

Both products require Apex Path to work, so they are only relevant to those who also buy Apex Path.
We have not yet finally decided on the pricing.

No Apex Path has not been tested on Unity 5 yet. Unity 5 will bring breaking changes to some parts of scripting and we will wait until its is near completion before applying changes to Apex Path and other products.

 

Thanks for your prompt response.
Based on your ample experience, will the changes for Unity 5 take months? a year?
I now it's just a guess, but that will suffice for now.
Can't wait to see the Advanced DO package.
Thanks again

 

My best guess is that it will take no time at all to upgrade to Unity 5. The first goal is to upgrade to the point where everything works. The next goal is to make use of new improvements in Unity 5 to enhance our products as well.

 

I can't seem to get dynamic obstacles working. Are there additional steps that need to be taken besides adding the dynamic obstacle component to an object and configuring it there? And yes, I am checking in-game.

 

Hello.
I am having trouble defining portals.
Basically every time I re-open my project I get to be able to redraw the area of a portal again using the Edit Portals. But once I run the game and I go back to the scene, I loose the ability to redraw the portals, even if I load the scene again or change scene.
I just get the typical Select Rectangle and I can not affect the scene.

In the first video I show how I can not edit the portals, I run the game and I actually use one portal with a custom PortalActionComponent.

In the second video, I reopen the project, edit a portal, run the game, and try to affect the portal again, with no luck.

https://www.dropbox.com/s/1oikcpxbjjzh13h/Problem.mov?dl=0
https://www.dropbox.com/s/cqbe2k0uj326e51/Problem2.mov?dl=0

Any ideas what could be causing this behaviour?
I have tried reimporting the Asset, with no results.
Thank you

 

No apart from the different options on how the obstacle updates, there is nothing more to do.
However a bug crept into the Grid Visualizer in the last update, so it doesn't mark cells covered by dynamic obstacles red. The cells are blocked, its just the visualizer that is rebelling.

 

Unfortunately I cannot recreate the behaviour you describe, also I cannot see the inspector in the second video.

But my guess is that some other script you use hijacks the control ID the portal editor wants to use, but I am by no means sure.
How many portals do you have on one game object?

I assume that you actually activate edit mode again after returning from playmode?

Are you using other packages that offer some sort of in scene lay-outing that might be interfering?

I recommend you post this issue on our forum so we can process it there.

 

Grid Visualizer Bug in 1.2.4
Unfortunately the introduction of the new Portal editor had the undesired side effect of introducing a bug with the grid component.

For a quick fix, until we release an update, replace the OnEnable method on the GridComponent class with the following:

Code (CSharp):

1.  
2.         protected virtual void OnEnable()
3.         {
4.             if (Application.isEditor && !Application.isPlaying)
5.             {
6.                 Init();
7.                 return;
8.             }
9.  
10.             if (this.automaticInitialization)
11.             {
12.                 EnsureGrid();
13.                 RegisterWithManagers();
14.             }
15.         }

The portal editor itself is also bugged and does not properly draw portals if at y > 0.
Both issues will be fixed soon.

 

Apex Path v1.2.5 Released

Important: Due to folder structure changes you must remove the old version of Apex Path before importing this update.


v1.2.5
Improvements:

• • Added patch functionality to the Products window so that minor fixes such as this can be applied without having to download a new package manually.

Bug Fixes:

• Fixed a bug with the Grid that was caused by the new Portal Editor.
• Fixed the Portal Editor so portals can now be properly drawn on elevated terrain.

The Apex Team
www.apexgametools.com

Connect with us and get all our news, updates, tutorials, etc.

 

Hi,
About when does the Unity5 support schedule?
Apex Path is a wonderful asset. I want to keep using Apex Path long.
However, there is a performance problem of physics in my game project, and I want to shift to Unity5 immediately.

I wish Apex Path to support Unity5 immediately.

 

We are certainly going to support Unity5, but since it has yet to be released and may still change, we have not done the port yet. Besides it may prove a necessity to have two versions of Apex Path, such that new features of Unity 5 can actually be used. It is doubtful that we will have support for Unity5 before February 2015, unless Unity5 is actually released before that time.

 

Hi, How well will this work with vehicles in a track & arena situations? The maps / locations aren't going to be wide open. My design plans are to have 7 AI vehicles and 1 player vehicle on a moderately sized map with multiple buildings, obstacles, jumps, etc.

General plan for vehicle AI:

1) Player vehicle and seven AI vehicles spawn
2) The seven AI vehicles start wandering and are constantly trying to find other vehicles.
3) Once AI finds another vehicle it will break off and go wandering again.

 

I am not sure what you mean by track & arena.
If by vehicles you mean car like vehicles and by track you mean race track, then the default settings of Apex Path, which favours humanoids, will need some tweaking. Also depending on the type of track, you may find that a grid based solution is sub optimal, since a grid is made up from evenly sized squares.

If what you ask has nothing to do with race tracks, then all what you state in points 1-3 are easily supported.

 

Hi,

just some questions about the dynamic obstacles. In another pathfinding solution dynamic obstacles are a problem, because the path finding algorithm do not see them if they are updating (mark the grid unwalkable) the grid (grid based path finding). In this case the pathfinding generates a path through the dynamic obstacle, thats lead to more complex path finding AI's. What i would need is, a smoth grid updating algorithm (or another solution), which just free the necessary grids and just make the new grids unwalkable and never let the pathfinding algorithm create a path through the dynamic obstacles. At the time i have to free the grid if the vehicle/unit start path finding and just block the grids under the vehicle/unit if it stops again. Until moving, my local avoidance take care of collisions. The problem is, whatever i do to clean up the grid after the vehicle changes the position, for a reason like the vehicle pushed away, i always can have some wrong updated grids. which must be updated with a whole grid update in a certain period.

- Do you have the same problem with your path-finding solution (Does the path-finding-solution creates paths through FAST MOVING dynamic obstacles?), or do you implemented a better solution? And is the solution fast enough for an RTS game with max 50-100 units for one player side + 8 x AI sides (+ 8x50 - 8x100). Max. 900 units on host side (host side must take care of the AI-players).

- Do you have a free test version?

Thanks in advance for your answer.