Reusing one big buffer instead of many seems like a great idea. Less moving parts the better here. Why the vertices are expensive to compute is mostly a question of scale. For instance, with indirect draw calls I can handle 4000+ chunks of terrain and 25 million+ vertices at 60 fps. With much lower terrain distances the meshing on the CPU can keep up fine, but when I push it there is a lot of frame dropping when moving over the terrain and generating meshes for dozens or hundreds of chunks. Part of this is that my meshing is single-threaded on the CPU, but my experience with Swift multi-threading is so far hit and miss for this kind of thing. As such, parallelism is the entire point of trying to offload this to a compute shader. The process of vertex generation is pretty standard for block/Minecraft-style terrain. We loop through all the blocks in a chunk, and if a block is solid, we check if any of its neighbours are air, and therefore if we should put a quad opposite it. Roughly: for y in i..
Topic:
Graphics & Games
SubTopic:
General
Tags: