NavAgent and Pathfinding in ECS?

Hi everyone,

I am doing a feasibility study for a demo and the following is crucial for it to work.

Is it possible to have the NavAgent component and the full A* pathfinding in ECS, without having to rewrite everything ourselves? Because I can't find a way to convert a GameObject containing a NavAgent to a working AI Entity (working in ECS).

Thx

 

There isn't, there are A* tutorials for ECS though and it wouldn't take too long to implement

 

I'm not using navagent specifically AFAIK but it's been pretty easy to generate a navmesh and do the queries from DOTs (in a similar way to the projects Joachim linked above).

 

Thanks. I have seen some tutorials by Code Monkey on YouTube and he uses a simple 2D navmesh. I guess it all can be converted in 3D, but I don't feel confident in being able to achieve a proper result tbh.

 

Thank you all for the useful inputs.

I'll try looking into the linked example and see if I can reverse engineer it and do something with it.

On a side note, is there a plan for developing navagent/navmesh high-level API support in the future?

 

I actively maintain an unofficial DOTS navigation package available on OpenUPM. It's part of a monorepo on GitHub that includes demos and other packages. Mine is technically a hybrid approach, since it works with existing NavMesh assets; however, it does use its own custom definition of the "NavAgent" as component data.

At the very least, someone reading may be interested in my code, most importantly the NavPlanSystem, and how I hacked in pointers to thread-indexed NavMeshQuery objects with the NavMeshQuerySystem. And there's more: jump automation and complex transform hierarchy support, among other things. I wrote a blog post explaining what I did and why. State is handled in a trait-like manner, which is what I use to differentiate between planning, jumping, falling, etc.

I'm busy working on my own projects, one game in particular, but I'm relatively responsive to submitted issues (the ones I put off are the ones I create). PRs are so very welcome too, but I haven't received one yet. There's always something that can be refactored, optimized, made more readable, etc., and I would love to have help. My project is basically the spiritual successor to the old nav project mentioned by @Joachim_Ante.

 

Appreciate it man, I'll look into it.
This seems like the right package for me,
thanks for sharing!

 

I also have a pretty thorough pure dots solution for nav meshes - it's basically a re-implementation of
NavMeshComponents in pure dots including full conversion as well as dynamic runtime updating of the navmesh (using change filtering).

I've been meaning to post it for a while but I just haven't had time to polish the remaining few features I've wanted. For example, here is the NavMesh for a single agent built from huge subscene.



One day I'll get around to releasing all my projects....

-edit-

couple more screenshots. supports multiple sized agents on the authoring (and you can see I replicated most of the NavMeshComponents UI)



each agent has it's own graph

 

That is awesome @tertle I hope you find the time to release it at somepoint

 

i was recently working on something similar

but seeing this thread just made me want to scrap the whole project and wait for you masters to finish what you have

i', looking forward for you to finish your project

 

Great to see cool solutions, keep 'em coming!

 

So I have AI system using the traditional routine of accessing of NavMeshAgent on the main thread via ComponentSystem. On a quick test, 300 agent moving on navmesh this way have a total average navmesh call time of 1.3ms. So far I haven't need to touch the low level NavMesh API as it is not really effecting anything and I am ok with Hybrid ECS.

 

hello there

any updates...?

 

@jdtec asked me yesterday if I was close to releasing this and if it was available. Well I haven't touched it in months but I happened to start working on it again yesterday.

I've attached a copy of the relevant code from my navigation package if anyone needed some reference material. I'm in the process of refactoring/changing it a lot so stuff is missing and it's very rough.

Notes:

