Welcome! - New NavMesh Features Experimental Preview

Nope! I'd assume that would fail.

I'm planning one of these:
- post-process the built navmesh, either to just read out the generated polygons to generate interesting metadata about the navigation surface, or to actually change the polygons in some way
- Build a navmesh from scratch without basing it on renderers or existing geometry.

 

What if our game worlds are large and need to be divided into a grid, stored in a format other than unity scenes or randomly generated?

 

Anyone answers about the angular speed issue in the new implementation of nav agent?

 

Hello,

Trying to get this working in the newest 5.5.0b11, but getting a lot of errors. Anything I'm missing?

Screenshot attached

 

You'll need the experimental build of Unity - it's based on 5.5, see the

https://github.com/Unity-Technologies/NavMeshComponents#how-to-get-started

 

. API for extracting polygons is from navmesh is planned - but not in development yet.
. You don't need to have renderers or colliders to build a navmesh - you can use the Mesh class directly - maybe i should add an example with that (check NavMeshBuildSource struct)
. Actually changing the generated navmesh is not planned so far - what kind of post-processing do you have in mind ?

 

I cannot see a difference. Please report a bug with reproduction steps - and i'll have a look .

 

I'm not sure what the question is - can you elaborate ?

 

Mostly adjustment to make agents behave nicely.

Here's a screen from our game:



If I had NPCs that wanders randomly around the map, it could get awkward if they walk up into that corner on the right. The villager that wanders into a narrow corridor, stands there, and walks back out would just be embarrassing. Still, adjusting the baking process so that little strip doesn't generate will cause other areas to have

If I could iterate the navmesh and find polygons with very small areas that only connect to one other polygon, and snip those out, that would be useful in this situation. It'd also reduce the amount of complicated situations the NPC agents would have to take care of.

That would especially be useful for generated maps, where you can't fix situations like that with a Navmesh obstacle.

 

Situations where navmeshes need to be modified at runtime but creating from scratch is unnecessarily costly.

 

The "NavMeshBuilder.UpdateNavMeshData" method should provide you with that - i.e. update local modifications only.

 

I make the angular speed as 1e+10. But it still rotates slow. In the old implementation, it will rotate fast. It seems that there's a max limitation. But it doesn't exist in the old implementation.

 

You can use your old approach with navmesh, look at the documentation for .CalculateTriangulation()

 

I had some issues like that but my solution was to give the navmesh very generous traversal options, then just reference a specially made mesh, it's a pretty poor approach but it does get around those kinds of issues. Kind of forcing it to accept our geo when it could just, well, accept our geo.

 

Bad news: the inside of large empty objects still longer produce islands still a source of many bugs. @Jakob_Unity we need an option to detect normal direction.

Also a way to delete pieces of navmesh that are not connected.

 

Yes - that behaviour hasn't changed. We cannot meaningfully auto-discard the inside of a house or similar. a "NavMeshSeedPoint" to solve this issue - is on the list for of things to do.

 

I am finding some issues with the NavMeshAgent and longer paths. Some longer paths seem to cause the NavMeshAgent to halt. I've checked the path in debug and found that there is a complete list of corners from the start to the destination. The navigation debug overlays also show shaded polygons up to the target. Despite all this, the NavMeshAgent's desired velocity is 0. You can still use the path, just requires you write code to manually step through; it breaks the high-level usage, though.

 

Is there any way to save a runtime generated navmesh to avoid having to recreate it when a game save is reloaded? Also can you read the data of a polygon a agent is on and the ones it connects to get a list of places it could move?

 

The problem encountered in the past
Agent with a radius of 0.5 It moves across the grid
but if you set any other value then move the field reduced

another example
with a radius of 0.3 agent does not move

 

The agent can only move on a navmesh that has been built for that agent type. Ie. you need to build a navmesh for the "New Agent".

 

The problem with a radius decided
defaultBuildSettings.overrideVoxelSize = true;


here is also happening

 

An update is available - Fixing a number of reported issues:
• carving + async navmesh building causing errors
• slow agent rotation speed on rotated navmesh surface
• swap endpoints of link
• baking NavMeshSurface on prefab
• Agent unable to move to some tiles

You need to fetch a new feature build as well as updating the script code. See:
https://github.com/Unity-Technologies/NavMeshComponents#how-to-get-started

 

Are you planning on having the NavMeshSurface complain if they were built with different settings than what the agent type current is set to? That would probably help with this.

I was going to suggest turning off Agent type editing during play, but I guess that if you're baking on the fly, it can be nice to modify it as you're moving around to see what the mesh ends up looking like.

 

@Jakob_Unity What if stacked navmeshes were used to simulate a navmesh volume, the API would only need a way for flying characters to be loosely linked to their nearest surface and to navigate using these linked surfaces when blocked at one level?

 

This is normal or planned to fix it?

 

no complaining planned - it's possible that users might want to swap agent type at runtime - and add/remove/modify etc. as you mention.

 

