koobas.hobune.stream
Creating a mesh programatically for a tile-based 2D game
Hello,
currently I create a tilebased mesh programatically. The user can edit the tiles (place or destroy them) in the game. The tiles are all squares, so I can reuse the vertices from the right side of one tile for the left side of the next one. That way I can reduce the vertices in the mesh to 1/4. But now I face a problem with this while applying a texture to the mesh:
The texture is a spritemap, so the uvs determine which sprite the tile will have. It works great for single tiles but leads to a problem when some vertices are reused. For example a vertice belongs to tile 1 as the right bottom corner and tile 2 as the left bottom corner. The texture contains only one sprite for this example. Now both tiles would need different uv coordinates for the same vertice (tile 1 would need (1, 0) and tile 2 (0, 0).
Right now I think it is impossible to reuse the vertices but have different uvs. So there are two options available:
a) Don't reuse vertices. This would lead to four times as many vertices in the mesh. I got up to 5,000 tiles on the screen, so 20,000 vertices and uvs need to be saved. I don't know how much this affects performance/ram usage.
b) Don't use a spritemap but build a texture instead. With this approach I would create a texture for each chunk and paint it with the pixels from the spritemap. With 5000 tiles I would only need around 1250 vertices/uv's (okay, some more because vertices are currently not shared between chunks) but I had to repaint the texture every time the user changes the map. It would "only" affect the actual edited chunk and it's direct neighbours. Again I don't know how the impact on the performance/ram usage is.
Perhaps anyone have experience with this topic and can help me to choose the right option. Or maybe it doesn't have much impact at all. I could implement both and try to find the best one, but perhaps someone has done something similar and can spare me some struggle.
Don't reuse vertices. 20k vertices shouldn't be a problem. If the vertex count gets higher than 65k, you can always divide the mesh into chunks.
Okay thanks, I already thought that would be the way to go but it's good to know, that it's right. I changed everything now and the performance seems to be the same fps when idling. But when changing the tiles, the performance is much better now (only drops 1-2 when rebuilding the mesh every frame). Just one question left: Let's say I have a Vector3 a = new Vector3(0,0,0) and add it twice to a list. Is that better than adding new Vector3(0,0,0) twice (creating a new Vector3 each time)? I know this would be the case for classes but I am unsure since Vector3 is a struct. Therefore the vector will be saved twice anyway and I think I could just remove all the caching in my code to make it easier to read and to maintain.