• It won't compile without some work (it's missing some basic extensions from my core library I am not providing but shouldn't be hard to implement yourself.)
• It's in no state for public consumption and I will provide no support
• I'm not even sure the current iteration even works at runtime
• The nav mesh query system is not provided at the moment (I'm mid rewriting how it works)
• This iteration does not support links
• I only just made it generate the navmesh during conversion (instead of at runtime). This reduces loading but makes live link a bit useless as it'll make every change take a few seconds extra. I'd highly recommend turning it off for now. I'm researching a better alternative at the moment.

I'm simply providing it at reference material if someone needs ideas on a way of implementing it.

How to use:
If you get it compiling, all you need to do is add a NavMeshSurfaceAuthoring component to an object in a subscene and it'll generate the navmesh from its children. You can add this multiple times to the same game object for different actors and it'll generated separate nav meshes.

There is a NavMeshModifierAuthoring to change how certain meshes in the children behave (can make some block etc).

If you want a properly supported version, maybe I'll have something in a few weeks/month.

 

Thanks for posting @tertle

 

I am working on a job system pathfinder based on dynamic connected nodes with an influence radius (sort of A* but a little more primitive because it is not for a grid). It will redraw paths if blocked and find alternatives if possible. It also adds precalculated paths to a lookup array O(1) based on start and end to avoid having to calculate it again if the path is available. The paths are created in an IJobParallelFor using some ridiculous 1D-array manipulation. It's currently being called from a MonoBehaviour due to testing and project legacy issues, though.

However, the loops are not vectorizing and it doesn't seem to be a way for them to do it. I even tried something as silly as setting the for-loop index to the loop length for early exiting using a math.select(). I wish I was smart.

I can post this a little later once I have tested it enough. I can add some screenshots too.

[Edit] Screenshottes:

Here it shows a little how it works where cyan is a calculated path and yellow is a lookup path.

This shows a cached path with backtracking in red (excuse the nodes they are just for testing).

It's a bit hard to tell from the .GIEVES above but is in 3D:

A couple of findings about this:

1. It's rather light even though it is not vectorized.
2. I wish I didn't have to do this.
3. I learned a lot about 1D-array manipulation that I also wish I didn't have to do.

4. 
   
   distance = distance + NodeDistances[ConnectionsLookup[(amount * node) + path[arrayNode + ((e + 1) % count)]]]; // This is so that TraversalPathTotalDistance can be [WriteOnly]
   
   

 

On the Unity asset store there is an asset called A* Pathfinding Project, which has a lot of advanced pathfinding features. One of the features I like most is that it only requires one graph instead of multiple graphs for different agent sizes (there is a funnel path modifier that can be used instead). It has multithreading and uses burst so path searching is fast. It supports grid graphs as well as navmesh graphs (with navmesh cutting). There is also a module for local avoidance.

The bad news is that it was built around OOP and monobehaviours without a low-level function API, so it requires converting a lot of classes into systems and components in order to get it working with ECS. I was able to get some very basic functionality working in ECS (and I'm a terrible game developer). A few people were able to get local avoidance working. Unfortunately, what I have so far isn't quite game-worthy yet, but "if" I get it working, I'll put what I have into a git repo.

 

I have a really simple burst/job friendly astar implementation that I use in my roguelike

https://github.com/sarkahn/dots-roguelike/tree/master/Assets/Lib/Pathfinding

It's nothing too fancy but is pretty fast in burst for small maps (slows down a lot around 500x500) and works well for my use cases.

 

Did you ever post it?

 

Nope because I decided to implement my own version of Recast for pathfinding instead to give myself a lot more control and access to the raw data.



It works pretty well - can generate at runtime from pure Entity data. Can query for paths, raycasting, supports multiple agent sizes etc.
However it's still needs an optimization and usability pass but due to focusing on other parts of my library (mainly AI) I haven't worked on it in a few months.
I'm actually looking at doing a showcase of everything in a week or so when I've finished the AI UI polish. I basically have a lot of systems working together really beautifully but realistically I don't expect this navmesh implementation to be polished for at least 6 months.

 

What's the status of your navmesh solution these days mr tertle?

 

Unfortunately not much apart from the fact it still works. I've been spending time polishing other areas (AI + general application architecture). Unlike some of my other libraries I'm working on I've never been committed to this navmesh library as I'm not certain what Unity has planned.

 

Recently I have been working on my own custom agent local avoidance system that includes many more behaviors when what built-in navmesh agent offers. Currently it is written in DOTS and now I am working on ECS implementation that would use this Low-Level Navmesh API for jobified solution.
For those who interested https://forum.unity.com/threads/local-avoidance-3-0-0.1299813/ (Currently there is not much infor about navmesh there, but I plan to post changes).

In past I also did ported fully NavMesh into DOTS (whole navmesh is serialized into blobassets):