texture sizes other than powers of 2???
Right but you would lose quality, more or less significantly depending of the picture type (photo or cartoon) and depending on the filter applied during the resize.
You don''t lose quality from expanding the texture... not really. If you looked very closely at it, you might notice there seems to be higher resolution horizontally than vertically or vice versa, but it''s minor.
It also allows mipmaps to work correctly. They won''t work otherwise, not correctly.
~CGameProgrammer( );
It also allows mipmaps to work correctly. They won''t work otherwise, not correctly.
~CGameProgrammer( );
Why dont you use Nehe''s iPicture? It loads bitmaps, and jpegs and other formats i think. There is no size limitation so you can load whatever you want. To get the loading code to work all you realy have to do is cut and paste (dont forget includes - or something, i think). Anyway i find that iPicture usually solves all of my texture problems. Good luck 
quote:You don''t lose quality from expanding the texture... not really.
I agree than it may not be noticeable on some (most?) cases, but since there is a loss, if there is another method without loss then I would choose it instead. It''s just a matter of preference though. Either way, it all depends on the application.
quote:It also allows mipmaps to work correctly. They won''t work otherwise, not correctly.
I''m sorry but I have to disagree with that point. What will not work correctly is the gluBuild2DMipmaps function, but OpenGL''s mipmapping functionality will work correctly.
It''s not accurate to say there is a loss, as no data is lost. All that happens is the resolution in one direction is slightly higher than the resolution in another, and even this isn''t always true - if the width:height ratio of the original texture is equal to the width:height ratio of the power-of-two one, then there''s no noticeable difference at all.
If the ratios are not the same, then even the difference resolutions are barely noticeable since the texture will be scaled to its correct size. You have to keep that in mind - if you were to open the bitmap in an image editor, it would look distorted, but it would not look distored in the game because of teh way you scale it.
~CGameProgrammer( );
If the ratios are not the same, then even the difference resolutions are barely noticeable since the texture will be scaled to its correct size. You have to keep that in mind - if you were to open the bitmap in an image editor, it would look distorted, but it would not look distored in the game because of teh way you scale it.
~CGameProgrammer( );
That's true that there is no loss at all in some particular cases (though, be careful of using the right resize filter depending on texture's magnification/minification filter) and so forth the only disadvantage of resizing is the computation time of the resize. Unfortunately this case happens rarely. Fortunately, as you wrote, even the loss is (merely) not noticeable.
[edited by - vincoof on October 24, 2002 5:30:20 AM]
[edited by - vincoof on October 24, 2002 5:30:20 AM]
Has anyone mentioned that theres an nvidia extension for oddly sized textures yet? I don''t think it can be tiled though 
If it can''t be tiled, this is because it uses a trick similar as the technique I''ve described above (allocating a bigger texture and filling a subtexture). You can get the full specifications of the NV_texture_rectangle extension here.
Advantages of NV_texture_rectangle over the technique I described :
- Uses less memory (in theory) because there''s no need to allocate a "bigger powere-of-two dimensioned" texture,
- Easier to clamp (and clamp_to_edge and clamp_to_border).
Disadvantages of NV_texture_rectangle :
- no mipmap, even though the technique I descibred can not do "easy" mipmaps,
- no repeat, even though the technique I described may not be able to do it either in most cases
- available on NVIDIA cards _only_ (and also a few other cards)
Advantages of NV_texture_rectangle over the technique I described :
- Uses less memory (in theory) because there''s no need to allocate a "bigger powere-of-two dimensioned" texture,
- Easier to clamp (and clamp_to_edge and clamp_to_border).
Disadvantages of NV_texture_rectangle :
- no mipmap, even though the technique I descibred can not do "easy" mipmaps,
- no repeat, even though the technique I described may not be able to do it either in most cases
- available on NVIDIA cards _only_ (and also a few other cards)
That''s what I do, to deal with odd size textures:
I convert them, with an image editor, into a power of 2. In most of the cases, your program doesn''t have to rely on user selected textures, so, if you have a game, or something, it''s better to just resize/rescale them BEFORE even loading them in your aplication.
Advantages:
It can tile
Can have mipmaps
Higher image quality (since the resizing is made with a special software that usually does it better than your quick hacks)
No extra code
Dissadvantages:
Won''t work if the user selects whatever textures s/he has
Might take a little more disk space
Which is worse? Ignorance or apathy? Who knows?! Who cares?!
I convert them, with an image editor, into a power of 2. In most of the cases, your program doesn''t have to rely on user selected textures, so, if you have a game, or something, it''s better to just resize/rescale them BEFORE even loading them in your aplication.
Advantages:
It can tile
Can have mipmaps
Higher image quality (since the resizing is made with a special software that usually does it better than your quick hacks)
No extra code
Dissadvantages:
Won''t work if the user selects whatever textures s/he has
Might take a little more disk space
Which is worse? Ignorance or apathy? Who knows?! Who cares?!
That seems like a very useful extension. I find it simplest just resizing my textures to powers of two... I do this with the bitmap itself, I don''t have the program do it.
~CGameProgrammer( );
~CGameProgrammer( );
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
