NavMesh2D - Navmesh generation and navigation for your 2D projects [Coming soon]

Please refer to our release thread!

NavMesh2D for Unity

Click to enlarge​

NavMesh2D is a tool to generate and navigate navmeshes for 2D projects. It is designed to work very similarly to the built in Navigation tool which unfortunately doesn't work in 2D.

It is quick and easy to set up your navmesh with NavMesh2D. You can generate your navmesh in 3 steps - specify which layer contains your floors, specify which one contains your walls and hit bake.

Features

​

Seamless Integration
The tool does not use any special colliders or 'helper scripts' that need to be attached to objects around your scene. It works with Unity's built in colliders (Box/Circle/Polygon). Your gameobjects will get processed if they are a 2D collider on either the floor or wall layer. Thats all there is to it!

​

Tolerant
NavMesh2D is extremely tolerant of overlapping colliders and 'messy' scenes. You don't have to be 'pixel perfect' with all your placements. NavMesh2D will collect all of your colliders and crunch away on that data to spit out a clean navmesh.

​

Full Control
You have full control over how much padding should be applied to the navmesh and you can also pick from 3 different corner/edge types. You can also bake a grid with a specified resolution into your navmesh to improve path finding results.

​

 

Are you planning to support pathfinding for a 2D platformer?

 

No, NavMesh 2D will be top down only. In the near future, we do have plans to release a tool (called Node Networks) that allows you to easily create node networks manually/by hand in the editor. It will use the exact code that we have layered NavMesh 2D on top of. Node Networks won't generate a navmesh for you, but you can place down nodes on the platforms and connect them up together yourself to form your 'navmesh'. It is still in the works, however, and we plan to release that separately (and for free!).

 

Would this work for procedurally generated maps, ie maps not created in the editor but rather at run time?

 

Currently, no. You need to bake the navmesh into the scene, same as with Unitys 3D navmeshes. We do have plans to go down that route as it would be nice feature to have for endless runner or rouge like games. We need to overcome a few technical hurdles first before we make the functionality available at runtime. For example, we need a way of stitching navmeshes together. Until then you will have to prebake all your navmeshes into the scene

 

Will this support dynamic obstacles?

 

Hey Scorpion, it won't be supporting dynamic obstacles any time in the near future. The focus right now is moving towards run-time mesh navigation.

 

you could have posted this in my thread http://forum.unity3d.com/threads/239875-external-mesh-building-application

i was searching from head to foot of google for finding a mesh building application like this

do you like making games or not?

cast your vote at my other thread http://forum.unity3d.com/threads/239876-do-you-guys-enjoy-creating-games

 

Moved. http://forum.unity3d.com/threads/151487-Unity-Developer-Network-Rules

 

Hello!

I've been testing the system and its neat n_n.

I do have a question though, I wonder if there is a way to find a path, even if I try to reach outside the generated navmesh. Of course it will never each, but I wonder if I can somehow try to "go as close as you can" to the point in the end position?

Thanks,

 

I actually managed to modify the code to find the solution I needed n_n.

Here it is in case you might want to add it to the system .
This doesn't work when trying to reach in a place that has a blocker inside though, only when outside the collision mesh... I guess some more experimenting and might make it work with internal colliders .

Code (csharp):

1.  
2. /// <summary>
3. /// A smoothed path from start to end. will attempt to get as close as posibile
4. /// </summary>
5. /// <param name="startPosition">The Start position</param>
6. /// <param name="endPosition">The End position</param>
7. /// <returns>A list of points, order from start to end</returns>
8. public static List<Vector2> GetClosestSmoothedPath(Vector2 startPosition, Vector2 endPosition)
9. {
10.     if (instance == null)
11.     {
12.         Debug.LogError("NavMesh2D: Scene does not contain a 2D NavMesh");
13.         return new List<Vector2>();
14.     }
15.     List<Vector2> resultingPath = new List<Vector2>(0);
16.     NavMesh2DNode startMesh2DNode = GetNavMeshObject().ActualClosestNodeTo(startPosition);
17.     NavMesh2DNode endMesh2DNode = GetNavMeshObject().ActualClosestNodeTo(endPosition);
18.     if (startMesh2DNode != null && endMesh2DNode != null)
19.     {
20.         resultingPath = instance.SmoothedVectorPath2D(instance.GenerationInformation.ColliderPadding, startPosition, endMesh2DNode.position, instance.GetPath(startMesh2DNode, endMesh2DNode));
21.     }
22.  
23.     return resultingPath;
24. }
25.  

EDIT: Managed to make moving as close as possible when inside collisions work as well. You an do ti by removing the layer collision checks in NodeIndexQuadTree.cs. Of course the best approach is to duplicate the methods and create your own ClosestSmoothedPath version or something, so you don't destroy anything coded inside