Sign in to follow this  
knobby67

copy part of one texture into another

Recommended Posts

knobby67    126
Hi All,
I need to copy part of one texture into another. Basically I have a texture I map onto a model (say 100x100) I have a second texture (say 1000x100) which I use to hold an animation (10 frames in this case eg 10 x (100x100 pixels)) basically an old 2d animation strip. How can I map an area of 100x100 from the animation strip onto the model texture strip? I read about gltexsubimage using a back buffer or a FBO but if I need to do this for a dozen + models it seems to be very heavy on the processor. Is there an easier way to do this?
Thanks in advance

Share this post


Link to post
Share on other sites
bluntman    255
Just off the top of my head:
You could use the animation texture directly and modify the UVs in your shader using a uniform.
FYI it is better to use textures whose dimensions are a power of 2 (PoT), e.g. 128x128 instead of 100x100.

Share this post


Link to post
Share on other sites
V-man    813
[quote name='knobby67' timestamp='1306913598' post='4818189']
Hi All,
I need to copy part of one texture into another. Basically I have a texture I map onto a model (say 100x100) I have a second texture (say 1000x100) which I use to hold an animation (10 frames in this case eg 10 x (100x100 pixels)) basically an old 2d animation strip. How can I map an area of 100x100 from the animation strip onto the model texture strip? I read about gltexsubimage using a back buffer or a FBO but if I need to do this for a dozen + models it seems to be very heavy on the processor. Is there an easier way to do this?
Thanks in advance
[/quote]

How heavy is it? How many milliseconds is it taking? Did you use a BGRA format? Which hardware are you targetting? Are you doing this each frame refresh?

glTexSubImage doesn't use the back buffer. glCopyTexImage uses the backbuffer.
As for the FBO method, you can blit (glBlitFrameBuffer or glBlitFrameBufferEXT).

BTW, what is wrong with this site?

Share this post


Link to post
Share on other sites
mhagain    13430
glTexSubImage2D can be very efficient but you need to get the parameters right. The most common mistake is using a 3-component (RGB or BGR) format with the mistaken - but well-meaning - intention of "saving memory". As V-man said, using a GL_BGRA format is the key to good performance and I've personally found that some hardware likes you even better if you use a GL_UNSIGNED_INT_8_8_8_8_REV type. A second common mistake is to do texture updates as-required immediately before drawing. This gets you into an "update texture/draw with texture/update texture again/draw with texture again" cycle, which will cause GPU stalls and wreck parallelism. You need to bulk-update absolutely everything in one go instead.

For the texture sizes you're using and number of textures you're updating this should be almost transparent in terms of performance. If you do want to do it entirely on the GPU you can look at glCopyTexSubImage2D instead; this can normally transfer from the backbuffer (or currently bound FBO) to a texture in a fraction of a millisecond.

Don't worry about what seems on first reading to be very heavy or very light on the processor. When you're coding to graphics hardware a lot of what might be considered "the normal way of things" needs to be forgotten and re-learned - intuition gained from working with a pure software setup can be irrelevant or misleading, and can lead you down the wrong route.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this