Simple question, is using many SurfaceGuis to achieve this laggier than using Textures?
Textures force me to upload these decals one by one, whilst the SurfaceGui method lets me upload a singular texture atlas, then crop it in with an ImageLabel. I do wonder if this extra utility comes at a cost, however.
Many players could be placing many blocks inside the same room, so even if there is a small performance hit, I would want to know about it.
Consider textures for static images, but if you need more flexibility, animations, etc, SurfaceGuis may be worth the performance cost, however you will need to monitor carefully the performance.
The surfaceGuis would mean smaller texture sizes although roblox will still upscale them but they look better imo. If your going to have block placing systems make sure you use greedy-meshing, and remove any surfaces that won’t be visible. That’ll only get you so far.
Side note if you want to store voxel data make sure to store them in chunks, and use buffers since 3d arrays can get big fast (memory wise). remember that you only have about 6.4 Gb + 100mb/player
For individual chunks look into what Minecraft does with it’s palette based compression. It allows you to store less data for the same chunks depending on how many unique voxel types there are. Meaning if you only have one type of block in a chunk then each block will only take up 1 bit.
If you wan’t state for your blocks (ie. being on or off, or maybe storing data), consider a ECS (It’s what Minecraft does as well).
Edit: The size of a chunk should be some multiple of 8 for easy binary storage.
I think the textures would be better because for the surfacegui you would have more objects in the game because an imagelabel must be parented to the surfacegui and for texture you just need to put it inside the part and it will work perfectly.