M Terrain Navigation first Demo - Open Word Navigation handling for Godot
Вставка
- Опубліковано 16 жов 2024
- So This is what I a achieved up to This point, Navigation baking is really process heavy, I optimize that a lot, depend of type of the mesh it take a few second to bake that, but it not freeze the game as it use another CPU thread
Discord:
/ discord
GitHub repo:
github.com/moh...
I've been following your progress and wow you work fast! Reducing the number of polygons in the navmesh should improve path finding performance. Since generating the navmesh is performant, perhaps you can generate multiple navmeshes at different resolutions. A high detail, smaller one for when the NPC's are close to the player, and a large, low detail navmesh for NPC's that are far away from the player. And automatically switch the correct one as the distance changes.
Thanks, @CodingKaiju
That is not a bad Idea, To generate multi resolution Navmesh, We can use Navigation Layer to switch between them
But at the end I think if the size of the map grow really big that even can not work, I think the best way is to create a Road system for entire map, Roads are much simpler and contain only some points which can be implemented easily with AStar algorithm, So when an NPC want to travel from one side of the map to other side it find by navigation mesh the closest path to closest Road, and from there it switch to road navigation system and find its way by that
Also if you look at most of the game they generally spawn NPC in roads
Godot has something called Navigation Link, I wonder if we can use that to build a road system
Why aren't you on godot developement team? 😭 It would be better if the features of your extensions are integrated on the engine itself.
Despite this works Good, I am agree if Godot create a Terrain system as Core it is much better, Unfortunately a lot of core feature for Godot is not accessible when you write code in GDExtension.
But still this works and that is really Good
After the Navmesh is all cooked, LOD can be applied. So I'm talking about splitting into parts. I don't know if such a thing is possible, but if it does, it can gain performance. You should also be appreciated for working so fast. I hope you can work in Godot's team.
You know I am not sure about that, We should test that, but it is possible that if we split that up Godot navigation system need more calculation power to connect multiple region
But this is also possible
I think the best way to handle the navigation system for entire terrain is Road system
Thanks man
Does this support nav mesh baking for NPCs/enemies? For example if I have an agent/character that isn't following the player (say they are fleeing or just patrolling), but they have a need to navigate to a location and avoid obstacles on the way - at any time they maybe outside the radius of the player's navmesh settings.
The Class which I added to Godot is responsible to bake navigation mesh from terrain, You can tell that where to bake and how big to bake, You can set that to the position of enemy or village or player, This is your choice
Perfect, thank you.
I don't get it why the navmesh needs baking at runtime? What about baking it only once for the whole map? I know the polycount and file size will be huge but atleast no further computation needs to be made at run time.
You have the option to bake that offline too, There is no problem with that
But even if you bake that offline you can not load all of that at the same time. If the map is big that will occupy a lot the RAM memory
Even if you load all of them you can not enable all of them together, Because if the navigation mesh become big the process to calculate path for NPC become much more expensive
How about dynamic obstacles?
Watch the updated video on my channel about navigation mesh, Now you can paint the navigation mesh