[Herra Tohtori]

As far as I know, the current shader implementation doesn't use height maps, and adding them in would require another texture mapping unit, in which case it would be more prudent to actually call it -mask texture.

[pecenipicek]

what about using a channel in the height map? as far as i know the height map uses all 3 channels as grey, what if we just keep it in green and then use red or blue for the mask channel. we also get another channel for future use, or we can allocate it so we can do 2 tone team colors.

heightmaps have been disabled in the engine for the time being, afaik. my original idea for the implementation was to go that way and not to mess with normal maps.

[Nuke]

what about an alpha channel in the glowmap?

[pecenipicek]

what about an alpha channel in the glowmap?

WHY THE **** DOES IT MATTER RIGHT NOW?!? Stop being whiny little pricks and use u8888 if you dont want compression artifacts, end of story god ****ing dammit!



[edit] for the records sake, TAP is using the glowmap alpha as a gloss map channel

[Reprobator]

Why so much violence there?

[Nuke]

what about an alpha channel in the glowmap?

WHY THE **** DOES IT MATTER RIGHT NOW?!? Stop being whiny little pricks and use u8888 if you dont want compression artifacts, end of story god ****ing dammit!



[edit] for the records sake, TAP is using the glowmap alpha as a gloss map channel

who is complaining? i bring up a valid point and it does little harm in discussing it. it matters because using 8888 would double the memory usage in the normal map, and if you're gonna do that you might as well use another texture all together, not to mention this is an invalid use of the dxt5_nm format. save for one mod thats using a custom shader so that the glow alpha does something, it seemed a more logical place to store data in the glow map (really do you even need a gloss map? i can get gloss without needing any additional maps). i have nothing against this idea, its a pretty good one, but i do have a few issues with its implementation, as i have made clear. stop being a drama queen.

[pecenipicek]

thing is, all the solutions end up being inadequate at best. if you hop on to the height map, you have the same issue as with the normal maps, you have 2 ballast channels if you want better quality.

as far as i'm concerned, i'm of the "oh well" opinion on the memory usage for the normal maps. at least compression artifact dont even enter into it there.


as for the gloss map, it modifies the specular highlight intensity. yes you can get gloss anyhow. i prefer a bit more control


the only realistical-ish solution is to get an actual two-channel format into the engine and ride on that.


i got pissed off due to the fact that you folks keep suggesting new stuff, yet noone tries to add something constructive, like for example adding support for a new texture format. yes, ideas and all that are appreciated. why do you all think we havent mulled over them already? restating them again and again will not help.

Spoiler:

also, sorry for the blowout earlier there nuke, i really should keep myself off the keyboard when i wake up -.-

[Nuke]

i suggested using 3dc/bc5 on my first post in this thread (and several times before now). its a 2 channel compressed format for normal maps. its data for both channels is stored in a similar way to a dxt5 alpha channel. it would be equivalent size to dxt5_nm. unfortunately its a fairly new format and older video cards (especially older nvidia cards) probibly dont support it. but for the cards that do support it, it would exceed dxt5_nm in quality. would probibly need to do another hardware survey to see what video cards support this format.  i believe these formats are supported under the GL_ARB_texture_compression_rgtc ot GL_EXT_texture_compression_latc gl extensions. this also supports a one channel version (bc4) of the format.

supposidly nvidia didnt support this till the geforce 8 series. im not sure how far back ati support goes (its their format so probibly before nvidia). if used you would probibly need to support fallback to dxt5_nm and mods would need to supply normal maps in both formats. probibly use a -normrg texture suffix so that the shader knows to use red/green instead of green/alpha.

[Zacam]

For that matter, even a standard RGB map should work for stacking BOTH of the features into. If you only need 2 channels for the Team Colors and 1 channel for the Gloss, combining those into a -TAP map for explicitly those features might be a better way to go. I woud not want to imagine Gloss maps with an Animated Glow map, for example. You'd have to alter the alpha on all of files in the sequence.

Okay, it probably doesn't need to be called a -TAP map, but you get the idea I hope. And lets take it one further. make it an RGBA map and add an Anisotropic control channel in there as well. 1 additional model map, covers 3 functions, doesn't interfere with the utilization of existing maps (or compromise quality for using them in an alternative fashion) AND makes it extensible for use -outside- of the given mod without requiring rejiggering any assets to any other mod that may choose to adopt the option. Like, Starfuries in TBP, HOL ships in FS1/Reconstruction, X-Wing Wings in Fate of the Galaxy, etc.

Yes, we -do- have two unused channels in the normal map and at some point it might be nice to correct that, though if a 3dc/bc5 is the same size as a DXT5, might as well stick to DXT5_NM. Yes, we do have an alpha channel on the diffuse and the glow maps (and they actually DO affect the maps when not otherwise told to do so). Yes, they -could- be re-purposed into providing extended functionality, but it hampers adoption by others that may be interested in doing so by -requiring- all previous maps to be either redone, or potentially introduce quality loss by editing and re-saving them to do so. Or introduces garbage if/when somebody introduces an asset to an adoption system that isn't made to utilize that feature, which is why Anisotropic Reflection isn't using the 2 "unused" channels in a normal map either and I'd hate to see what would happen if somebody inadvertently tried to do both AR and Team Colors at the same time.

I do get that we want to limit how many extra files we add to the stack of being loaded per model. We don't need to arbitrarily or unnecessarily raise that count. But I don't think the answer should be shoehorning functions into areas where they will either A: produce quality concerns (whether or not you or your mod share them or think them of consequence or worse, can only be over come at cost to the end user experience) or B: produce significant adjustment issues towards adopting them.

So in this case, I'd really like to heavily recommend that we DO actually add that "one more map" to the list and collaborate on the most effective manner towards implementing it (How many channels should it be, which channel is going to handle what, etc) and make this something that is fit and easily used and usable by everybody.

Mind you, that's just my two cents and I only make it as a recommendation, not as a discouragement.

[The E]

If we were to introduce a new map type, I would suggest to call it a "misc" map, to indicate that it's just a way for a mod to store 4 more float values per texture rather than implicating that there's a fixed use for that texture (unlike, say, glow or normal maps).

[Dragon]

Interesting, I've already thought up a myriad of uses for team colors, and it'd be great to see gloss and AR. A separate -misc map sounds like a good idea. Perhaps even the engine could even recognize multiple types of -misc maps (up to 8, for example, or better yet, a dynamic number), named -misc1, -misc2, etc. to allow things like using more team color channels (could be nice for a customizable camouflage scheme, for example), adding in more features or splitting maps for quality increase/size reduction.
Also, it'd be nice if FS could recognize grayscale DDS. I found that saving them like that (in "grayscale" mode in GIMP, to be precise) reduces their size by a fair margin without messing with quality or creating compression artifacts (in fact, it gets rid of artifacts when saving a grayscale map in DXT1), but FS doesn't show them correctly. I don't know if using multiple, DXT1 compressed grayscale maps wouldn't be more effective and give better quality than using fewer RGBA maps (given the same compression and size).

[BlasterNT]

Won't adding more maps decrease the number of models the game can handle?  How will this affect the texture limit, if each model will need one more image file now?Or am I underestimating the texture limit, and assuming it's much lower than it really is? 

[mjn.mixael]

The bmpman limit is there, but the average mod likely won't (or shouldn't) every hit it. But this new '-Misc' map is also optional and not necessary for every single ship. Shouldn't be an issue, unless you are going nuts with misc maps.

[Nuke]

Yes, we -do- have two unused channels in the normal map and at some point it might be nice to correct that, though if a 3dc/bc5 is the same size as a DXT5, might as well stick to DXT5_NM. Yes, we do have an alpha channel on the diffuse and the glow maps (and they actually DO affect the maps when not otherwise told to do so). Yes, they -could- be re-purposed into providing extended functionality, but it hampers adoption by others that may be interested in doing so by -requiring- all previous maps to be either redone, or potentially introduce quality loss by editing and re-saving them to do so. Or introduces garbage if/when somebody introduces an asset to an adoption system that isn't made to utilize that feature, which is why Anisotropic Reflection isn't using the 2 "unused" channels in a normal map either and I'd hate to see what would happen if somebody inadvertently tried to do both AR and Team Colors at the same time.

3dc only gives a (probably slight) quality increase over dxt5_nm, the maps are effectively the same size. i really have no problem sticking to dxt5_nm (namely compatibility reasons) so long as it doesn't end up becoming a dumping ground for new map channels. i was kinda hoping that the engine/shader could take a 3dc (or even uncompressed 2-channel normal maps, which use the same channel mappings) if 1: they are compatible with the video card, and 2: the maps are available. if neither condition is met, fall back to dxt5_nm. that would be the ideal implementation, imho.

