would be a neat thing to have a navmesh allocator which caches navmeshes at various points in the world as needed and discards them when no longer needed. If you are chased by an enemy and you leave the bounds of an allocated navmesh a new navmesh would be allocated for the AI which is chasing you which would include you and the ai in its bounding "cube".
NavMeshes look for StaticBodies to bake, not collisions. A collision without an StaticBody will be ignored. That's by design so you can use Areas, RigidBodies, KinematicBodies, etc. (Which also have collisions) with NavMeshes.
Not true. You can choose the type of node that will be parsed as geometry for navmesh baking and you have 3 options: meshinstance, collider, or both. If you choose collider nothing happens. Static bodies have nothing to do with it.
Sorry for a long question, but in a previous video you mentioned that you were using an individual IK chain for each hand. I'm trying that in my game, too, but it's meant that I have to manually define different gun positions for being idle, running, and aiming, and then each of those has to have another separate position depending on what type of gun is being held (rifle vs pistol, for example). Your animations and weapon controls look awesome, so just figured I'd ask - can you break down a bit how you define where the gun should be when running/shooting/etc? Do you combine animations and IK, or is it pretty much all IK? Thanks man - the game is looking awesome and your video breakdowns are super helpful.
I'm wondering, how do you mix the procedural/on the fly part of loading the terrain with actual landmarks in your map? (Example, a house that needs to be placed in a particular place)
Nice progress. Even at this time I dont understand everything You talk about, I hope one day I will use it :). BTW whats the video ending song name please?
If I remember correctly you can create custum navigation meshes in blender and import it to godot using a flag iirc🤔 i know in this case it wouldn't be useful since you're using the height map terrain. But then again you can using the height map png file in blender to generate it pretty quickly 🤔
In this vid I'm focusing on Godot only. You can of course make a navmesh in Blender but still you should bake a navmesh inside Godot from the one you import, otherwise you're losing the ability to adjust the navmesh and all of its settings (like agent settings), which means that every time you change your level in Godot you have to go back to Blender and redo the navmesh. Also, you can't export a heightmap terrain as a mesh into Blender - you'd have to recreate your terrain in Blender first which is tricky because Belnder uses a different vertex displacement algorithm...
@@actualdevmar I mean to export the png file that the height map creates. But your right you definitely lose the flexibility of regenerating it on the fly. I was talking more of a contained level built inside blender.
Regarding the mesh construction: I wonder if it would be faster to have the SurfaceTool take the mesh data from a PlaneMesh via "create_from" and then modifying its vertices based on the heightmap. There is also "generate_normals", so changing the height should be sufficient.
Tried it. Surface tool works very similarly to immediate mesh but takes a little longer to build the mesh. It's a more powerful tool and the better option when you're building meshes for in-game use. But here I'm just building a mesh so I can bake a navmesh from it and then discard it so I went for a faster/simpler option.
@@actualdevmar I would have thought that by using the SurfaceTool, more of the work happens in engine-internal parts written in C++. So I'm a bit surprised that the gdscript solution is faster. But the SurfaceTool probably isn't optimized for this strange corner case.
@@christianbrenner984 In my procedural terrain project in Godot 3.x I ended up with manual way using ArrayMesh. SurfaceTool and ImmediateGeometry were really slow. Manual creation of the vertices, calculating normals, uvs, and indexation of the vertices made in C# turned out to be at least 10 times faster than using Godot's tools.
Hello! I, too, someday will get to creating a landscape on Godot 4 for my game. I will study how you did it.
Yep, can absolutely agree, Game Dev Journey is an awesome channel! (Also yours is, otherwise I wouldn't have subscribed to it quite some time ago…😉)
I never knew about @tool and that is so crazy I’m gonna abuse it everyday from now on 😂
would be a neat thing to have a navmesh allocator which caches navmeshes at various points in the world as needed and discards them when no longer needed. If you are chased by an enemy and you leave the bounds of an allocated navmesh a new navmesh would be allocated for the AI which is chasing you which would include you and the ai in its bounding "cube".
You should use static body as collider, currently you have only collison node. Static_Body --> Collision_node.
I'd subscribe 100 times if I could. This channel is wonderful.
NavMeshes look for StaticBodies to bake, not collisions. A collision without an StaticBody will be ignored. That's by design so you can use Areas, RigidBodies, KinematicBodies, etc. (Which also have collisions) with NavMeshes.
Not true. You can choose the type of node that will be parsed as geometry for navmesh baking and you have 3 options: meshinstance, collider, or both. If you choose collider nothing happens. Static bodies have nothing to do with it.
@@actualdevmar Static Collider means StaticBodies.
@@actualdevmar yeah I'm pretty sure he's right... you need a static body as parent to that collider you added.
Sorry for a long question, but in a previous video you mentioned that you were using an individual IK chain for each hand. I'm trying that in my game, too, but it's meant that I have to manually define different gun positions for being idle, running, and aiming, and then each of those has to have another separate position depending on what type of gun is being held (rifle vs pistol, for example). Your animations and weapon controls look awesome, so just figured I'd ask - can you break down a bit how you define where the gun should be when running/shooting/etc? Do you combine animations and IK, or is it pretty much all IK? Thanks man - the game is looking awesome and your video breakdowns are super helpful.
I'm wondering, how do you mix the procedural/on the fly part of loading the terrain with actual landmarks in your map? (Example, a house that needs to be placed in a particular place)
Nice progress. Even at this time I dont understand everything You talk about, I hope one day I will use it :). BTW whats the video ending song name please?
If I remember correctly you can create custum navigation meshes in blender and import it to godot using a flag iirc🤔 i know in this case it wouldn't be useful since you're using the height map terrain. But then again you can using the height map png file in blender to generate it pretty quickly 🤔
In this vid I'm focusing on Godot only. You can of course make a navmesh in Blender but still you should bake a navmesh inside Godot from the one you import, otherwise you're losing the ability to adjust the navmesh and all of its settings (like agent settings), which means that every time you change your level in Godot you have to go back to Blender and redo the navmesh. Also, you can't export a heightmap terrain as a mesh into Blender - you'd have to recreate your terrain in Blender first which is tricky because Belnder uses a different vertex displacement algorithm...
@@actualdevmar I mean to export the png file that the height map creates. But your right you definitely lose the flexibility of regenerating it on the fly. I was talking more of a contained level built inside blender.
Great info, thanks!
Regarding the mesh construction: I wonder if it would be faster to have the SurfaceTool take the mesh data from a PlaneMesh via "create_from" and then modifying its vertices based on the heightmap. There is also "generate_normals", so changing the height should be sufficient.
Tried it. Surface tool works very similarly to immediate mesh but takes a little longer to build the mesh. It's a more powerful tool and the better option when you're building meshes for in-game use. But here I'm just building a mesh so I can bake a navmesh from it and then discard it so I went for a faster/simpler option.
@@actualdevmar I would have thought that by using the SurfaceTool, more of the work happens in engine-internal parts written in C++. So I'm a bit surprised that the gdscript solution is faster. But the SurfaceTool probably isn't optimized for this strange corner case.
@@christianbrenner984 In my procedural terrain project in Godot 3.x I ended up with manual way using ArrayMesh. SurfaceTool and ImmediateGeometry were really slow. Manual creation of the vertices, calculating normals, uvs, and indexation of the vertices made in C# turned out to be at least 10 times faster than using Godot's tools.
I see that you are using Godot4.
Could you give us your opinion and experience with it so far?
can I download Immediate mesh script? great video
for the algorithm
Algorithm appreciates
Are you used GD script?
Yes. The code you saw is gdscript.
@@actualdevmar can you upload video on only game footage not code, only game footage