My R9700 experince and Aniso still "flawd"?

[Althornin]

Fuz, I think jb is talking about bilin + aniso "flaw" - I don't think that progiie reveals any such "flaw".

He's talking about the issue where the filtering doesn't work correctly when the poly is rotated around the Z axis, which is what that image is showing. Look at the surface which reaches to the bottom right hand corner - on the 8500 shot you can clearly see that filltering gets much blurrier early, however it does not on 9700.

Yup. Basically, bilin + aniso while Z-rotated, I think.

Nope.
just bilinear while z-rotated, on the R8500. No aniso at 45, going to full at 90 and zero.

 

[bmg]

I've tried Humus's driver and high res textures now work ok. Detail textures don't, however.

 

[NV25]

I'm very impressed with the 9700. Only one game has given me a problem - Medieval: Total War (it crashes while loading the campaign). I'm not sure what's causing that because I can play single battles fine.

Anyway, I get 12259 points in 3dMark2001

Nature score has risen from 36 fps on a GeForce3 to 98 fps on 9700! I'll settle for that However, I do get some nasty lows in car chase (high detail). During the robot firing scene the speed sometimes drops to 22 fps, whereas my GF3 went no lower than 29 fps.

system:

Athlon XP 2200+
512mb DDR Ram
Radeon 9700 PRO

One game I had to test was Morrowind, and it's super-smooth @ 1024x768 with 6x AA and 16x aniso. No sign of aniso probs that I could see but I've yet to play around with the settings to any great extent. I'll check out AvP2 as this game did have some issues on my GF3.

 

[Randell]

aah found it, Digit Life specifically tested the aniso, thats where those coloured number tunnels come from (RightMark 3D), here's a snippet;

'Have you noticed the difference? And now look at the screenshots of the RADEON 9700 above to make sure that the problem of angles close to 45 degrees is solved.
Now let's return to the difference in operation of this "Performance/Quality" function. We saw above that although the anisotropy quality grew and didn't depend on angles anymore, it is still unable to coexist with the trilinear filtering. Quality mode'

Here's the whole review

http://www.digit-life.com/articles2/radeon/r9700pro.html

strange then jb you dont concur, someone needs to test the SS:SE level as you asked.

 

[Humus]

I've tried Humus's driver and high res textures now work ok. Detail textures don't, however.

Fixed

 

[OpenGL guy]

However, I do get some nasty lows in car chase (high detail). During the robot firing scene the speed sometimes drops to 22 fps, whereas my GF3 went no lower than 29 fps.

You'll see results similar to the Radeon 9700 on a GeForce 4 as well. This is a very CPU limited benchmark, particularly at the point you are referring to.

 

[vogel]

1) High Res Textures did not work in OpenGL in UT (I did not try them in D3D). FPS was in the 10s. I tried to use several tricks that we have heard about on Rage3d that got it to work for the 8500. None worked

It struck me that I haven't played UT seriously since that problem started to occure for people, so I haven't looked into it before now. Somehow now that you mentioned it I got a feeling that it must be something with the renderer. After doing some investigations it turns out from looking at the UnrealTournament.log file that the GL_EXT_texture_compression_s3tc isn't recogniced for whatever reason, even though it clearly shows up in the extension string. As I had an old copy of the OpenGL renderer source code laying around I picked it up and played around with it. The code style used isn't really my kind of style, so I didn't bother trying to find the actual cause of the problem for longer than 5min ... instead I took the simple path of simply explicitely insert a row SupportTC = 1; after the test ... and now it works Will probably crash on systems that doesn't support TC though, but who cares ...
As my server is currently down due to some hardware rearrangements I've put up the fix on my old website ... over here

Edit: Fixed URL

This is a bug in UT's OpenGL renderer extension querying code which I fixed for UT2k3 a while back. I'll post a fixed dll for UT at some point.

-- Daniel

 

[vogel]

This is a bug in UT's OpenGL renderer extension querying code which I fixed for UT2k3 a while back. I'll post a fixed dll for UT at some point.

http://unreal.epicgames.com

-- Daniel

 

[Typedef Enum]

Hey Daniel,

How's she lookin', as far as an OpenGL renderer for UT2003?

Come on, tell the truth...does it kick the crap out of the D3D one?

 

[Reverend]

Fuz, I think jb is talking about bilin + aniso "flaw" - I don't think that progiie reveals any such "flaw".

