Hard Light Productions Forums

Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: The E on January 26, 2012, 08:45:13 am

Title: Introducing: Team Colors
Post by: The E on January 26, 2012, 08:45:13 am
This was initially a TAP request, and credit for the idea and initial implementation goes to pecenipicek.


Okay, so what's this about?

If you have played Homeworld 2, you may remember that that game allowed you to customize the colour pallette used for your ships in multiplayer. You could choose a base and a stripe colour, and through shader magic, these colours would be applied to your ships.

This is a port of that same feature to FS2.

Great, how does it work?

First, you need to make a few adaptations to the textures used by the model you wish to recolor. This feature uses the heretofore unused red and blue channels on the normal map. Areas you wish to carry the base colour should receive a full value in the red channel, while areas that should get the stripe colour should receive a full value in the blue channel.

The models' diffuse map should also be adapted. The areas that should be coloured should receive a base colour of (127, 127, 127) (Or, in other words, a half value in the red, green and blue channels).
Essentially, those parts of the base diffuse texture should be grayscale only.

Now, in order to get a ship to use this, a few table changes are necessary. First, you need to define a set of team colors in colors.tbl (don't worry if you can't find that one, it's pretty damn new).
A team definition looks like this:
Code: [Select]
#Start Colors
;Because of the way the colors.tbl parser is set up, this section MUST be present, even if it is empty
#End

#Team Colors

$Team Name: Vaygr
   $Team Stripe Color: ( 10 240 10 )
   $Team Base Color: ( 240 10 10 )

#End

Both the stripe and base colours MUST be defined. If you wish to have one of those to not have an impact, set it to ( 127 127 127 ).

In ships.tbl, you need to set a default team for the ship class that will be using this feature. You can do this by adding a "$Default Team: <name>" entry after the $ND and before the $Show Damage entries. The team name is the name defined in colors.tbl. Setting this property will enable team coloring for that ship class. Not having it means team coloring will be unavailable for that particular class.

Finally, you need an updated main-f.sdr file.
Code: [Select]
#ifdef FLAG_LIGHT
uniform int n_lights;
#endif

#ifdef FLAG_DIFFUSE_MAP
uniform sampler2D sBasemap;
#endif

#ifdef FLAG_GLOW_MAP
uniform sampler2D sGlowmap;
#endif

#ifdef FLAG_SPEC_MAP
uniform sampler2D sSpecmap;
#endif

#ifdef FLAG_ENV_MAP
uniform samplerCube sEnvmap;
uniform bool alpha_spec;
varying vec3 envReflect;
#endif

#ifdef FLAG_NORMAL_MAP
uniform sampler2D sNormalmap;
varying mat3 tbnMatrix;
#endif

#ifdef FLAG_TEAMCOLOR
uniform vec3 base_color;
uniform vec3 stripe_color;
#endif

#ifdef FLAG_FOG
varying float fogDist;
#endif

#ifdef FLAG_ANIMATED
uniform sampler2D sFramebuffer;
uniform int effect_num;
uniform float anim_timer;
uniform float vpwidth;
uniform float vpheight;
#endif

varying vec4 position;
varying vec3 lNormal;

#if SHADER_MODEL == 2
  #define MAX_LIGHTS 2
#else
  #define MAX_LIGHTS 8
#endif

#define SPEC_INTENSITY_POINT 5.3 // Point light
#define SPEC_INTENSITY_DIRECTIONAL 3.0 // Directional light
#define SPECULAR_FACTOR 1.75
#define SPECULAR_ALPHA 0.1
#define SPEC_FACTOR_NO_SPEC_MAP 0.6
#define ENV_ALPHA_FACTOR 0.3
#define GLOW_MAP_INTENSITY 1.5
#define AMBIENT_LIGHT_BOOST 1.0

void main()
{
vec3 eyeDir = vec3(normalize(-position).xyz); // Camera is at (0,0,0) in ModelView space
vec4 lightAmbientDiffuse = vec4(0.0, 0.0, 0.0, 1.0);
vec4 lightDiffuse = vec4(0.0, 0.0, 0.0, 1.0);
vec4 lightAmbient = vec4(0.0, 0.0, 0.0, 1.0);
vec4 lightSpecular = vec4(0.0, 0.0, 0.0, 1.0);
vec2 texCoord = gl_TexCoord[0].xy;

 #ifdef FLAG_SPEC_MAP
vec4 specColour = texture2D(sSpecmap, texCoord);
 #endif

 #ifdef FLAG_LIGHT
  #ifdef FLAG_NORMAL_MAP
// Normal map - convert from DXT5nm
vec3 normal;
vec4 NormalMap = texture2D(sNormalmap, texCoord);
   #ifdef FLAG_TEAMCOLOR
vec2 teamMask = NormalMap.rb;
   #endif
normal.rg = (NormalMap.ag * 2.0) - 1.0;
   #ifdef FLAG_ENV_MAP
vec3 envOffset = vec3(0.0);
envOffset.xy = normal.xy;
vec3 envReflectNM = envReflect + envOffset;
vec4 envColour = textureCube(sEnvmap, envReflectNM);
   #endif
normal.b = sqrt(1.0 - dot(normal.rg, normal.rg));
normal = tbnMatrix * normal;
float norm = length(normal);
// prevent breaking of normal maps
if (length(normal) > 0.0)
normal /= norm;
else
normal = tbnMatrix * vec3(0.0, 0.0, 1.0);
  #else
vec3 normal = lNormal;
   #ifdef FLAG_ENV_MAP
vec4 envColour = textureCube(sEnvmap, envReflect);
   #endif
  #endif

vec3 lightDir;
lightAmbient = gl_FrontMaterial.emission + (gl_LightModel.ambient * gl_FrontMaterial.ambient);
float dist;

#pragma optionNV unroll all
for (int i = 0; i < MAX_LIGHTS; ++i) {
  #if SHADER_MODEL > 2
if (i > n_lights)
break;
  #endif

float specularIntensity = 1.0;
float attenuation = 1.0;

// Attenuation and light direction
  #if SHADER_MODEL > 2
if (gl_LightSource[i].position.w == 1.0) {
  #else
if (gl_LightSource[i].position.w == 1.0 && i != 0) {
  #endif
// Positional light source
dist = distance(gl_LightSource[i].position.xyz, position.xyz);
lightDir = (gl_LightSource[i].position.xyz - position.xyz);

  #if SHADER_MODEL > 2
if (gl_LightSource[i].spotCutoff < 91.0) {  // Tube light
float beamlength = length(gl_LightSource[i].spotDirection);
vec3 beamDir = normalize(gl_LightSource[i].spotDirection);
// Get nearest point on line
float neardist = dot(position.xyz - gl_LightSource[i].position.xyz , beamDir);
// Move back from the endpoint of the beam along the beam by the distance we calculated
vec3 nearest = gl_LightSource[i].position.xyz - beamDir * abs(neardist);
lightDir = nearest - position.xyz;
dist = length(lightDir);
}
  #endif

lightDir = normalize(lightDir);
attenuation = 1.0 / (gl_LightSource[i].constantAttenuation + (gl_LightSource[i].linearAttenuation * dist) + (gl_LightSource[i].quadraticAttenuation * dist * dist));
specularIntensity = SPEC_INTENSITY_POINT;

} else {
// Directional light source
lightDir = normalize(gl_LightSource[i].position.xyz);
specularIntensity = SPEC_INTENSITY_DIRECTIONAL;
}
vec3 half_vec = normalize(lightDir + eyeDir);

// Ambient and Diffuse
lightAmbient += (gl_FrontLightProduct[i].ambient * attenuation);
lightDiffuse += (gl_FrontLightProduct[i].diffuse * (max(dot(normal, lightDir), 0.0)) * attenuation);

// Specular
float NdotHV = clamp(dot(normal, half_vec), 0.0, 1.0);
lightSpecular += ((gl_FrontLightProduct[i].specular * pow(NdotHV, gl_FrontMaterial.shininess)) * attenuation) * specularIntensity;
}

lightAmbientDiffuse = lightAmbient + lightDiffuse;
 #else
lightAmbientDiffuse = gl_Color;
lightSpecular = gl_SecondaryColor;
 #endif

 #ifdef FLAG_ANIMATED
vec2 distort = vec2(cos(position.x*position.w*0.005+anim_timer*20.0)*sin(position.y*position.w*0.005),sin(position.x*position.w*0.005+anim_timer*20.0)*cos(position.y*position.w*0.005))*0.03;
 #endif

 // Base color
 #ifdef FLAG_DIFFUSE_MAP
  #ifdef FLAG_ANIMATED
vec4 baseColor;
if (effect_num == 2) {
baseColor = texture2D(sBasemap, texCoord + distort*(1.0-anim_timer));
} else {
baseColor = texture2D(sBasemap, texCoord);
}
  #else
vec4 baseColor = texture2D(sBasemap, texCoord);
  #endif
 #else
vec4 baseColor = gl_Color;
 #endif
 
 #ifdef FLAG_TEAMCOLOR
vec3 base = base_color - vec3(0.5);
vec3 stripe = stripe_color - vec3(0.5);
baseColor.rgb += (base * teamMask.x) + (stripe * teamMask.y);
 #endif

vec4 fragmentColor;
fragmentColor.rgb = baseColor.rgb * max(lightAmbientDiffuse.rgb * AMBIENT_LIGHT_BOOST, gl_LightModel.ambient.rgb - 0.425);
fragmentColor.a = baseColor.a;

 // Spec color
 #ifdef FLAG_SPEC_MAP
 #ifdef FLAG_TEAMCOLOR
specColour.rgb += ((base * teamMask.x) + (stripe * teamMask.y)) * 0.3;
 #endif
fragmentColor.rgb += lightSpecular.rgb * (specColour.rgb * SPECULAR_FACTOR);
fragmentColor.a += (dot(lightSpecular.a, lightSpecular.a) * SPECULAR_ALPHA);
 #else
fragmentColor.rgb += lightSpecular.rgb * (baseColor.rgb * SPEC_FACTOR_NO_SPEC_MAP);
 #endif

 // Env color
 #ifdef FLAG_ENV_MAP
vec3 envIntensity = (alpha_spec) ? vec3(specColour.a) : specColour.rgb;
fragmentColor.a += (dot(envColour.rgb, envColour.rgb) * ENV_ALPHA_FACTOR);
fragmentColor.rgb += envColour.rgb * envIntensity;
 #endif

 // Glow color
 #ifdef FLAG_GLOW_MAP
fragmentColor.rgb += texture2D(sGlowmap, texCoord).rgb * GLOW_MAP_INTENSITY;
 #endif

 #ifdef FLAG_FOG
fragmentColor.rgb = mix(fragmentColor.rgb, gl_Fog.color.rgb, fogDist);
 #endif

//Commented out. If HDR makes a comeback, we may need this.
//fragmentColor.a = clamp(fragmentColor.a ,0.0,1.0);

 #ifdef FLAG_ANIMATED
if (effect_num == 0) {
float shinefactor = 1.0/(1.0 + pow((fract(abs(gl_TexCoord[0].x))-anim_timer) * 1000.0, 2.0)) * 1000.0;
gl_FragColor.rgb = fragmentColor.rgb + vec3(shinefactor);
gl_FragColor.a = fragmentColor.a * clamp(shinefactor * (fract(abs(gl_TexCoord[0].x))-anim_timer) * -10000.0,0.0,1.0);
}
if (effect_num == 1) {
float shinefactor = 1.0/(1.0 + pow((position.y-anim_timer), 2.0));
gl_FragColor.rgb = fragmentColor.rgb + vec3(shinefactor);
#ifdef FLAG_LIGHT
gl_FragColor.a = fragmentColor.a;
#else
// ATI Wireframe fix *grumble*
gl_FragColor.a = clamp((position.y-anim_timer) * 10000.0,0.0,1.0);
#endif
}
if (effect_num == 2) {
vec2 screenPos = gl_FragCoord.xy * vec2(vpwidth,vpheight);
gl_FragColor.a = fragmentColor.a;
float cloak_interp = (sin(position.x*position.w*0.005+anim_timer*20.0)*sin(position.y*position.w*0.005)*0.5)-0.5;
#ifdef FLAG_LIGHT
gl_FragColor.rgb = mix(texture2D(sFramebuffer, screenPos + distort*anim_timer + anim_timer*0.1*normal.xy).rgb,fragmentColor.rgb,clamp(cloak_interp+anim_timer*2.0,0.0,1.0));
#else
gl_FragColor.rgb = mix(texture2D(sFramebuffer, screenPos + distort*anim_timer + anim_timer*0.1*lNormal.xy).rgb,fragmentColor.rgb,clamp(cloak_interp+anim_timer*2.0,0.0,1.0));
#endif
}
 #else
gl_FragColor = fragmentColor;
 #endif
}


How does it look in action?

Like this:
Team colors off:
(http://blueplanet.fsmods.net/E/pics/screen0053.png)
Team colors on:
(http://blueplanet.fsmods.net/E/pics/screen0054.png)

Can I use more than one color set per ship class?

Yes. In FRED's initial status editor, you can choose which team colors to use, if team coloring has been enabled for that particular ship.

Are there patches and test builds?

Of course.

Patch: http://blueplanet.fsmods.net/E/stuff/teamcolor.patch
Executables: http://blueplanet.fsmods.net/E/stuff/teamcolorexe.7z

EDIT: Changed shader to let base/stripe colours interact with spec colour.
EDIT2: Fixed a bug where team colors were not applied in the techroom.
EDIT3: Patch and exes have been updated to fix a few issues where team colors were not applied correctly in-mission.
Title: Re: Introducing: Team Colors
Post by: redsniper on January 26, 2012, 09:24:09 am
This is incredible! :eek: One of my favorite features of Homeworld. :yes:

Is there anyway the player could select colors in-game, or is it all modder-controlled for now?
Title: Re: Introducing: Team Colors
Post by: The E on January 26, 2012, 09:25:05 am
All modder-controlled for the moment. Will be player-controlled once Valathil finishes his new options screen.
Title: Re: Introducing: Team Colors
Post by: Commander Zane on January 26, 2012, 09:48:50 am
I think this is one of the most impressive things done here.
I wonder if this will see use in other mods outside of TAP, it could pave the way for further expressing the uniqueness of a squadron's craft outside of just having the insignia.
Title: Re: Introducing: Team Colors
Post by: MetalDestroyer on January 26, 2012, 09:51:48 am
I think it will be very usefull to Fate of the Galaxy. Great job !
Title: Re: Introducing: Team Colors
Post by: Deadly in a Shadow on January 26, 2012, 09:57:15 am
What-the-hell.

That's awesome! Very good job over here.

EDIT: Yay, question: So, how do I change the channels with, let's say, GIMP?
Title: Re: Introducing: Team Colors
Post by: Dragon on January 26, 2012, 10:29:39 am
Wow, this is incredible. I wonder if Esarai's ships could be adapted to use this...
BTW, how to distinguish stripes from base on the texture itself? And how does this work with shinemaps?
Title: Re: Introducing: Team Colors
Post by: The E on January 26, 2012, 10:40:43 am
Quote from: Myself
First, you need to make a few adaptations to the textures used by the model you wish to recolor. This feature uses the heretofore unused red and blue channels on the normal map. Areas you wish to carry the base colour should receive a full value in the red channel, while areas that should get the stripe colour should receive a full value in the blue channel.

In other words, the normal map red channel acts as a mask for the base colour, while the normal map blue channel does the same for the stripe colour.
Title: Re: Introducing: Team Colors
Post by: pecenipicek on January 26, 2012, 10:44:29 am
Wow, this is incredible. I wonder if Esarai's ships could be adapted to use this...
BTW, how to distinguish stripes from base on the texture itself? And how does this work with shinemaps?
from what i've seen in the shaders, it does not yet do anything. one of the ideas was to add a 4th value to the table, and then determine how strongly will the color be applied on the specular side.
Title: Re: Introducing: Team Colors
Post by: The E on January 26, 2012, 12:12:18 pm
from what i've seen in the shaders, it does not yet do anything. one of the ideas was to add a 4th value to the table, and then determine how strongly will the color be applied on the specular side.

Fixed that.
Title: Re: Introducing: Team Colors
Post by: Nuke on January 26, 2012, 06:17:04 pm
id question whether or not the unused red or blue channels are really unused. i think using them would reduce the quality of the normal map. the color portion of a dxt* block(technically its the same for 1, 3, 5, and 5_nm and slightly different in 1a). when you save a dxt texture, for each block it finds the brightest color and the darkest color, and interpolates 2 more colors based on that data, this becomes the 2-bit color palette for that block. after that a color index is chosen for each index with the closest color value. dxt5 nm usually blacks out the red and blue channels so they dont play any role in palette generation (only the brightest and darkest green are considered and this ensures that only a green gradient exists in the color table).

when you start putting color data in those unused colors it changes the way the colors are chosen. to explain requires maths. c0 has the highest magnitude (lightest) and c1 has the lowest magnitude (darkest):
c2 = (2/3)*c0 + (1/3)*c1
c3 = (1/3)*c0 + (2/3)*c1
this is technically an integer vector operation because each c* value is a 16-bit 5'6'5 rgb value. im somewhat concerned that when we start messing with the red and blue channels that we will loose accuracy on the green channel.

say we have a block with a green pixel value between 20 and 40, with the red and blue channels at 0 the range values are (in index order):
Code: [Select]
c0=0'40'0
c1=0'20'0
c2=0'33'0
c3=0'26'0
so long as there exists max (31) red and min (0) blue or min blue and max red, no change to magnitude calculations should occur. becakse 0+31 == 31+0 and when you add green to the equation the darkest color has the lowest green value and the brightest color contains the brightest green, so no accuracy is lost. of course when the texture artists get ahold of this what will happen is they will do something stupid like try to soften their edges of these areas. so you now have green and blue channels which may be anything between 0 and 31. and this is where you run into troble. say a block has a softened edge running paralel to the sides of the block so that the range of red is 0-18 and the range of blue is 0-31, you might have a bright pixel of 18'20'31 and a dark pixel of 0'30'0. the pixel with the highest green value is actually the dim pixel. the color table would look like this:
Code: [Select]
c0=18'20'31
c1=0'30'0
c2=12'23'20
c3=6'26'10
in that case a pixel may exist in the source color block of value 0'63'0, however c2 (though it may be c1, im not sure how the closest color is chosen, but even then the point is still valid) is the closest value and so that index will be assigned to that pixel and when uncompressed at the video card will be read as 12'23'20, which has a much lower green value than it should, and thus its normal will be greatly innacurate.

so long as the rules are followed to the letter everything should be fine. if you add every pixel's red and blue value the result must be the same for every pixel, otherwise you compromise green's accuracy.

those 2 cents aside this is a great feature. there is little the coders can do prevent this problem as its done when you save your maps as dxt5. they could add more maps, which id assume is out of the question. another idea is switch normal maps to a 2 channel format (like bc5/3dc) and then use a dedicated luminance channel (like bc4) for masking areas which to apply team colors to (with a reduction of 1 channel). but those formats are not widely supported. the problem isnt really that severe just more artifacts in the normal maps. but so long as artists stick to values of 0'*'31 or 31'*'0, everything should be fine and dandy.

tldr: you might get more normal map artifacts if you use pixel values other than 0'x'31 or 31'x'0 (where x can be any value).




Title: Re: Introducing: Team Colors
Post by: The E on January 27, 2012, 01:37:34 am
I am well aware of that.

But, the options I had were to either use channels in other textures that were not used to carry data, or to introduce a new texture type. The first option seemed to be the best one available.
Title: Re: Introducing: Team Colors
Post by: Colonol Dekker on January 27, 2012, 02:00:02 am
Can't download at work at the moment.


Are there example/sample maps included?


Congratulations and Kudos by the way :yes:
Title: Re: Introducing: Team Colors
Post by: The E on January 27, 2012, 02:36:50 am
No, there are no examples included.
Title: Re: Introducing: Team Colors
Post by: Colonol Dekker on January 27, 2012, 03:55:48 am
No problem, still a warmly recieved innovation to the engine. :yes:
Title: Re: Introducing: Team Colors
Post by: Herra Tohtori on January 27, 2012, 07:15:53 am
id question whether or not the unused red or blue channels are really unused. i think using them would reduce the quality of the normal map. the color portion of a dxt* block(technically its the same for 1, 3, 5, and 5_nm and slightly different in 1a).

[...]

tldr: you might get more normal map artifacts if you use pixel values other than 0'x'31 or 31'x'0 (where x can be any value).


Yep, we discussed that already in #scp. And yes, the colour information in red/blue channels does affect the quality of the green channel.

Using uncompressed texture format (u8888) will work, but it will also mean the texture uses four times as much memory than using dxt5 normal map.


By comparison, using another texture (let's say with a -mask suffix) would only add as much memory as the new texture size is. Or, in a table format:


standard dxt5 normal map            X amount of memory

uncompressed u8888 normal map
+embedded colour data in red/blue               4X amount of memory

standard dxt5 normal map
+ dxt5 team colour map            2X memory



For the intent and purpose of using DXT5 compression for normal maps, it should be thought of as containing only two channels: RGB, and Alpha, for the exact reasons that Nuke mentioned - the compression algorithm reduces the green channel quality, if red and blue channel are not identical to green, or black. And when I speak of reduced quality, I mean there is significant degradation, to the extent that I don't think it's a viable option to use the R/B channels for this purpose.

Thankfully, DXT5 would be quite well suited for storing the colour and stripe information in a separate file for exactly the same reasons that make it decent for normal maps. Just save the colour information in RGB, and stripe information in Alpha (or vice versa).


It would, of course, be quite nice if we could get working support for a 2-channel, compressed or uncompressed normal map format. Small as they are, there's two ballast channels in the DXT5nm format that would be quite nice to be rid of.


In case you didn't notice, I for one support a separate file to store the stripe information, mostly for quality reasons, memory optimization reasons, as well as my opinion that a separate file would also be easier to add, support and maintain.
Title: Re: Introducing: Team Colors
Post by: The E on January 27, 2012, 07:34:18 am
Conceptually, it would be much cleaner to use a new texture to store this kind of masking information. However, introducing something like that would have meant using another TMU, a step I am reluctant to take if a solution is possible using the already established pipeline.
Title: Re: Introducing: Team Colors
Post by: Dragon on January 27, 2012, 09:00:44 am
Perhaps this could be done as an alternative solution. I can see it being much more efficient if the ship in question had a lot of rectangular color blocks, so resolution of the team color mask could be reduced considerably. Also, this could allow up to four different team colors. I don't know if anything would use that many, but a perspective of having a customizable 4-color camo texture is certainly an interesting one.
Title: Re: Introducing: Team Colors
Post by: The E on January 27, 2012, 10:10:19 am
You could do that with the current code, and a bit of shader magic.
Title: Re: Introducing: Team Colors
Post by: Nuke on January 27, 2012, 07:08:53 pm
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.
Title: Re: Introducing: Team Colors
Post by: Herra Tohtori on January 27, 2012, 08:09:09 pm
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.
Title: Re: Introducing: Team Colors
Post by: pecenipicek on January 27, 2012, 08:34:23 pm
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.
Title: Re: Introducing: Team Colors
Post by: Nuke on January 28, 2012, 01:04:10 am
what about an alpha channel in the glowmap?
Title: Re: Introducing: Team Colors
Post by: pecenipicek on January 28, 2012, 05:36:20 am
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
Title: Re: Introducing: Team Colors
Post by: Reprobator on January 28, 2012, 06:03:02 am
Why so much violence there? :p
Title: Re: Introducing: Team Colors
Post by: Nuke on January 28, 2012, 06:07:47 am
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.
Title: Re: Introducing: Team Colors
Post by: pecenipicek on January 28, 2012, 06:39:29 am
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 :p


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 -.-
Title: Re: Introducing: Team Colors
Post by: Nuke on January 28, 2012, 07:10:56 am
i suggested using 3dc/bc5 (http://en.wikipedia.org/wiki/3Dc) 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 (http://www.opengl.org/registry/specs/ARB/texture_compression_rgtc.txt) ot GL_EXT_texture_compression_latc (http://developer.download.nvidia.com/opengl/specs/GL_EXT_texture_compression_latc.txt) 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.
Title: Re: Introducing: Team Colors
Post by: Zacam on February 02, 2012, 10:33:43 am
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.
Title: Re: Introducing: Team Colors
Post by: The E on February 02, 2012, 10:44:32 am
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).
Title: Re: Introducing: Team Colors
Post by: Dragon on February 02, 2012, 08:02:46 pm
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).
Title: Re: Introducing: Team Colors
Post by: BlasterNT on February 02, 2012, 09:45:36 pm
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? 
Title: Re: Introducing: Team Colors
Post by: mjn.mixael on February 02, 2012, 10:07:54 pm
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.
Title: Re: Introducing: Team Colors
Post by: Nuke on February 02, 2012, 10:19:21 pm
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.
Title: Re: Introducing: Team Colors
Post by: Dragon on February 03, 2012, 06:17:12 am
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.
Title: Re: Introducing: Team Colors
Post by: The E on February 03, 2012, 07:02:45 am
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 (http://www.opengl.org/wiki/Array_Texture), 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.
Title: Re: Introducing: Team Colors
Post by: Dragon on February 03, 2012, 05:34:47 pm
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 :)).
Title: Re: Introducing: Team Colors
Post by: chief1983 on February 03, 2012, 09:37:36 pm
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.
Title: Re: Introducing: Team Colors
Post by: Zacam on February 05, 2012, 09:51:40 pm
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.
Title: Re: Introducing: Team Colors
Post by: CaptJosh on February 06, 2012, 09:02:59 am
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?
Title: Re: Introducing: Team Colors
Post by: Zacam on February 06, 2012, 09:25:20 am
CaptJosh: Incorrect. Those are glowPOINTS not animated glow MAPS. And a glow point is a singular texture of any given color that is usually used by a significant number of ships.

The red pulsing on a Shivan ship on its main body, (like, the Mara) is a glow map and it can be anywhere from 15-150 images that are rotated through in a sequence to produce the "animated" effect. And each and every one of those images takes a slot from bmpman, regardless of what texture type it is (be is Diffuse, -Shine, -Glow or -Normal...or -Misc.)
Title: Re: Introducing: Team Colors
Post by: Nuke on February 06, 2012, 11:03:06 am
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?

they are a waste, and while they are used for many effects, there are better ways to do those effects procedurally (shader magic) that demand less from bmpman. id like to see those at some point in the future, though i think the setup for those effects will require some form of materials system. probably a system where you define regions and colors for a number effects, these would be masked by another map (possibly glow alpha), and applied as if it were a glow map. these effects could also be linked to game events, such as having the pattern change depending on say, hitpoints, or shield strength to give visual indications of whats going on with it.

actually considering the number of things shaders bring to the game having another map sounds like a better idea, this thread has brought up a need for 2 channels for team colors, a gloss channel has been brought up, somone brought up anistrophic reflection, so in the end we will have a lot of maps and possibly the ability to have mods make their own shaders/maps. i really think its a bad idea to set map affix names and map channel allocation in stone, because once we have that materials system its more stuff to add reverse compatibility for later on.
Title: Re: Introducing: Team Colors
Post by: CaptJosh on February 07, 2012, 02:32:32 am
Ok. Thanks for the clarification, Zacam.
Title: Re: Introducing: Team Colors
Post by: Aesaar on February 12, 2012, 10:35:00 pm
Not really related, but what is the actual program used for viewing ships like this?
(http://blueplanet.fsmods.net/E/pics/screen0053.png)

Apologies for disrupting the thread, but I've looked around, and I can't find what it is.  I assume everyone knows, so this is probably among the most noobish question I can ask, but I'm at a loss.

Title: Re: Introducing: Team Colors
Post by: CommanderDJ on February 12, 2012, 10:46:00 pm
It's the ship lab. When you get to the mainhall in FSO, press F3.
Title: Re: Introducing: Team Colors
Post by: Aesaar on February 12, 2012, 11:02:46 pm
Thanks, much appreciated. 

I feel stupid now.
Title: Re: Introducing: Team Colors
Post by: chief1983 on February 13, 2012, 12:46:54 am
Nothing stupid about having to ask how to access an undocumented (or at best poorly documented) interface.
Title: Re: Introducing: Team Colors
Post by: X3N0-Life-Form on February 13, 2012, 03:20:37 am
Yeah, it took me a couple of year before I found out how to access it.
Title: Re: Introducing: Team Colors
Post by: Dragon on February 13, 2012, 06:27:40 am
I guess this thread could use some feedback. I've used the feature since it was implemented and I didn't had any problems with it. Works both with tiles and UVmaps, fighters and destroyers, animated parts and everything I've tried it on so far.
It might be a good idea to start looking into making team colors carry on to ship debris. Big ship exploding and losing all paint in process looks weird.
Another thing I'd like to see in the future would be allowing external weapons to use the parent's colors. Would be mainly useful for guns, but could also look nice on big torpedoes (of course, they'd have to keep their colors after launch).
Title: Re: Introducing: Team Colors
Post by: chief1983 on February 13, 2012, 10:14:12 am
Just don't have pieces of debris that came from colored parts of the ship.
Title: Re: Introducing: Team Colors
Post by: Dragon on February 13, 2012, 10:17:47 am
That's not an option, considering I'm adapted existing ships.
Title: Re: Introducing: Team Colors
Post by: Nuke on February 13, 2012, 12:01:15 pm
i think the best way to use team colors is sparingly, enough to mark the ship as being on a specific team, and it should be visible from any angle, but i wouldnt paint the whole ship with it like in the example.
Title: Re: Introducing: Team Colors
Post by: The E on February 13, 2012, 12:07:15 pm
Coloured debris pieces are going to happen. External weapons models, probably not.
Title: Re: Introducing: Team Colors
Post by: Dragon on February 13, 2012, 05:25:10 pm
i think the best way to use team colors is sparingly, enough to mark the ship as being on a specific team, and it should be visible from any angle, but i wouldnt paint the whole ship with it like in the example.
Many ships are using something other than metal gray as their main hull color, and I'm converting this color to main one, and the "secondary" color (if present) to stripes.
Most of the ships converted to use team colors would have their whole hull covered with them, there's no real alternative.
Also, I'm not using them to represent any sort of "team". Instead, they could represent the fleet ship belongs in, or it's owner, or even pilot (Aces could have a distinctive scheme).
Title: Re: Introducing: Team Colors
Post by: MatthTheGeek on February 13, 2012, 05:35:02 pm
Team colors are best used on non-tileraped ships, tbh. Wholy-colored ships don't usually look good. Trust my HW modding experience.
Title: Re: Introducing: Team Colors
Post by: Dragon on February 13, 2012, 05:45:16 pm
Steve-O's ships look great with team colors (I'd show you a pic, but I've only made schemes that look like default colors anyway, as I'm making this mostly for BP).
Tilemapped ships look really good with it, though I can't show you these, because I've used classified Inferno ships for testing (due to well defined stripe/main areas).
I'll soon have pics of non-classified tiled models and Steve-O's ships in other than default schemes.
Title: Re: Introducing: Team Colors
Post by: Nuke on February 13, 2012, 07:58:42 pm
for me i just need to open up my psd files and add a desaturation layer. just make a layer on time set blend mode to saturation and draw in white anywhere you want to grey out. you can also use it for one of your color masks. make a second saturation layer for your other channel. then export the red channel from one and the blue channel from the other.
Title: Re: Introducing: Team Colors
Post by: Enzo03 on February 14, 2012, 03:12:50 pm
If I decide to get back into modding again, I'll be sure to look into this because I was doing "color scheme tests" for the ships I made.  That is, there were certain parts which were a bright color just to see how it looked.  I had tried blue, red, and grey and they all turned out to look at least decent, for a completely undetailed texture on a subpar ship model.

It looked like this:
(http://i268.photobucket.com/albums/jj35/IastarothI/screen0021.png)
Hmm.  The colors on the monitor in my lab are much, much darker than the colors for my laptop monitor that I used while putting this together.
I was planning on using the colors in a more "realistic" approach such as stripes later on.  I stopped trying after slipping into depression last spring.

That ship does NOT use the stuff in the first post, it was just something I was messing around with some 10 months or so ago (actually almost exactly 10 months ago now that I think about it).

And yeah that ship is going really fast, FS2-wise.
Title: Re: Introducing: Team Colors
Post by: mjn.mixael on February 21, 2012, 03:55:46 pm
I was kinda watching from the sidelines on this one as I didn't think I really had a use for it. However, we are now considering using this feature in BtA and so, I think it's time for me to really weigh in.

I don't know if a decision has been made, but here's my OCD modder's perspective... Basically, in our case we would have to take the normal maps from many of the MVPs ships and edit them if this were to use the normal map channel. This is time consuming in that not only do we have to work on where the colors go, but we have to try and manipulate the maps to eliminate as much quality loss as possible. That, to me, doesn't sound like a particularly productive use of my time, and as such I'm very much in favor of a -misc map.
Title: Re: Introducing: Team Colors
Post by: Nuke on February 22, 2012, 02:44:15 am
i figure the best way to avoid quality loss would be to avoid putting team colors on areas of the hull with a lot of surface variation. essentially try to limit coloration to mostly flat areas. trouble spots are abrupt changes in normal direction over an area only a few texels wide, where full range needs to go to the green channel. also one axis of the normal is completely isolated from the color data, and variation on that channel shouldn't matter (not sure if alpha is the vertical or horizontal though, i think its horizontal but im not completely sure). so you can color areas in places where you have a lot of variation on the alpha channel , but little or none on the green channel. another thing you can do when colorizing is try to put your contain edges to colored spots within a single 4x4 block (put up a 4x4 pixel grid to be able to identify where the blocks are). you can soften your edges, so long as the transition stay withing the edge blocks. you can probibly also have surface variation in colored areas if the color masks are fairly uniform and completely contain any abrupt seams.

still its a lot of trouble for a pixel monkey. red and blue normal map channels are ballast, and should be treated as such. so thats a vote for a -misc map from me. one thing i thought about (for my own game engine at least), is using the diffuse and specular maps' alpha channels for u and v normals, so that no ballast channels are required. which would give equal performance to bc5, without the need of hardware support. probibly not practical for freespace's established paradigm though. i kinda hope that in the future map channel allocation could be handled with a material system proper, but that may be out of the scope of such a system.
Title: Re: Introducing: Team Colors
Post by: Zacam on March 09, 2012, 03:32:17 am
Technically, the feature can exists with BOTH options available to it simultaneously (with a little modification).

Simply allow the specification (to either the colors.tbl or mod.tbl or whatever) to define the "Team Color Read From:" to allow either "-normal" or "-misc" maps.

Course, if you go about mixing the two, then that could be a problem unless we really want the flexibility to define on a per declaration as well as a universal.

I only bring this up because I think it possible that the intended requesting mod for this feature may have already gone and created all their content based on how it is already implemented, namely in the normal map unused channels. And it would be utterly unfair to force them into the same amount of work that we ourselves don't want to do, which is to port all that work to yet another map.

I just can not agree to sticking it into the normal map channels and calling it a day and marking the feature as complete.
Title: Re: Introducing: Team Colors
Post by: The E on March 09, 2012, 03:55:48 am
Once I'm done with my current Mass Effect-related break, I'll do a new version of this that should adress these things.

As for the work required, at the moment, that isn't much. Copying channels out of an existing map and into a new one isn't that hard.
Title: Re: Introducing: Team Colors
Post by: pecenipicek on March 09, 2012, 06:54:17 am
Technically, the feature can exists with BOTH options available to it simultaneously (with a little modification).

Simply allow the specification (to either the colors.tbl or mod.tbl or whatever) to define the "Team Color Read From:" to allow either "-normal" or "-misc" maps.

Course, if you go about mixing the two, then that could be a problem unless we really want the flexibility to define on a per declaration as well as a universal.

I only bring this up because I think it possible that the intended requesting mod for this feature may have already gone and created all their content based on how it is already implemented, namely in the normal map unused channels. And it would be utterly unfair to force them into the same amount of work that we ourselves don't want to do, which is to port all that work to yet another map.

I just can not agree to sticking it into the normal map channels and calling it a day and marking the feature as complete.

As far as TAP assets go, dont worry about our stuff. I can always change the textures in a matter of 2 hours of work tops.
Title: Re: Introducing: Team Colors
Post by: pecenipicek on July 28, 2012, 06:56:53 pm
As of commit 9058 to the svn, this feature is in trunk. You still will need to modify your shaders to benefit from it and the default implementation on the first page uses the red and blue channels of the normal map.

But, in other news, the -misc texture has been added to the engine a while back as well, so you can have the shader pull up data from there instead of having to resave all of your normal maps and such.

Just a heads up to anyone marginally interested.

Title: Re: Introducing: Team Colors
Post by: mjn.mixael on July 28, 2012, 08:52:00 pm
I'm interested, I just don't have the ability to modify shaders... :(

Nor do I want to bother with as many shader changes that are going on recently.
Title: Re: Introducing: Team Colors
Post by: pecenipicek on July 28, 2012, 11:48:21 pm
I'm interested, I just don't have the ability to modify shaders... :(

Nor do I want to bother with as many shader changes that are going on recently.
grab either me or the e on irc for a quick walkthrough to modify the shaders for -misc texture useage.
Title: Re: Introducing: Team Colors
Post by: pecenipicek on July 30, 2012, 12:07:51 am
Okay, a simple and easy way to get team colors in your mod is as follows:

Open your colors.tbl
If it doesnt exist, create it.
Copy-paste the following and then edit to your hearts content. You are not restricted to a single team color entry. Just make sure that the general structure is kept.

Code: [Select]
#Start Colors
;Because of the way the colors.tbl parser is set up, this section MUST be present, even if it is empty
#End

#Team Colors

$Team Name: Vaygr
   $Team Stripe Color: ( 10 240 10 )
   $Team Base Color: ( 240 10 10 )

#End

Next, to actually apply a team color to a ship, you must do two things.

First, to actually even apply any sort of color to a ship, you need to either edit a ships ship.tbl entry and then, after that you can assign it custom team colors via FRED, in the ship editor, initial status.

For the default ship table entry, open your ships.tbl, find the "$Detail Distance:" entry and put the following immediately after it.
if you just want to enable team colors for the specified ship:
Code: [Select]
$Default Team: NoneIf you want to enable a particular team:
Code: [Select]
$Default Team: <Team name as defined in colors.tbl>
Example table excerpt from TAP:
Code: [Select]
...
$POF file: VGR_Destroyer.pof
$Detail distance: (0)
$Default Team: Vaygr
$Show damage: YES
$Density: 1
$Damp: 0.4
...

The last step is to create the neccesary "masks", or areas where the colors will be applied on a ship. this can be done via a texture with the -misc suffix. The red channel equates to what will be applied as the "base" color, and the green channel will be the "stripe". Think of it as an alpha channel for the color being applied, with 0 being no color applied and 255 full color applied at that spot.

If all goes well, you should have a model ingame with the colors applied.

One of the things to note is that if you are using a mod with some shaders tucked in a vp somewhere, chances are, its going to override the built-in shaders in the engine. in that case, drop this into your mods effects folder.
Code: (main-f.sdr as in r9076) [Select]
#ifdef FLAG_LIGHT
uniform int n_lights;
#endif
#ifdef FLAG_DIFFUSE_MAP
uniform sampler2D sBasemap;
#endif
#ifdef FLAG_GLOW_MAP
uniform sampler2D sGlowmap;
#endif
#ifdef FLAG_SPEC_MAP
uniform sampler2D sSpecmap;
#endif
#ifdef FLAG_ENV_MAP
uniform samplerCube sEnvmap;
uniform bool alpha_spec;
varying vec3 envReflect;
#endif
#ifdef FLAG_NORMAL_MAP
uniform sampler2D sNormalmap;
varying mat3 tbnMatrix;
#endif
#ifdef FLAG_FOG
varying float fogDist;
#endif
#ifdef FLAG_ANIMATED
uniform sampler2D sFramebuffer;
uniform int effect_num;
uniform float anim_timer;
uniform float vpwidth;
uniform float vpheight;
#endif
#ifdef FLAG_TEAMCOLOR
uniform vec3 base_color;
uniform vec3 stripe_color;
vec2 teamMask = vec2(0.0, 0.0);
#endif
#ifdef FLAG_MISC_MAP
uniform sampler2D sMiscmap;
#endif
varying vec4 position;
varying vec3 lNormal;
#if SHADER_MODEL == 2
  #define MAX_LIGHTS 2
#else
  #define MAX_LIGHTS 8
#endif
#define SPEC_INTENSITY_POINT 5.3 // Point light
#define SPEC_INTENSITY_DIRECTIONAL 3.0 // Directional light
#define SPECULAR_FACTOR 1.75
#define SPECULAR_ALPHA 0.1
#define SPEC_FACTOR_NO_SPEC_MAP 0.6
#define ENV_ALPHA_FACTOR 0.3
#define GLOW_MAP_INTENSITY 1.5
#define AMBIENT_LIGHT_BOOST 1.0
void main()
{
vec3 eyeDir = vec3(normalize(-position).xyz); // Camera is at (0,0,0) in ModelView space
vec4 lightAmbientDiffuse = vec4(0.0, 0.0, 0.0, 1.0);
vec4 lightDiffuse = vec4(0.0, 0.0, 0.0, 1.0);
vec4 lightAmbient = vec4(0.0, 0.0, 0.0, 1.0);
vec4 lightSpecular = vec4(0.0, 0.0, 0.0, 1.0);
vec2 texCoord = gl_TexCoord[0].xy;
 #ifdef FLAG_SPEC_MAP
vec4 specColour = texture2D(sSpecmap, texCoord);
 #endif
 #ifdef FLAG_MISC_MAP
   #ifdef FLAG_TEAMCOLOR
    vec2 teamMask = vec2(0.0, 0.0);
    teamMask = texture2D(sMiscmap, texCoord).rg;
   #endif
 #endif
 #ifdef FLAG_LIGHT
  #ifdef FLAG_NORMAL_MAP
// Normal map - convert from DXT5nm
vec3 normal;
normal.rg = (texture2D(sNormalmap, texCoord).ag * 2.0) - 1.0;
   #ifdef FLAG_ENV_MAP
vec3 envOffset = vec3(0.0);
envOffset.xy = normal.xy;
vec3 envReflectNM = envReflect + envOffset;
vec4 envColour = textureCube(sEnvmap, envReflectNM);
   #endif
normal.b = sqrt(1.0 - dot(normal.rg, normal.rg));
normal = tbnMatrix * normal;
float norm = length(normal);
// prevent breaking of normal maps
if (length(normal) > 0.0)
normal /= norm ;
else
normal = tbnMatrix * vec3(0.0, 0.0, 1.0);
  #else
vec3 normal = lNormal;
   #ifdef FLAG_ENV_MAP
vec4 envColour = textureCube(sEnvmap, envReflect);
   #endif
  #endif
vec3 lightDir;
lightAmbient = gl_FrontMaterial.emission + (gl_LightModel.ambient * gl_FrontMaterial.ambient);
float dist;
#pragma optionNV unroll all
for (int i = 0; i < MAX_LIGHTS; ++i) {
  #if SHADER_MODEL > 2
if (i > n_lights)
break;
  #endif
float specularIntensity = 1.0;
float attenuation = 1.0;
// Attenuation and light direction
  #if SHADER_MODEL > 2
if (gl_LightSource[i].position.w == 1.0) {
  #else
if (gl_LightSource[i].position.w == 1.0 && i != 0) {
  #endif
// Positional light source
dist = distance(gl_LightSource[i].position.xyz, position.xyz);
lightDir = (gl_LightSource[i].position.xyz - position.xyz);
  #if SHADER_MODEL > 2
if (gl_LightSource[i].spotCutoff < 91.0) {  // Tube light
float beamlength = length(gl_LightSource[i].spotDirection);
vec3 beamDir = normalize(gl_LightSource[i].spotDirection);
// Get nearest point on line
float neardist = dot(position.xyz - gl_LightSource[i].position.xyz , beamDir);
// Move back from the endpoint of the beam along the beam by the distance we calculated
vec3 nearest = gl_LightSource[i].position.xyz - beamDir * abs(neardist);
lightDir = nearest - position.xyz;
dist = length(lightDir);
}
  #endif
lightDir = normalize(lightDir);
attenuation = 1.0 / (gl_LightSource[i].constantAttenuation + (gl_LightSource[i].linearAttenuation * dist) + (gl_LightSource[i].quadraticAttenuation * dist * dist));
specularIntensity = SPEC_INTENSITY_POINT;
} else {
// Directional light source
lightDir = normalize(gl_LightSource[i].position.xyz);
specularIntensity = SPEC_INTENSITY_DIRECTIONAL;
}
vec3 half_vec = normalize(lightDir + eyeDir);
// Ambient and Diffuse
lightAmbient += (gl_FrontLightProduct[i].ambient * attenuation);
lightDiffuse += (gl_FrontLightProduct[i].diffuse * (max(dot(normal, lightDir), 0.0)) * attenuation);
// Specular
float NdotHV = clamp(dot(normal, half_vec), 0.0, 1.0);
lightSpecular += ((gl_FrontLightProduct[i].specular * pow(NdotHV, gl_FrontMaterial.shininess)) * attenuation) * specularIntensity;
}
lightAmbientDiffuse = lightAmbient + lightDiffuse;
 #else
lightAmbientDiffuse = gl_Color;
lightSpecular = gl_SecondaryColor;
 #endif
 #ifdef FLAG_ANIMATED
vec2 distort = vec2(cos(position.x*position.w*0.005+anim_timer*20.0)*sin(position.y*position.w*0.005),sin(position.x*position.w*0.005+anim_timer*20.0)*cos(position.y*position.w*0.005))*0.03;
 #endif
 // Base color
 #ifdef FLAG_DIFFUSE_MAP
  #ifdef FLAG_ANIMATED
vec4 baseColor;
if (effect_num == 2) {
baseColor = texture2D(sBasemap, texCoord + distort*(1.0-anim_timer));
} else {
baseColor = texture2D(sBasemap, texCoord);
}
  #else
vec4 baseColor = texture2D(sBasemap, texCoord);
  #endif
 #else
vec4 baseColor = gl_Color;
 #endif
  #ifdef FLAG_TEAMCOLOR
vec3 base = base_color - vec3(0.5);
vec3 stripe = stripe_color - vec3(0.5);
baseColor.rgb += (base * teamMask.x) + (stripe * teamMask.y);
  #endif
vec4 fragmentColor;
fragmentColor.rgb = baseColor.rgb * max(lightAmbientDiffuse.rgb * AMBIENT_LIGHT_BOOST, gl_LightModel.ambient.rgb - 0.425);
fragmentColor.a = baseColor.a;
 // Spec color
 #ifdef FLAG_SPEC_MAP
fragmentColor.rgb += lightSpecular.rgb * (specColour.rgb * SPECULAR_FACTOR);
fragmentColor.a += (dot(lightSpecular.a, lightSpecular.a) * SPECULAR_ALPHA);
 #else
fragmentColor.rgb += lightSpecular.rgb * (baseColor.rgb * SPEC_FACTOR_NO_SPEC_MAP);
 #endif
 // Env color
 #ifdef FLAG_ENV_MAP
vec3 envIntensity = (alpha_spec) ? vec3(specColour.a) : specColour.rgb;
fragmentColor.a += (dot(envColour.rgb, envColour.rgb) * ENV_ALPHA_FACTOR);
fragmentColor.rgb += envColour.rgb * envIntensity;
 #endif
 // Glow color
 #ifdef FLAG_GLOW_MAP
fragmentColor.rgb += texture2D(sGlowmap, texCoord).rgb * GLOW_MAP_INTENSITY;
 #endif
 #ifdef FLAG_FOG
fragmentColor.rgb = mix(fragmentColor.rgb, gl_Fog.color.rgb, fogDist);
 #endif
 #ifdef FLAG_ANIMATED
if (effect_num == 0) {
float shinefactor = 1.0/(1.0 + pow((fract(abs(gl_TexCoord[0].x))-anim_timer) * 1000.0, 2.0)) * 1000.0;
gl_FragColor.rgb = fragmentColor.rgb + vec3(shinefactor);
gl_FragColor.a = fragmentColor.a * clamp(shinefactor * (fract(abs(gl_TexCoord[0].x))-anim_timer) * -10000.0,0.0,1.0);
}
if (effect_num == 1) {
float shinefactor = 1.0/(1.0 + pow((position.y-anim_timer), 2.0));
gl_FragColor.rgb = fragmentColor.rgb + vec3(shinefactor);
#ifdef FLAG_LIGHT
gl_FragColor.a = fragmentColor.a;
#else
// ATI Wireframe fix *grumble*
gl_FragColor.a = clamp((position.y-anim_timer) * 10000.0,0.0,1.0);
#endif
}
if (effect_num == 2) {
vec2 screenPos = gl_FragCoord.xy * vec2(vpwidth,vpheight);
gl_FragColor.a = fragmentColor.a;
float cloak_interp = (sin(position.x*position.w*0.005+anim_timer*20.0)*sin(position.y*position.w*0.005)*0.5)-0.5;
#ifdef FLAG_LIGHT
gl_FragColor.rgb = mix(texture2D(sFramebuffer, screenPos + distort*anim_timer + anim_timer*0.1*normal.xy).rgb,fragmentColor.rgb,clamp(cloak_interp+anim_timer*2.0,0.0,1.0));
#else
gl_FragColor.rgb = mix(texture2D(sFramebuffer, screenPos + distort*anim_timer + anim_timer*0.1*lNormal.xy).rgb,fragmentColor.rgb,clamp(cloak_interp+anim_timer*2.0,0.0,1.0));
#endif
}
 #else
gl_FragColor = fragmentColor;
 #endif
}


If you are unclear on the idea still, please do say so, and i will try to help.


[edit]Also, as of now, there is some sorta bug that makes it not work at all, i have no idea why, so this will have to wait for a smidge of coder review -- Bug squashed, commited as of r9076.
[edit]mentioned the neccesity of at least $Default Team: None entry.
Title: Re: Introducing: Team Colors
Post by: z64555 on July 30, 2012, 01:07:16 am
Updated wiki to match the format of the rest of the tables. :P

Did see a note somewhere that at least one $<Color> had to be defined, but as far as I can tell by looking at the .cpp this isn't the case?
Title: Re: Introducing: Team Colors
Post by: The E on July 30, 2012, 01:27:23 am
Not anymore, anyway
Title: Re: Introducing: Team Colors
Post by: pecenipicek on July 30, 2012, 01:42:59 am
Updated wiki to match the format of the rest of the tables. :P
Thanks :)
Btw, where would be a good place to punt a link to the guide for team colors i made above?
Title: Re: Introducing: Team Colors
Post by: mjn.mixael on July 30, 2012, 08:02:14 am
Best thing to do, IMO, is to copy the whole guide onto a wiki page... Then you can link to it from the modding forum (tutorials thread) as well as linking to it in the colors.tbl and ships.tbl Wiki pages when the 'Team' stuff is mentioned.
Title: Re: Introducing: Team Colors
Post by: mjn.mixael on October 06, 2012, 11:55:00 pm
 :bump:

Actually working on Team Colors these days. This is something I've found myself wanting just for ease of modding. Consider this a take it or leave it suggestion.

But I've found myself wishing I could rotate through the various Team Colors I've got setup in the Lab. The only way to view colors on any given ship is to set the default in ships.tbl, load FSO, view it, exit FSO, alter the default in ships.tbl... repeat. A scroll through would be mighty helpful. But it'd also only be helpful for the few times a modder actually needs that functionality, so the code time may not equal the benefit time.
Title: Re: Introducing: Team Colors
Post by: MatthTheGeek on October 07, 2012, 03:20:57 am
Given how messy the lab code already is and how few people actually use team colors...
Title: Re: Introducing: Team Colors
Post by: Dragon on October 07, 2012, 04:41:46 am
Given how messy the lab code already is and how few people actually use team colors...
Coming from one of the people who do. :D
It's a good idea, definitely worth the time. This feature has the potential far beyond HW-style team colors, and I think it might see a lot of use.
Title: Re: Introducing: Team Colors
Post by: The E on October 07, 2012, 04:48:33 am
But I've found myself wishing I could rotate through the various Team Colors I've got setup in the Lab. The only way to view colors on any given ship is to set the default in ships.tbl, load FSO, view it, exit FSO, alter the default in ships.tbl... repeat. A scroll through would be mighty helpful. But it'd also only be helpful for the few times a modder actually needs that functionality, so the code time may not equal the benefit time.

The problem, at least as far as I can work it out, is that there's no "selection" type control in the lab UI code. So I think what I'm probably going to do will be a few boxes where you can enter RGB values directly.
Title: Re: Introducing: Team Colors
Post by: Dragon on October 07, 2012, 04:52:45 am
The problem, at least as far as I can work it out, is that there's no "selection" type control in the lab UI code. So I think what I'm probably going to do will be a few boxes where you can enter RGB values directly.
Even better. Would that a be possible to make a button to dump those settings to a text file? That'd greatly speed up fine-tuning the colors.
Though I can see "Selection" of table presets being possible by having "next preset" and "previous preset" buttons that scroll through the table.
Title: Re: Introducing: Team Colors
Post by: Admiral MS on October 07, 2012, 05:21:30 am
But I've found myself wishing I could rotate through the various Team Colors I've got setup in the Lab. The only way to view colors on any given ship is to set the default in ships.tbl, load FSO, view it, exit FSO, alter the default in ships.tbl... repeat. A scroll through would be mighty helpful. But it'd also only be helpful for the few times a modder actually needs that functionality, so the code time may not equal the benefit time.

The problem, at least as far as I can work it out, is that there's no "selection" type control in the lab UI code. So I think what I'm probably going to do will be a few boxes where you can enter RGB values directly.

You could use key input to rotate through the team colors similar to what it does for throttle settings or insignia switching without adding new interface parts - but a new box to input RGB values sounds lot more useful  :)
Title: Re: Introducing: Team Colors
Post by: Dragon on October 07, 2012, 05:29:55 am
You could use key input to rotate through the team colors similar to what it does for throttle settings or insignia switching without adding new interface parts - but a new box to input RGB values sounds lot more useful  :)
Wait. You can control insignia and throttle in the lab? Since when, how and where is it documented? Is there any complete list of what you can do in the lab?
Title: Re: Introducing: Team Colors
Post by: redsniper on October 08, 2012, 09:10:46 am
We're also going to need sexp control of team colors so that we can have color-cycling psychedelic disco ships. Thank you.
Title: Re: Introducing: Team Colors
Post by: Dragon on October 08, 2012, 09:15:32 am
Or HW style "instant repainting". That feature could also come in handy, especially if they could be defined on the fly.
Come to think of it. If it was possible to use SEXPs (or a LUA script) to cycle the R value in the team color setting, and to somehow apply the team color to the glowmap instead of diffuse, it could be possible to make a "cheap" animated glowmap. I don't know how well would that work in practice, but the possibilities are there.
Title: Re: Introducing: Team Colors
Post by: mjn.mixael on October 08, 2012, 10:23:37 am
We're also going to need sexp control of team colors so that we can have color-cycling psychedelic disco ships. Thank you.

 :eek: Redsniper is making JAD competitor campaign!
Title: Re: Introducing: Team Colors
Post by: Admiral MS on October 08, 2012, 10:42:05 am
You could use key input to rotate through the team colors similar to what it does for throttle settings or insignia switching without adding new interface parts - but a new box to input RGB values sounds lot more useful  :)
Wait. You can control insignia and throttle in the lab? Since when, how and where is it documented? Is there any complete list of what you can do in the lab?
I looked at what code is in there that could be used as an example. I don't know of any lab documentation so I guess it doesn't exist??

So we do have (not sure if all of them are working properly):
/ (key_divide): rotates through insignias
L: switch damage lightning effects (arcs) on/off
0-9: FXAA preset 0-9
B: increase bloom
N: reduce bloom
+5%/-5% throttle button: increase/reduce throttle
afterburner button: switch afterburner thruster on/off

E: Since when are these functions in there? Probably many years... I won't go checking when this part of lab.cpp has been changed  :p
Title: Re: Introducing: Team Colors
Post by: mjn.mixael on October 08, 2012, 10:43:59 am
That looks right.
Title: Re: Introducing: Team Colors
Post by: redsniper on October 08, 2012, 11:48:52 am
Oh wow. I had no idea the lab could do that stuff. Now I can see if FXAA is actually working or not. :p
Title: Re: Introducing: Team Colors
Post by: The E on October 08, 2012, 11:50:20 am
The FXAA and bloom things are pointed out on the lower screen edge......
Title: Re: Introducing: Team Colors
Post by: redsniper on October 09, 2012, 08:19:45 am
Well maybe I can't read then. :p
Title: Re: Introducing: Team Colors
Post by: Flaser on October 09, 2012, 08:24:41 am
Let's not forget mouse interaction:
Left click + Drag = rotate model
Right click + Drag up/down = zoom
Shift + Left click + Drag = drag model
Title: Re: Introducing: Team Colors
Post by: Colonol Dekker on October 09, 2012, 04:32:46 pm
I knew about the mouse controls.. But nit the keyboard ones. Not meaning to detract from the original topic, but is there a techlab wiki page covering these?
Title: Re: Introducing: Team Colors
Post by: Dragon on October 09, 2012, 04:54:23 pm
There's not. The wiki page on F3 lab is very lacking in that regard.
Title: Re: Introducing: Team Colors
Post by: mjn.mixael on October 16, 2012, 03:35:49 pm
This got a little off topic.. So back to Team Colors...

I've just a few nitpicks. They are things I can deal with, but if someone's got time to fix/add them then all the better.

-Can't change or set the player's Team Colors in FRED.
-LOD 1 (in the target box) isn't showing team colors as far as I can tell.
-Can't switch between different Team Colors sets in the F3 Lab.
-SEXP Team Color switching? (This was mentioned by someone else.. thought I'd add it to the summary because I can see some use for it.)