HL2 AA issue a thing of the past?

[SsP45]

During the Nvidia chat on IRC, NV_Derek posted this link, to Gabe Newell talking about the HL2 AA issue.

http://www.halflife2.net/forums/showthread.php?s=&threadid=3071

Since people seem to be hyperventilating over the anti-aliasing issue, I thought I'd update everyone.

1) How bad is the problem?

With current multi-sample implementations of anti-aliasing, you may sample texels outside of the polygon boundary, which may result in sampling light maps from other polygons.

This has always been a problem. This is a problem with Quake 1, Quake 2, Quake 3, Daikatana, Sin, Elite Force, Half-Life, Counter-Strike on the X-Box, or any game that uses packed lightmaps with multi-sample anti-aliasing.

You would see these artifacts on polygon boundaries where the wrong lightmap is being sampled. It will look like a bright or dark line on the edge of a polygon.

Gary McTaggart brought this up in an email because he is being pretty hardcore about graphics quality right now. This is not a new problem. If you've run a game that uses lightmaps with anti-aliasing turned on, then you've been seeing these artifacts the whole time.

Artifacts may show up more frequently in Half-Life 2 simply because we've eliminated lots of other artifacts, and because we have a lot of variation in scene lighting due to our art direction.

To put this in perspective, not doing tri-linear filtering on mipmaps is a lot worse.

2) What are potential solutions?

Support Centroid Sampling

Use Pixel Shaders to Clamp Texture Coordinates

Centroid sampling doesn't have the problem that center sampling does in multi-sample antil-aliasing. ATI has supported this form of anti-aliasing for the 9000 series. The tricky part is enabling this when DirectX doesn't easily expose this.

There's a different trick you can use with hardware, such as NVIDIA's, that doesn't support centroid sampling. Basically you trade off some pixel shader bandwidth to clamp the texture coordinates so that you don't sample texels outside of that polygon's lightmap sub-rect.

Between these two approaches, multi-sample anti-aliasing artifacts should be a non-issue for any DX9-level hardware running Pixel Shader 2.0.

3) How will this look?

We'll release one of the demo movies with the anti-aliasing artifacts in and one with the anti-aliasing changes.

________
Rl250

 

[Dave Baumann]

Interesting. It sounds like its still out fro GF4 though.

 

[OpenGL guy]

There's a different trick you can use with hardware, such as NVIDIA's, that doesn't support centroid sampling. Basically you trade off some pixel shader bandwidth to clamp the texture coordinates so that you don't sample texels outside of that polygon's lightmap sub-rect.

I'm curious as to what they have in mind. I was thinking you could use texkill, but I don't think it would work because you would get some weird aliasing artifacts on pixels that would normally be partially covered.

If your lightmaps are all rectangular, you could pass in plane equations, I suppose. Would the derivatives available in the pixel shader be enough to compute the proper direction so you can find the intersection point with the plane?

Other ideas?

 

[arjan de lumens]

If each lightmap forms an aligned rectangular portion of a texture map (the common case, it seems), you can do it more easily than that: just clamp the texture coordinates using a 2-instruction sequence - one MAX instruction and one MIN instruction, something as follows:

def c0, <left_coord>, <bottom_coord>, 0.0, 0.0
def c1, <right_coord>, <top_coord>, 0.0, 0.0
..
max r0, <texture_coordinates>, c0
min r0, r0, c1
<do texture lookups with r0 here>

The downside is, of course, that for every lightmap you wish to use from a packed texture, you need to redefine c0 and c1, causing large numbers of state changes (or else supply them per vertex instead of as shader constants).

EDIT: this clamping method won't completely prevent samping outside the lightmap rectangle if anisotropic mapping is enabled.

 

[incurable]

There's a different trick you can use with hardware, such as NVIDIA's, that doesn't support centroid sampling. Basically you trade off some pixel shader bandwidth to clamp the texture coordinates so that you don't sample texels outside of that polygon's lightmap sub-rect.

Between these two approaches, multi-sample anti-aliasing artifacts should be a non-issue for any DX9-level hardware running Pixel Shader 2.0.[/b]

Somehow, using additional PS2.0 ressources on NV3x-based hardware sounds like a rather interesting proposition.

cu

incurable

 

[horvendile]

