Hi,
It seems that the navigation mesh is bound to the x-z axis while the new 2d physics and rendering is performed on the x-y axis. Are they completely incompatible?
Thanks
2 Likes
A very important question. I too would like to know how we can get around this.
I agree, this is the biggest thing holding us back from switching right now.
What Iâd really like to see to an option to turn the whole 2D system to work on XZ instead of XY. Then we donât have to recode and remake every asset in our top-down game in order to transition to the new system. It also fixes the NavMesh issue.
I should also note that behaviour such as LookAt doesnât work properly in XY. The ability would go XZ would again fix this.
1 Like
Agreeâwould be really nice to be able to switch Unity2D to XZ for top-down games. Iâm currently working in 3D so I can have pathfinding.
This is exactly the feature that should be implemented, either that or some way to do 2D navigation.
Unless there is already a work around that Iâve completely missedâŚ
Hi there, quick question:
What is the current method of performing navigation in 2D top down game development in Unity, could someone point me in the right direction?
(I have googled it)
Think itâs a great idea.
Maybe I am missing something here but I donât see where the problem is. Since 2d only uses two dimensions, where does it matter which ones you use? Its an just a visual abstraction anyway (âdownâ is always toward the enemy gates). If you really need to the 3d navmesh for a 2d game (which seems a bit overkill), whats wrong with simply rotating the camera and assets? And I donât see how LookAt would be âfixedâ as with 2d your camera is always going to always be perpendicular to the viewing plane. Rotating in any direction around the relative âzâ is 3d, not 2d.
Also, why would you have to rebuild/recode all your assets? If the game already is coded and built, why redo it? Most the new 2d features are to ease production, none are really ânewâ. What benefit would there be to redoing everything?
Whatâs overkill about wanting pathfinding in a 2D game, exactly?
Box2D only works in XY.
Most of the methods like this manipulate transform.forward. In pure XY, transform.forward is meaningless (it is not related to any visible direction of an object), so any such methods must be redone manually assuming transform.up is actually the forward direction of the transform instead.
No itâs not. Z is just a letter. If I have two letters representing a graph, one of them is X (representing what appears to be âhorizontalâ and the other is Z (what appears âverticalâ on the graph), I still only have two possible dimensions.
Box2D is a huge performance benefit to 2D games. For us, it means the difference between mobile platform targets and not.
Anyway, weâve just sort of accepted it, and been converting everything over the past month. Itâs a lot of work but 80% done now. Moved to AAronâs Astar implementation for pathfinding. My main issue now is that there are giant game-breaking bugs in the Box2D implementation that need to be fixed before moving forward.
As fas as I know thereâs currently no way to do it. NavMesh works on the XZ plane, while Unityâs 2D mode is XY.
An alternative would be to look at the other pathfinding solutions on the Asset Store, since most of them support any orientation.
bump Iâd also like to see this be integrated into future versions for any top-down (or similiar) games.
A 2D navmesh implementation would really be awesome. 
Bump too. For both the pathfinding and the fact that LookAt has a weird behavior when using XY axis
For a quick fix I made a Gameobject use look at and made the sprite a rotated subobject so that the direction fits the XY plane. I would not recommend this for anything final or other than testing, though. Itâs a very hack-ey quick solution 
Just to add my 2 cents⌠I think there could have an option to simply swap the z by the y axis but keeping some functionality (perhaps as an option) so you could use box2d and navmesh and stuff like dragging and dropping sprites (only works when youâre in 2d mode (x+y).
Imho itâs much easier to work with x&y for 2d but when talking about 3d, it just doesnât make sense in my head that the y axis is the vertical one, I know some 3d packages like maya have this same approach but it doesnât make much sense to me because besides Iâm extremely used to z being the vertical axis, in things like topology and stuff the z is always the vertical, the only exception I know they use the y as the vertical axis is in cinema because generally the thing is relative to the camera and stuff, and in this case it does make sense that the z axis for a camera is the axis going in the direction the camera is facing, but in a âglobalâ approach, the z axis should be the vertical imho.
Itâs a real pain in the bit to use most 3d modellers and Unity.
Is there any update on if/when weâll get a native 2D pathfinding solution in Unity? (for top-down games using 2D sprites and Box2D physics)
Also, are there any plans to implement the ability to generate NavMeshes at run-time? (for procedurally generated levels)
Bump. Anyone knows if a feature that turns XY/XZ axis is coming in 4.6?
In a few official threads about feature wishes this topic came up and I think Graham (?) loosely said that 2D pathfinding is in the works and will be an upcoming thing in some version somehwere down the road. No timeframe given.
From what I understand it will be coming some day. Until then if time is pressing maybe you want to look as one of the pathfinding solutions on the Asset Store. Some have a free release with less features but it might just be enough for your project?
The idea is posted here:
http://feedback.unity3d.com/suggestions/make-2d-work-with-navmesh-and-terrain
The feature is in research
Here is a tutorial, that shows you how to use the NavMesh system with 2D sprites, if you are interested.
@Artifactx Its a cool idea, but the methodology creates quite a bit of mess under the hood.