I know time was short but I would have loved more details around the shortcomings of going the gdscript/c# route for generating terrain versus shaders, not counting the required programming experience.
Thanks, that's a good point. Generally you will have more flexibility in the types of algorithms you can implement if you do it on the CPU side (GDScript/ C#). It's easier to implement global algorithms there, which need to look at many or all points in order to determine how they should be positioned. Once the number of vertices starts growing though, this approach becomes quite slow (especially in GDScript). You need to look into chunking and multi-threading at that point. Another advantage of generating on the CPU is you can easily connect the game play to it (e.g. by adding a collider mesh or querying the mesh using SurfaceTool or ray casts with the collision). In contrast, using shaders is nice because you get a bunch of parallel processing of vertices or fragments for "free" thanks to it running on the GPU. You are more limited in the amount of information you have available in the shader and what kinds of algorithms can be implemented. However, everything that only looks at a single vertex at once works great for this. However, it is much harder to get data back from the GPU, so this is mainly used for visual customization and not stuff that's related to game play (e.g. doesn't have collision or the collision boundary doesn't change based off of the generated result). It's also much easier to animate things cheaply on the GPU side, as doing some calculations based off of e.g. cos(TIME * speed) allows you to move around vertices and change colors over time (without incurring the cost that modifying a mesh every frame or so on the CPU has).
Hey Godot Team! Thanks for uploading (and continuing to upload) this useful content. Much respect for organizing this so well
I love everything about Godot
I know time was short but I would have loved more details around the shortcomings of going the gdscript/c# route for generating terrain versus shaders, not counting the required programming experience.
Thanks, that's a good point. Generally you will have more flexibility in the types of algorithms you can implement if you do it on the CPU side (GDScript/ C#). It's easier to implement global algorithms there, which need to look at many or all points in order to determine how they should be positioned. Once the number of vertices starts growing though, this approach becomes quite slow (especially in GDScript). You need to look into chunking and multi-threading at that point. Another advantage of generating on the CPU is you can easily connect the game play to it (e.g. by adding a collider mesh or querying the mesh using SurfaceTool or ray casts with the collision).
In contrast, using shaders is nice because you get a bunch of parallel processing of vertices or fragments for "free" thanks to it running on the GPU. You are more limited in the amount of information you have available in the shader and what kinds of algorithms can be implemented. However, everything that only looks at a single vertex at once works great for this. However, it is much harder to get data back from the GPU, so this is mainly used for visual customization and not stuff that's related to game play (e.g. doesn't have collision or the collision boundary doesn't change based off of the generated result). It's also much easier to animate things cheaply on the GPU side, as doing some calculations based off of e.g. cos(TIME * speed) allows you to move around vertices and change colors over time (without incurring the cost that modifying a mesh every frame or so on the CPU has).
They explained the presentation as if it was their first time seeing it.