cgl VS opengl-skydome

my base code is https://github.com/Jaysmito101/cgl the code for this specifically is extremely dirty (was just experimenting) so i didnt post it publicly

you used this project as a base for the procedural sky, didn't you ? Ha, ha, I used the same one. The problem with this shader is that it is quite expensive for the GPU: complicated formula for the sky color and sun (somewhat approximating the Reyleigh/Mie scattering), and the fractal brownian motion (FBM) used for clouds isn't cheap either. I ended using this project for the sky color (since it is entirely texture based, it is super cheap) and a slightly cheaper FBM for the clouds (found on shadertoy, sorry can't find the link).

Having written my own voxel engine back in the days (circa 2015), some advices if you want to push this further : * Yep, your hashmap to store block information per chunk is not going to scale up at all. Since there is fixed amount of blocks in a chunk, ... simply use some big tables. This is what Minecraft does: 4096 bytes for the block Ids, 2048 bytes for data values, 2048bytes for skylight, 2048 for blocklight, ... accessing those values will be very quick, since everything will be close in memory. Block updates will also need (very) quick access to nearby voxels: everything in Minecraft depends on this: meshing, skylight, blocklight, redstone, water, lava, ... * You used the same sub-chunk size as Minecraft: 16x16x16, but used one draw call per sub-chunk: again, this is not going to scale up: Minecraft terrain is the textbook example for instanced rendering. OpenGL 4 has a draw call for this: glMultiDrawArraysIndirect, PITA to use, but performances you get from this call are fantastic. It is possible to emulate this draw call with OpenGL 3, but it is pretty hardcore (not recommended for beginners). * You didn't do any frustum culling: I remember struggling a lot implementing this one. Never ending parade of edge cases. Also pretty costly to run: on the CPU I had back then (core i7 from 2013), it took 2 to 4ms per frame (with a 16 chunks render distance): 20% of the time budget at 60FPS, yikes! Given all the optimization I tried, I was quite disappointed by this. But, if you want a decent rendering distance, with a decent amount of blocks below the sea level, it is pretty much required. I also remember implementing the cave culling algorithm; it was actually surprisingly easy to do, with a decent amount of chunk being culled. * Your lighting is obviously way too simplistic (well, there is none): Skylight is extremely important, this is what will allow you to do day/night cycle, especially if you also have BlockLight information. Updating Skylight values is a major PITA, I struggle way more than I care to admit to get this right (and so did Mojang: those black patches in the world were due to bad SkyLight values). * Dynamic skydome (ie: sky color with day/night cycle) was also not that trivial to implement. I tried various PBR rendering techniques back then (Rayleigh/Mie scattering), but the results were kind of meh (and took way too much GPU power back then). I remember using the techniques from this project: very cheap and not bad looking (with better textures though). * User interface: you'll be for one hell of ride with this one. So many bad memories... * Careful with your floating point usage: I did the same mistake and uses floats everywhere: they do not have a lot of precision. This is particularly bad when you start playing with huge coordinates (>10000): on the GPU, you will be multiplying those coordinates by the MVP matrix, which will give even bigger intermediate numbers: the loss of precision will quickly stack up. Especially when doing collision detection/correction: this is particularly sensitive, if you use an algorithm like the swept AABB. So many times I fell into the void of gone through blocks because of this. Extremely annoying to debug. * The biggest PITA was handling entities: I massively under-estimated the complexity of these, and this is what killed the project back then. Not much pixels on screen, but massive amount of tedious, boring and unrewarding code behind the scenes.