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

Hello,
Is there proper way to:
1. Add cost by collider to cells (like Dynamic Obstacles but instead of blocking cells just increase cost of cells)?
2. Visualize cost of cells for debugging?

(I'm using 1.2.5 version)

 

Thank you very much for the feed back, excellent to hear.

 

While cell costs are considered by the path finder, there is no API in place to handle cost fields or visual debugging of costs. Those features are intended for Apex Cost, which has yet to be scheduled for release.

You can however apply costs yourself simply by setting the cost property of a cell.

May I inquire as to why you are using version 1.2.5?

 

OK, thanks

Found a simple way to visualize cost of cells. You need to add next lines to GridVisualizer :: DrawLayout in inner loop:

Code (CSharp):

1. #if UNITY_EDITOR
2.   UnityEditor.Handles.Label( c.position, c.cost.ToString() );
3. #endif

It gives you



There are two main reasons why I stay on 1.2.5:
* I spent a lot of time to upgrade to 2.0. I have own SteeringComponents and use a grid a lot not only for path finding. API changed almost everywhere. But at the end behaviours of units was incredibly different from original. I can't find more time to fix all new problems.
* I think Apex2 became very difficult to understand. Billions of components. When you add Apex Steer you just multiplies your incomprehension by 10. I can't use it with others developers. ( What is going on? Why unit is not stopped when I say STOP? What component I need to use? No one of them? All of them? How they work with each other? How to deprecate strafe movement in right way? Group and Grouping what the difference? Why it works perfectly in demo scene and works like S*** in my game? )

I'll try to upgrade to Apex 2.2.5 when it'll be released

 

Ok I understand that upgrading steering components to 2.0 does require some effort, but we do have a number of videos to explain the changes and the reasons behind them.

It is of course unfortunate that you find 2.0 difficult to comprehend, that was certainly not the intention, but as long as you are happy with 1.2.5 all is good.

 

@Geminior , can I specify my own grid to Apex? I mean, I have a two dimensional matrix representing free/obstructed spaces and would like to have Apex use that instead of calculating a grid based on layer objects.

 

In the next update you can do so fairly easily by overriding how the grid establishes whether a cell is free or blocked.
That update will be released around the start of June.

As things are now you can still do it as a post initialize action. You will basically have to iterate over each cell of the grid once it has initialized itself, and then manually mark cells you want to block.

 

Two questions:

1) Can I combine Apex Path with TerrainComposer or I've to set up every tree etc for ApexPath?

2) Is there PlayMaker support now?

 

I am not familiar with TerrainComposer, but Apex Path supports any type of terrain as long as it has a collider.
For obstacles, these need to reside in one or more named layers that Apex Path can then use to detect them, so you likely want to add your trees to this layer.

Playmaker support is being implemented by another developer. You can contact him via email (satyajit(at)flyingrobotstudios.com) if you want to check on the status.

 

Just to understand it right: Why is there a difference in detection? I mean why does Apex makes differences between a collider and layer for obstacles? A tree is a obstacles, too but only needs a collider.

 

It seems you misunderstood, or else I don't understand your follow up question.

Apex Path operates with three layer mappings that represent Terrain, Static Obstacles and Units respectively.
If a piece of geometry is to be detected as an obstacle it must be in a layer that is mapped to the Static Obstacles in Apex Path. It must also have a collider.
The same goes for the other types, i.e. terrain and units.

Why do they need to be in a layer and have a collider? Because detection is done via ray casting.

 

Hi.

Having in mind the latest version of Apex Path/Steering and Dynamic obstacles, what is the most viable solution, in your opinion, for following cases:

1. Suppose we have 2 types of units: infantry and mechs. Obviously they are of different size. Mechs should not be able to pass places where only infantry could.

2. Groups of units of same size steer/avoid perfectly in your demos. What about groups of units of different size. For example, we have 2 mechs and several infantry units supporting them.

Thanks.

 

Currently the path finder does not take unit size into consideration. Clearance maps is a feature we have on the todo list, but have yet to implement.
There are ways to achieve this however, although depending on the scenario they can prove a bit cumbersome.
Dynamic Obstacles provide a way to mark areas as impassable to certain units, so narrow corridors where only infantry is to be able to pass, can be covered by a Dynamic Obstacle whose Exceptions property is set to an attribute only Infantry has.

Avoidance does take unit size into consideration, so unit of various sizes will avoid each other correctly.

 

