Loading textures with unusual pixel formats

I’m currently working on a viewer for OpenFlight files, as part of a rather larger project. However,the OpenFlight API’s image loading function seems to work in a rather strange manner (which took a hell of a long time to work out, especially as there was no documentation that I could find as to its behaviour)

Instead of returning pixel data in the usual RGBRGBRGB… format, it returns all the red pixel data, then the green, then the blue. (Anyone with experience with the OpenFlight API who knows otherwise please say so, but all the problems I’ve been having seem to suggest this is how it’s working).

My question is therefore this:

Is there any way that I can use this data directly in a call to glTexImage2D, by using various glPixelStore and/or other OpenGL calls, to avoid having to reprocess the texture data to get it into a more normal format. (This is especially important since the textures are rather large, 1024x1024 images, and the load time is already quite long, and I’d prefer not to have to make it any longer)

You might be able to load it as is, and do some fancy texture coordinate hacks in a fragment shader to produce the correct output. Granted, it’ll be slower than normal, as it will require 3 separate texture accesses.

If it turns out that I really can’t do this using just OpenGL calls, I think it’d be preferrable to reformat the texture, rather than slow down the drawing of the object itself (The objects being viewed have a few thousand textured faces, and drawing needs to be fast enough for smooth rotation).

A few thousand faces is nothing for modern hardware.

However, you’re very likely best off to re-interlace your data. As you do, make sure to put it in BGRA/UNSIGNED_BYTE format in memory (with a made-up alpha value) because that’s what most hardware likes best to upload.

Is there any way that I can use this data directly in a call to glTexImage2D, by using various glPixelStore and/or other OpenGL calls, to avoid having to reprocess the texture data to get it into a more normal format. (This is especially important since the textures are rather large, 1024x1024 images, and the load time is already quite long, and I’d prefer not to have to make it any longer)
Even if you could directly load noninterlaced textures, I don’t think any hardware can store textures this way internally, so the drivers would have to reformat them anyway. The fact that each texture is 3 or 4 megs doesn’t matter; it’s the total amount of texture data that has to be rearranged. I think a modern processor could rearrange, say, 32 megs in less than a second, so it probably wouldn’t have a noticable impact on the load time, at least if the textures are only loaded at startup.