Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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?

share|improve this question
    
which openGL version are you using ? –  concept3d Nov 15 '13 at 12:50
    
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? –  Tordin Nov 15 '13 at 13:33
    
@concept3d, I am using OpenGL 4.0 with shaders –  2am Nov 15 '13 at 16:49
    
@Tordin, I am talking about on top of each other in UV space. –  2am Nov 15 '13 at 16:50
1  
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. –  alariq Nov 15 '13 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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.