Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Trivial Psychic on January 26, 2007, 12:04:21 pm
-
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!
-
A new file format won't help with this at all.
Even if you squeeze all channels into a single map, it will still take mutliple passes to render each effect.
What you're actually requesting are shaders, which can do multiple things in a single pass.
-
^^ What DaBrain said. ^^
We still have to do multiple passes whether the files are in a container format or not. The base and glow maps are rendered on the same pass, so that isn't an issue. The env map is on a separate pass more for code simplicity reasons than technical ones. Technically we can do the env pass (which is the envmap modulated against the spec map) in the same pass as the base/glow map pass, if your card supports 4 texture units (base/glow/env/spec). We require 2 texture units for the game to even work, so the render passes are restricted to two textures per pass just so that we don't have to make it all conditional and complicate things.
The specmap pass itself is special though, since it must be a separate pass because the lighting changes. When using a specmap we only render diffuse, ambient, and emissive (if enabled) light on all other passes. Those are then turned off and specular light is turned on when rendering the specmap. That way you get the proper lighting effects.
NVIDIA only offers 4 texture units, unless you use shaders. Many ATI cards support 8 texture units regardless of whether you have shaders or not. Most Intel cards (the ones that we would support anyway) support 4 texture units. But either way the specmap pass will always be separate until shaders get into full use, since we don't have enough control over the lighting to pull off the effect otherwise.
When normal map support is fully in I'll probably redo the rendering code so that it's a bit easier to handle all of that stuff (since we won't have shaders yet). At that point I will likely take a look at combining the env pass into the main render pass for the cards that can do it.
-
Given that I was talking about PCS a couple threads ago, the damning thing I see about this is the additional plugin/program support. How long until a coder said "Well, I could add bumpmapping, but given that the plugin developer has simply disappeared for the last month, nobody would actually be able to use it. Oh well."
-
Ah... so the answer is: we're not doing anything like this, because we won't have to, but some time from now we'll make it so its not really an issue.
Thanks for indulging me in my half-baked and uninformed ideas. :)
-
more like were not going to do it because it wouldn't do any good.
now I'd support a generic transparent container file for other reasons, but that would just be due to it making it easier to organize, it wouldn't help performance at all. map!=render_pass, you can have more than one map in a single render pass (glowmapping and environment mapping), and you can have one map used in sevral passes (this is how we do lights over 8 ), the only thing you can't do is have the same texture in the same render pass more than once.
anyway... were did I put that catapult....
-
im against a continer format, only cause its another step for modders. there are more than enough vp tools theese days to make packing easy. so at least from the players perspective its all neat. l just like my textures where i can get at em incase i need to change something.
now if performance is the problem id avoid using tga files. dds is a super-effietient texture format. you get an 8x compression with dxt1 and 4x with dxt5. if your worried youre gonna loose some quality then just go up to the next power of two, its still faster than tga. i see alot of mods using tga files iand i tend to frown on it.
-
do you know how the normal maps will be implemented at first?
it'll probably be much easier to test if someone can have some worked-on maps waiting for it.
-
Well, either wait for the SoL demo (for proper normal maps), or you could use my normal map pack for FS2.
I've created them by making a rather complex Photoshop batch.
The results vary though. Some of them should look 'ok', but a lot of them will probably look bad. It's up to use to rework them one by one.