- Home /
Painting or assigning NavMesh area's on terrain
I have been experimenting recently with the NavMesh and agents for my RTS game. As neat and awesome that it is, the NavMesh feature seems to be biased toward games where the navigation is object based and not so much terrain. And I say this because you cannot define areas in on your terrain since there are no objects to specify as terrain.
I have looked at the NavMesh Components library but it requires that you add objects all over the place that you want the baking to consider, which is extremely tedious and impracticable for a larger terrain map.
The feature I see lacking is the ability to paint or assign areas of a baked nav mesh that are not objects and I am curious if there is a way to do this?
The main reason I ask is because I want to be able to make the navigation across rough terrain less desirable than say a road or grassy field. I also want to dynamically change the areas based on the assigned use. Such as a grassy field becoming farm land so obviously shouldn't be walked through.
If this is not possible, what are some other solutions that people have used to create their own 'nav mesh' per say. At this time it seems that creating my own navigation system will be required that allows me to paint out areas on top of my terrain.
Any and all suggestions and guidance is appreciated.
Answer by B3Designs · Apr 01, 2021 at 09:51 AM
I don't know if you're still on the lookout for this, but I got around this problem by scratching terrains completely..
I created a reasonably detailed plain mesh in ProBuilder, edited the rough geometry and used PolyBrush to fine tune. I subdivided selected faces further in the areas of high detail, and used PolyBrush vertex painting (not quite as good splat maps in terrain editor, but it gives an acceptable result if the mesh is detailed enough). I then went back into Probuilder, selected and extracted the faces I wanted into separate meshes.
Give these separate meshes the relevant navmesh layer and you're good to go...
This does work better with a more 'low-poly' graphic style, but you could (theoretically) apply smoothing in ProBuilder - Can't advise on this as I didn't need to.
Might help you out, or might help someone else looking for a similar solution.
Danny
Answer by I5 · Oct 18, 2020 at 08:18 AM
As far as rolling your own nav system, I would put at least a few days of effort into using Unity's Nav system first.
Some suggestions/work-arounds: 1. Look into Off Mesh Links (https://docs.unity3d.com/Manual/nav-CreateOffMeshLink.html), you may be able to set properties at runtime (https://docs.unity3d.com/ScriptReference/AI.OffMeshLink.html) to alter the nav of a char. Haven't done a lot with that though so just an idea. 2. Have you already looked at https://docs.unity3d.com/ScriptReference/AI.NavMeshBuildMarkup.html? 3. If you need something super runtime dynamic and flexible, maybe try incorporating some custom path logic with Unity's. For example, have char raycast across terrain and each different terrain type could have a large invisible trigger collider that has a name/id/layer/whatever that's unique to it's terrain type, and have logic to set the next destination/waypoint accordingly. This would require each terrain section/type to have known nav points on it though, as well as logic to calculate shortest vectors. This may have been what you were already referring to though.
Answer by DallasP9124 · Oct 19, 2020 at 09:29 PM
I have looked at links but they are for linking/joining navigation between different meshes. Since the terrain is essentially one big NM, these wouldn't help my use case.
The markup tells me what I already figured in that the NM works with objects, not arbitrary places on a terrain or space. I could set the area with the markup but it still want's objects as a whole, so that wont work either.
So pretty much create my own nav mesh...
its such a shame they have two awesome feature tools but they are not really designed to work together extensively. The NM could be so much more attractive if you could manually define arbitrary areas.
I also looked and tried using the NavMeshComponents package but I wasn't able to get it working and keep finding dead threads saying it's not really maintained even though they make it Unity version comparable.
The nav mesh link solution inferred breaking up your terrain with "un-navigable" areas, and then linking them at runtime. The suggestion was half-baked in my $$anonymous$$d though so it very well could be a dead end. I like the challenge of the problem your facing so I'm curios to see what will work for you.
in re "it still wants object", is "it" referring to the navagent, nav obstackle, terrain?
I don't think creating your own nav mesh will solve your problem. If you want runtime decision making based on dynamic and variable terrain (as opposed to baked), I think you're needing custom "path finding", which is very much distinct from the nav mesh. The reason I would avoid trying to write a custom nav mesh and/or nav mesh agent is that you'll potentially lose core/key functionality provided by the Unity's (slope, obstacles, skin width, inter-char nav coordinating and avoidance, etc). I'm guessing there's a very good reason why unity engineers don't already provide this, LOE will not provide the ROI, or, the typical cpu will simply not provide the cycles per second (pathfinding is very cpu demaning, thus the baking). This is the logic that lead to a hack'ish solution for leveraging and maybe extending Unity's path finding. Would raycasting across the terrain for different terrain "types" not work?
@I5 "it" referes to the Build $$anonymous$$arkup and related classes. Looking into the Nav section of the Scripting References, the methods are mentioning the Objects that the area is applied to. This confirms my suspicions that the Area's are only assignable by Objects and are not arbitrary.
Well, a nav mesh is meant to give weights to places to help the pathfinding make good decision on path and if I cant do that with terrain and Unity's Nav$$anonymous$$esh then it defeats the purpose of using it for what I want in my game. I am not looking for crazy dynamic path finding or runtime re-baking just the basics with terrain and area's.
I think the hardest part of doing my own mesh would be the mesh building itself, using my own baking mechanism and search algorithm, I have done A* several times and the algorithm is not that complex.
The raycasting method could work for simpler/shorter paths but I can see it fighting with the Nav pathfinding quite a bit since it wont take into account my opinion and essentially would have to incorporate my own nav logic to work with it. Not sure if thats the way I want to go.