A Unity ID allows you to buy and/or subscribe to Unity products and services, shop in the Asset Store and participate
in the Unity community.
Discussion in 'AI & Navigation Previews' started by Onigiri, Oct 10, 2019.
Hi! I would like to know i there any plans to make DOTS compatible pathfinding system and agent?
We will be moving navMesh to DOTS in 2020, together with some code re-org and new features. It 's a long undertake so we do not have a delivery date yet, but work will start in January of next year.
what's the alternative if we want to do navigation in ECS?
There is a NavMeshQuery API, but it's limited ATM
thanks. any examples I can quickly evaluate?
Here's one https://github.com/zulfajuniadi/unity-ecs-navmesh.
Basically, for NavMeshQuery, you instantiate an instance of it from a NavMeshWorld, which you can obtain through NavMeshWorld.GetDefaultWorld(). Put the NavMeshQuery instance in a job, and call its API. The API is very incremental - you have to call, in order, BeginFindPath, UpdateFindPath (this one multiple times if needed), EndFindPath, GetPathResult, each of which returns a PathQueryStatus, which you can use to check how well the pathfinder is faring. There's more in the official API documentation. Unfortunately, GetPathResult only returns an ordered list of PolygonIds. Fortunately though, you can use https://github.com/Unity-Technologi...ressTesting/Assets/Scripts/Utils/PathUtils.cs to turn the list of PolygonIds into a list of waypoints! PathUtils is even jobifiable and burst compatible with a bit of modification. Overall, while far from complete, there is just enough code and libraries out there to achieve DOTS navigation.
Even once you get the straight path it's still in 2D not on the surface, you have to use yet more low level api's to do it correctly. All told it's a lot of work to get a system working to the equivalent of the standard navigation api. Unity's own demo's don't do it all right, none of the user submitted open source stuff does it all right.
And it doesn't handle the crowd logic, so there is that.
Just to be informed before diving into it.
very low level, very nice, thanks for the details
You can use my DOTS navigation code as a UPM package, if you want.
Technically, the source code is located in my my Unity monorepo on GitHub. I wrote a blog post explaining how the nav code generally works. At the very least, you may be interested in seeing how I orchestrate NavMeshQueries via a Burst-compiled job in my NavPlanSystem.
PRs are welcome. I've gone ahead and documented some known issues here as well, which I would love to collaborate on.
Hopefully this helps.
Hi. Any new update?
No update to share.
This is very interesting dude, thank You!
Does anyone have any knowledge as far as how to make the path travel along the NavMesh surface rather than directly between the points?
Hi, just wondering if there will be a preview package soonish or am I better off going with reeseschultz' work around? Don't want to redo a lot of work if it's due shortly.
Many thanks, keep up the great work
No, there won't be any Navigation package published any time soon.
Sad. There are still plans for dots navmesh in the future or it's has been cancelled?
either the rats are leaving the ECS ship (unlikely) or something radically new and awesome is about to happen like full voxel based GPU realtime navmesh (also unlikely)
either case stick to today's tech, we know the bugs and monobehaviors have tons of life left in them
We continue working on aspects of DOTS NavMesh but we don't have news to share at this point.
any info on DOTS navmesh ? can we expect anything for 2021 ?
I'm pretty sure the internal plan for public preview release has been moved to 2021 but depending on what obstacles they have to overcome it could very well take even longer than that.
Does it generate navmeshes at runtime?
My package relies on the existing tooling for NavMesh generation. As you may know, that can take place at authoring or runtime. I wouldn't recommend much runtime generation with the existing tooling, but if someone were to DOTS-ify generation with the new mesh API, then that would make a huge difference in terms of performance. I don't have the need for runtime generation in my other projects (and thus no incentive to implement it), but if someone were to create such a package I would be happy to integrate mine with it. I'm also open to PRs.
In my demo scenes, such as the one in the quote, I'm showing that nav meshes can be transformed (without being regenerated). Really, all my code is doing is figuring out how the agents should move in conditions such as that. In "normal" conditions, you can just think of it as multi-threaded, 3D path-finding.
I see, well i could take a look!
Hi @adriant. Any new update? What's the ETA of releasing preview package?
Hi, I don't have any news. It's still too early to talk about a preview package.
Any News or Updates yet?
My project is still waiting for the DOTS-NAV-MESH!
Any update on DOTS navmesh? Any rough estimates for the preview package? 2021? 2022? 2023?
Checking in again to see if DOTS is coming to unity navmesh. This is a must have IMO for any game that is larger then a few units and a small area.
I think at this point your are expected to write your own ECS navmesh from scratch...
That's fine I suppose. It looks like it's been done a few times.
Hi @adriant. Any new updates of DOTS Navigation first preview package version soon? Is that implemented in pure DOTS way?
@adriant any chances we will get something with DOTS 0.5 or 1.0?
Any updates on this?
@reeseschultz Is it possible to do navmesh cutting at runtime with your package (like when the player places a building in an RTS)?
RIP DOTS Navigation
Hey @lclemens. In my GitHub repository, there are two packages at this time: navigation (heavy) and pathing (barebones). Both of them are interoperable with (and depend upon!) Unity's conventional NavMesh tooling, so stuff like obstacle carving is supported. Use these packages at your own peril, as they depend on experimental APIs. Be aware that I'm considering big changes for the future of my Unity packages, including how they're maintained.
@Onigiri, navigation is a massively broad umbrella term for a plethora of divergent use cases (hence why I regret the name of one of my packages). I'm of the opinion that Unity should not build a monolith; they should focus on low-level, DOTS-compatible tooling, so folks can use it to make purpose-built middleware. This product board seems to indicate that low-level APIs actually are the focus. Note, for example, the "queryable navigation model," where the plan is to have:
An enhanced set of API methods for querying the navigation data in greater detail than before, compatible with Unity’s Job System.
I have concluded that it is enough for Unity to reconcile NavMesh and grid-based, low-level APIs, with Jobs and Burst. I am highly skeptical of incorporating ECS into any low-level or middleware solution, at this point, because there are two major ways to use it. There's the approach I prefer, which is basically using components in terms of state machines (I wish we had a GUI for that). To my knowledge, that approach is, however, less performant with Unity ECS' memory model than maintaining the same set of components on an entity for its entire lifetime. To understand this issue better, please see this blog post comparing two Rust-based ECS frameworks, Specs and Legion. I am aware of a technical solution that accounts for both approaches; I believe it has been (or is being) incorporated in Legion, which is used in the Amethyst game engine. Someone correct me if I'm wrong.
Anyway, for Unity to build out a high-level navigation solution, users would likely expect components and systems, in terms of ECS, to go along with it, not just for it to simply be compatible with ECS. I built something with ECS, literally for free, and users were still dissatisfied because they disagreed with my assumptions/opinions. I am convinced there is no way Unity can do something similar without major backlash, so I would warn against it, at least without a few more years of R&D. Third-parties can build out middleware in the meantime that caters to different audiences via open source, sponsorware, the asset store, etc.