The thing is all the textures for different blocks are actually one big texture which contains the textures for all blocks.
Is there any way to take several 16x16 pixel images and place them like side by side or in a grid and combine to form one larger texture? That way if I wanted to add a new block to the game, I don’t have to edit this massive image used to make textures, but instead make the texture for the individual blocks and specify the coordinates on the grid to place the individual textures on.
Thanks.
PS: If I posted this in the wrong thread then can staff please move it to the correct one?
Without checking the tutorial to see exactly what you’re using this for…
If you are just concerned about the performance advantages of putting all of your textures into an atlas, you may be able to use Unity’s sprite packer (or legacy sprite packer) to automatically combine textures that you import into Unity as separate files.
If you are using custom code to extract pieces of a larger texture based on their coordinates, though, then this might not help, since you won’t have explicit control over where each sprite gets placed within the atlas.
Voxel-based games like minecraft run into the problem of balancing draw calls with flexibility. A common way to handle this is to place all textures used in the game into one large texture atlas, which enables us to define the block to draw based on the UVs within that texture atlas. Or in other words, you only use one material / texture for everything.
If i understood correctly, OP wants to use a texture atlas, but only create it at runtime, based on a collection of 16x16 pixel images, each representing a block (or a side of a block), such that he does not have to edit the whole atlas for each change.
That’s certainly possible… somehow. I dont know if i’m the right person to answer this, as i havent really worked with textures yet, but i’d try creating your own texture, by reading and comining all of the little ones. So your texture atlas texture would for example be 16blockCount pixels long and 166 (for each side of a block) wide. You now create your own Texture2D at runtime with that size, or something like that. You could then set the pixels sequentially by copying the pixels from the smaller images. Throughout this process you’ll need to remember where in the atlas you placed which block (id) tho, or you’ll run into problems later on. https://docs.unity3d.com/ScriptReference/Texture2D.SetPixel.html
My idea was to create the textures for each block as separate images. Then I would create a class titled TextureData which would take the image of a block’s texture as an input and a vector2 that would be used to specify where this texture should go on the main texture to form a grid with the others when combined.
Something like that is probably possible in principle, but you may need to jump through some hoops to ensure that the “original” 16x16 textures get unloaded from memory when you’re done, or else you’ll have 2 copies of everything in RAM for your whole game. Also, this will certainly increase your game’s loading time compared to having the atlas pre-made at build time, and you’d probably run into “interesting” issues if your atlas grew beyond a certain size.
If you are just learning to program and your goal is to make your life easier, this might not be the best path.
while technically true, this should not add any noticable difference unless OP wants to add thousands of blocks, or Unitys interal workflow for textures is extremely slow for some reason (could probably do it on the GPU in extreme cases tho). Creating a texture atlas for a couple douzen or even hundreds of blocks should not take long. Also, it’s exactly what Minecraft, for example, does too. So unless this is just some learning experience, it’s the right approach for easier texture pack support and such.
However, i honestly would not bother implementing this until a way late(r) stage in development, as it represents more of a nice-to-have feature, and implementing it definitely takes more time than manually editing the texture atlas each time you add a new block. Minecraft as well added it mainly for texture pack support (allowing packs to only change certain blocks, meanwhile preventing problems with outdated packs when introducing new blocks to the game).
Did you try what i suggested above? Seems to be exactly what you want if it works.
Is “thousands” an unrealistic number for this sort of game? Pardon my ignorance.
I think Unity limits its own packer to atlases of 2k square. I’m not sure why they chose that particular limit, but if you wanted to stay within the same limit and you are placing each block “type” on a separate row for organization, then you’d cap out at 128 block types.
How many is realistic depends on the kind of game. Some only feature a hand full of different block types, some hundreds. I looked up an ID list for Minecraft, and it goes roughly into the 500’s, so that’s probably a pretty good estimante for a large game. It’s worth mentioning that blocks often use the same texture for all 6 sides.
So even if there was a restriction of 2k*2k, then we’d still be able to save 15625 individual 16x16 textures in it. However, according to the link kdgalla just posted, it seems like they removed this limit (?) as the example creates an atlas of Texture2D(8192, 8192). Please correct me if i’m misunderstanding anything here.
Either way, the amount of blocks you can fit into such a texture shrinks rapidly as the resolution per block grows. A quick google search told me that some MC texture packs go up to 1024x1024 or even 2048x2048 pixels per block. Now that i think about it, the resulting atlas must be absolutely freaking huge.
So if there is some size restriction on Texture2D, you still have a good point there. Also, with these resolutions, the resulting loading times would probably justify a GPU based approach for speeding up the atlas creation.
But i guess at this point the discussion is getting a bit ahead of the problem, as OP should work on some proof of concept first, or even delay this task until a later stage of development imho.
So @kennethrunescape2019 how far in the development are you? If you are still in the early stages you probably should not worry about it, especially if you just started following that tutorial series.
I’d never heard of any sort of imposed limit but if you were working on mobile, it might be a good idea to stick to 2048x2048 just because there are also hardware limitations on texture size too.