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

[Robmonster]

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

You know, a developer codes ther gfx engine to use a particular graphics feature, which looks fine. However, the way they have coded means that they utilising a bug in the driver that just happens to display correctly.

A little later the gfx driver people squash this bug, and now suddenly the game looks odd as it is no longer displaying correctly.

Something similar happened at a company i worked for whereby cosde that ran just fine before failed to compile on later versions as they had tightened up the compiler in a later version. We had to code it 'properly' to get the programs compiled.

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:Trade-offs

[junkgrep]

But most game review sites say that ATI's AA looks better at lower levels than NVIDA cards do at higher levels. So whachoo talking about Willis?

Re:Trade-offs

[PainKilleR-CE]

Like I said, there're a number of ways you could look at it. In what way does ATI's AA look better? It's something that you can't easily measure, because it could look better simply because the algorithms are faster, or because the algorithms do less (or because the edge cases, as in the centroid algorithm's case, are harder to see flaws with).

nVidia's newest cards also do FSAA in a significantly different manner from their previous cards (ie FX cards vs. non-FX cards), utilizing buffers from other operations to perform the AA instead of rebuilding their buffers (whether or not ATI does this I don't know). For higher level AA (6x and 8x) they actually use the 2x and 4x AA methods on portions of the screen and then combine the results in the buffer, which may also lead to ATI's results looking better.

Of course, to me FSAA never looks better than rendering at a higher resolution, because none of the current cards do FSAA by simply rendering at the higher resolution and then scaling down to the displayed resolution (which would give better image quality, but causes bigger performance hits).

In the end, if one card (nVidia) shows artifacts on the polygon edges because they don't use centroid algorithms in their AA and another card (ATI) does use the centroid algorithms, many people will say that the card that uses centroid 'looks' better, especially in a game that causes a lot of problems in those edge cases. It doesn't mean that those edge cases are more accurate in terms of antialiasing algorithms, simply that the eye doesn't catch them as easily.

Re:Trade-offs

[Anonymous Coward]

That's just because AA wasn't the focus on the early 5x00 models. When nVidia started designing the NV30 most people didn't turn the AA or the Aniso up high because gamers didn't want to sacrifice even a few frames. nVidia made their big bet on beating DX9 requirements in several areas, particular shader code length. It turned out people didn't want lengthy shader code yet, ATi found a way to keep cycling new instructions into a small code buffer anyway, and that an awful lot of people are hooked on ATis excellent anti-aliasing now, especially for flat-panel monitors. You live, you learn, you come back for the next round. The 5900s AA and Aniso is essentially fixed, but the momentum's gone for now.

Centroid workaround

[Sesse]

Now, would somebody please explain what this "centroid" workaround is all about? Ie. technically, what does it do? :-)

/* Steinar */

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.

Parhelia 16X

[Kamalot]

How will Half-Life run on cards like the Matrox Parhelia and its 16x anti-aliasing? I believe it is a Direct X 8 card.

Re:Parhelia 16X

[Tragedy4u]

Does that card still even exist? With it's poor performance ratings I thought it was DOA....to bad for Matrox they used to own the 2D video card market many years ago.

How does this happen?

[Tom7]

Based on my understanding of 3D rendering, I don't see how this can happen.

I thought that FSAA worked by one of two methods:

- Render the entire screen at a higher resolution (double width and height, for instance), and then downsample it to the screen resolution

- Render the same scene at screen resolution several times from slightly (sub-pixel) different locations, then mix the images together

Either way, I don't see how texture coordinates would be disturbed such that parts of other textures show through at boundaries. Can someone with an understanding of modern graphics hardware clue me in?

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:How does this happen?

[Tom7]

Well, I think the idea is that (a) you'd be able to do that on the card, so you wouldn't need to move it to main memory, and (b), you do not need to literally render the whole screen and then shrink it; you can just do 2x2 pixel or 4x4 pixel blocks and then combine those to get each pixel. The intermediate data does not need to stick around.

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

How is AA on the textures different from bilinear sampling? Or, how does anti-aliasing the edges cause textures to leak through?

Selective antialiasing?

[AltaMannen]

Can't the antialiasing simply be switched off when rendering the translucent polygons and kept for opaque? Worked fine on N64 but that didn't have hardware multipass rendering and such so maybe it's not that simple..

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

Did you read the first line?

[Baikala]

"With current multi-sample implementations of anti-aliasing, you may sample texels outside of the polygon boundary ..."

This is the key, but you have to understand what a centroid is in the first place. A centroid is a the geometric place the triangle (In 3d graphics "polygon" means "triangle in space") defined by the intersection of the lines that go from every corner to the midpoint of the oposite edge. One of its properties (the most relevant for this particular application) is that is allways inside the triangle. It's a litte harder to calculate it than the gravicenter (intersection of any two heights) but is always inside so if you sample a texsel on that point you get the rigth light map for that triangle.

Re:Did you read the first line?

[Tom7]

"With current multi-sample implementations of anti-aliasing, you may sample texels outside of the polygon boundary ..."

I understand what they say is happening, but I don't understand *why* an implementation of anti-aliasing would sample outside the polygon boundaries. What does the implementation do that causes this?

Programming: OS vs. Application Programmers

[Synic]

This is the same problem that systems programmers have been grappling with for ages-- how much optimization does the system provide in libraries or drivers, and how much does the application developer have to bring to the table. However, in this case, the graphics drivers have to be optimized a heck of a lot in order for people to eek out those last 5-10 frames per second to beat the competitor's product on benchmarks. So then you have hacks happening not only on the side of the drivers/system and hardware itself, but also the game developers who have always used incredible hacks to get around hardware limitations. The intersection of these two worlds gets really ugly when one side doesn't understand what is going on in the other side. :(