Valve's Glowing Text Shader

Started by
4 comments, last by simotix 13 years, 2 months ago
I wrote a decal generater with the Alpha Tested Magnification method defined here http://www.valvesoftware.com/publications/2007/SIGGRAPH2007_AlphaTestedMagnification.pdf and I tried to implement the outer glow shader but I had a few questions

1) What is the appropriate valus for something like "GLOW_UV_OFFSET", "OUTER_GLOW_MIN_DVALUE" and "OUTER_GLOW_MIN_DVALUE"? I have tried used (-0.004, -0.004), 0.3 and 0.5.

2) What is the value for "mskUsed"?

I tried to implement this with the code below but it just looked terrible and not even noticeable. (I do have the rendering working without trying this effect).

float4 PS( PS_INPUT input) : SV_Target
{
float4 baseColor = float4(0.0f, 0.0f, 1.0f, 1.0f);
baseColor.a = txDiffuse.Sample(samLinear, input.Tex.xy).a;

float2 glowOffset = float2(-0.004f, -0.004f);
float4 glowColor = float4(0.0f, 0.0f, 0.0f, 1.0f);

float4 glowTexel = txDiffuse.Sample(samLinear, input.Tex.xy + glowOffset);
float4 glowc = glowColor * smoothstep(0.3f, 0.5f, glowTexel.a);
baseColor = lerp(glowc, baseColor, baseColor.a);

return baseColor;
}
Advertisement
Has anyone been able to implement any of the text shaders that Valve described in that article? (Not just the glow shader)
[font="Courier New"]GLOW_UV_OFFSET determines the number of pixels that the glow effect will be offset from the text by (for using glow as a drop shadow). This is in normalized texture coordinates --- so if your texture is 512x512, then 1 pixel = [font="Courier New"]float2(1/512.0, 1/512.0).

[font="Courier New"]OUTER_GLOW_MIN_DVALUE / [font="Courier New"]OUTER_GLOW_MIN_DVALUE determine how far outside the shape the glow begins appearing, and when it reaches full opacity. The numbers to use here depend on how you generated your distance field....
0.5 means "right on the edge". 1.0 means "x units inside the shape". 0.0 means "x units outside the shape". Depending on how you generated the distance field, "x" is going to be a different number of pixels.

I would guess that [font="Courier New"]baseColor.a is the right value to use in place of [font="Courier New"]mskUsed, but before you do that part, you're missing eitherbaseColor.a *= smoothstep( SOFT_EDGE_MIN, SOFT_EDGE_MAX, baseColor.a );orbaseColor.a = step(0.5, baseColor.a);

[font="Courier New"]GLOW_UV_OFFSET determines the number of pixels that the glow effect will be offset from the text by (for using glow as a drop shadow). This is in normalized texture coordinates --- so if your texture is 512x512, then 1 pixel = [font="Courier New"]float2(1/512.0, 1/512.0).

[font="Courier New"]OUTER_GLOW_MIN_DVALUE / [font="Courier New"]OUTER_GLOW_MIN_DVALUE determine how far outside the shape the glow begins appearing, and when it reaches full opacity. The numbers to use here depend on how you generated your distance field....
0.5 means "right on the edge". 1.0 means "x units inside the shape". 0.0 means "x units outside the shape". Depending on how you generated the distance field, "x" is going to be a different number of pixels.

I would guess that [font="Courier New"]baseColor.a is the right value to use in place of [font="Courier New"]mskUsed, but before you do that part, you're missing eitherbaseColor.a *= smoothstep( SOFT_EDGE_MIN, SOFT_EDGE_MAX, baseColor.a );orbaseColor.a = step(0.5, baseColor.a);


Thank you for the help, I have been experiementing with this for a little bit now and have a few questions.

Currently my text is getting a poor inner shadow look, rather then an outer shadow. If the code I posted above is correct (which is nearly identical to the Valve example), it seems like it is do to the MIN/MAX glow value. I calculate my text fields using the type of algorithm that OrangeTangy posted in his blog, do you have an algorithm you can suggest. This uses 0.5 as the mask type value, I am not sure at all though what the MIN/MAX values should like though, I have tried numerous pairs but "nothing fit".

Where did you happen to find out some of this information, such as the normalized texture coordinates? I don't recall reading any of that.

Also, since it seems you may have implemented this before, what is your commendation for the smoothstep values when no effects are applied? I am currently doing "smoothstep(0.48, 0.52, alpha)"
When you calculate your distance field, each pixel ends up with a distance value to the edge of the shape. You then perform some kind of operation that converts these distances into bytes, where 0=far outside, 255=far inside and 127/128=on the edge.
Depending on how this conversion is performed, the meaning or your MIN/MAX parameters will be different!

For example, let's say that after converting distances to bytes, a difference of 1 means a distance of "1 pixel".
That would mean that 126 is 1px from the edge, 125 is 2px from the edge, etc, etc, and 0 is 127px from the edge.

Remember, once we're in shader-land, our 0-255 bytes are automagically converted to floats, meaning now:
0.0=far outside, 1.0=far inside, 0.5=on the edge.

This also means that "one pixel" in distance is now a difference of 1/255, instead of a difference of 1.

So, if you want a soft edge that is 6 pixels wide, you would use:
float onePixelDistance = 1.0/255.0;//value determined by distance field generation tool
float SOFT_EDGE_MIN = 0.5 - onePixelDistance * 3.0;
float SOFT_EDGE_MAX = 0.5 + onePixelDistance * 3.0;


Looking at your "smoothstep(0.48, 0.52, alpha)" example, that's a distance of "0.02" either side of the centre, or in our byte representation, it's "5.1" either side of the centre.
Now, "0.02" and "5.1" have no meaningful units at this point without knowing how your tool converts distances into the byte representation.
If we assume it's doing it the same as my example above (1 unit = 1 pixel distance in the original map), then you edge blur should be 10.2 pixels wide relative to the original texture.

[font="Courier New"]
txDiffuse.Sample() takes normalised texture coordinates as inputs. Seeing you add GLOW_UV_OFFSET to the parameter passed into this function, then it follows that GLOW_UV_OFFSET should also be specified in normalised texture coordinates. This isn't specified in the Valve paper, it's just background shader programming knowledge.
Thanks for the help, it looks like that about clears it up for me. By any chance do you happen to remember where you figured out your method for generating distance maps? Mine was just put together from random places that I read.

This topic is closed to new replies.

Advertisement