Is animating a tile in a tilemap (quad per tile) m

I am new to procedural mesh generation and uv mapping from sprite atlas. So I don't know whether a solution that come to my mind is efficient, logical and "best way", or neither of these.

I am currently making a procedural tile map "engine-y" in Unity. I had a question about it here few days ago, (i asked whether to use a mesh or multiple sprite objects) and by the given answers i am now proceeding with the mesh generation way.

I've created the base structure-framework in my mind. I even made some prototypes. I will map each quad's UV, by the corresponding tile in the sprite atlas. (If there is a better way, please don't hesitate to tell ^^)

But i have a problem with animating them. For example, for a "water-type" tile, which is going to be animated ofcourse, there will be different "frames" of water sprites in the sprite-atlas.

So, i am thinking about updating "that quad's" UV positions to shift to the next frame of the water sprite in the atlas. But i am not sure if it's a good way or not. Is it logical to do that in a Update cycle? Even with the slow animation speed, it will be updating lot's of uv points in an Update cycle.

Say if i zooomed-out in game, and there are 100x100 = 10.000 water tiles in screen, (10.000 quads * 4 = 40.0000 uv points to be updated), will there be an impact on performance when i update that much of UV positions?

Or does the graphic card optimizes it so it doesn't even noticible?

If it's not a wise way, which probably isn't, what is most logical and professional way of animating tiles?

Note: There may or may not be a solution by computing it with shaders, but I don't know anything about shader programming, so if the best solution is to use shaders, I am not hesitated to learn it. If so please provide training sources for both shader programming and UV updating. (Unity uses ShaderLab for shaders if it matters)

Updating the UV positions is a fine way to do this animation. I don't think it will cause you performance problems.

However, here's another approach to consider. Make your water a separate material, only as wide as one tile's texture, but as tall as you want to make it. Build a mesh of quads for just the water textures, with UVs set to just one tile's worth of the texture height. Now, in the material properties, just change the Y offset of the texture on each frame. Leave all the UV's alone; the Y offset will effectively be added to the V values at each vertex. You can even change it in small increments on each frame (less than an entire tile's worth), for butter-smooth animation without having to touch the mesh at all.

The cost, of course, is that it's a separate material, and thus a separate draw call. But people tend to fuss far too much about draw calls anyway.

If you have multiple scrolling materials (e.g. clean water, muddy water, lava, glowy rivers of magical power, whatever), they can all share the same material, with one column each of the texture map. (But this will require them to all scroll at the same rate.)