State of the Graphics Industry Rant

[Bjorn]

Atleast your disagreement is on a clearer track now, I think, though the justification for it seems to be missing right now. Just to be clear, this is not a dispute as to what you consider for your own preference, but a dispute about what can be used to objectively state that the Radeon (<9500) method of anisotropic filtering is "incorrect".

Actually, the discussion (at the start of the thread) was about if the R8500 aniso was flawed or not.
And imo, it clearly is.

It's clearly incorrect at 45 degree angles (imo of course but i actually think that you agree with me here) since it doesn't do any aniso filtering at all then.

Broken is a word i would use for something that doesn't work at all so i'm with the people that doesn't want to use that specific word.
But flawed yes. And then it's of course up to the users to decide if they can live with that or not. Just the same as with MSAA and alpha textures.

 

[Joe DeFuria]

demalion is responding pretty much as I would. Thanks demalion.

And yes, Bjorn, you did originally mis-read what I said.

Thins might help with Bjorn's "hangup" about "one implementation specific to a single piece of hardware."

I would wager that GeForce's multisample AA is a unique implementation of multisample AA. It's certainly different than ATI's multisample AA in the Radeon 9700.

I chose "Radeon 8500" aniso as the descriptor out of conveniece. Yes, because it is the only implementation I'm aware of that exhibits that artifact. But the fact that it's the only implementation, doesn't have anything to do with my stance.

And i'd then disagree with him since i don't consider MSAA , Supersample and FAA to be nearly as "hardcoded" as one specific vendors implementation of anisotropic filtering.

Certainly, I would consider FAA more "hardcoded" as you put it. (I presume you mean "more inflexible"?)

 

[Bjorn]

Certainly, I would consider FAA more "hardcoded" as you put it. (I presume you mean "more inflexible"?)

Not more inflexible. More like less connected to a specific vendor (MSAA, Supersampling).

 

[Joe DeFuria]

Actually, the discussion (at the start of the thread) was about if the R8500 aniso was flawed or not.
And imo, it clearly is.

Well, we're back to sqare 1. No one would argue about the "quality drawbacks" of R8500 method. You can consider that a "quality flaw", I don't think anyone would disagree.

However, the discussion turned into a comparison of comparing one flaw (quality) vs. another (performance). Advantages and disadvantages. And some people have essentially argued that if they had their way, Radeon 8500 aniso would not exist, because it is not "correct."

They have argued that before any "performance optimizations" can be tweaked, it must first "comform to correctness". (And at that point, the debate about correctness ensued.)

Broken is a word i would use for something that doesn't work at all so i'm with the people that doesn't want to use that specific word.

Actually, I don't think "broken" ever really came into it. It was more of a question of "corectness".

But flawed yes. And then it's of course up to the users to decide if they can live with that or not. Just the same as with MSAA and alpha textures.

Of course, it all depends on your definition of "flawed". I don't really care what your definition is, as long as it's applied consistently.

So, if you consider R 8500 aniso "flawed", then I would argue that you must also consider MSAA as "flawed" as well (as you appear to do in the above quote.) If that's true, then we basically agree.

 

[Joe DeFuria]

Not more inflexible. More like less connected to a specific vendor (MSAA, Supersampling).

Well, what about 3dfx's AA implementataion? Clearly, that appears to have been unique to a specific vendor. I'm not seeing how something connected to a specific vendor should have any bearing on whether it's "correct" or "flawed" or not. One needs to look at the results, in any case.

Edit: And also, if your definition of "hardcoded" is "connected to a specific vendor", then clearly Matrox's FAA falls into that category.

 

[demalion]

Atleast your disagreement is on a clearer track now, I think, though the justification for it seems to be missing right now. Just to be clear, this is not a dispute as to what you consider for your own preference, but a dispute about what can be used to objectively state that the Radeon (<9500) method of anisotropic filtering is "incorrect".

Actually, the discussion (at the start of the thread) was about if the R8500 aniso was flawed or not.

