Dynamic Mesh for a Tile Map

I am trying to render my procedural world. The generation part works, it generates data in a grid fashion (so you can get what tile should be at (x,y) with a function). The problem I am having now is actually in the rendering of it! It’s a tile map, with each tile having its own material. It has its own material so that each tile can have its own shaders and normal maps. Keep in mind the generation takes very little resources, the rendering is what is causing the slowdown. So let me start with what I have tried:

Loading in chunks:
This seemed like the obvious solution to me. The generation is done in 64x64 chunks, why not the rendering? It first creates the vertices, 4 per tile in a 64x64 grid. Then it checks all the tiles in that 64x64 chunk and creates a submesh for each type of tile. The result is a mesh that uses only the materials needed and just where it needs it. As for how many of them it needs, it uses 9 in total. The one the camera is in and the surrounding chunks.
This process is just slow. It loads 9 initially but only 3 every time you move out of the current chunk, but still it is slow.

Single Mesh:
This method is similar to the last, only here I have a single static mesh (created in the same way as the previous method) and then every time you move over to a new tile it regenerates, with a size of 64x64. This was meant to be a very brute force method that I used just to visualize the generated world, but oddly enough it has given me the best results. Yes it is expensive, but it doesn’t have to load as much at once. All in all though, it is still far too slow.

So that is what I have tried, and I have some thoughts on what might work:
I like the single tile map method, but it needs to be optimized. To be only have to update the tiles needed rather than the whole map. Because of how far the camera can zoom out, this tile map would probably have to be 128x128, which would exceed the vertices limit in unity. I suppose that would mean this tile map would need to be separated into several meshes. But the problem with this method, is I simply wouldn’t know how to go about it. The only idea I had was to have a list of verticies and then convert it to an array to write to the mesh filter. Being a list means I could remove points and the other points would shift to where they need to be, but this method comes with a list of complications (pun not intended).

So, that’s what I’ve got. Any ideas?

As always, thanks in advance! :slight_smile: Hope I can give back to this community more once I become more experienced in both C# and Unity.

Anyone have any ideas? I just tried having 16x16 chunks load in over time and the problem then was that I would have 64 meshes on screen. So far the most efficient method is still just using one mesh and updating it.

Bump.

I’d probably go with the chunks method. It shouldn’t be that slow, maybe you could use smaller chunks? Also, are you regenerating them every frame? Maybe you could just generate the meshes once and keep them?

I would generate the meshes only on demand, and keep them around enough to be near you, like the 3x3 you mentioned originally (9 meshes).

Then as you near the edges and start to need more meshes beyond that, fire off a coroutine that fabricates the new meshes, perhaps one strip of vertices at a time, yielding each frame, and finally when it is done produces the actual game object with the mesh filter and mesh renderer, and puts it in the scene. That way your performance should be better because you are slicing up a single chunk’s worth of work into several frames of time.