NPOT : No need to re-scale the image or anything like that in order to support NPOT textures, just simply create an image which snaps to the next largest power of two size on both axis, then load your image data into the 0,0 corner and then rescale your texture co-ordinates by the ratio of the new NPOT image size to the Original image size. You waste some texture memory but it's quicker to load the textures (As you don't need to scale them). If all the GTA2 textures are loaded on map startup and nothing is streamed during gameplay, you may as well rescale like you are in order to save wasting memory.
EDIT : totally ignore that, if you're scaling the images for POT anyway then you won't use any more GPU memory using the method I suggested. it'll be quicker than scaling and you won't have a DevIL (or other image lib) dependancy.
A Texture atlas would let you save memory and would also be faster when rendering (less texture switching) it's really easy, for the first image you create the biggest texture you can for your hardware (256x256 should be fine for example) and load it into the top corner, then return that images GL_ID and the texture coords that are used. Then for each sucessive image you 'search' your available space in your 'texture atlas' for a clear spot that your image will fit in (so look at the dimensions of existing images, itterating along X and Y until you've found some free space) then copy your image data there, then return the coords that were found for use for the new reference.
If your search doesn't find a space big enough for the image due to all the other images, you just create another big texture in GL and start the process all over again.
The end result is a handfull of big textures with all your small textures splattered across them and all your material/texture references are to these images and coord offsets to the actual image data you want.
There's all kinds of ways of doing it, different optimizations to use etc but the basic principal is sound. Look at light-map construction in a BSP map loader for an example, you can also read up on the design of ID Software's mega-texturing implementation in RAGE. Essentially the same technique but creates super large images in system memory, portions of which are copied to GPU memory when needed. RAGE (tech 5 or whatever) has algorithms (at map compile stage) that try to group required textures together in the mega-texture so when the 'atlas' portion is copied to a normal texture you're using most of the sub-textures for the on-screen geometry. They probably use visbility determination, portals etc as part of the algorithm to optimize the grouping of sub-textures.
Reply With Quote
Bookmarks