No the discussion was about an article/"rant", then it evolved into whether 8500 aniso was flawed, then it was further stated by some that it was broken(I'm pretty sure the word was used)/incorrect anisotropic filtering, and then maintained that this qualification of "broken" was an objective criteria. Since the way I replied, and the way I read Joe replying, was dealing with this last particular aspect, when you replied the way you did I thought you were aware of the distinction. I think your dispute is with one sentence of Doom's, and I'm not even sure if he'd maintain it in the context presented here (go ask him ), as I read it as meaning "unsatisfactory" where "flawed" is stated (ah, the slippery slope of English ).

And imo, it clearly is.

It's clearly incorrect at 45 degree angles (imo of course but i actually think that you agree with me here) since it doesn't do any aniso filtering at all then.

Notice the key word opinion, and re-read the long discussions with darkblu about what was being disputed (where your view was proposed as a standard without substantion).

Broken is a word i would use for something that doesn't work at all so i'm with the people that doesn't want to use that specific word.
But flawed yes. And then it's of course up to the users to decide if they can live with that or not. Just the same as with MSAA and alpha textures.

Anything is "flawed" that can be done better. It can be said that the "GF 3/4 method was flawed in terms of speed", and "the 8500 was flawed for image quality in some instances." That is why the terminology of "tradeoffs" was used.

 

[darkblu]

demalion,

allow me to try clearing out a few things for you, as you seem to encounter some difficulties reading api specs.

first, the right order to read those quoted ogl excerpts is as follows:

From the Overview for that extension, copyright 1999 nVidia by the way:

Several approaches exist for improving texture sampling by accounting
for the anisotropic nature of the pixel filter footprint into texture
space. This extension provides a general mechanism for supporting
anisotropic texturing filtering schemes without specifying a
particular formulation of anisotropic filtering.

The extension permits the OpenGL application to specify on
a per-texture object basis the maximum degree of anisotropy to
account for in texture filtering.

[ed: from the Specs Addition section]

It is also acceptable for an implementation to approximate the ideal
functions Px and Py with functions Fx and Fy subject to the following
conditions:

1. Fx is continuous and monotonically increasing in |du/dx| and |dv/dx|.
Fy is continuous and monotonically increasing in |du/dy| and |dv/dy|.

2. max(|du/dx|,|dv/dx|} <= Fx <= |du/dx| + |dv/dx|.
max(|du/dy|,|dv/dy|} <= Fy <= |du/dy| + |dv/dy|.

<snip>

[ed: from the corresponding Issues section]

Should an implementation-defined limit for the maximum maximum degree of
anisotropy be "get-able"?

RESOLUTION: YES. But you should not assume that a high maximum
maximum degree of anisotropy implies anything about texture
filtering performance or quality.

the clause for non-assumption of the texture filtering quality in the above Issues section refers to the given maximal high (this meaning greater than 1) degree of anisotropy as returned per-implementation-of-degree, not per pixel! why? - because the above Issues section should be interpreted in the context of the preceeding Overview and Specs Addition sections. and this is very important! because the Issues section should not be interpreted by itself, nor can it (directly) oppose the Overview section, nor the Specs Addition section.

IOW, what the above Issues section says is:

a given implementation reports the maximal high degree of anisotropy, but said maximal degree 'does not guarantee a certain filtering quality', which is different than 'said maximal degree does not guarantee a constant degree of anisotropy' for the encountered anisotropy level. in fact, the Specs Addition section implies exactly such a constant degree of anisotropy for a rolled plane by the rule that max(|du/dx|,|dv/dx|) <= Fx <= |du/dx| + |dv/dx|. max(|du/dy|,|dv/dy|) <= Fy <= |du/dy| + |dv/dy|. once again, i repeat, the Issues section cannot directly oppose the Overview or the Specs Addition section.

see, demalion, you've been trying to suggest exactly the latter, which would make the whole extension specification completely meaningless.

and while we're at api excerpts, here's directX account on the matter:

Anisotropic Texture Filtering
Anisotropy is the distortion visible in the texels of a 3-D object whose surface is oriented at an angle with respect to the plane of the screen. When a pixel from an anisotropic primitive is mapped to texels, its shape is distorted. Microsoft® Direct3D® measures the anisotropy of a pixel as the elongation (that is, length divided by width) of a screen pixel that is inverse-mapped into texture space.

You can use anisotropic texture filtering in conjunction with linear texture filtering or mipmap texture filtering to improve rendering results. Your application enables anisotropic texture filtering by calling the IDirect3DDevice8::SetTextureStageState method. Set the value of the first parameter to the integer index number (0-7) of the texture for which you are selecting a texture filtering method. Pass D3DTEXTUREMAGFILTER, D3DTEXTUREMINFILTER, or D3DTEXTUREMIPFILTER for the second parameter to set the magnification, minification, or mipmapping filter. Set the third parameter to D3DTEXF_ANISOTROPIC.

Your application must also set the degree of anisotropy to a value greater than one. Do this by calling the IDirect3DDevice8::SetTextureStageState method. Set the value of the first parameter to the integer index number (0-7) of the texture for which you are setting the degree of isotropy. Pass D3DTSS_MAXANISOTROPY as the value of the second parameter. The final parameter should be the degree of isotropy.

You can disable [ed: a couple of doc typos here] anisotropic filtering by setting the degree of anisotropy to one; any value larger than one enables it. Check the MaxAnisotropy flag in the D3DCAPS8 structure to determine the possible range of values for the degree of anisotropy.

ps to Russ:

API specs are usually not as blatantly self-contradictory as some people occasionally attempt to read them into. do not be fooled into thinking of us software guys as that big idiots

edit: the pixel anisotropy approximation rule is from the Specs Addition section (particularly from the txture min-/magnification), not from the Overview. i overlooked it - my bad.

 

[demalion]

demalion,

allow me to try clearing out a few things for you, as you seem to encounter some difficulties reading api specs.

My, that is a mighty condescending tone for a presentation that you went on to edit indicating that your own ability to make a mistake. Let me include that edit comment here so people know what I'm talking about for my discussion:

edit: the pixel anisotropy approximation rule is from the Specs Addition section (particularly from the txture min-/magnification), not from the overview. i overlooked it - my bad.

first, the right order to read those quoted ogl excerpts is as follows:

Why is my order "not right" and yours is? Nice groundless statement that doesn't seem to illustrate much except indirectly attack me.

From the Overview for that extension, copyright 1999 nVidia by the way:

Several approaches exist for improving texture sampling by accounting
for the anisotropic nature of the pixel filter footprint into texture
space. This extension provides a general mechanism for supporting
anisotropic texturing filtering schemes without specifying a
particular formulation of anisotropic filtering.

The extension permits the OpenGL application to specify on
a per-texture object basis the maximum degree of anisotropy to
account for in texture filtering.

<snip>

It is also acceptable for an implementation to approximate the ideal
functions Px and Py with functions Fx and Fy subject to the following
conditions:

1. Fx is continuous and monotonically increasing in |du/dx| and |dv/dx|.
Fy is continuous and monotonically increasing in |du/dy| and |dv/dy|.

2. max(|du/dx|,|dv/dx|} <= Fx <= |du/dx| + |dv/dx|.
max(|du/dy|,|dv/dy|} <= Fy <= |du/dy| + |dv/dy|.

<snip>

[ed: from the corresponding Issues section]

Should an implementation-defined limit for the maximum maximum degree of
anisotropy be "get-able"?

RESOLUTION: YES. But you should not assume that a high maximum
maximum degree of anisotropy implies anything about texture
filtering performance or quality.

the clause for non-assumption of the texture filtering quality in the above Issues section refers to the given maximal high (this meaning greater than 1) degree of anisotropy as returned per-implementation, not per pixel! why? - because the above Issues section should be interpreted in the context of the preceeding Overview section. and this is very important! because the Issues section should not be interpreted by itself, nor can it (directly) oppose the Overview section.

Well, I didn't include it by itself, I included it with an excerpt from the Overview section (among other things). Your text reads like I didn't (IOW it reads as if you are lying). It then proceeds to imply that some aspect of my presentation is invalid without specifying support for that implication. Your conclusion is that "and this is very important! because the Issues section should not be interpreted by itself, nor can it (directly) oppose the Overview section." yet you fail to illustrate how this accusation fits my text, and ignore the context I provide for how all these sections relate.

IOW, what the above Issues section says is:

a given implementation reports the maximal high degree of anisotropy, but said maximal degree 'does not guarantee a certain filtering quality', which is different than 'said maximal degree does not guarantee a constant degree of anisotropy' for the encountered anisotropy level.

It is? How so? The actual text again is:

Should an implementation-defined limit for the maximum maximum degree of
anisotropy be "get-able"?

RESOLUTION: YES. But you should not assume that a high maximum
maximum degree of anisotropy implies anything about texture
filtering performance or quality.

A clear reading of the text allows both readings, if you disagree provide substantion please. You provide a new set of wording and fail to illustrate how the text does not make that statement, seeming to depend on the fact that it isn't the same wording to be proof that it doesn't fit the statement. All you've said so far is my substantion is incorrect, ignored most of said substantion, and provided an alternate and selective inclusion of text to favor a new interpretation without any justification is to how this selective text is somehow more "valid". Pretty consistent with your arguments so far. The catching an error and leaving it in as an integral part of your argument is new though.

in fact, the Overview section implies exactly such a constant degree of anisotropy for a rolled plane

And how does it do this?

by the rule that max(|du/dx|,|dv/dx|) <= Fx <= |du/dx| + |dv/dx|. max(|du/dy|,|dv/dy|) <= Fy <= |du/dy| + |dv/dy|.

That's in the Overview? Let me look again...no, it is not. You recognized your premise was invalid at the end, and still present an argument based on your error. That's OK, I'll address the Additions section you brought up anyways in a bit.

once again, i repeat, the Issues section cannot directly oppose the Overview section.

This is a completely non-sensical statement, since I never implied that it did, but you caught that at the end with an edit. Yet look how you began this response with a condescending remark...

Anyways, on to the Additions section.

see, demalion, you've been trying to suggest exactly the latter, which would make the whole extenstion specification completely meaningless.

You are basing this on a flawed presentation, but I'll quote something from the Additions section:

When the texture's value of TEXTURE_MAX_ANISOTROPY_EXT is equal to 1.0, the GL uses an isotropic texture filtering approach as described in this section and Section 3.8.6. However, when the texture's value of TEXTURE_MAX_ANISOTROPY_EXT is greater than 1.0, the GL implementation should use a texture filtering scheme that accounts for a degree of anisotropy up to the smaller of the texture's value of TEXTURE_MAX_ANISTROPY_EXT or the implementation-defined value of MAX_TEXTURE_MAX_ANISTROPY_EXT.

The particular scheme for anisotropic texture filtering is implementation dependent. Additionally, implementations are free to consider the current texture minification and magnification modes to control the specifics of the anisotropic filtering scheme used.

None of which contradicts the Overview or Issues, and you seem to have selectively read.

and while we're at api excerpts, here's directX account on the matter:

More text I have to go through to find the text you selectively ignored? OK, atleast I am learning some things.

Anisotropic Texture Filtering
Anisotropy is the distortion visible in the texels of a 3-D object whose surface is oriented at an angle with respect to the plane of the screen. When a pixel from an anisotropic primitive is mapped to texels, its shape is distorted. Microsoft® Direct3D® measures the anisotropy of a pixel as the elongation—that is, length divided by width—of a screen pixel that is inverse-mapped into texture space.

You can use anisotropic texture filtering in conjunction with linear texture filtering or mipmap texture filtering to improve rendering results. Your application enables anisotropic texture filtering by calling the IDirect3DDevice8::SetTextureStageState method. Set the value of the first parameter to the integer index number (0-7) of the texture for which you are selecting a texture filtering method. Pass D3DTEXTUREMAGFILTER, D3DTEXTUREMINFILTER, or D3DTEXTUREMIPFILTER for the second parameter to set the magnification, minification, or mipmapping filter. Set the third parameter to D3DTEXF_ANISOTROPIC.

Your application must also set the degree of anisotropy to a value greater than one. Do this by calling the IDirect3DDevice8::SetTextureStageState method. Set the value of the first parameter to the integer index number (0-7) of the texture for which you are setting the degree of isotropy. Pass D3DTSS_MAXANISOTROPY as the value of the second parameter. The final parameter should be the degree of isotropy.

You can disable [ed: a couple of doc typos here] anisotropic filtering by setting the degree of anisotropy to one; any value larger than one enables it. Check the MaxAnisotropy flag in the D3DCAPS8 structure to determine the possible range of values for the degree of anisotropy.

Hmm...well, when I said before that your examples didn't include any specification of the expectations you filled in, and you never addressed it, I suppose it is not surprising that you did it again. OK, this supports your assertion about how the 8500's aniso is invalid how? I'm looking for mentions of things like the 45 degree case, whereas all your bolded text are things the the 8500 aniso does do. I'll also quote your last quoted sentence: "Check the MaxAnisotropy flag in the D3DCAPS8 structure to determine the possible range of values for the degree of anisotropy." But, whatever, I don't expect to get any further with this much text for you to throw in front of the issue.

ps to Russ:

API specs are usually not as blatantly self-contradictory as some people occasionally attempt to read them into. do not be fooled into thinking of us software guys as that big idiots

"Some people"? Sounds even sillier when it was your misinterpretation that made it seem contradictory.

edit: the pixel anisotropy approximation rule is from the Specs Addition section (particularly from the txture min-/magnification), not from the overview. i overlooked it - my bad.

That's fine, but it makes the tone of condescension and flaw it introduces into your argument more than slightly aggravating.

 

[Bjorn]

Well, what about 3dfx's AA implementataion? Clearly, that appears to have been unique to a specific vendor.

It sure was, but the only difference between their implementation and Nvidias was in quality. Both AA'ed the entire scene 45 degree angle or not.

I'm not seeing how something connected to a specific vendor should have any bearing on whether it's "correct" or "flawed" or not. One needs to look at the results, in any case.

Correct. And again, we're back to square one.
Because aren't we looking at the result here ?
45 degree angle = no aniso = problem.

It's just the matter of what you define as a quality problem. That is, when is it so bad that you can start to talk about incorrectnes.
And something that under some circumstances completely fail to work, well that's definitely incorrect/flawed imo.

 

[Joe DeFuria]

It sure was, but the only difference between their implementation and Nvidias was in quality. Both AA'ed the entire scene 45 degree angle or not.

No.

We're talking about two AA implementations, bone of which does NOT AA the entire scene. Look at Voodoo5s implementation of "antialiasing" vs. GeForce 4's. The only difference is NOT quality. GeForce4's AA does not do anything for textures.

45 degree angle = no aniso = problem.

Alpha Textures = no AA on GeForce4 = problem.

Again, I am looking for consistency here in your arguments. One would think you would have to either have the opinion that you agree with both of the following statements, or disagree with both of them:

1) 45 degree angle = no aniso on Radeon = problem = "incorrect aniso implementation"
2) Alpha textures = no antialiasing on GeForce4 = problem = "incorrect AA implementation."