We thought about "attribute" way, but as you said, it is indeed cumbersome. What about overlapping grids?

Do you have any estimation, when clearance maps would be implemented? Any RTS will require this and many others with different sized units.

On a side note, do you have a road map for Apex Game Tools, what should developers wait for?

Thanks.

 

Due to the nature of uniformly sized grids, having overlapping grids of different cell sizes does not work in practice, unless the larger cell size is a multiple of the smaller cell size.

We know that this is an essential feature for certain games. It is the next feature to be added, but at this time I can only give a very loose estimate of a couple of months.

There is no live road map, since we are not sure how the immediate future will pan out.
Apex AI is the next product, but as to adding features to existing products, we are currently in a planning process.

 

Larger cell size is a multiple of the smaller cell size, is acceptable enough.

Couple of months is also acceptable, I only hope it will not become couple of years.

PS: Apex AI sounds interesting.

 

Having a little issue posting on your forums, so just copying and pasting my question here. Sorry in advanced:

Hey all, I'm running into a little bit of a snag as I'm not sure where to look for this information. I've got 2 grids connected with a portal and my unit is standing on that edge of one of the grids. Using ICell's GetNeighbour method side that should connect to the second grid via portal returns a null. I have yet to find anything that lets me know if my current cell is a portal and how to get the cell's neighbor over that portal. Any thoughts?

 

Seems posting on the forums succeeded, the answer can be found there.

 

I don't suppose you guys have considered producing a DLL version? Or maybe put a nested unitypackage inside of the asset store unitypackage with a DLL version so you don't break everyone's existing projects when they upgrade. I know lots of customers want to be able to see the source code, but once you actually start using a lot of assets in a large project you really wish everything just came in DLLs. My current project takes 15-20 seconds to recompile just because of a bunch of asset .CS files

Great asset & thanks for all of your hard work!

 

We have considered it. However since we decided on going with full source, we have also made use of that in the way our different products interact (partial classes).
So unfortunately it is not just a matter of compiling the product assembly and including that.

I understand that having long compile times is a pain, and we may well provide some way of enabling customers to compile the Apex products to a dll. However when such a feature will be available I cannot say.

 

Hi guys,

This post is for the developers who need Playmaker Actions for Apex Path.

I've started working on a set of actions for Apex Path. And you can access the beta right now.

Now, for this suite of actions I've not made it the way I want to access it via PlayMaker. Rather, I've kept the development phase open to suggestions for this integration. I've released a basic set of the actions in Asset Store and right now developing the full suite. During this Beta phase you can test out and suggest workflows. I believe with your suggestions it will be much more useful than ever.

The Asset is here
https://www.assetstore.unity3d.com/en/#!/content/39428

After buying you can mail me to get into the Beta discussion group. Please mention your invoice no.

 

I am new to Apex, I was hoping Apex would give me more control over my navigation mesh's than Unity's navmesh.

However, I am struggling to create an Apex navigation mesh on anything more complex than a very very basic scene like in the tutorials.

The screenshot below is of a test scene I am trying to setup navigation for. I have managed to get Apex to allow the agent to walk up the stairs highlighted Yellow. But Apex only allows navigation in the open. I have highlighted 3 areas orange, Apex can't navigate to these because they are under a roof.

I am assuming that Apex can easily create a navmesh for buildings with different levels? Or do I need to create a navmesh for each flat area and somehow link them?

This scene has buildings with internal stairs and multiple levels, some underground tunnels, a couple towers with an elevator and multiple levels at the top. Not a very complex scene, but I am struggling to get Apex to solve this.

Could you please provide high level steps on how to achieve navigation in the scene below.

Edit: One other thing. I can't get the grid visualiser to display anything in this scene. It just puts a flat grid at the bottom of the zone I defined in the grid component. It doesn't map out the navigation paths on top of the model? Does the visualiser grid only show on flat surfaces?

 

Ok, I found the answer to my question in an earlier post on this thread. Sorry, I missed this when I first investigated.

So, Apex does not support multiple levels automatically and the visualizer does not map to the terrain.

Apex is the most expensive navigation tool in the Asset store. If you add the cost of all 3 tools (Steer, Path, Dynamic Obstacles), total cost is $180. I expected that Apex would be capable of handling basic features like multiple levels and just displaying the navigation mesh on uneven terrain. I am disappointed Apex doesn't do this automatically.

