i've been back on making games. i experimented with making a Minecrap clone in rust+bevy and got super deep into the terrain generation, so now I am a font of knowledge about how Minecraft 1.18+ terrain gen works, ask me anything about density functions and octaves and shit, I guess. One of the most satisfying things was improving the performance of the algorithms and rendering since it was Very Slow at several stages.

1. Render a cube for each block that's not air - this is obviously not performant, but I wouldn't recommend anyone skip the easiest step for performance for like a bunch of reasons (a. the performance characteristics may not be as you expect! b. simple code is easier to modify than optimized code and easier to find bugs in). It was slow, lol. ESPECIALLY when I added colliders to each block, yikes, neither Rapier or Avian was prepared for like 32k colliders. I hoped there would be some optimizations for non-moving blocks but it seems that that was too much to ask (since technically, I guess any of the blocks could move every frame because I controlled the Transform)
2. I then optimized to only render the blocks that were actually visible (ie. they have at least one air block adjacent to them),
3. I tried to make a Mesh per face and only show the visible faces. This was slower than the above, somehow?! (like, unusably, 4fps on my laptop with huge stutters as you traversed the world) I guess this was a good lesson for me that just because an optimization sounds good on paper, there's a ton of nuance and other things you maybe didn't consider that only arises from testing. In this case, I believe the issue was the huge number of Entity-s I was spawning (one for each face). ECS has limits I suppose and they are ... (if the average chunk has 16 * 16 top faces + say another 16 * 16 side faces to be generous, and I'm trying to show a 10x10 grid, then that's 51k entities that are completely static that need a bunch of transform propagation etc. every frame)

I ended up settling on a system that would:

1. On startup, stitch all the textures for the blocks into one single atlas. Minecraft does this too: https://minecraft.wiki/w/Blocks.png-atlas . This allows me to have one Material for the entirety of the static game world.
2. Each chunk is built into a single custom Mesh filled with vertices and carefully calculated UV co-ordinates (and I even stuck in some extra vertex attributes to bake light levels in) to select the block type, a custom Mesh topology that would calculate visible faces based on adjacent blocks.

I found that actually building the mesh for a given chunk would take ~2ms, but that doesn't include generation time (which I moved to an async task pool).

For actually generating chunks, there's so much information out there about how Minecraft actually does this stuff that it was really easy to solve these problems. Things I liked were the talk by one of the devs on the wiki about terrain generation and the basics of how it works, the wiki which explained density functions, the fact that the worldgen code is literally just json files inside the jar, and of course the mostly-working Deepslate JavaScript library https://github.com/misode/deepslate which had a close-enough noise implementation (although yikes I think the naming of the deeply nested noise classes is not great, not that I could do much better) which helped take a lot of the difficulties of the documentation on the wiki and turn it into code implementation, and led me down the path of using the Visitor pattern for actually handling the deeply nested web of complex operations that involve determining the final density of a given block.

It was slow, so I tried to get SIMD working and struggled with the FastNoise2 library (which has rust bindings, which is nice, but I had to symlink some files to get it to work right as it would build the library in the wrong folder for some reason) and once I did suddenly it was fast, but as is typical with optimization, a complete refactor was necessary. Lots of hours.

Eventually, I decided to move on to other things as I felt like I was neglecting other skills I needed to actually be a competent game dev like modelling, mechanics design, etc. stuff like that that's a lot more nebulous and way outside of my skill set. So my partner and I did a 5 hour Blender tutorial about making donuts and animating them, and while I think I learned a lot from it I still feel totally lost on how to take the mess of ideas in my head and turn them into a compelling game without getting lost or burnt out along the way. So I'm taking some time off from creation to read Tynan Sylvester's Designing Games to see if having a bit of a more solid framework will help make it all make sense.

I still feel totally lost in a lot of ways, but I'm trying to take it easy and just idk be kind to myself.