If HL2 uses more and smaller polygons than the mentioned games - which should be a fair guess - couldn't it also be that the artifacts are noticed not only because other artifacts have been dealt with, but also because there are so many opportunities for edge artifacts to appear? I thought that extensive use of small polygons was sort of the main issue.

 

[Arun]

Interesting. It sounds like its still out fro GF4 though.

Yes, but the GF4 was competing agains the 8500, which also got the problem since centroid sampling is only supported in the "9000 series" ( what about 9000/9100/9200? Not supported I guess? )
So ATI doesn't really have an advantage there.


Uttar

 

[Dave Baumann]

Errr, Whether or not ATI has an 'advantage' is going to be little solace to GeForce3/4 owners that may want to try out AA in HL2.

 

[BoardBonobo]

Boils down to the same thing in the end. GF3\4 owners and R8500 owners will be stuffed for FSAA.

 

[vrecan]

am I the only one that see's a problem with adding even more pixel shader work on a card notorious for bad pixel shading in a pixel shading limited game?

 

[arjan de lumens]

R8500 shouldn't exhibit any artifacts under HL2 with AA enabled - remember that it only supports Supersampling, not Multisampling AA, so there is no need to do centroid sampling. Same applies for R9000/9100/9200. Performance may be low, though.

 

[Bouncing Zabaglione Bros.]

am I the only one that see's a problem with adding even more pixel shader work on a card notorious for bad pixel shading in a pixel shading limited game?

It's not unusual for Nvidia to offer a solution that technically works, but in real life is too slow to be used whilst actually playing games. The've been doing it for years. Every time they introduce a new feature, or a "solution" to compete with other companies, it's never fast enough to be usable for the first couple of iterations. They did it for 32 bit colour, large texture support, FSAA, etc.

 

[Hanners]

Interesting. It sounds like its still out fro GF4 though.

Yes, but the GF4 was competing agains the 8500, which also got the problem since centroid sampling is only supported in the "9000 series" ( what about 9000/9100/9200? Not supported I guess? )
So ATI doesn't really have an advantage there.

Surely the fact that the 8500 and derivatives use SSAA means that they won't have any such problems, or am I missing something?

Having said that, I'd 'pity the foo' that tries to use AA on Half-Life 2 with an 8500. :?

 

[Bambers]

R8500 shouldn't exhibit any artifacts under HL2 with AA enabled - remember that it only supports Supersampling, not Multisampling AA, so there is no need to do centroid sampling. Same applies for R9000/9100/9200. Performance may be low, though.

Depends, if HL2 doesn't use fog then 2x and 4x quality modes on the 8500 will have the same problem as the locations of the geometry samples don't match the texture ones in those modes.

 

[Arun]

Interesting. It sounds like its still out fro GF4 though.

Yes, but the GF4 was competing agains the 8500, which also got the problem since centroid sampling is only supported in the "9000 series" ( what about 9000/9100/9200? Not supported I guess? )
So ATI doesn't really have an advantage there.

Surely the fact that the 8500 and derivatives use SSAA means that they won't have any such problems, or am I missing something?

Having said that, I'd 'pity the foo' that tries to use AA on Half-Life 2 with an 8500. :?

Eh, that's a good point. Completely forgot about that one.
Although I'm sure that if the need is there, nVidia could enable OGSSAA in the same way they did for the GF1/2 in the GF3/4. The question is whether they'll accept to do it then...


Uttar

 

[THe_KELRaTH]

Maybe Nvidia will follow their route with AF - turn it off ingame

 

[WaltC]

Maybe Nvidia will follow their route with AF - turn it off ingame

What I found interesting in viewing the movies was that the lack of FSAA is very, very noticeable, both in terms of pixel shimmer and jaggies. I can run HL with MSAA enabled (9800P) and see very few, if any, of the artifacts Gabe's talking about. Apparently, he feels the aliasing is less objectionable. It'll be interesting to see the movies done with MSAA to judge the degree of this problem.

 

[andypski]

Just FYI.

If anyone wants to see some good examples of the kinds of artifacts that can be generated by texture sampling falling outside the covered subsamples then the game Max Payne shows them fairly clearly if you turn on AA. (If I recall correctly)

 

[OpenGL guy]

If anyone wants to see some good examples of the kinds of artifacts that can be generated by texture sampling falling outside the covered subsamples then the game Max Payne shows them fairly clearly if you turn on AA. (If I recall correctly)

Yes, on Max's hair.

 

[karlotta]

Thats because he does not use Centroid shampoo