AA or AF?

[OpenGL guy]

Would you've been confident if he addressed angles then OpenGlguy?

Yes. I am quite confident that we don't turn off texture filtering based on angles. How would the driver determine such a thing without resorting to SW TL, anyway?

If you are referring to differences in AF results, I still can't see how that has anything to do with texture stages, as Chalnoth said.

Thank you, come again.

 

[Ailuros]

Where did I say that texture filtering gets turned off entirely anyway?

In any case results have shown that ATI's anisotropic implementation is not giving the same output on all angles.

For the record I never said or implied it's a bad implementation either.

 

[OpenGL guy]

Where did I say that texture filtering gets turned off entirely anyway?

Re-read my original post, then your reply. I was referring to Chalnoth's comments regarding disabling texture filtering on some stages. I took your reply as a comment on what I said.

In any case results have shown that ATI's anisotropic implementation is not giving the same output on all angles.

This has nothing to do with what Chalnoth or I posted.

 

[Ailuros]

I'll remember to add a smiley next time sheesh. I'm not going to reread anything, I know exactly what I was thinking at the time.

Neither IHV has AF disabled on texturing stages on default, I took that as granted.

 

[KimB]

Would you've been confident if he addressed angles then OpenGlguy?

Yes. I am quite confident that we don't turn off texture filtering based on angles. How would the driver determine such a thing without resorting to SW TL, anyway?

If you are referring to differences in AF results, I still can't see how that has anything to do with texture stages, as Chalnoth said.

Thank you, come again.

I'm really sorry. I did mean to say disabled anisotropic for specific texture stages, not filtering entirely. For once, I went back and corrected the error, too.

Anyway, OpenGLGuy, are you aware whether or not the Radeon 8500/9700 cards attempt to disable or reduce anisotropic filtering for certain texture stages? What I've heard on the subject so far has been very vague, so I really don't know.

 

[KimB]

Would you've been confident if he addressed angles then OpenGlguy?

Chalnoth,

I replied with UT2003 in mind. Why do have to to have two texturing stages simultaneously optimized? What I meant was:

There's no reason why you must disable aniso for two texturing stages simulataneously. I did it because the GeForce4 has two texture pipelines per pixel pipeline, so disabling 0,2 always results in disabling anisotropic for the first texture pipeline, and so on.

The reason I did this was simply that I was attempting to investigate how the GeForce4 worked. It wasn't out of any desire to increase performance or anything of the kind, since I usually don't play any Direct3D games.

 

[Ailuros]

Hmmm so you're playing UT2003 in openGL or did I misunderstand that one?

Which leads me back to my question about it: why does openGL respond better to anisotropic filtering than D3D in terms of IQ (irrelevant to performance) in UT2003?

PS: If you read german 3DCenter.de has a nice article about GF4Ti and the supposed aniso "bug". Their theory about reduced logic concerning bilinear/aniso makes more sense than anything I've read so far on it.

 

[Humus]

I haven't seen any screenshot illustrating the difference between OpenGL and D3D renderer in UT2003 with aniso, but it might have something to do with the LOD. The D3D renderer by default uses some really odd LOD, which causes texture shimmering, which I don't think the OpenGL renderer does, at least there's no such settings in the .ini file.

 

[KimB]

Hmmm so you're playing UT2003 in openGL or did I misunderstand that one?

Which leads me back to my question about it: why does openGL respond better to anisotropic filtering than D3D in terms of IQ (irrelevant to performance) in UT2003?

PS: If you read german 3DCenter.de has a nice article about GF4Ti and the supposed aniso "bug". Their theory about reduced logic concerning bilinear/aniso makes more sense than anything I've read so far on it.

Yes, I do play UT2k3 in OpenGL mode. It loads a little bit faster, and appears to run just a little bit smoother. As for D3D vs. OpenGL in anisotropic, I have no idea. I never noticed much differences in the tests I did other than a very slight LOD difference.

And yes, I did read that article, but I'm not sure I agree with them. I'll have to look over it again.

Well, I think one reason is that since I don't read German, I have to rely on a crappy translation, so I really have a hard time understanding what the article is attempting to state.

Regardless, due to the fact that disabling anisotropic filtering for the first texture stages out of two results in performance figures indentical to those without anisotropic, I'm convinced that the performance hit lies with the lack of a separate anisotropic degree calcualtion part for each texture pipeline, and, very probably, other hardware-level optimization issues.

 

[Ailuros]

I haven't seen any screenshot illustrating the difference between OpenGL and D3D renderer in UT2003 with aniso, but it might have something to do with the LOD. The D3D renderer by default uses some really odd LOD, which causes texture shimmering, which I don't think the OpenGL renderer does, at least there's no such settings in the .ini file.

You can however use the same LOD value for both API's through the ini (f.e. "0" for both). I haven't got time right now to deal with screenshots, but the difference is very apparent with aniso turned on between OGL and D3D on floor textures in maps like Anubis.

 

[KimB]

You can however use the same LOD value for both API's through the ini (f.e. "0" for both). I haven't got time right now to deal with screenshots, but the difference is very apparent with aniso turned on between OGL and D3D on floor textures in maps like Anubis.

Only the same LOD is not used in both API's, even when both set to zero.