Texture size issue?

Ok please keep in mind I am aiming to run this on video cards with 32 megs of ram or better. With that said, I am creating an exporter for maps. I want to texture the map obviously. I can do this one of two ways, either with alot of smaller 256256 textures, or with one LARGE 20482048. I have found draw backs to both of these methods. For instance, I want to compile all the map data into ONE compiled interleaved vertex array. That would make the map data very very fast. But with 256*256 textures I would have to break that data up into areas and compile the map by “zones” for instance. The larger texture will work fine for the entire map being compiled as one, but that one texture will take up 16 megs of video memory. But that is the only map I will need exept for character maps. I guess my question is this. I know on older cards textures over 256 are compressed down to 256, but I am not aiming for old cards. Will using that large of texture cause issues, being that it is TOO big for the internalworkings, or is useing smaller ones, and jockying them around in memory better??
Sorry to confuse you, and thanks again in advance.

You said that one big texture works and you don’t care about older video cards. Use one big texture …or is there other criteria that you didn’t mention?

Maybe you want to look into texture paging? I am not too familiar with that topic but you may want to do a search on the web.

What type of image format are you using? you may want to look into some different types. OR compression methods.

First, what is texture paging? and second, if i use one large texture, will that cause issues with mipmaps, and LOD settings, like if the polys right in front of me versus 30 units away use the same texture, will that cause problems with the internal mip mapping or LOD.

Got this from the sgi site.


Thanks for the sight, but that is one confusing idea. I think that I will simply use 2048*2048 at 24bit for my maps. That should keep that texture to 12megs, 8megs if i use 16bit instead. But here is a good question. Dont some cards internaly turn the textures into 32bit anyway? So by doing this, wouldnt my whole rant about saving space, and CPU cycles with 24bit be waisted???

If the internal format of your texture has 24 bit color and no alpha, some implementations may pad each pixel with an extra 8 bits for more effective addressing. For 16 bit internal formats, you have your texels on 2 byte boundary, and padding isn’t necessary.

If you really want to save memory, you should use texture compression.

I was under the impression that some implementations will pad out to RGBA regardless (with A = 1.0) - so you should be prepared for 4widthheight - (I’m I right here?)…

That seems realy stupid, to internaly pad everything upto 32bit. Talk about waisting space for speed. Is there anyway around this??? I just see that as very stupid. So I should turn all my textures into 32bit ones. Let me ask this… Does that make things faster at all?? Or just easier for the Video card. Sorry to get off on a rant, but that is really really stuppid. I mean why even have 24bit, and 16bit, formats anymore if they will never even be used??

Everything isn’t padded to 32 bits. 24 bits images usually are, but not 16 bit ones. It’s about efficiency when addressing each individual texel during rasterization. And yes, it can be faster to pad 24 bit images to 32 bit.

16 bit formats are usefull since they occupy only half the space of a 32 bit texture. And it’s also efficient to match the internal format with the format of the frame buffer. So if you have a 16 bit frame buffer, a 16 bit texture is usually more efficient than a 32 bit.

In terms of quality, what is lost when you use a 16bit texture versus a 24? I know that there is oviously a larger color scale with 24, but in actaul visable color, how large is the difference???

A fair amount is lost. You end up with only 32 shades for each primary color, as compared to 256 shades for each primary color in 24 bit color. This can lead to very obvious banding in images that are not complex or noisy. On the otherhand, for photographic images, it is usually much harder to notice the loss in quality.