x800 texture shimmering: FarCry video

Grestorn

Newcomer
Hi,

I've got my x800Pro a couple of weeks ago and after lots of discussion in the 3DCenter forums (www.forum-3dcenter.org) about ATI's "optimizations", I started to look hard for areas where you can see their algorithms to fail.

As I've already written, there are a couple of games where it's more than evident. Most of them are older games, but there are also some new ones, e.g. FarCry.

To prove this, I've created two videos of the same scene, one on the x800Pro and the other on my old 9700Pro. The later one shows the scene with very little texture shimmering (most won't even see it at all), while the x800 shows some obvious shimmering (look at the left wall).

Here are the videos (about 2 MB each, compressed using DIVX)

Video FarCry X800Pro: FarCryx800ProHiRes_Divx.avi
Video FarCry 9700Pro: FarCry9700ProHiRes_Divx.avi

The videos are created using FRAPS on 800x600 (full size) with 25 fps.

If someone wants to recreate the situation himself, here's how I created these videos:

On the mission "Fort" (I hope the US version uses the same mission title)the third-to-last save point is the exact spot. Enhance the gamma value since the scene is quite dark (the videos themselves have been created with the standard gamma setting). Also turn on the flashlights, otherwise you won't see anything.

Please let me stress that this doesn't mean that there is texture shimmering everywhere. In fact, there are but a few areas, where you can see it. In most games you'll never recognize any shimmering at all.

But what this proves is that trilinear banding and changing the LOD base DOES cause some quality degradation. And while it has the advantage of additional performance, which is nice to have in some games, it MUST be optional for those users who prefer the better IQ over the speed.

/edit: Replaced the videos with HiRes version (800x600) and removed the gamma enhancing to remove any doubt about the validity of the videos.
 
Althornin said:
would be nice if the videos were the same size....
make for a more even comparison
What do you mean, same size? The resolution is the same (they were created using FRAPS, half size, original resolution was 800x600, so the result is 400x300).

Evidently I moved by hand, so the captures aren't 100% identical. But I don't think that this changes anything at all.

You might want to make sure that you use a replay tool which is capable of zooming the video. It doesn't make much sense to use Win Media Player, where you can see just a tiny picture on a screen with high resolution.
 
Oh, I forgot:

Both videos were created with these settings:

rTool: AA and AF "App preference", "Trilinear filtering (App.)". So ATI's AF stage optimization is off. VSync forced on.

FarCry settings: 800x600, AA "High", Trilinear, 4xAF, all other settings to "very high" or "ultra high".
 
Well thats disappointing to say the least, i used to notice a little bit of shimmering with my 9700pro, we're led to believe that was due to the reduction in the standard bilinear filters to 5bits, now with the forced brilinear we've got even more shimmering being introduced, To all the naysayers that claim this didn't degrade quality, well we have lots of proof. Which brings us back to ATI doing the righ thing by people and offering to disable these optimisations in the control panel.
 
mozmo said:
To all the naysayers that claim this didn't degrade quality, well we have lots of proof. Which brings us back to ATI doing the righ thing by people and offering to disable these optimisations in the control panel.

...or perhaps improve their texture detection algorithm so that it can better recognize where not to use the optimization?
 
Daliden said:
...or perhaps improve their texture detection algorithm so that it can better recognize where not to use the optimization?
It has been proven that the only function of that detection algorithm is to sort out colored mipmaps.

There is an excellent article about that issue on computerbase.de (http://www.computerbase.de/artikel/hardware/grafikkarten/radeon_x800_texturen). Unfortunately, it's in german, and I don't have much hope that babelfish can create anything usefull out of this quite technical article. But maybe someone cares to translate the article?
 
Grestorn said:
Daliden said:
...or perhaps improve their texture detection algorithm so that it can better recognize where not to use the optimization?
It has been proven that the only function of that detection algorithm is to sort out colored mipmaps.

So there should be plenty of room for improvement then, eh? ;)
 
Those AVI's show the problem quite clearly. It would be really interesting if someone could create an AVI (same spot) using 6800 too.
If it's much the same then there's not much to be said but if the 6800 gives a clean image I know what direction my next upgrade will be.

Maybe I'll be able to play any game with decent levels of brightness / gamma etc too.
 
Grestorn said:
Althornin said:
would be nice if the videos were the same size....
make for a more even comparison
What do you mean, same size? The resolution is the same (they were created using FRAPS, half size, original resolution was 800x600, so the result is 400x300).
Well, no. The 9700 video is 512x384 while the X800 one is, as you say, 400x300. Also the video (not ingame) framerate is different as well as the number of frames (different compression ratio).
 
