View Full Version : texture size in FBO
06-19-2007, 03:02 PM
I use FBO to render to texture, then show the texture to fill my window. I test it in my program that the texture dimensions have to be power of two, or the output is weird. But my window dimension is not power of two, besides users can change the size of the window. So there will always be margins. If I draw to a bigger texture which covers the window, the cost is more expensive. If I make a texture closer to cover the window, the quality is poor. How do I use the texture to fill my window? The texture dimensions have to be decided when building the FBO. I don't understand how games with a resolution like 1280x1024 can use full-screen FBO textures. Or do they use one of the methods I mentioned?
There is an extension for "rectangle" textures. That is, textures that are not power of two, but are still very fast to use. They are usually used for those cases, that you describe.
Those textures don't support mipmapping and only bilinear filtering. Also texture-coordinates are used differently. Those are all features, that one does not need, when you only render to those textures, therefore they are suited very well.
Take a look here (http://opengl.org/registry/specs/ARB/texture_rectangle.txt) .
When the user resizes your app, just recreate that texture with the new size.
Hope that helps,
PS: Modern hardware also supports real non-power-of-two textures, but they are usually pretty slow and therefore i would advise against using them.
06-19-2007, 03:27 PM
I don't understand how games with a resolution like 1280x1024 can use full-screen FBO textures.First, games render to the framebuffer most of the time. When they render to a texture, it isn't as a replacement for the framebuffer (which is what you're doing); it is because they want to use that texture to texture something.
Second, games usually don't let the player arbitrarily change the resolution. There is a resolution option, of course, but even those are limited to the actual real resolutions of the display and OS.
In any event, if you want to render to a "not-framebuffer" and then blit it to the screen, then you should allocate a texture that is of the nearest powers-of-two in size. So if they ask for a 1280x1024 screen, you create a 2048x1024 texture. Then only render to the portion of the texture that matches the viewport, and then blit from that onto the real framebuffer.
But in general, you should avoid the idea of "render everything off-framebuffer then blit" unless you have a specific need to do so.
06-20-2007, 03:59 AM
Originally posted by Jan:
PS: Modern hardware also supports real non-power-of-two textures, but they are usually pretty slow and therefore i would advise against using them. I found them to be as fast as power-of-two textures and slightly faster then rectangle textures on my GF7900, so I won't descrieb them as slow...
06-20-2007, 05:13 AM
Originally posted by Zengar:
Originally posted by Jan:
PS: Modern hardware also supports real non-power-of-two textures, but they are usually pretty slow and therefore i would advise against using them. I found them to be as fast as power-of-two textures and slightly faster then rectangle textures on my GF7900, so I won't descrieb them as slow... Starting from the Geforce 6xxxx, they made a pretty good GL 2.0 chip, so it's ok to use them on these. But Geforce FX apparently doesn't like them from what I hear (software emulation). It's best to use GL_TEXTURE_RECTANGLE on these.
We are talking about non mipmaped, clamp_to_edge textures, right?
On my ATI card using rectangle textures instead of NPOT textures gave an enormous speed boost. NPOT textures might work fine on some hardware, but for now rectangle textures work best when you target different hardware configurations.
Also, i like the non-normalized texture addresses. That's really useful, when you are doing screen-space calculations.
06-20-2007, 06:47 AM
First, games render to the framebuffer most of the time.All games supporting HDR render to texture most of the time.
My game only renders HUD to framebuffer. Everything else is rendered to texture (reflections, sky animation, water waves etc).
I've tried different approaches, and my final choice was to use power-of-two textures larger than screen.
Of course using 2048x1024 texture to cover 1280x1024 screen its very important that you remember to use glScissor.
06-20-2007, 08:15 AM
Does glScissor give improvement? I forgot about that. I was just using glViewport and this acts like a glScissor (I think). The rest of the texture remained all black but perhaps I should call glScissor as well.
06-20-2007, 12:48 PM
GL_TEXTURE_RECTANGLE_ARB is what I am looking for. I don't need mipmaps. The screen is now showed in a native texture resolution!
06-25-2007, 09:12 PM
Hi, it's me again.
I can use GL_TEXTURE_RECTANGLE_ARB without any problem. But when I try to render the texture by glsl, the texture coordinates are wrong.
Here are my shaders
uniform vec2 texdim;
gl_TexCoord = gl_MultiTexCoord0 * vec4(texdim, 0, 0);
gl_Position = ftransform();
uniform sampler2DRect source;
gl_FragColor = texture2DRect(source, gl_TexCoord.st);
}I use these shaders for the simplest case(rendering the texture in FBO). The result is a blank screen with only clear color. If I use normalized coordinates (0~1), the result is fine. However, if I change the window size, the texture would be stretched.
I don't have any problem if no shaders are used, so texture coordinates in glsl are obviously the problem.
ATI mobility radeon 9600, omega 3.8.360
Powered by vBulletin® Version 4.2.3 Copyright © 2016 vBulletin Solutions, Inc. All rights reserved.