[The E]

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:

Team colors on:


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.

[redsniper]

This is incredible! One of my favorite features of Homeworld.

Is there anyway the player could select colors in-game, or is it all modder-controlled for now?

[The E]

All modder-controlled for the moment. Will be player-controlled once Valathil finishes his new options screen.

[Commander Zane]

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.

[MetalDestroyer]

I think it will be very usefull to Fate of the Galaxy. Great job !

[Deadly in a Shadow]

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?

[Dragon]

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?

[The E]

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.

[pecenipicek]

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.

[The E]

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.

[Nuke]

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).

[The E]

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.

[Colonol Dekker]

Can't download at work at the moment.


Are there example/sample maps included?


Congratulations and Kudos by the way

[The E]

No, there are no examples included.

[Colonol Dekker]

No problem, still a warmly recieved innovation to the engine.

[Herra Tohtori]

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.

[The E]

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.

[Dragon]

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.

[The E]

You could do that with the current code, and a bit of shader magic.

[Nuke]

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.