Please explain ARB_texture_non_power_of_two
Author
Can someone explain how to use ARB_texture_non_power_of_two? I've read the specs. but can't seem to make it work. Where am I supposed to replace my 'GL_TEXTURE_2D', and to what?
with ARB_npot, no new texture targets where introduced. Instead, you can now use all "old" texture targets with npot-sized images without getting errors.
Please read the specs:
http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_non_power_of_two.txt
Please read the specs:
http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_non_power_of_two.txt
Normally in OpenGL your textures need to have sizes of powers of 2 (16, 32, 64, 128, etc) to be used in your game.
With the ARB_texture_non_power_of_two you now have the option to use other dimensions for your texture (as long as it stays rectangular). Meaning you can then have textures with dimensions like 257 or 148, etc. Make sure though that the videocard support the extension before using it.
EDIT: you can still use the GL_TEXTURE_2D as it has to do with the loading of your texture, if I am not mistaken.
With the ARB_texture_non_power_of_two you now have the option to use other dimensions for your texture (as long as it stays rectangular). Meaning you can then have textures with dimensions like 257 or 148, etc. Make sure though that the videocard support the extension before using it.
EDIT: you can still use the GL_TEXTURE_2D as it has to do with the loading of your texture, if I am not mistaken.
Author
That's the thing ... Am I supposed to enable something, or should odd sizes work right away?
(I'm running a gf6600 card, ogl 1.5)
(I'm running a gf6600 card, ogl 1.5)
If the extension is listed in the list of extensions you get from Open GL, it's supported, otherwise you've gotta stick with the old power-of-two textures.
Well the obvious question is how the hell is mipmapping done without power of 2 textures...I was under the impression power of 2 textures existed because their dimensions are always divisible by 2 for mip mapping...
@MrLane:
for mipmapping issues and faster computing. Power of two values are easier to
compute with/handle for processors.
But the question which cames up then for me is:
theoretically it should be a little bit slower - has anyone alread done some
tests on this new extension ?
for mipmapping issues and faster computing. Power of two values are easier to
compute with/handle for processors.
But the question which cames up then for me is:
theoretically it should be a little bit slower - has anyone alread done some
tests on this new extension ?
i belive NPOT textures are a bit slower to use, simple because the gfx card cant perform the same optermisations it can apply with a POT texture, however the speed hit shouldnt be that big so if you need 'em use 'em.
Quote:Original post by Mr Lane
Well the obvious question is how the hell is mipmapping done without power of 2 textures...I was under the impression power of 2 textures existed because their dimensions are always divisible by 2 for mip mapping...
Read the specification the AP above posted. Issue 6 answers that question.
Nothing is changed really; mipmaps are halved all the way down to size 1, just like power of two textures. In the case of an odd size, the next size is rounded down. For example, the size 123 gets halved to 61, 30, 15, 7, 3 and finally 1.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
