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

 

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.

 

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.

 

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 problem with a radius decided
defaultBuildSettings.overrideVoxelSize = true;


here is also happening

 

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?

 

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?

 

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.

 

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?