koobas.hobune.stream
How do I use many different tile textures for one mesh? 2D Tile based game.
I am making a 2D sandbox/tile based game (like terraria/starbound), and I am restarting my tile system. I know how to create a world/chunks/tiles for the game using a single mesh per chunk. The mesh contains squares to represent each tile as you could imagine, and I map the UVs for the mesh from a single texture.
But I want to be able to make many different variations for each tile (such as dirt, stone, etc.), and these tiles would consist of fulls blocks, straight-half blocks (4 sides), and diagonal-half blocks (4 sides). And each of these 9 options would have 4+ slight variations to make the game feel more random. So that is 36 versions of a roughly 18x18pixel texture for each tile type.
The method I am using now maps the tile from a SINGLE tile sheet that is the gameobject's material, that would contain all of the tile types, but as I added more tiles the single texture would get bigger and bigger to fit so many variations.
How can I map textures from different PNG files onto my mesh? Sorry if this is confusing, maybe there is a better method or maybe it is complicated. Any ideas would be appreciated.
Here are examples of Starbound's and Terraria's sprite sheet for a single tile.
Your Tile class needs to have a variable that holds the material/texture, or material/texture name, so your mesh/chunk generating method knowd which material/texture to use.
But how do you link the UV's with the correct material to use. The chunk object just renders using whatever material is on it, but I can't get it to use external materials.
It goes like this. Your tile class deter$$anonymous$$es the material to use. The chunk generating method keeps a list of materials that are being used for the mesh. If it reaches a tile that uses a material not yet in use, the resulting triangles are used with a new submesh. It's hard to explain but I sugggest reading up on using submeshes to use multiple materials with a mesh created from script.
Is there a specific reason you want to use a single mesh other than reducing draw calls? Because that's what batching is doi g for you anyway. Have SpriteRenderers with sprites from the same texture and Unity will batch draw calls for you.
I made the game work with sprite renders using a pooling system, but the amount of tiles on screen is about 80x45 = 3600 sprites for just the tiles. I was planning on including walls and other game objects on the scene and I found my FPS reaching about 55fps without implementing lighting and nearly any CPU calculations yet. I don't think I was doing it wrong because I first tried SpriteTile's (https://www.assetstore.unity3d.com/en/#!/content/13794) tile pooling, and then I recreated my own with the exact same idea and got similar fps.
I was testing if I could create the same exact system for tiles with much better performance by using $$anonymous$$esh Renders ins$$anonymous$$d of Sprite Renders (and far less of them), and in the process hopefully learn a thing or two about Unity's rendering systems because I am fairly new to it.
Also I've been reading around about creating new textures at run time in code so I'll see if I can get around to my idea using that.
I am actually creating textures in runtime its actually very fast and just one drawCall. I was using mesh generation but the meshes have tearing so i drop the idea.
So i am just creating a chunk with a runtime texture say 64*64 tiles if i need modify i just set pixels and apply the changes.
Another idea i will try its a material with tiling properties
