Valve Defuses NVidia Half-Life 2 Issues

suineg writes "Gabe Newell, Valve's main man, has commented on Half-Life 2 and anti-aliasing problems with DX9 cards over at HalfLife2.net: '[The current problems] ...will look like a bright or dark line on the edge of a polygon. This is not a new problem. 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.'" As far as solutions go, Newell has some: "ATI has supported... [the centroid work-around] form of anti-aliasing for the 9000 series... [as for] NVIDIA's [hardware], that doesn't support centroid sampling... you trade off some pixel shader bandwidth to clamp the texture coordinates."

Comments

Trade-offs

[JonoPlop]

Artifacts may show up more frequently in Half-Life 2 simply because we've eliminated lots of other artifacts

What? Apart from not making much sense, is this implying that new artifacts are being traded for a lot of older ones? (i.e. get rid of lots of old ones, but by doing that, introduced some more in the process)

Re:Trade-offs

[samael]

Nope, it means that things that previously would have faded into the general 'unrealism' that pervades computer games stand out more and more when the other problems aren't there along with them.

Look at (for instance) Quake3. Point out a couple of problems with the graphics. Now look at Quake. The problems that FF has are almost certainly there too, but you won't notice them because other problems are far more glaring.

Re:Trade-offs

[Zardoz44]

It will look like a bright or dark line on the edge of a polygon.

This is all a guess, but if you make the graphics look sharper by removing some of the other problems, you might have more cases where these lines become more noticable. You take out the big glaring obvious artifacts and you can see these subtle problems more frequently. Makes sense.

Does "Can't see the forest for the trees" apply here?

Re:Trade-offs

[PainKilleR-CE]

I wonder if its a case of driver bugs being used as features.


It's actually just a combination of a few different things.

1) Most developers, if they absolutely must pack textures into larger textures, learn pretty quickly to put a border on their textures so that oversampling of any type will still pick up the right texture (or at least a similar texture), they even tell you to do this in some of the books aimed at teaching 3d game programming to new developers.

2) 'Centroid' antialiasing techniques is a shortcut to do antialiasing without the high overhead of 'true' antialiasing, but it looks so bad (because it averages the values) that it's normally only used on these edge cases (which tend to be problematic in many antialiasing algorithms), where people are unlikely to notice.

3) depending on how antialiasing algorithms are implemented by nVidia, the centroid algorithms may never be available. For instance, if the entire process is done in hardware, it's unlikely that they'd change the hardware unless they felt it would improve their algorithm. Even then, those with older hardware would still not gain the benefit.

For whatever reason, nVidia doesn't use centroid algorithms in their antialiasing, you could either look at this as a quality choice, or as just a simple matter of using a different set of algorithms. More than likely, not using this is part of the reason that nVidia's antialiasing has usually been slower than competitors' antialiasing (first 3dfx and now ATI). That being said, not using this may also result in more accurate antialiasing, even though the edge cases may have more obvious problems when developers don't compensate for it. Chances are that if nVidia utilized a centroid algorithm in a newer driver without specifying the games it should be used for or giving an option to enable/disable it, then those games that actually border their textures would look worse with the centroid algorithm when they previously had no problems.

Re:Centroid workaround

[PainKilleR-CE]

Centroid antialiasing takes the average of the sampled pixels and applies it to the entire sampled area (or, in most cases, just the edges of the area, as centroid antialiasing does not look good over a large surface, but can smooth out problem cases like the edges of polygons). This will make some situations look better, and some look worse (the example in the white paper I read mentions that as two objects move towards the camera the colour may 'snap' from one to the other, although it's still only in the edge cases that Valve is discussing).

Basically, it's an algorithm used to reduce the memory (and memory bandwidth) requirements of high-sample anti-aliasing techniques (for example 4x FSAA, which at say 1280x1024@32bpp would require ~160MB of RAM and/or slow rendering 16x). Algorithms that work for high accuracy without the slow-downs of full antialiasing will use centroid algorithms in combination with a number of other algorithmic shortcuts which, when combined, can produce nearly the same image, though with more artifacts and problem cases.

Re:How does this happen?

[Radius9]

They cheat on the FSAA. What they do is they don't actually sample the entire screen, they basically just run AA on the textures when they are rendered, then anti-alias the edges as they are rendered. Although technically what you said is true, if you think about it, its fairly unfeasable to say, render it at double resolution (say 3200x2400), then render that down into 1 1600x1200 screen. The memory requirements alone are massive. 1 24 bit 1600x1200 screen is 5.76 megs of video memory as it is, so one at 3200x2400x24 bits is roughly 24 megs. That is a lot of video memory to be using just for anti-aliasing, not to mention, can you imagine what kind of memory bandwidth you'd need to move that much data around every frame?

Re:Selective antialiasing?

[Merlin42]

Uhh ?!?!?! Who said anything about tranlucency?

This has to do with the interaction b/w the programmer doing things 'behind the back' of the driver (ie packing multiple logical textures into one texture as far as the driver/card is concerned) and the driver/card doing things 'behind the back' of the programmer (ie multisample antialiassing in such a way that texture cooordinates may fall slightly outside the range the programmer specified).