Enybody experienced/noticed overhead decrease when switching from "old NavMesh"? I didn't pay attention when I have changed to component based meshes but I think it is less demanding. My AI scripts seem to need less CPU to get the job done.
Cool to see the vertical nav mesh working, though my first thought was that it would mean we could use this new system in 2D projects but that doesn't seem to be the case yet. Baking a nav mesh using the NavMeshSurface component doesn't pick up any 2D renderers or colliders. I just tested this for tilemap renderers in the 2017.2 beta as well, with no luck.
Just spitballing, but I'd guess you can do that with Navigation layers. Have a "Flyable" navigation Layer that reflects anything on the ground that affects (or is of interest to) flyers. Flyers can be set to ignore small obstacles on the ground (fences, rocks), but avoid things like cliffs or forcefields. As Hannah Crawford says, use Base Offset to set a standard "hover" height for flyers (your model origin may already be set accordingly). I think you could even support stoop/dive behavior (like hawks) by enabling/disabling NavMeshAgent temporarily, and changing your y-position accordingly, once you've locked onto your target.
Looks good. I would love tutorials to go over how to do things with these changes. Also, I would like a way for an agent to know what type of nav mesh area it is on. But that can wait. Thank you for these components.
Okay, so we can add paths at runtime. But what about blocking them? Let's say that there is a narrow canyon with some army on the one side and you on the other. But you can trigger an avalanche that will fill the canyon with rocks. Wouldn't army just walk through these rocks?
I asked in the forums a while back but got no answer. How do we set different navigation areas at runtime? SO far I can only apply the default "walk" area. Which means my shark ends up chasing landlubbers.
I came here to find a solution for the character zooming between meshes connected by a NavMeshLink and it turns out this guy had the same issue in his demo and didn't even acknowledge it.
Os novos componentes estão aqui: github.com/Unity-Technologies/NavMeshComponents Basta colocar a pasta NavMeshComponents no seu projeto e já pode utilizá-los. E para o bake em tempo real eu utilizei os métodos RemoveData() e BuildNavMesh() em seguida no meu NavMeshSurface e funcionou bem.
Just wanted to say... Unity guys listen to suggestions :). I was posting about the problems with different agent sizes some time ago: forum.unity3d.com/threads/solved-problem-with-unity-navmesh-and-multiple-agent-sizes-with-a-workaround-solution.178628/
That mazegen code is very overly complicated for the information you're trying bring across. It's hard to read and uncommented. Keep your explanations to the bare minimum, and don't introduce 350+ lines of hard to read code that are not related to nav at all. I'm sorry, but this is very bad.
What are you talking about? He didn't show the mazegen code in the talk, or if he did it was so by0the-way that I missed it. This was an excellent presentation and brought across exactly what it was intended to imo
Enybody experienced/noticed overhead decrease when switching from "old NavMesh"? I didn't pay attention when I have changed to component based meshes but I think it is less demanding. My AI scripts seem to need less CPU to get the job done.
Cool to see the vertical nav mesh working, though my first thought was that it would mean we could use this new system in 2D projects but that doesn't seem to be the case yet. Baking a nav mesh using the NavMeshSurface component doesn't pick up any 2D renderers or colliders. I just tested this for tilemap renderers in the 2017.2 beta as well, with no luck.
File it as a bug! It's little passive-aggressive :T but the need for 2d pathfinding is clear and they should know about it
use 3d colliders with 2d objects? it doesn't fit all projects sadly tho
next-gen navmesh for free, awesome !!!!
thanks !
Now here's a Question:
What if I want to make a Flying NPC that can find the Player no matter where the player is or how High they are?
i have same problem
use the base offset option, it will make it appear to fly however it will not be able to fly over walls and stuff
Just spitballing, but I'd guess you can do that with Navigation layers. Have a "Flyable" navigation Layer that reflects anything on the ground that affects (or is of interest to) flyers. Flyers can be set to ignore small obstacles on the ground (fences, rocks), but avoid things like cliffs or forcefields.
As Hannah Crawford says, use Base Offset to set a standard "hover" height for flyers (your model origin may already be set accordingly). I think you could even support stoop/dive behavior (like hawks) by enabling/disabling NavMeshAgent temporarily, and changing your y-position accordingly, once you've locked onto your target.
I believe this would still be a job for the old raycaster so your object looks for obstacles
I love Mike Geig
He's my #2 favorite Unity trainer (behind Adam Buckner, b/c Scripting FTW :)
This is trullly amazing for my needs!
Mike being awesome as always
I love the parallel development! Keep it up!
While there's a serious issue with terrain trees (it basically ignores them). Those new components already saved my ass.
this looks pretty amazing, but what about local avoidance? are you willing to implement somehow local avoidance (eg. interactions with mobs)?
Wow. Looks like a very powerful feature.
Hi how do I get it working on a 2d game
Looks good. I would love tutorials to go over how to do things with these changes. Also, I would like a way for an agent to know what type of nav mesh area it is on. But that can wait. Thank you for these components.
Ok. I should have thought of that. Thank you!
Okay, so we can add paths at runtime. But what about blocking them? Let's say that there is a narrow canyon with some army on the one side and you on the other. But you can trigger an avalanche that will fill the canyon with rocks. Wouldn't army just walk through these rocks?
There is a NavmeshModifierVolume component that can do this. It effectively modifies the navmesh properties to block paths.
I asked in the forums a while back but got no answer. How do we set different navigation areas at runtime? SO far I can only apply the default "walk" area. Which means my shark ends up chasing landlubbers.
Norb i dont think ya could at runtime. At least in 5.0
Im a noob tho
I came here to find a solution for the character zooming between meshes connected by a NavMeshLink and it turns out this guy had the same issue in his demo and didn't even acknowledge it.
Where's that Bake() method in the new NavMesh Components?
Os novos componentes estão aqui: github.com/Unity-Technologies/NavMeshComponents Basta colocar a pasta NavMeshComponents no seu projeto e já pode utilizá-los. E para o bake em tempo real eu utilizei os métodos RemoveData() e BuildNavMesh() em seguida no meu NavMeshSurface e funcionou bem.
Just wanted to say... Unity guys listen to suggestions :). I was posting about the problems with different agent sizes some time ago: forum.unity3d.com/threads/solved-problem-with-unity-navmesh-and-multiple-agent-sizes-with-a-workaround-solution.178628/
I actually ended up on this video from your exact post, thanks :)
It is cool! Thank you!
Thanks a lot 😎
Using it now. Thanks.
cool
Navigation, you want it? Its your my friend as long as you have enough navmesh
so awesome
lit, super cool...loved it..
4 years and still not implemented
human flies off from horizontal to vertical plane looks very bad, Mike quickly moves on to the next topic
First
Space between function and brackets... i m outta here...
That mazegen code is very overly complicated for the information you're trying bring across. It's hard to read and uncommented. Keep your explanations to the bare minimum, and don't introduce 350+ lines of hard to read code that are not related to nav at all. I'm sorry, but this is very bad.
What are you talking about? He didn't show the mazegen code in the talk, or if he did it was so by0the-way that I missed it. This was an excellent presentation and brought across exactly what it was intended to imo