I have been working on a Voxel-Based game, using a tutorial slightly. However, I have tried turning on many things to no avail. There are no meshes, no unions, no ui (not much that is, only the loading screen), and the sheer amount of blocks with textures. I need to keep the textures, or the blocks will look like solid slime. I also added fog, which bearly interferes with anything, whilst keeping everything intact. The worst part is… If I am to use anything other than these blocks, it will ruin everything, and I must restart. I am trying to go for a specific style, whilst keeping the 90,601 blocks.
Game link:
since your game is a voxel game if every voxel is the same size you can implement greedy meshing but it is complicated
another thing is that you can implement Occlusion Culling i think that the Documentation have smt abt it
there are alot of yt tutorials on these and they need alot of math
but why there are alot of voxels with the loading screen when i joined? i saw less than 5k blocks and the loading screen showed me a very large number of voxels loading
That is because I have StreamingEnabled checked.
It looks like a small number, but really, It is big.
The game is utilizing some good features for a game like this
Good feature: Preloading system
Good feature: Streaming enabled
However, one VERY important feature that you have missed for games like this is called parallel luau
It’s heavily used in chunk-loading like your game does, roblox documentation specifically talks about a system like yours to ensure frame rates remain stable.
TL’DR: You are not using parallel luau
ig a good way to reduce that amount of voxels is to rander voxels when a player is near the end of a chunk like what mc does
From what i’ve seen in the game the lag spike occurs as soon as the chunk-loading system starts and ends. Everything else seems to be fine.
I do not know how to do any of these suggestions. Any easier ones perhaps?
Greedy Meshing Algorithm - Roblox Scripting Tutorial (youtube.com) – a great vid on greedy meshing
idk any easier solution but the terrain gen method that you used is not efficient a good way of generating generating a random seed when the server starts and generate terrain based of that seed on every client that reduce the part count and remove lag spikes since they are rendered on the client and every client will generate the same terrain i know a vid on doing this i will search it up rn – i didnot find it but there are alot of tutorials on yt
This will definitely break the loading screen. I will not try this.
yeah your right i didnot notice that
just a question does your game have a limit of 90,601 generated blocks?
No, however, for some reason it always stops there. It might just be an error however.
Edit: It has to be an error. I calculated 5,192 from selecting children. This may however be client sided.
ok your game lag spikes are because of streaming enabled they arnot really lag spikes
when u get near the end of a chunk streaming enabled will load it so your game will pausesimulations until you get that info back from the server
you can click ctrl f7 / f5
you will see that your fps willnot decrease when new chuncs are being loaded
and you will see that your NetWork Recive will increase alot
Nonnonoo, I mean the lag inbetween those. Not spikes.
yeah itsnot lag its your game paused waiting for the info to be transferred to the client
i think you can change that withen the streaming setting
You could try loading all of the blocks into a 3D array ( {{},{},{}} ). When rendering the parts, you can greedy-mesh the parts in range and load them in. You will need to mark the parts that got “greedy-meshed” in another array. When unloading, you should unload the entire meshed part, so make sure you’re out of distance. You will need to start spawning the parts as soon as you are in a corner of the part
You could try implementing it with the chunk system, where you greedy-mesh every chunk by itself and load / unload it all at once. That would be more inefficient tho, because you could render bigger parts if the chunk borders weren’t there (or the chunks were way bigger, what would kinda defeat the whole purpose of chunks)
Red: Assumed Chunks Blue: Optimal meshed part