If in your opinion number 1 is a correct statement, but number 2 is incorrect, then you are being inconsistent with how you are applying your criteria for defining something as "incorrect."

So either revise your definition of what constitutes "incorrect", or revise your opinion.

 

[Galilee]

would that be the same alphatextures that R300 don't AA?

 

[Xmas]

would that be the same alphatextures that R300 don't AA?

Yes. Does it matter in this discussion?


I agree with Joe here. But I'd neither label "R200 aniso" nor multisampling being incorrect. I only think that the drop from "NV aniso" to "R200 aniso" is worse than the drop from supersampling to multisampling.

btw, Joe, Bjorn was talking about Supersampling on GeForce Cards back then.

 

[Joe DeFuria]

would that be the same alphatextures that R300 don't AA?

Yes, exactly. Your point?

Just as Xmas is saying: I don't see multisampling (GeForce4 or R300) as being incorrect. Similarly, I do not see R200 aniso as being incorrect.

 

[Fred]

Very silly thread.

Supersampling is also 'incorrect'. Weighted area sampling, is, in the limit the only mathematically valid solution that sets aliasing ===> zero. (and im not even quite sure about that, b/c as screen pixels ---> infinity, there could be poles in the math)

See Foley and Van Dam.

The only way to talk about this without the nitpicking is to define some sort of error function that quantifies what you're talking about.

 