i had assumed glow alpha wasnt actually used by anything. i kinda think of animated glowmaps to be a considerable waste of bmp slots, so i did not consider them. i hope that at some point they will be depricated by a superior shader effect. does give me an idea though, use glow alpha for team glow effect mask. effects could be generated by the shader with color parameters defined elsewhere. kinda went off on a tangent there.

i didnt really want to change existing maps though, because that creates a lot of trouble for modders, especially ones that dont have access to bitmap sources (like when you need to edit someone else's maps, like those in the media vps). i keep map sources in their original psd format with all layering intact, its overkill but has saved me a lot of work. modders should at least keep uncompressed versions of their maps on file. still asking people to change around their maps each time a new feature comes around should be avoided.

If we were to introduce a new map type, I would suggest to call it a "misc" map, to indicate that it's just a way for a mod to store 4 more float values per texture rather than implicating that there's a fixed use for that texture (unlike, say, glow or normal maps).

id just make it possible for mods to define custom map suffixes (assuming they cant already) for cases where they wish to roll their own shaders and need new map types. actually this whole thread is a case for a materials system.

The bmpman limit is there, but the average mod likely won't (or shouldn't) every hit it. But this new '-Misc' map is also optional and not necessary for every single ship. Shouldn't be an issue, unless you are going nuts with misc maps.

i figure anyone with the skills to write their own shaders will understand the implications of doing just that. at some point you got to step back and say theres just too many maps, they are slowing things down.

[Dragon]

Not only slowing things down (a good machine will handle even a huge amount of maps), but causing texture corruption due to getting over a certain hardcoded limit in BMPMan. This happened with old Steve-O's ships to me, having a lot of them in mission, fully normalmapped, plus early Nighteyes' effects (lots of frames) caused really weird issues with BMPMan.
Since then, I'm waiting for Steve-O to rework his capships and stopped using large numbers of 300+ frame effects.

[The E]

There are a few things we can do in the engine to make things easier on the GPU. OpenGL 3 introduced things called texture arrays, which effectively combine several textures and their associated mipmaps into a single large blob object. Since each texture array only occupies a single TMU, the amount of maps used by the engine can be increased dramatically; this is a necessary precursor to introducing shadow mapping for point light sources. It can also serve to massively simplify the current shaders, as we can remove a lot of the preprocessor directives.

[Dragon]

That sounds very, very interesting. Though I recall somebody saying that it'd take a while to move FSO to fully exploit OGL3 and use such textures (next day, Valathil posts an Texture Array build ).

[chief1983]

Nuke, keeping your original PSDs is not overkill, not one bit.  I don't know why any sane person wouldn't.

I'm not thrilled about the idea of another new map.  If there's any way to work this in with existing maps without a headache, I'd much rather do that.  The bitmap limit was bumped once already _because_ mods were hitting it, so I don't really agree that an average mod isn't likely to hit it.  Especially with all the effects people are trying to do now, EFF support being added for all sorts of elements, etc.

[Zacam]

It can and already has been worked into existing maps. However, the concern is that unless people have original sources for their images, implementing this or any other feature that can use a texture map channel is significantly impacted by the loss of quality that would be incurred in implementing it for any mod seeing to adopt it.

And even for those modders that DO have source maps resources, the loss in quality to the Normal map alone is tremendous and simply using uncompressed maps (while it is technically an answer from a quality standpoint) is not the answer if you want to introduce the feature to a lower end machine map which has to be compressed.

I see the point of not wanting to add maps unnecessarily. Which is why I don't make the recommendation lightly. But I still think it is the best way to move forward with the feature that can co-exist well with all mods, past and present, in terms of painlessly adopting the feature. And really, the biggest killer in any mission space for hitting the BMPMAN limit is going to be the Animated Glow Maps, not whether or not we have an additional -misc map in the list.

Now, if Layered DDS ever came out, then we could kick the whole conversation into the bucket because then we'd have 1 file where everything is in individual layers. But we don't have that yet and probably wont for quite a while.

[CaptJosh]

Nuke, you say animated glow maps are a waste of slots, but isn't an animated glow map how the lights on the "runway" of the Orion work? Also aren't there several other ships that look far better for having animated lights on them?