koobas.hobune.stream
How to texture huge tile grids?
Hello,
I'm designing a grid based 3d game. My grid can potentially get several thousand tiles wide and deep and maybe 5-10 layers high at most.
Now the general recommendation for large tile maps seems to be to create your own custom mesh instead of instantiating several million planes or cubes. There's tutorials for that kind of thing it's handled.
But how do I actually texture the result? There seems to be a semi-hard cap for textures of about 4000 x 4000 pixels, but in a 1000 x 1000 tile map that'd leave me with 16 pixels for each tile. So not an option.
Now there's two options I'm currently seeing myself capable of implementing, but both seem to be suboptimal.
The first would be to create a million materials for that mesh with clamped textures (and 0 alpha edges) which are maneuvered into place by using offset and tiling, so each tile would have it's own materials. The problem is I'm not convinced this is actually significantly more effective than just spawning a million cubes if not worse. (If I'm wrong it'd be good to know)
The other option would be to give up on having one mesh for my field and just move and instantiate the field as needed and run everything over the game logic. I'd have like 4000 cubes that I'd move under the camera and reskin as needed. The problem with this is that it'd be a huge pain in the ass to program and it'd put hard limits on my zoom.
I'm thinking about having one material for each field/tile type and just having those appear where they're needed while all other tiles would be transparent for the material. But I have no clue how I'd go at that.
Or are there other potential solutions?
Are we talking about voxels here? If so then the usual way to solve this is to use a texture atlas and dynamically build the mesh in chunks through code. Each voxel's stored material just sets the relevant triangles' UV coordinates to the appropriate place in the atlas. Definitely don't have a bazillion cubes unless you're going to combine meshes at runtime, that way you avoid having too many draw calls and can optimise in many other ways too.
So I wouldn't build one large texture for the whole thing, but I'd have one texture and just position the vertices of each triangle on that graphic with the UV coordinates? So I can have several vertices mapped to the same position on the texture?
Sort of like in this picture? (I mean I'm using squares here but that's the idea.)
Alright, I can imagine this would work. But isn't there some sort of limit on vertices?
Hi, I don't know exactly the visual style you are trying to achieve but I'm thinking two possible ways to solve it: 1) You make a texture with a palette of colors and then you match parts of your grid mesh into the correct color coords. (Could work for a toon-looking game I think...) 2) You make a single texture with some squared tiles (for example: one for grass, one for rocks...) and then you assign the uvs of your mesh to match the desired texture at specific sections. The resolution could be big for this texture but you only need one for all the objects. This have been done before, check Doom megatextures for example.
Wouldn't it make more sense to have several materials ins$$anonymous$$d? I imagine the settings I'd want for each texture would be different.
Anyway the idea is to have something like a civilisation 5 map only with square fields and 3d. 
That's the editor scene view on my 3600 cube field that I want to replace/expand. (The blue fields are random water areas I spawned to test something else)
Either way if I go with the mapping idea, won't I run into the Vertex limit? As I understand it you can't have more than 65000 in a grid. Which considering I need like a million fields isn't exactly a satisfying solution consindering it only gives me 16250 fields.It's 5 orders of magnitude better than just instantiating cubes, but it'd be nice if I only needed one mesh (if possible).
Either way thank you for your advise.
Okay, so the solution I've picked is to generate meshes for each texture/field type. With ~60000 vertexes maximum for a mesh this gives me 15000 fields for each mesh object. It's helpful that parts of meshes don't need to be connected.
In a 1000 by 1000 grid this means I require a $$anonymous$$imum of 67 meshes, but I think/hope that's not a problem. I also don't need to go with a megatexture as a result and can have diverse shaders.
