Alpha Textures
- Thread starter Mike89
- Start date
BenSkywalker
Regular
Yes.
Alpha texture are textures that have sections that you can see through(in the context of what you are asking). The railings in CounterStrike are a good example. They are used as they are much less intensive then building the images they represent with actual polygons. The reason MSAA doesn't apply AA to them is it compares Z values of objects to search for edges of objects and then applies AA to those areas. With alpha textures, there is no edge present inside the texture so no AA is applied. Trees are another object that tends to use alpha textures in most games, building all of the branches and leaves would be pretty intensive on a system so alpha textures are used to simulate it instead.
horvendile
Regular
Speaking of questions that have probably been asked before, and almost on-topic:
Anyone care to explain what an alpha test is?
I seemingly remember that term being involved in alpha textures and AA discussions.
Anyone care to explain what an alpha test is?
I seemingly remember that term being involved in alpha textures and AA discussions.
Yes, it's the Alpha test and not Alpha textures (= textures consisting of an alpha channel, such as GL_ALPHA8, or sometimes refers to textures that contains an alpha channels, such as GL_RGBA8) Gah! I hate hearing these concepts being mixed over and over and over ...
Using an alpha texture does not cause any problems whatsoever with multisampling. There are zillions of applications of alpha textures that will work just fine with multisampling. Using alpha test however doesn't. Why? Because alpha values aren't known before the termination of the fragment shader. This means all samples would have to be evaluated (basically => supersampling) to be able to antialias it. Depth and stencil values on the other hand after known before executing (unless you're using depth replace), so such edges are known and the approriate amount of samples can be taken whenever a pixel falls on an edge.
Supersampling antialiases the alpha test just fine just because it always evaluates all sample positions.
Using an alpha texture does not cause any problems whatsoever with multisampling. There are zillions of applications of alpha textures that will work just fine with multisampling. Using alpha test however doesn't. Why? Because alpha values aren't known before the termination of the fragment shader. This means all samples would have to be evaluated (basically => supersampling) to be able to antialias it. Depth and stencil values on the other hand after known before executing (unless you're using depth replace), so such edges are known and the approriate amount of samples can be taken whenever a pixel falls on an edge.
Supersampling antialiases the alpha test just fine just because it always evaluates all sample positions.
From the "user experience" point of view there are three types of surfaces:
1. Opaque surfaces
In these type of surfaces all pixels are opaque
2. Surfaces with holes in them (punched surfaces)
In these type of surfaces same pixels are opaque, some are fully transparent.
3. Transparent surfaces.
In these type of surfaces same pixels are opaque, some are fully transparent, and some are semi-transparent.
Opaque surfaces are trivial, lets see the other two:
2. Surfaces with holes in them (punched surfaces)
There are (or used to be) two ways of achieving this:
a.) Using a texture with color-key.
Some color (typically black or purple) is determined to mean transparent, other pixels are opaque.
This is the old method and it is the still the most usual way to do it in 2D.
It is no longer supported in 3D however, because it didn't work well with bilinear filtering.
b.) Using a texture with an alpha channel and using alpha-test
In every rendered pixel the alpha value (0..1 range) got from the texture is tested with a reference value (usually 0.5), and it it's larger the pixel is opaque, it's less it is transparent.
The alpha value is the filtered value from the texture so it works with all kind of texture filtering (bilinear, trilinear, anisotropic)
3. Transparent surfaces.
There is basicly one way to do it,
using a texture with an alpha channel and using alpha-blend
In every rendered pixel the alpha value (0..1 range) got from the texture is used to blend with the pixel already in the same location in the render target.
0 means fully-transparent, 1 means opaque, anything between is semi-transparent.
---
As you can see saying "alpha-texture" doesn't tell the full story as "alpha-textures" are both involved with 2/a (alpha-test) and 3 (alpha-blend).
1. Opaque surfaces
In these type of surfaces all pixels are opaque
2. Surfaces with holes in them (punched surfaces)
In these type of surfaces same pixels are opaque, some are fully transparent.
3. Transparent surfaces.
In these type of surfaces same pixels are opaque, some are fully transparent, and some are semi-transparent.
Opaque surfaces are trivial, lets see the other two:
2. Surfaces with holes in them (punched surfaces)
There are (or used to be) two ways of achieving this:
a.) Using a texture with color-key.
Some color (typically black or purple) is determined to mean transparent, other pixels are opaque.
This is the old method and it is the still the most usual way to do it in 2D.
It is no longer supported in 3D however, because it didn't work well with bilinear filtering.
b.) Using a texture with an alpha channel and using alpha-test
In every rendered pixel the alpha value (0..1 range) got from the texture is tested with a reference value (usually 0.5), and it it's larger the pixel is opaque, it's less it is transparent.
The alpha value is the filtered value from the texture so it works with all kind of texture filtering (bilinear, trilinear, anisotropic)
3. Transparent surfaces.
There is basicly one way to do it,
using a texture with an alpha channel and using alpha-blend
In every rendered pixel the alpha value (0..1 range) got from the texture is used to blend with the pixel already in the same location in the render target.
0 means fully-transparent, 1 means opaque, anything between is semi-transparent.
---
As you can see saying "alpha-texture" doesn't tell the full story as "alpha-textures" are both involved with 2/a (alpha-test) and 3 (alpha-blend).
madshi said:
Multisampling calculates color + alpha once per pixel. Because there is only one alpha value, alpha test affects either all subsamples or none. So no antialiasing can happen on "texture-edges".
Supersampling calculates color + alpha per subsample, that means the alpha test can determine that some subsamples are visible (above alpha test threshold) while others aren't. That results in smooth edges.
MSAA "works" only on polygon (and polygon intersection) edges, in all three cases. However, in case 1 there are no other edges, and in case 3 the edges are already smooth because of texture filtering. Case 2 leaves aliased edges.
Hmmmm... So the edges are not smoothed by MSAA, but only because of the alpha channel? I'm not sure if I have understood that correctly. If you have an alpha channel like:Xmas said:
0 0 0 0 0.2 0.4 0.6 0.8 1.0 1.0 1.0
This might be smooth and show no edges - but who is the smoother here? Is it only smooth because the alpha channel goes smoothly from 0 to 1? Or does MSAA effect the edges here? And if you have an alpha channel like this:
0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1
Will this behave identical to the (2) alpha test situation?
Thank you!
No, because you have texture filtering. If you're sampling the texture at some point between the 0 and the 1, you get an alpha value between 0 and 1.madshi said:
With alpha test, you only have "visible" or "not visible", nothing in between. Either the alpha value passes the comparison with the threshold value (you can select different comparison modes: >, >=, =, !=, <, <= ), or it does not.
With alpha blending and texture filtering, you get results like "50% visible" when you sample the texture halfway between 0 and 1. Alpha blending will give you almost "perfect" smooth edges.
Very difficult. Alpha Blending requires that all triangles are depth sorted, while Alpha Testing does not. Forcing Alpha Blending can cause visual artifacts around the edges of objects. In some cases it might work and look acceptable, but be sure that it will likely fail in as many that it works.
Not too difficult in many cases I imagine, but I guess it's hard to find a developer willing to modify an old game. Most newer games use alpha blending in those cases.madshi said:Ah, thanks!
How difficult would it be to patch existing games to use alpha blending instead of alpha testing? This would at once give us smooth trees etc in all games on both R300 and GeForce3+, right?
There are three drawbacks with using alpha blending instead of (or on top of) alpha test. One is speed. Alpha blending is quite slow because it requires a read-modify-write operation on framebuffer content.
Also, you need high-res alpha textures to prevent blurring when getting close to such objects.
And, most important, you need to depth-sort all alpha-blended polygons and render them last in a scene to prevent rendering errors. In some cases, like trees formed of two polygons intersecting like an X, the only way to prevent rendering errors would be to split polygons to allow proper sorting.
madshi said:
Bad wording on my part I guess. It's not restricted to fragment shaders. What I meant to say is that alpha testing occurs in the end of the fragment pipeline. That is, first when a pixel has passed the fragment processing, such as a fragment shader or the old fixed function pipeline, the alpha value is known and the fragment can be either be discarded or be written into the framebuffer. Because the alpha value is known first after it has passed through all the fragment processing it's just not possible to detect these edges.