[Bjorn]

btw, Joe, Bjorn was talking about Supersampling on GeForce Cards back then.

Yep.

would that be the same alphatextures that R300 don't AA?

Yes, exactly. Your point?

Just as Xmas is saying: I don't see multisampling (GeForce4 or R300) as being incorrect. Similarly, I do not see R200 aniso as being incorrect.

The point is imo that the MSAA alpha texture thing i a well known issue with that implementation. Known before the first consumer level MSAA card was available afaik. And an issue that even new DX9 cards have. (Same card that took care of the aniso problem i might add)

Also a issue that is more and more a non issue as i see it.

Thus, (excuse me for repeating myself here) i don't want to say that MSAA and it's problem are at the same wavelength as the R8500 aniso problem since that's a issue with an implementation and not with the method itself.

 

[LeStoffer]

hmmm regarding the AF & AA-metodes: The simple matter of fact is that the lastest og greatest - the Radeon 9700 - makes the right decisions IMO:

1) The consumer can choose between a performance AF and a quality AF. For the consumer this implies the obvious: that performance mode cannot be top-quality (but might be suffient enough.

2) ATI is going MSAA - and thank God for that! We need performance before anything with AA right now and since ATI finally is going this route maybe game developers will get rid of those nasty alpha textures from hell (or make the hack to AA'ed them anyway). So patch the damn games, okay!

3) The R9700 sums up the best from the R8500 and the GF3/4: Fast MSAA and the choice between performance and quality AF.

