Archived

This topic is now archived and is closed to further replies.

Bucket_Head

Overcoming OpenGL's Insidious Texture Limitations

Recommended Posts

One of the only things that I don''t like about OpenGL is that annoying power-of-two, 256x256 texture limitation...What gives with that, anyhow? Why exactly is there such a limitation? I imagine it has something to do with efficiency of texture memory storage and/or transfer...But it still seems somewhat rediculous. The main issue I''d like to understand how to address is that of overcoming these limitations. How does one do this? When left to my own imagination, I considered some sort of funky routine that involves breaking a large or non-uniform image up into chunks, and peicing those image chunks appropriately onto the geometry as you wish them to appear...Though the idea of trying to figure out such an algorithm gives me a headache. Is there a much easier way? Possibly even one built into OpenGL? A coder friend of mine seems to be loading in a 1024x768 image without even knowing how he''s doing it, and the idea that he accidentally stumbled on a solution astonishes me. Maybe he got some bitmap loading routine from somewhere that automatically solves this problem, I don''t know... Anyways, this would clear up a large stumbling block, and allow me (and anyone else reading this who''s wondering) to make everything look so much better with high-resolution textures. That, and I wouldn''t have to re-size textures for some md2 files to load in my program, heh...I always thought that was annoying... So please help me! How do I overcome...OpenGL''s Insidious Texture Limitations?!? Thank you for your time. - Bucket - Hai, watashi no chichi no kuruma ga oishikatta desu! ...or, in other words, "Yes, my dad''s car was deliscious!"

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
OpenGL does NOT limit texture size to 256x256 (if something limits, then it must be your graphics card).
Use the OpenGL glGetIntegerv(GL_MAX_TEXTURE_SIZE, &texSize); call to determine maximum texture for a specific OpenGL implementation on a specific graphics card.
And texture maps aren''t limited to power-of-two either.


-t33

Share this post


Link to post
Share on other sites
Anonymous poster is right.

AFAIK power of two limitation in hardware is to avoid page break and reduce computations for texture mapping.


-* So many things to do, so little time to spend. *-

Share this post


Link to post
Share on other sites
You can use any size, but some cards don''t support that. You should stick with powers of two for compatibility.

The resons powers of two are used are so that a pixel can be found quickly by using bitshifting, ie, a pixel in a 32 bit 256x256 texture can be found with x<<2+y<<10 and the next 4 bytes are the colour. Bitshifting is faster than multiplying.

Share this post


Link to post
Share on other sites
You can load a non-power of 2 texture into a "best fit" power of 2 surface and then use modified texture coordinates to reference only the image portion. You can also load multiple images into a texture surface and use modified texture coordinates to reference the various subregions as needed. Instead of using 4 256x256 texture and requiring 4 texture changes, use 1 1024x1024 texture with no texture changes.


"That ones free, the next one is gonna cost ya"

Share this post


Link to post
Share on other sites
only the voodoo1/2/3 and some other early noname cards have this limitation my vanta(tnt2) can handle 2048x2048 textures. either as ppl have said break the texture up or rescale the image. u can use gluBuildMipmaps(..) to do this

http://members.xoom.com/myBollux

Share this post


Link to post
Share on other sites
Better yet, why not just put your say 47x256 texture in a 256x256 one, then when it comes to texture mapping your objects, use the desired texture co-ords which define the position of the 47x256 texture in the 256x256 one?

Share this post


Link to post
Share on other sites
There is a trick that I use sometimes if I have a specific sized texture that I want to map to a specific sized quad.

Lets take a splash screen for example. I create a splash screen at 1024x768. Now I want to map it to a fullscreen quad.

First I load it in PhotoShop and change the Image Size to 512x512. This makes it look all scrunched up. But when I map it to a quad that takes up the full screen, it stretches it back out and it looks right again And it will look right on any standard resolution.

I lose a little bit of precision but PhotoShop does an excellent job of making it unnoticable.

Seeya
Krippy

Share this post


Link to post
Share on other sites
power of two does mean equal values !
I see 256*256 to contain a 47*256 texture !!! This is wrong

if you want to do so, use a 64*256 texture.
64 is a power of two number and 256 too.

you''re not limited to square textures, bloody hell !

-* So many things to do, so little time to spend. *-

Share this post


Link to post
Share on other sites
Guest Anonymous Poster

Ingenu: I don''t think so. Try to avoid small textures (smaller than 128x128), they''ll just increase the number of state changes.
Used a big texture instead (512x512 or 1024x1024), and copy all your small textures to it. Address them through modified uv coords. That is *alot* faster, esp. if you have countless small textures.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
STOP STOP STOP all these questions on what is fastest. A state change may be and in general is slow. However, you should profile your code path. Have a seperate path for 1) Changing texture with glBindtexture() and 2) your routine to modify texture coordinates on the fly. For all we know in 6 months time the state changes on the new whizz-bang graphic card will be less of a hit than the texcoord routines. Once you determine what is fastest, then use that path. You could enable a test at runtime to determine the best option for whatever the current pc spec is.


Share this post


Link to post
Share on other sites
Guest Anonymous Poster
if you use gluloadbitmap() you can use any size image and the glu routine will scale it to the closet ^2 this is maybe why your friend accidently can load any size image as his texure.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Using the texcoord manipulation thing is ALWAYS faster, independend of state change speed. You obviously will need texcoords for texture mapping your object, if you use state changes or not. Pre-adjusting them will get you rid of the state changes, and will NOT modify your runtime code otherwise, there is NO other performance hit associated with them ! You will always gain speed. This works only with non-tiled textures though.

Share this post


Link to post
Share on other sites