My R9700 experince and Aniso still "flawd"?

[KimB]

Before making that comment, I tested it on my GeForce4. My comment is still valid if only the GeForce4 is using the application settings.

 

[Randell]

Before thinking of running older games, remember the 9700 doesnt AA 16 bit titles unless 32 bit can be forced (like Half-Life)

 

[Mize]

Before thinking of running older games, remember the 9700 doesnt AA 16 bit titles unless 32 bit can be forced (like Half-Life)

Good point!
Maybe ATI should have a "force 32-bit" option in their drivers as the V5-5500 had?? (You listening OpenGL Guy?)

Mize

 

[OpenGL guy]

Maybe ATI should have a "force 32-bit" option in their drivers as the V5-5500 had?? (You listening OpenGL Guy?)

Huh, what? Did someone say something?

 

[OpenGL guy]

Does the Radeon9700 anisotropic filtering algorithm determine anisotropy per triangle/polygon?

I don't know, but I don't think it matters... the pixel shape is the same no matter if you look at a single pixel or the whole triangle.

Just wanted to clear this up as I realized I confused people (including myself) with my poor wording. Since du/dx, du/dy, dv/dx, dv/dy are computed per pixel, the level of anisotropy is computed per pixel.

If you didn't compute the derivatives per pixel, you'd have all sorts of issues.

 

[noko]

Just wanted to clear this up as I realized I confused people (including myself) with my poor wording. Since du/dx, du/dy, dv/dx, dv/dy are computed per pixel, the level of anisotropy is computed per pixel.

The per pixel anisotropy makes sense, but what determines the per pixel? Once again I see it fall within the polygon to define it. Anyways I am no expert in 3d so please break down the ratio's of du/dx, du/dy, dv/dx, dv/dy, which I do believe is the ratio of the source texture u,v positions to the screen pixel x,y positions. A simple drawing would be absolutely wonderful here . Thanks for your time OpenGL, remember I am learning as I go along.

 

[OpenGL guy]

The per pixel anisotropy makes sense, but what determines the per pixel? Once again I see it fall within the polygon to define it. Anyways I am no expert in 3d so please break down the ratio's of du/dx, du/dy, dv/dx, dv/dy, which I do believe is the ratio of the source texture u,v positions to the screen pixel x,y positions.

This is exactly it. But as I stated before, you can change the texture coordinates with the same polygon and get totally different results. The main thing is to think about how the texels are matching up with the pixels on the screen. Also, du/dx, etc. are all derivatives which describe the rate of change of the texture coordinates against the pixel. In other words, how fast the texel coordinates are changing at the current pixel.

A simple drawing would be absolutely wonderful here .

I am a lousy drawer (one big complaint back when I was teaching calculus).

 

[noko]

In other words, how fast the texel coordinates are changing at the current pixel.

Now I am seeing a little bit in why ATI has an effective adaptive anisotropic filtering scheme. The calculations are based per pixel which is derived from curves which defines the number of samples needed to accurately texture the screen pixel, as in as the polygon is being texturized the texel coordinates rate of change is determined. NEAT!! (Maybe I am wrong , but that does sound like what is happening here.)

This is a huge improvement besides being logrithmically smarter then samlpling every pixel with a fix number of samples which for most pixels is beyond what is needed, creating a huge performance hit for little to no IQ improvement. ATI is definitely leaps and bounds ahead of anyone else here.

I am a lousy drawer (one big complaint back when I was teaching calculus).

My WORD! teaching calculus without DRAWINGS!! Poor students .

 

[KimB]

This is a huge improvement besides being logrithmically smarter then samlpling every pixel with a fix number of samples which for most pixels is beyond what is needed,

This doesn't happen in ANY anisotropic implementation, noko.

The anisotropic specifications require that the function lies within certain boundaries. That is, being adaptive in this way is required for support of anisotropic.

Update:
The way I see it, doing the anisotropic on the pixel level or polygon level is sort of an optimization. It stands to reason that calculating the anisotropic level (and/or MIP mapping...the two are interrelated) for an entire polygon at once would take less calculation than doing it every pixel whenever the polygons are much larger than pixels, but the situation reverses when polygons approach the size of pixels.

 

[KimB]

One other clarification. The du/dx, du/dy, dv/dx, dv/dy cannot really be considered rates of change, in the normal sense. These are derivatives in position with respect to position, so they could be better described, in lay terms, as a description of the geometry, of how the texture looks with respect to the pixel.

Quick example:

Just imagine for a moment, that a small pixel in a 3D rendering image was blown way up, and within it you could see the texture. Let's say that what you see is a perfect 4x2 grid (three pixels across, two pixels down). If the "u" direction of the texture is up on the screen, then here's what the derivatives would be:

du/dx = 0
du/dy = 2
dv/dx = 4
dv/dy = 0

In this case, the proper MIP map selection factor for normal bilinear/trilinear filtering would be a plain 2, whereas acceptable approximations would lie between 2 and 2.59. The floating point number would be either truncated for bilinear filtering, or used for blending with trilinear (2.59 would mean .41 * MIP2 + .59 * MIP3).

For proper anisotropic, the degree selected would be 2. In this particular case, any approximation would need to also return exactly 2 for the chosen degree of anisotropy. Given this situation, an optimal MIP selection would be to use MIP level 1 (the base texture).

 

[KimB]

Might as well add a little bit more on the calculation of the partial derivatives of texture space with respect to screen space.