All of this is obvious of course (!) so my point is that the R9700 sets the bar for the features that any future card should have. No more need to bitch about whether you prefer the performance hit from supersamling or quality AF, e.g. silly R8500 vs GF3/4 threads.

(Note that I'm not convienced about Parhelia's FAA just yet).

 

[Bjorn]

The problem with obvious stuff it that they take some of the fun out of the discussion

 

[demalion]

AFAIK the only thing lacking in Performance aniso is trilinear filtering. In other words, it makes both the flaws in the "8500 aniso" (image quality in a specific situation) and the "GF3/GF4 aniso" (poor performance such that usage to enhance image quality is limited in specific situations) seem unecessary and distorts the issue such that it lends itself to the fallacious argument that either is "broken" or "incorrect" by some objective criteria (though this has only been applied to the "8500 aniso" aspect by anyone).

That is why I've tried to have a discussion about objective critera...no one seems to address or recognize that there doesn't seem to be an objective criteria for anisotropic filtering "correctness" such that the "8500 aniso" is shown to be a "broken" or "incorrect" (objective) anisotropic filtering implementation and instead seem dedicated to proposing that it is "flawed" or "unsatisfactory" (subjective) for them as if that is the same thing. Why I'm frustrated personally is that the text that has been thrown at me has been proposed as demonstrating the first with so many holes and inconsistencies in that application that I feel I am wasting my time in pointing them out, and I feel that the reason there are so many holes and inconsistencies is because of a persistant assumption that their subjective evaluation is an objective standard despite what objective standards actually say.

It seems to have come down to an issue of doing anything but possibly admit a proposed stance is wrong in any way, or modifying a viewpoint based on discussion...it is only working on that premise that the last 4 or 5 (or is it more?) pages make any coherent sense to me.

 

[RussSchultz]

You're absolutely right--there's nothing new said in the past 10 pages that wasn't said before.

We obviously believe there is enough documentation and mathematical reasoning behind the concept of anisotropic filtering that you can do it correctly, or incorrectly(yes, objectively).

You obviously don't.

If it irritates you so much, just stop responding. You'll live longer.

 

[demalion]

You're absolutely right--there's nothing new said in the past 10 pages that wasn't said before.

We obviously believe there is enough documentation and mathematical reasoning behind the concept of anisotropic filtering that you can do it correctly, or incorrectly(yes, objectively).

Umm...so do I. I am merely stating that it doesn't disqualify the "8500 aniso" method.

It is disappointing that after I've addressed every example of "documentation and mathematical reasoning behind the concept of anisotropic filtering" that you, darkblu, and Chalnoth have thrown at me that instead of replying and discussing what I've addressed with logical support, you resort to this instead.

You obviously don't.

This is so obviously incorrect, intentionally obtuse, and blatantly deceptive that you've pretty thoroughly offended me. I don't expect an apology or any admission of how obviously incorrect this statement is, however...you've sort of forced me to expect less from you. You probably think that makes me happy, or that I gain some sort of self-importance from making the statement, don't you? To be clear, I'm no "better" than I was a week ago, so the world isn't a better place for it.

If it irritates you so much, just stop responding. You'll live longer.

Hmm...a false and distorted premise, and then using "it" in a statement of dismissal so that it is just disconnected enough from your patantly false premise that you can stand by it and repeat it in the future by itself. Atleast, that is the expectation that seems reasonable to me based on this example.