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
This project is using the lowlevel navmesh API to do path finding against the existing NavMesh assets.
https://github.com/zulfajuniadi/unity-ecs-navmesh
It is similar to what we did a couple years ago in the nordeus demo:
The github project linked above is using a very old version of entities, so likely upgrading it is not a great idea. But i think reading the code to get an understanding of how to use the low level API in practice might be useful.
There is currently no supported high level API + Samples for NavMesh & navMesh agent use in unity.entities.
But you can put it together yourself using low level API’s.
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_1 .
Appreciate it man, I’ll look into it.
This seems like the right package for me,
thanks for sharing!
@reeseschultz Sweet that looks really nice.
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:
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:
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
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.