Sounds unmanegable to me - but i've seen implementations of flying objects using a single navmesh plane in mid-air - and agents having baseOffset modified for height - avoidance breaks down though (no over/under avoidance)

 

The overlapping navmesh and almost vertical skirts look like a bug. will be investigated.

 

OK by avoidance do you mean Obstance or Unit avoidance?

Side Note: How fast is the dynamic Navmesh system could it be used to fly a fast moving vehicle around a complex procedurally generated 3d world?

For example you could have 3 axial planes each with a dynamic navmesh that provide obstacle avoidance and basic pathfinding?

 

I'm not thinking for if the users swap agent types. I'm thinking if you've got the agent type "ogre" that used to have a radius of 1, and you built a bunch of surfaces. Then you change the radius of "ogre" to 0.8. Now you've got a bunch of surfaces that's registered as ogre-surfaces, but with the wrong radius.

Or have I missunderstood how things work?

 

We don't want to throw errors on that - as users might want to tweak agent radius a bit for the sake of avoidance.
e.g. reuse Ogre navmesh for "Big Ogre" - but have slightly bigger radius for better avoidance on "Big Ogre"

 

So is there any way to read or save navmesh data?

 

I see one more reason to make the mesh data read/write, we can write this code in c#.

 

The example scenes are really well made, what you want is done in 5_sliding_window_terrain.
It's quite slow with default build values on terrain. I think it voxelize the highres geometry of the tetrrain instead of using the raw heighmap... my guess is the next terrain is voxel so Jakob didn't bother - I'm bored so I'm starting a rumor :-D
EDIT: reading the github doc I see that the system references the terrainData so the updated rumor is that the new terrain is still heightmap
Once you tune NavMeshBuildSettings.voxelSize and .tileSize you can get something pretty fast.
In the example, I use voxelSize of 0.1 tileSize of 50 and it's catching up with agent movement speed of 50.
Also playing around with the lowres scene 4_sliding_window_infinite I can see that the navmesh updater is having no problem with a 50/50 agent. Se can deduct that the voxelizer is having aneasier time with lowres mesh. Your procedural environment generator will need to instantiate low res proxy mesh alongside the highres mesh to keep within your cpu budget. Wouldn't it be nice if we could control the # of threads for baking isn't it? (@Jakob_Unity ?)

For your flying project use something else, you're trying to shoehorn a planar system into a volume system. Have you tried breadcrumb pathfinding or boids? I'm always surprised at how low tech approach to AI works just fine.

 

It would be great if a version number is added to the releases. Such as a1,b1,f1.

 

I hope that new NavMesh will work with Unity's native 2D solution (top-down games). It would be great if you create 2d colliders for agents and 2d obstacles.

 

Can you add the ability to bake 2d maps, created in the unity tilemap editor(experimental)? It would be cool if we could bake NavMesh using sprites.

 

The latest version will crash with this line "Input.location.Start();" in android build.
It seems that it's a fixed bug.
Maybe it's related to these bugs below.

• Android: Android: LocationService - Fixed crash bug (757111)

https://issuetracker.unity3d.com/is...-wrong-type-android-dot-location-dot-location
https://issuetracker.unity3d.com/is...dot-start-on-android-5-dot-0-or-newer-devices

If it's not fixed, I can't move to the new release.

 

What are the requirements for LocalNavMeshBuilder to work? It sometimes works and sometimes does nothing for reasons I don't understand.

 

1. Each mesh needs to be collected as source, @Jakob_Unity uses a component called NavMeshSourcetag, place one per mesh object.
2. all sources need to be within the bounds defined in LocalNavMeshBuilder

If this doesn't work for you, post a youtube, we'll have a look.

 

Thank you for your help, I though that it would automatically collect all geometry in its bounds.

 

It doesn't because the new system is dynamic so you can no longer rely on static flags.
To get a grasp of how it works, try all the samples and find how they work because they're all minimalist and very well made. "4 sliding window infinite" is a good start for you.

 

I did try the samples but missed the tags and though it just used a physics.overlapBox.

 

It's planned but not done yet. Stil - if you can extract a mesh for you 2D geometry - you should be able to do it using the NavMeshBuildSource directly

 

This bug is unrelated to navmesh - meaning it'll appear in 5.5 RC - Which is bad - plz reopen the bug then.

 

Correct - the static flags are not available at runtime - so collecting the navmesh generation input sources is different from the "old" behaviour.

 

Because the bug is an private issue. And the public bugs are flagged as duplicate. I have no way to reopen it. Could you please reopen it? The previous Navmesh build is without this bug.

 

It's great that we can bake navmesh in the x-y plane. Anyway, i hope that later we could use navmesh which can work with sprites (without meshes).

 

Now that NavMeshLinks have width, is it possible for multiple NavMeshAgents to use the same NavMeshLink at the same time? And if not, then can agent's current NavMeshLink be accessed somehow so I could programmatically tell the agent to use other NavMeshLink?

 

It's single user only still - but good point. I think it would make sense to add API to choose between link behaviours on traversal. Single User/Multiple Users.