He's talking about the issue where the filtering doesn't work correctly when the poly is rotated around the Z axis, which is what that image is showing. Look at the surface which reaches to the bottom right hand corner - on the 8500 shot you can clearly see that filltering gets much blurrier early, however it does not on 9700.

Yup. Basically, bilin + aniso while Z-rotated, I think.

Nope.
just bilinear while z-rotated, on the R8500. No aniso at 45, going to full at 90 and zero.

Er, that's what I meant (i.e. even if aniso is applied, it doesn't work/reverts-to-bilin when z-rotated).

 

[OpenGL guy]

Er, that's what I meant (i.e. even if aniso is applied, it doesn't work/reverts-to-bilin when z-rotated).

The 8500 only fails to apply aniso at 45 degrees.

 

[KimB]

And, of course, the more accurate description:

The degree of anisotropy is decreased from the maximum value when the polys are hotizontal/vertical to the minimum value of no anisotropy halfway inbetween.

i.e. there are problems at all angles that are not perfectly horizontal/vertical...just that the most pronounced is at 45 degree angles.

 

[Althornin]

And, of course, the more accurate description:

The degree of anisotropy is decreased from the maximum value when the polys are hotizontal/vertical to the minimum value of no anisotropy halfway inbetween.

i.e. there are problems at all angles that are not perfectly horizontal/vertical...just that the most pronounced is at 45 degree angles.

yep.
Rev, sorry, it sounded to me like you were saying it did bilin+aniso when rotated, but that shot just shows bilin - no aniso at 45 degrees... sorry if i misunderstood you.

 

[Mize]

aah found it, Digit Life specifically tested the aniso, thats where those coloured number tunnels come from (RightMark 3D), here's a snippet;
We saw above that although the anisotropy quality grew and didn't depend on angles anymore, it is still unable to coexist with the trilinear filtering. Quality mode'

This statement is incorrect. Trilinear and Quality aniso work fine together. Also, I ran pcchen's rotating road proggie and the improvement in aniso over the 8500 is dramatic. I can't see any reason to call it flawed by any stretch.

(like this card BTW except that it doesn't get along with two DIMMs at 185 FSB on my mainboard for some reason. I have to downclock to 175 MHz or remove one stick )

Mize

 

[Randell]

I think I may have missed out the reference to Performance mode

 

[Reverend]

Er, that's what I meant (i.e. even if aniso is applied, it doesn't work/reverts-to-bilin when z-rotated).

The 8500 only fails to apply aniso at 45 degrees.

Two questions :

1) Based on jb's post, is this repeated with the 9700?
2) I must've missed it (since it must've probably been explained somewhere) - why is this the case with the 8500 (i.e. no aniso at 45 degrees) ?

 

[Mize]

Based on my tests with pcchen's rotating road proggie, the 8500 has four points about a 360 degree rotation where aniso is applied virutally NIL. The 9700 has eight locations where aniso is slightly less sharp in the distance; that is the mipmap boundary edges only slightly closer eight times throughout a 360 degree rotation.

As for the claim about quality aniso and trilinear not working together this is false as I've tested it with Q3A (colormiplevel=1). The mipmap boundaries are pushed back as with bilinear+aniso, but very smoothly blended owing to the trilinear filtering.

The 9700 is a huge IQ improvement over the 8500.

Now if I could just get the 9700 to get along with two DIMMs at an FSB of 180+ MHz

Mize

 

[jb]

Mize,

I guess looking at those screens shots again and after playing around with it more could it be that its apply aniso at the 45 degree angles just not as much?

 

[Mize]

Mize,

I guess looking at those screens shots again and after playing around with it more could it be that its apply aniso at the 45 degree angles just not as much?

There are minima in the level of aniso filtering starting at about 15 degrees and every 45 thereafter. It is nothing like the minima in anisotropic filtering seen on the 8500; in this case the first minima is at about 45 degrees and repeats every 90 degrees and is quite severe (vitually no filtering). Personally, I find 16x + trilinear on the 9700 to be about the best IQ I've seen and at an amazingly low hit.

Mize

 

[OpenGL guy]

The 9700 is a huge IQ improvement over the 8500.

As I once posted on Rage 3D: There is no time when the 9700 doesn't apply anisotropic filtering. Unless, of course, no aniso is needed.