I recall bringing this up about a year ago in some thread, but I figured I'd post this again, as I had another thought on the matter while walking home from work.
The issue is with the number of passes being required for the more types of maps being applied. Right now, we have your base map, which is typically 32-bits for the more advanced maps, 24-bit color, 8-bit alpha. Then, we have a pass for the glowmaps, which can be 8-bit pcx or pretty much anything else, though I occasionally see 24-bit DDS used. Finally, for the moment we have the integrated shine/env maps, which use 32-bit for the more advanced maps with 24-bit color and 8-bit for the environment mapping. Soon, a new pass will be added for bump-mapping or normal-mapping, of which I'm not sure what the bit requirements are, but that will be a 4th render pass. What I had half-seriously proposed, was an FSO custom map format (obviously requiring some custom utility or plugin) which would merge the bulk of, if not all of these maps together into a single map format that would require only one render pass... say requiring a maximum of 128-bits to cover all possible necessities. I believe Taylor mentioned that such a thing was feasible, and that something like it was on the distant horizon.
On my way home the other day, it occurred to me that possibly a container format could be used, in place of a single mega-format filetype. In the way that .eff files list all the files that are needed for an animation, and that it can support multiple formats, perhaps we (when I say "we", I mean the coders who represent the interests of the FS community

) could develop a .umf or Unified Map Format. Like EFF, the file itself would reference the maps needed, their filetypes, and intended useages, like whether it includes an Alpha for the env mapping or not. It would need to be intelligent enough to know, for example, to ignore the glowmap during map load if the game was run without -glow in the command line. This would obviously mean that the maps need to be loaded and merged during the model loading process, so that they can be properly applied in the techroom and missions.
I assume that Taylor, Bobboau or another coder with knowledge of graphics implementation, will be by soon to say one of the following:
- That's completely preposterous
- Cool idea, but very hard to implement
- We've actually got something like this in the works, but it's for post 3.7
- Have you been reading my development log?
- OMFG, that's an AMAZING idea!! *runs off to implement*
- Thou shalt not mention this or anything like it ever again, under punishment of catapult.
Later!