Resolved How to use NavMeshQuery in Entities.ForEach?

InvalidOperationException: OnUpdate_LambdaJob0.JobData.navMeshQuery is not declared [ReadOnly] in a IJobParallelFor job. The container does not support parallel writing.

Ok... so there is no parallel writer version of NavMeshQuery? How do I use this?

 

I guess there is no way to do it. I schedule the pathfinding jobs in parallel with Entities.ForEach then use NavMeshQuery in Job.WithCode to calculate the paths.

 

A query has query specific data, so no you can't use it concurrently.

I would focus on getting a simple flow working end to end, including agent movement over some surfaces with angles and slopes and such.. There is a substantial amount of domain knowledge here that you likely haven't discovered and you need to know before you can even get a simpler flow setup correctly. Then you can optimize.

Like paths are not on the navmesh surface for instance. There is a concept of a detail surface so the flow is you get the path and then query the detail surface using MapLocation/MoveLocation as you move the agent, to keep them on the precise surface. That naturally impacts your larger flow, your agent movement code needs access to the query.

The pathfinding results are also not straightened. That's another thing you have to do. The Nordeus demo has code to handle that.

Also suggest you google ECS navmesh. There is more then one github project out there that has most of the pieces you need, although some never got far enough themselves to discover stuff like the detail surface.

 

@velenrendlich one thing you can do is, on startup, create as many NavMeshQueries as there are threads available and point to them, then you can read/write to them in a job by thread index that leverages Experimental.AI extensively. It's unsafe so the thread indexing is critical. Btw, that code I'm sharing is actually part of a UPM package you can install if you want. Or just use the code for guidance if that helps.

There's other ways that are less hacky, but likely far more involved.

Alternatively, if you created a DOTS-friendly replacement for, say, Experimental.AI or the NavMesh implementation, which is the "best" approach, you'd not only have a tremendous amount of design, programming and maintenance to do, but you'd end up engaging in what I assume is serious duplicative effort being performed by an entire team.

Unity is working on some kind of nav-related thing. That said, I have no idea what that is, and there's been nothing of substance shared with users, not even like a gif of a potato navigating a maze, so we'll just have to keep refreshing this forum post. With that in mind, if I were you I'd try to hold out for now with my package, or something like it, rather than jumping down a rabbit hole. Ultimately if you're an indie building a game, you don't want to spend all your time building tools to make your game. It's (ideally) the responsibility of the game engine to provide those tools, that underlying foundation, so you can stay focused on business/game logic.

 

Thanks for the replies guys, I just wanted to know if it was something trivial I'm missing not that I worry about performance right now. I used the FindStraightPath you mentioned from the Unity demo (but I'm getting random exceptions for some cases and I'm not sure why). I'll definitely be checking @reeseschultz 's source to get some ideas.