Unfortunately, multiple levels is critical for my purposes, and setting this up manually will be too time consuming so Apex is unusable for my project.

Do you have any plans to generate multiple level navigation for Apex? I expect the scanning is is not difficult to implement, instead of just doing one horizontal scan of the scene, you can iterate through vertical scans of the navigation area to find the different levels?

 

Will this work over photon

 

Your question doesn't make sense. It is like asking does a hammer work with a saw....

Apex is a pathfinding framework for Unity.
Photon is a networking framework for Unity.

They are 2 different frameworks that can be used in a Unity project.

Can you please expand on what exactly you are asking and give some context.

 

Apex Path is a grid based solution, which provides a lot of advantages, especially with respect to run time updates.
It does however also have a few disadvantages, the main of which is multi level geometry.

It is not simply a matter of identifying different levels, it has to do with how the graph is constructed and used.
So implementing true multi level support is far from trivial. That is not to say that it will never be done, however we have no plans of doing it in the immediate future.

It does, however not at design time. Elevation differences in terrain are not determined at design time, since it is too time consuming to do so real time and would heavily impact design time performance.
You can bake the grid, which will make the visualization follow the terrain at design time.

It is true that the combined price is $180. If you translate this into hours of work, I am sure you will agree that it is far from expensive. And yes there are a few features that a Nav Mesh does better, simply because they are inherently easy to do in that context, and the same is true for other features using a grid, e.g. dynamic obstacles.

Now it is unfortunate that you are unable to use Apex Path with your use case, but if you send us your order details (support(at)apexgametools.com) we will look into the possibility of a refund.

 

@Geminior. Thanks for the comprehensive response. I am not chasing refund, I picked up Apex Path in a sale a little while ago and it might come in handy one day. And I agree that $180 is not expensive. Asset store prices are amazingly ridiculously cheap for what you get.

 

Hi, I am going to make RTS game with totally 800 units moving at the same time on mobile. 400 for each side and divided into groups, kind of like Total War series on PC. When 2 groups start fighting, each unit will try to reach opponent unit and do fighting, they are not allowed to go through each other (like local avoidance of A Star path finding pro). Can Apex be able to handle that much of units?

 

It is unlikely that it will perform reasonably well, especially on a mobile unit.
Currently there are no optimizations in place for units not visible on screen. When that is added at some point, it may work, but of course it depends on the realistic number of units on screen at the same time.

 

Hi!
Last week I've bought Apex path and Steer and I would like to ask you few questions if I may.
1)I followed the tutorial for the Mecanim integration and for Apex Path works great.
I got some issues with Steer. In particular the unit tends to "shake" as soon I activate the unit avoidance. I suppose is due to the fact that they are trying to avoid each other (I use the Models and animations included in the Mecanim package).
I understood that is even related to which animations are considered to turn (sharp or smooth turn).

Is there any way to avoid this behaviour? I mean, my idea is :

the two unity understand that they have to avoid each other and recalculate a path (that will require somehow that the two units or more have to communicate their paths).


Please let me know your suggestions/idea.


Thanks in advance

 

The Mecanim integration has not been tested with Apex Steer, and is more of a proof of concept than a full fledged solution. Height navigation for instance is also not part of the Mecanim project.
The shaking likely has to do with the animations and the transitions between them.

Unit avoidance does not involve recalculating the paths of the units involved, they avoid each other and then resume their paths. Units are constantly given adjustments to their velocity, and especially so when avoiding others, and is likely these adjustments that cause the shaking you describe.
You can try adjusting (lowering) the acceleration and deceleration capabilities of the unit (Humanoid Speed Component) and see if that helps, but otherwise it is likely that it is caused by jittery transitions between animations.

 

Thanks for the reply.
I was thinking that the mecanim integration was not fully complete/perfect.
Maybe I misunderstood your words, but why the mecanim integration should not work with the Height navigation? or you were just talking about the project/tutorial?
I am a bit confused now.

 

The Mecanim Tutorial project does not have height navigation implemented since the movement is done by root motion and there are no animations to support scaling stairs or climbing etc.
In other words the tutorial project animations only 'understand' x-z movement and will ignore the y-component of a velocity.
So it is certainly possible to do height navigation via Mecanim, you just need the right animations.

 

Is it feasible to modify this package so both steering and pathfinding are deterministic, ie, no floats, no dictionary iteration, multithreading generates the same results, etc? Thanks

 