What resampling method did you use? Plus, as Zaphod mentioned, one is 512x384/25FPS and the other 400x300/30FPS. I notice the filenames too - AA? Ultimately it might not matter, but you might as well try and remove all contentious issues. Well done for getting them up, anyway. :)

If the R420/RV360 really looks that bad, in-game, then I'm very suprised nobody has noticed up until now.
 
mozmo said:
we're led to believe that was due to the reduction in the standard bilinear filters to 5bits

That only applies to texture ZOOMING. Anyway, do you ever stand so close to a polygon there's more than 64 on-screen pixels between each texel in the texturemap? Because that's how close you'd have to be before you'd start to see any difference between 5 and 8 bits interpolation.

To all the naysayers that claim this didn't degrade quality, well we have lots of proof.

Um, okaaaayyy... The original poster said it was only a few spots, and you'd have to bump the gamma and, and, and... Guess that means there's "lots" of evidence... :rolleyes: No, we're not at all bitching just for the sake of bitching, what are you talking about??? :LOL:

Which brings us back to ATI doing the righ thing by people and offering to disable these optimisations in the control panel.

Yeah, this I agree on. Users should always have the final choice.
 
Ok, well, here's the deal.

The original, uncompressed AVI's are both 400x300. Both use AA.

Since I don't have any DIVX encoder (yet), another guy was friendly enough to do the encoding for me, but I didn't really check what parameters he used.

I still have the original, uncompressed AVIs, so if anyone wants prove, I'd be happy to send them by mail (he needs at least 50 MB space in his inbox), you'll understand that I don't want to feature them on my webspace. (But please understand that I don't want to mail these files to 10+ individuals, so if someone who's usually considered to be trustworthy here would ask me for the files and wouch for the DIVX videos' ciorrect representations)

The reason for the "AA" in the filename is, that at first, for some reason, AA didn't work on the x800 if enabled in the game, only if forced in rTool or the CP. So I created the first movie without AA in the x800 version. Later, I reinstalled FC and AA started to work again. I recreated the video and therefor the "AA" in the filename. Again, both versions are using AA, which can be seen quite easily btw.

If I have the time this evening, I will install a DIVX encoder myself and reencode the videos so that there will no doubt anymore.
 
Guden Oden said:
The original poster said it was only a few spots, and you'd have to bump the gamma and, and, and... Guess that means there's "lots" of evidence... :rolleyes: No, we're not at all bitching just for the sake of bitching, what are you talking about??? :LOL:
While it is true that I had to bump the gamma, it's generally not true that the effect can only be seen if you increase the gamma.

The reason I bumped the gamma is that at this particular spot in FarCry it's actually quite dark (like in many other places). You can see the effect just by turning on your flashlight, but it's more evident if the texture is brighter, especially if your monitor produces a dark image, and I wanted to make it easier for the audience here.

If you have a game that's usually bright and uses fine structured textures (not plain or regularly patterned), like those old, rusty metal walls in FC, you shouldn't have any problems seeing the effect.
 
Cheers. I doubt that an interaction between certain framerates and resampling interpolators can cause this kind of effect anyway (especially not so localised). It doesn't look like something a quantization algorithm could produce either.

You really shouldn't make it easier for the audience to see though.
 
Can you some how save me your save. I will take it on a x800 to back up or refute (Sp?) your claim
 
jvd said:
Can you some how save me your save. I will take it on a x800 to back up or refute (Sp?) your claim
If you have played through the game, you should have the save game already, since I just used a standard save point position.

Again, it's in the Mission "Fort" (that's the third mission if I remember correctly, not sure if the US version uses the same name for that mission. It's the one where you have to destroy the satellite dish). Just before you reach the platform where the dish is installed on, you have to go through an old bunker. Within that bunker is exactly one savepoint. That's the one I used.

Remember to turn on the flashlight. You don't have to bump gamma if your monitor is bright enough. And you wont be able to refute my claim, at least not as long as you use the same Cat driver as I do (4.5 final).
 
I'll send you a save game this evening local time. (in about 6-8 hours).

But remember that I have the german version. I have no idea if that save game will work with the US version of FC.

Maybe someone else with an US version would like to send him that save game?
 
Grestorn said:
I'll send you a save game this evening local time. (in about 6-8 hours).

But remember that I have the german version. I have no idea if that save game will work with the US version of FC.

Maybe someone else with an US version would like to send him that save game?
someone just sent me a cheat. which will let me pick lvls so if the fort is the same thing i might be able to get there on my own. I will let u know though
 
Back
Top