Hi, I have tried the tutorial from nehe regarding the loading of textures. It was mentioned in the tutorial that only bitmaps of height and width which are to the power of 2, and between 64 and 256 pixels can be loaded. It also mentioned that there is a way to get around the above mentioned limitations. I searched for the other tutorials by nehe but could not find any that used bitmaps which do not satisfy the limitations. Can somebody tell me if there is such a tutorial that works around the limitations, or any other ways that it can be done?
Textures must, according to the OpenGL specification, have power of two dimensions. And the size must be at least 64. Anything above 64 is implementation dependent. However, you can almost assume that most graphics cards can handle textures at least of size 256. You should always ask your OpenGL implementation for how large textures it supports. Use glGetIntegerv with GL_MAX_TEXTURE_SIZE to find out how large textures you can use.
As for non-power of two textures, the only way to use them in OpenGL today is to use the NV_texture_rectangle extension, or resize the image to a power of two before uploading them as a texture.
I think’ll you’ll find that you can use gluBuild2DMipmaps( ) for textures which aren’t a power of 2 in width and height. This is used in Nehe tutorial 7 if you want to take a look.
But take note, that that tutorial hides the truth. gluBuild2DMipmaps resizes the texture dimensions to be powers of 2, and you have no control over how it exactly does that.
I’m still not sure why everybody thinks that 64x64 is the minimum texture size. I regularly use textures smaller than this, and they work on everything I have tried it on. Maybe because the spec says that an implementation must support textures up to at least 64x64, so everybody assumed that the minimum allowed max texture size is the absolute minimum texture allowed?
Yup, I missed that tutorial, but according to what DFrey said, it resizes the bitmap to one with dimensions of power 2. That implies that the bitmap will be somewhat distorted? What if I want to keep the same aspect ratio?
Textures at least 64x64, I have used textures as small as 2x2 for many year. Many older drivers did not support textures above 1024x1024 but many now support at least 2048x2048
Now when I read my message again, I can clearly see I expressed myself a bit wrong. What I meant to say was, of course, that an implementation must support textures up to 64x64. As a user, you can of course use smaller ones. Sorry for that.
Nicky, the ratio of the texture will be changed when the image is scaled to the neared power of two, that’s true. But this distortion is canceled out when rasterized. Think of it this way. You have a square texture applied on a quad. Everything looks fine. Now scale the image by a factor two in one direction, and leave it as it is in the other direction. Render the same square with the new stretched texture. Since you have twice as many rows (or columns) in the texture that needs to fit to the same area, only one half of the rows in the texture is needed. What you end up with is (more or less) the same result.
It’s easy to try it out yourself. Make a texture of size, say 128x128, and a copy of that scaled to, say, 128x512. Apply them to a quad with the same texture corodinates.
Nicky, the problem I was alluding to with gluBuild2DMipmaps is not that the ratio of the texture dimensions may change, that’s a given and may always occur. What I was hinting at was how gluBuild2DMipmaps actually builds the mipmap chain. E.g. you have no control over determining if the texture dimension gets rounded up to the closet power of 2 (preserving detail), or if gets rounded down to the closet power of 2 (removing detail). Also, you have no control of which type of resampling filter is used. Is it a box filter? Is it a linear filter?
For most textures these are not important questions and gluBuild2DMipmaps does a fine job. But there may be times when you have a certain texture that requires you to have more say in how the mipmap chain is built. I find this to be the case quite often with textures used for 2D sprites. Because of this, I always build my own mipmap chains. This also ensures the chain is the same across different OpenGL implementations.
Textures must be 2^n as opposed to n^2 in dimension (I believe). To overcome this you can…
load your image to an array bu then ‘pad’ it with a border so it becomes 2^n. Then load this padded 2^n texture and when you map it onto your quad rescale it to remove the border. i.e.
i = image
p = padding
i i i i i i p p
i i i i i i p p
i i i i i i p p
i i i i i i p p
pppppppp
pppppppp
pppppppp
pppppppp
(1.0 / 8) * 6 would be the x coord you use to map the top right corner of the image to the top right corner of your quad (width 6)