Floats are used extensively, there is no dictionary iteration I can think of, and the only multithreaded task is path finding.
Whether it is feasible to make the required changes depends on what you deem feasible .

 

Hi,
I was checking the script that you use for the mecanim integration and I think I got why there is the "shaking" problem.
the Angle direction calculated pass from negative to positive (and vicevers) very quickly.
I noticed that the script calculate the angle direction based on two points (p1 and p2) that I assume are the Start and Ending points of the Path.
Am I correct?

And here is my question : how to access to the current next point of the path?
I mean the one generated by the path calculation. Is it possible?

Thanks in advance,

 

No, the angle direction is calculated from the velocity and the unit's forward vector.
If the unit's forward vector is not aligned with the velocity vector, the unit will turn to make it so.

For single units, this is accessible on the unit facade.

Code (CSharp):

1. var unit = unitGameObjectOrComponent.GetUnitFacade();
2. var path = unit.currentPath;

 

Hi Apex,

I was impressed by the integration of apex path and apex steer, as I would like to use it for massive 2d sprite movement game. But after running the examples I realize that there is no solution to use sprites and the 2D physics system in junction with apex path/steer.

Is there any development done on allowing different planes to be used ? Else I feel I wasted my money on apex path+steer...

Thanks in advance,

 

You are correct, Apex Path and Steer is 2D navigation on the xz-plane, and currently I am afraid there are no plans to expand to allow for using other planes as the ground plane.
You can request a refund by writing us at support(at)apexgametools.com with the above information plus your receipt from Unity.

 

How good apex handles large terrains when it comes to memory consumption? How much memory is used for a 1000x1000 big terrain grid?

 

That depends on the cell size, and if using a height map, its granularity and the height map storage method.

A 1000x1000 grid with a cell size of 1 would take up approximately 66mb of memory, not including the height map.
Height maps are however not the only option with regards to height navigation. Also you have the option to cut the grid into smaller pieces and dynamically enable/disable if this makes sense for your use case.
We have a fair number of tutorials here, which include tutorials on large worlds and run time initialization and updating of the grid.

 

Oh, that would be too much for my project. Does Apex also work with NavMeshs or any other low memory method?

p.s. Does Apex Steer requires Apex Path or is it possible to combine it with (for example) the unity navmesh?

 

Apex Path is a grid based path finding and steering solution, so it does not operate with Nav Meshes.
A NavMesh will most likely have fewer nodes than a grid, however it is not a certainty.

Apex Steer is an expansion to Apex Path, which adds additional steering components, mainly aimed at group steering.
So in other words, Apex Steer requires Apex Path.

 

Apex looks really well designed, I don't have it, and I know it was stated that were aren't any plans to support other axis', but I just wanted to put my 2 cents in that I'll definitely be purchasing it if it ever does support the XY axis for 2D!

 

Good to know, thanks for the feedback. However it is still very uncertain if a 2D version will be released.

 

Failing to use mecanim root motion, I now tried to use the built in motion. I wanted the unit(humanoid) to rotate in place as much as needed before starting to move. But the unit moves before it rotates...

Seems to me there should be a way to wait with forward movment until rotation is done would be common. What am I missing

Edit: Think I got the mecanim root motion setup working. When I override rotation and movement, what settings on the steering components affect desired velocity given by velocity in public void Move( Vector3 velocity, float deltaTime ) ?

 

The default Orientation behaviour (turning to face the current velocity) is one possible behaviour, but you can make your own.
An example of a component that turns first before moving, can be found in the examples and tutorials project. It's called TurnThenMove.

All steering behaviours return an acceleration so they all influence the velocity.
The actual speed is controlled by the Humanoid Speed Component by default.
But perhaps I misunderstand your question?

 

I will make sure to check that scene should root motion confuse me to the breaking point again

Think I understand now.
If I could understand Mecanim better it would be awesome. Like changing the sample animator you use in your video to blend walking and turning. But thats got nothing to do with pathfinding.

 

I am having couple of issues going on :

In the MecanimMoverComponent (Script) that is attached to the agent. Under Move method the velocity.magnitude is gradually increasing untill it hit max, though I am not moving the agent.

When I have MecanimMoverComponent(script) attached to the agent, the Seek does not happen, but when I removed the script the Seek start working with no animation. Please advice

 

Any clue on this ?