The example I gave above is incredibly ideal. This essentially will never happen in a game with a perspective-correct view. It seems apparent that GPUs will generally calculate these derivatives at the center of the pixel currently being rendered, which should do a good job of making the partial derivatives averages of the derivatives across the pixel (this should work in all cases because of the linear nature of 3D rendering...that is, if you imagine a straight line on a graph with two endpoints, the middle value of that line should always be the average of all values on that line).

Now, in a real-world case, a common occurence will be for the texels (the original name for pixels within a texture) within the pixel to be closer together toward the top of the pixel than they are at the bottom. This is common when looking at a floor texture. It is much harder to see exactly how the MIP map selection/degree of anisotropy selection applies here.

 

[Humus]

It could be that the room isn't long enough to spot the difference between the 9700's 8x and 16x on the level floor, and that when rotated they both default to the same mipmap distances, but you would think the 22 degree rotated should be a bit sharper with 16x than with 8x.

I think it's pretty much obviuos what's going on here. On the 22 degree shot the aniso implementation decides that a level of anisotrophy of 8 or less is sufficient, while in reality it should be higher. Thus no difference between the different max anisotrophy selected.

The mipmap selection and aniso level detection certainly improved from the 8500, but still has some limitations. I don't think they are critical though. The 8500 seams to select mipmaps such that two lines meet somewhere around the middle of the screen. The 9700 has four line segments. I see an analogy from this to the anisotrophy selection. You get correct aniso selections at 0, 45, 90, 135, 180 degrees, while a slightly lower aniso than optimal is selected in between with worst case in the middle of these points. That can be though of as four line segments too. The 8500 hardware probably uses a 3 entry table with linear interpolation and the 9700 uses a 5 entry table. Pure speculation of course, but that's what it looks like at least.

 

[KimB]

It looked to me like it was still slightly "less than optimal" at the 45 degree angles as well. But, I think we'd need a test that is exactly at 45 degrees to be sure.

 

[antlers]

The 8500 seams to select mipmaps such that two lines meet somewhere around the middle of the screen. The 9700 has four line segments. I see an analogy from this to the anisotrophy selection.

You know, this is exactly what Chalnoth said earlier and OpenGL guy kind of slapped him down.

 

[KimB]

Actually, antlers, what OpenGLguy didn't like about my statement was the supposition that it was a per-poly method. After seeing his response, he's probably right, both the R200 and R300 probably use per-pixel methods.

Having said that, the MIP map selection and anisotropic degree selection are inherently intertwined. It simply makes sense that a deficiency in one would be related to a deficiency in the other. This is certainly what we're seeing: the GeForce cards have semicircular MIP lines, and no angle-preference on anisotropic. The move from the Radeon 8500 to the 9700 essentially doubled the number of vertices of the MIP lines, and apparently did the same for the anisotropic issue.

 

[OpenGL guy]

One other clarification. The du/dx, du/dy, dv/dx, dv/dy cannot really be considered rates of change, in the normal sense. These are derivatives in position with respect to position, so they could be better described, in lay terms, as a description of the geometry, of how the texture looks with respect to the pixel.

Now you want to dispute my description of derivative as rate of change? First, let me define derivative so we all know where we are:

Let u = u(x,y)
du/dx = d/dx u(x,y) = lim (h -> 0) (u(x + h, y) - u (x, y)) / h =
lim (h -> 0) (u(x + h, y) - u (x, y)) / ((x + h) - x))

In other words, it's the limit of ratios of the change in u as x varies. Similarly for du/dy, dv/dx and dv/dy. Now, if I said that du/dx = 2 for some (x,y), that would mean the rate of change of u with respect to x at the point (x,y) is 2. Another way of saying it is that if you fix y as a constant, you now have a single variable function u = u(x) and the slope of its tangent line would be 2. The fact that u is "position" and x is "position" is of no consequence whatsoever. Any variable can be considered "position". Take y = sin x. At position x, y has derivative cos x. QED. (Of course, these are all partial derivatives, but I don't know how to make the delta symbol.)

Please, don't argue about such trivial points... especially when you are incorrect.

 

[KimB]

Now you want to dispute my description of derivative as rate of change? First, let me define derivative so we all know where we are:

Yes, a derivative is a rate of change. What I was attempting to say is that that description is misleading in this case, as most people would think of "rate of change" as "rate of change with respect to time" which these derivatives certainly are not.

After all, I'm sure that back when you last were in a basic calculus room, the first descriptions of derivatives with respect to the real world had to do with time derivatives, where the description "rate of change" is obvious to anybody.

Unless you are very familiar with calculus (as I would assume we both are), then rate of change is a fine description...I just don't think that's the case with everybody here.

 

[Ilfirin]

Yes, a derivative is a rate of change. What I was attempting to say is that that description is misleading in this case, as most people would think of "rate of change" as "rate of change with respect to time" which these derivatives certainly are not.

Perhaps in the real-world one might associate rate of change with 'time', but this is texture-world - we don't want your erroneous time!

 

[KimB]

I know, Ilfrin. I was just trying to make it more clear for those not "in the know" with the math.

 

[Bigus Dickus]

Please forgive me... it's been a while since I was in a Calc or Diff. Eq. class, but I had this random thought when I first read OpenGL's wording:

I've been accustomed (perhaps incorrectly ) to thinking of dy/dx as simply the change in y wrt x. Further, I'm accustomed to thinking of the second derivative, d2y/dx2 as the rate of change of y wrt x.

I'm probably shooting myself in the foot here big time, but I think of derivatives in the time domain this way as well... dx/dt is the change in x wrt time, and d2x/dt2 is the rate of change in x wrt time.

I never really enjoyed math, only what I could do with it, and as long as I could solve the equations I was generally satisfied. Still, this sort of definition does seem stuck in my head for some reason...