i specifically wanna ask questions on the project.
how does your chunk system works? and also how much multithreaded it is?
also is it cubic chunks or not? like it does seem like a cubic chunks due to the amount of chunks but also it doesn't extend infinitely down, its as if it is cubic chunks but artificially limited upwards and downwards to still have a height limit...
interesting
Hello again.
I had recently finished adding multi threading, in the test build 8. The system works by scanning the amount of cores that your cpu have, and assign a thread to each. The multi threading is manly used to generate chunk data;Terrain generation, and calculating mesh data. Later i run it on my main thread, with a queue system.
As for now ill got 25-30 fps with 64 render distance with my old 8th gen Cpu. It still isn't perfect but it works.
When it comes to the chunks. Its cubic system. I sat a fixed world size for now at 10 y and 200 x,z. But in theory you could go infinitely in all direction. And yeah the share amount of chunks can be sometime overwhelming. Reaching in hundreds of thousands! But later i plan to limit the y direction generation to the terrain generation height, and make so when a player moves over it, it generates a chunk. So y size = worldSize.y + player position over world size.y. This way i could save a lot of performance by not having to generate thousands of empty chunks.
What system do you use? I saw in your C++ project that you mentioned the view distance in kilometers of blocks. How do you achieve it, especially when a player moves.
Cheers!
okay as for my MC clone:
how i achieve kilometers of render distance: you know the chunks are stored in a hashmap for the chunks with their chunk coords etc... so think of that but instead we get 5 of them.
basically the LODs are just separate grids of chunks, and chunks also know what LOD level they are so when rendered their LOD is also taken into account, so LOD0 chunks are rendered in LOD0 chunk coords, while LOD1 chunks are rendered in LOD1 chunk coords, and so on until LOD4.
and each LOD is 2x2 its previous level, so LOD1 is 2x2 LOD0 space, LOD2 is 2x2 LOD1 space, and so on, until LOD4 where it takes the 16x16 LOD0 space.
also each LOD level has the same 16x128x16 (to be faithful to Alpha) voxel data, and they are all meshed the same, the only difference is when generating LOD chunks the terrain generator itself skips the worldX and worldY and worldZ by the LOD factor.
and so basically instead of just one grid of chunks, i have 5 grids of chunks all stacked on top of each other and each using the chunk coords for their own LOD level..
and if you wanna calculate the render distance, basically take the length of LOD4 chunk and multiply it by the render distance, so LOD4 chunks have the length and width of 256 blocks, and on 16 chunks render distance radius, it ends up as 16x256 = 4096 blocks of render distance
WOW That's genius! Now it makes sense how you did achieve it. What i tried were the greedy meshing system instead, but it still had some problems at long view distances. Ill can only imagine how much performance boost i will get with using both of the systems!
What are you plans for the feature? Do you plan to stop at one point? Or do you have bigger ambitions?
i plan to recreate Minecraft Java 1 to 1 in C++ (AKA, what Bedrock Edition SHOULD have been), and follow a similar historical progression but instead starting from late infdev and reaching an infdev 2010-06-30 (the last one) equivalent, and then going from Alpha 1.0 to Alpha 1.2.6 and then going from a Beta 1.0 equivalent to a Beta 1.8.1 and all the way until release 1.8 (that is where i will stop)...
all while implementing QoL features like LODs and many optimizations (like very VERY heavy multithreading, and even a future Vulkan transition too for extra optimization), also preserving all the different terrain generations and letting people choose instead of just limiting to the latest one, and who knows maybe i could have either a branch of the game for cubic chunks too.
edit: so yeah this is my long term plan, but this MC clone is just one project of many others of mine that i am making simultaneously, so yeah, no rush, slow but sure progress, which is also why the code is open source too
i wouldn't say it is a better voxel engine, this is my first ever voxel engine too and my god i underestimated how much difficult making a voxel engine would be, it is because of this that i learned multithreading and i also realized that for voxel engines it is much MUCH better to use a ChunkProvider approach to manage chunks instead of whatever the hell i had before
Yeah its really complex. I my self now, I had been rewriting my code over and over just to make it perform better. It feels like I am making spaghetti right now. Maybe should focus more one adding new features, instead of just using my whole free time to make a code that runs 5-8 fps faster.... :skull:
