Hey Slapin,
I have implemented a procedurally generated terrain with splatmapping. So far however I have only implemented the simple version with 4 channels. For more channels my first approach would be to use 2 splatmap images, which should give you 4*4 channels. However maybe there are more clever way to do it (I haven't researched yet).
In case you haven't seen it, this video explains how to use splatmaps in Godot:
I have also managed to implement navigation using Godot's Navmesh. I'm building the navigation mesh at together with the terrain mesh, but leave out vertices that are under water or an a location that is very steep. Characters are then able to find their way around lakes or up a hill using a reasonable path. I can post some example code if you're interested. The downside of this approach however is that it's hard to change the navmesh at runtime (or at least I'm not aware on how to do it). For example I'd like to be able to exclude an area after a building has been placed or a new tree has grown.
I'm setting the height of an object by calculating the height, not using the terrain mesh. And I'm not using a heightmap, but just create the terrain using SurfaceTool to create meshes.
I have not implemented collisions.
About dynamic navigation - if you see c++ navigation code from Godot source, it is possible to add navmesh pieces. A problem is that nobody gave appropriate handles to generate these at runtime.
I hacked-up a module based on Detour and DetourCrowd, which is independent of Godot navigation and allows area tagging, fast obstacle placement and multi-agent navigation, but it is very crude and buggy now. Also there is certain opposition to it I guess, so the only hope to have decent navigation in Godot is that somebody adds these features to stock navigation code eventually. Currently I just basically bind DetourCrowd API functions, this uses about 10% of features, so the code as very far from complete. I hope to release that in form usable by others in a few months.
I plan to use heightmap-based terrain (using shader), Bullet heightmap collision and DetourCrowd based navigation in my game (unless somebody implements some better systems in Godot by then). DetourCrowd and Detour are parts of the same "recastnavigation" suite as Recast itself.
Detour sounds like an interesting alternative and I might check it out, thanks :)
@slapin said:
Well, code is always interesting.
Regarding code samples: I'll only post it, if you are interested in a specific part of it (for example how to build a navmesh or how to set the splatmap parameters, etc.). I don't want to post everything here, since it's a lot and I would just have to write a big post explaining all the details. (Actually I was thinking about writing a blog with some small tutorials for Godot. I would love to see more Godot tutorials myself. )
About dynamic navigation - if you see c++ navigation code from Godot source, it is possible to add navmesh pieces. A problem is that nobody gave appropriate handles to generate these at runtime.
I hacked-up a module based on Detour and DetourCrowd, which is independent of Godot navigation and allows area tagging, fast obstacle placement and multi-agent navigation, but it is very crude and buggy now. Also there is certain opposition to it I guess, so the only hope to have decent navigation in Godot is that somebody adds these features to stock navigation code eventually. Currently I just basically bind DetourCrowd API functions, this uses about 10% of features, so the code as very far from complete. I hope to release that in form usable by others in a few months.
I plan to use heightmap-based terrain (using shader), Bullet heightmap collision and DetourCrowd based navigation in my game (unless somebody implements some better systems in Godot by then). DetourCrowd and Detour are parts of the same "recastnavigation" suite as Recast itself.
Navmesh pieces can be generated at runtime (from the Navmesh class) but it doesn't take advantage of the Recast code so you have to manually make sure all the verts match if you have multiple pieces.
I'd love to see your module, too.
@bluepangolin55: A blog with Godot tutorials would be awesome!
About dynamic navigation - if you see c++ navigation code from Godot source, it is possible to add navmesh pieces. A problem is that nobody gave appropriate handles to generate these at runtime.
I hacked-up a module based on Detour and DetourCrowd, which is independent of Godot navigation and allows area tagging, fast obstacle placement and multi-agent navigation, but it is very crude and buggy now. Also there is certain opposition to it I guess, so the only hope to have decent navigation in Godot is that somebody adds these features to stock navigation code eventually. Currently I just basically bind DetourCrowd API functions, this uses about 10% of features, so the code as very far from complete. I hope to release that in form usable by others in a few months.
I plan to use heightmap-based terrain (using shader), Bullet heightmap collision and DetourCrowd based navigation in my game (unless somebody implements some better systems in Godot by then). DetourCrowd and Detour are parts of the same "recastnavigation" suite as Recast itself.
Godot will get navigation system fixed after 3.1.
Navigation is not working great in Godot, and the movement id coded in GDscript instead of beeing native, also multi threaded navigation would be also better for performance.
UE4 calls navmesh functions like moving and it uses directly the properties of the character because UE4 has a complete character native framework. While Unity uses Navmesh Agent components to define a character movement properties.
Both are valid approach, Godot could get some NavAgent node.
It's a must needed feature for any 3D game with AI that is not using 3D tiles or waypoints to move around.
UE4 uses Detour and DetourCrowd. Unity uses/can use Detour. Godot developers are against using Detour. So I think it never happens.
I work on Detour-based navigation in my fork, most basic code is complete.
Will need to add proper helper nodes to integrate to Godot. Will need to do some huge work for polish though.
I report status here: https://uncertain-games.blogspot.com/ (warning: obscene language and probably some NSFW graphics in future).
The code is here: https://github.com/slapin/godot/tree/navigation
Will get that into shape in a few weeks.
Need to say that navigation work is huge if you want to get to UE4 level with it. I plat to make basic agents work and make it easily configurable from editor. Then move to advanced things. I have very tiny amount of time to work on it so it will take time to implement propely.
@slapin said:
UE4 uses Detour and DetourCrowd. Unity uses/can use Detour. Godot developers are against using Detour. So I think it never happens.
Why against Detour ? i don't understand.
@slapin said:
Need to say that navigation work is huge if you want to get to UE4 level with it. I plat to make basic agents work and make it easily configurable from editor. Then move to advanced things. I have very tiny amount of time to work on it so it will take time to implement propely.
It's is C++ native or are you using GDscript ?
Unity path finding was not so great ( i don't know on last releases), the best navigation system is a plugin named A pathfinding Pro.
Features:
Grid, navmesh and point graphs.
Fully multithreaded so it will barely affect the frame rate
Path post-processing using raycasting, smoothing and using the funnel algorithm
A single line of code for a pathfinding call.
Graphs can be saved to files.
Local Avoidance both in the XZ and XY plane.
* Supports updating graphs during runtime.
I think this is what Godot 3 should aim for (grid and point graphs could be a good addition also).
You should provide some examples and submit it for Godot 3.1.
I don't think people will use a fork that will not be up to date with Godot Nighty builds.
I don't think so. Also I change it a lot at this stage. I will send PR as soon as I have minimal required features in.
Current TODO before PR is:
1. Fix bugs with relative/global transforms in areas.
2. Add debug geometry for obstacles, offmesh connections, areas, queries, crowds, agents. Also used as editor visual representation.
3. Add editor helper nodes to set up crowds (agent config, navmesh filters).
4. Add editor baking for navmesh.
5. Clean-up APIs
After PR I will improve UX and do some optimizations and move off to my own needs.
Will support the branch though if PR will fail (like 99%)