I have a model to which I have attached multiple textures. Both textures are currently static, but if I want to move (or slide) the texture which is on the top (in UV space), is that possible?

Maybe by moving the texture coordinates or something?

  • \$\begingroup\$ which openGL version are you using ? \$\endgroup\$
    – concept3d
    Commented Nov 15, 2013 at 12:50
  • \$\begingroup\$ are you refering to ontop of each other in uv space? on top in the register stack? On top of the color channels? What kind of on top are we speaking about? \$\endgroup\$
    – Tordin
    Commented Nov 15, 2013 at 13:33
  • \$\begingroup\$ @concept3d, I am using OpenGL 4.0 with shaders \$\endgroup\$
    – 2am
    Commented Nov 15, 2013 at 16:49
  • \$\begingroup\$ @Tordin, I am talking about on top of each other in UV space. \$\endgroup\$
    – 2am
    Commented Nov 15, 2013 at 16:50
  • 1
    \$\begingroup\$ well, if you want to "move" texture, so that it slides, you indeed can modify UV in the shader, you may e.g. pass time variable in your shader and do tex.uv += vec2(time, 0) but you must understand that it does not mean that it will slide in horizontal direct, it will slide along U vector, and U direction is/could be different for different triangle. \$\endgroup\$
    – alariq
    Commented Nov 15, 2013 at 19:22

1 Answer 1


Maybe by moving the texture coordinates or something?

Yes, the simplest way to do this is to animate the texture coordinates of the relevant geometry over time. You could either:

  • Create a shader uniform variable representing "time," which you periodically update before rendering, and use to offset the texture coordinate U or V component (as desired) prior to sampling the texture. This approach implies any geometry rendered with this shader will have the animating texture, and so you'll need to render your object in two passes (one containing the geometry with fixed textures, the other containing the geometry with animated textures).

  • Update the texture coordinates of the affected portion of the geometry directly on the CPU (using a similar time-based offset as above, just on the CPU). This avoids the need to render the object in two passes, but it also means you are constantly updating the vertex buffer data, which is potentially performance-intensive depending on your buffer creation options and how you need to use the rest of the buffer.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .