Any official word on the future of Navigation?

Hi all,

There are many [Official] forums dealing with terrain, particles, input, etc. But I haven't seen one dealing with navigation.

Is there one?
If not can the Unity mods/devs start one?

IMO navigation has been mostly unusable unless you're using it in the absolute simplest way, ie. pre-built (mostly static) levels with similar-sized characters.

I don't want this to become a rant, so some sort of indication of official interest in this area would be great! With feedback of strengths weaknesses of the current system.

Thanks!

 

All i've heard is that they're planning the Nav update in a point release somewhere in the 5.x cycle.

It would be cool to have more specific info. Are they actually even taking suggestions on it? There is really just plenty of stuff they could do to update it across the board so maybe they've decided to skip on the community feedback and just get what they know needs to be done knocked out first.

I managed to get some decent use out of it. You definitely have to roll some of your own solutions where other addons offer it built in.

 

Currently we’re working on a couple of things:

. multiple agent sizes for navmesh - supporting a discrete number of agent dimensions.
. runtime adding/removing navmesh data - supporting translation and rotation.
. segment-to-segment links (currently OffMeshLink is to point-to-point).
. low-level API for runtime building of navmesh.
. build navmesh based on volume selection.
. build navmesh based on physics geometry.
. build navmesh based on layer selection.

I cannot give any guarantees or dates on any of these feats. at this moment - as things will likely change.

 

Great upgrade scope. All of that is welcome improvements esp. runtime build navmesh and agent sizes.

Thanks for dropping by to mention it.

 

@Jakob_Unity That's awesome! I can't wait. You've pretty much addressed every annoyance I've had with navmesh

I particularly like the ability to build nav meshes on physics geo, in many cases it would give more accurate results.

Will these systems support lazy-building of NavMesh (either natively or via script)? ie. NavMesh patches get built when an agent approaches a patch that hasn't been built yet?

That way we can have a dynamic level load, only build patches immediately around agents, then as they wander, the new patches get built when needed.

So happy right now it's stupid!

 

@Wahooney
yes - local (re)builiding is one use-case we have in mind.

 

\ /

 

Will 2D Navmeshes be on that list as well?

 

@the_motionblur
By 2D navmeshes - you mean better integration with the Unity 2D feature set ?

We don't have features specific to 2D planned - but the upcoming navmesh translation/rotation will allow you to have e.g. top-down view of the navmesh in 2D mode - as opposed to the current fixed 'edge-on'

 

@Jakob_Unity Thanks - yes that's what I meant. I was trying to make an Alien Breed style game in 2D with 4.x and when I finally bought Pro I was kind of disappointed that navmeshes would not work. Also for other things like homing missiles in sidescrollers etc...
The features don't have to be 2D specific but they should work in 2D somehow.

 

The biggest things that we have run into that would help immensely:

Dynamic areas, something similar to an obstacle but it only overrides the area instead of carving. Example: a fireball spell creates a burning area on the ground. I temporarily want to increase that area's cost until the fire goes out. This would cause agents to path around it to get to the other side but still walk through it if they had to to reach their destination.

On that note - per agent area cost overrides. I want to be able to set my Fire Elemental to have a 1 cost for the "Fire" area.

NavMeshAgent.CalculatePath needs an option to take other agents into account. Right now the returned path ignores other agents. So if I want to pre-calculate a path to show the user I have to create temporary obstacles on top of all other agents. This is really janky and causes weird popping and all other kinds of crazy unintended side effects from turning the other agents and their carved obstacles on and off.

A terrain nav painting tool. We typically have much bigger terrains than we want walkable so if we could have a single splat layer to paint which areas of a terrain should be walkable would have saved us a ton of time and problems. We ended up writing our own nav masking tool that creates a copy of the terrain heightmesh sets it to not walkable and then we delete verts so it becomes a mask.

Offmeshlinks that could be bidirectional but be able to turn off one direction at a time. Example: I want 2+ agents to climb up a ladder one after the other. So the up direction should still be enabled ( with agent radius & height taken into account for proper spacing ) but the down should not until the ladder offmeshlink is not being used anymore. I managed to replicate this with a wrapper that monitored 2 separate OMLs (one for each direction, up & down) but it was a tangled mess.

 

This please, I need it!
Any chance/hack that could enable the use of the NavMeshBuilder on a build right now?

 

Really looking forward to this. Hope it works with some form of LoadLevelAdditive and translating that scene wherever we want.

 

Did you think of putting a Trigger Collider at the top of the ladder and setting the agent priority to a higher value in OnTriggerEnter and restoring it in OnTriggerExit (when agent starts down the ladder)? Agents climbing up with a lower priority value would block the ladder for the ones at the top so their avoidance would make them wait out of the way.

Just a thought, YMMV.

 

A few runtime navmesh questions (think city builder):

I have landmass that contains a river, and then I add a bridge over the river, will that bridge be able to become navigable?

When adding something such as a walking path/road will I be able to tell items that using the path is more desireable than walking off of the path?

Will I be able to add navmesh to a prefab, then when that prefab is added to the scene (runtime or not) it becomes apart of the nav mesh?

 

This already works - just select it and mark it Navigation Static and bake the navmesh again.

This already works - in the areas tab of the navigation window define additional areas with higher cost, and assign them to the terrain or other mesh renderers you want penalized.

Navmesh is defined for the scene...it's not a game object.

 

@MrG, those don't work at runtime.

 

ahh sorry @TheLittleGuy I overlooked that point in your question.

 

@superpig, cool! Is there a release version ETA on this?

 

Did 2D navmeshes disappear from the roadmap list?
Is this still in the works or should 2D Folks better settle for A*?

(edit) or is this the planned feature for 5.4?

NavMesh Surface component describes a volume where the navmesh will be build, you can have multiple volumes, in any orientation​

 

Yes

 

Okay ... cool. Thanks

 

Is multiple agent sizes for navmesh still a planned feature ?
I don't see it in the roadmap.

 

Hope you don't mind me chiming in.
I'd really like to see the ability to give terrain textures a navigation cost.
It would make it greatly improve our level creation productivity with the ability to add specific navigation costs to surfaces like mud, rocky areas, marsh land just by the texture.

That way agents might be more inclined to take easier routes like roads, paths etc with very little work. Without the need for separate terrains or the use of individual meshes just to define different walkable cost areas.

I appreciate this is probably not straightforward to implement.

 

What about agents pushing each other? I thought this is the most desirable feature for NavMesh.

 

Sorry to bother, But I was not clear on the idea of having prefabs with navmeshes. For example if I build a room with multiple height changes and then bake the navmesh for the room can I save them together in a prefab. This would be immensely helpful for procedural content that selects prefab rooms at runtime. My current work around is using navmesh carving but that makes stairs or ramps not possible and leads to simple design.

 

I don't see anything that supports AI decision. Navmesh.Get/SetCustomValueAtPosition ("value name", +3, position, radius) and NavmeshAgent.AddCostToCustomValue (-0.5f, "value name") would be very handy.
Also there is nothing covering moving navmesh, I assume that's handled by the new volume API right?

 

+1