When enough is enough (AF quality on g70)

I can think of reasons, I think that few of them are any good in this day and age. None of them apply when using anistropic filtering either ... using lod bias when using anisotropic filtering is like saying "haha you want good texture filtering huh ... well see how good you can do after I do my best to fuck it all up!".

Of course this isn't at all helped by the rather questionable history of not letting drivers determine LOD correctly by themselves during supersampling ... but regardless, a lod bias of -4 will result in aliasing.

 

I guess that if you did some pre-filtering to band-limit the frequency of your texture data then you might then want to alter the LOD bias since you would not need to switch mip level as early to avoid aliasing. Similarly you might want to apply a positive LOD bias to a very high frequency texture map in order to avoid aliasing because it will definitely alias at LOD 0.

 

More of a hack to work around poor texture filtering ... in an ideal world that would be optional, so it could be disabled for better performance. I dont see this explaining a -4 bias though.

If it aliases complain to the graphics card developer about their filtering algorithm, and then apply some blur to the lowest level mipmap only (after the other mipmaps have been created). Screwing up filtering for the entire chain to clean up some moire when using the lowest one is going at it the wrong way IMO.

If developers always second guess the graphics card/drivers, filtering will never improve ... because the driver developers will just third guess after the software comes out.

 

Actually Riva TNT reported the availibility of anisotropic filtering in the device caps, and when enabled it blurred (!) the textures somehow...
Altough it didn't have a performance hit...

We had to special case TNT cards and disable aniso on them in our engine...

 

Had to split up this reply because IE keeps hanging when I try to submit long messages... weird...

Completely wrong IMHO.

The API specifies linear filtering at a specific default LOD (ie. a specific level of compression at which you should change mip level). This LOD is set in a way that if you have a very high frequency texture then it is going to shimmer, because if you set it low enough to prevent all possible shimmering then you would end up with a blurry mess because most of the mid-high frequency data would be gone very quickly.

Applying blur to the lowest mip level will achieve nothing - it's the highest mip level that is most prone to aliasing because it contains, by definition, the highest frequency information. Lower mip levels are progressively less likely to (visibly) alias because they are low-pass filtered, and the lowest mip level is already blurred into a single colour and hence is not prone to aliasing at all.

 

Complaining about the way linear filtering works when we match the spec is really not going to fly, and nor should it. If we are way outside the spec then there's cause for complaint, but this isn't the case. Even with CatalystAI on we are pretty conservative about what we do (hence filtering quality is still good), and with Catalyst AI off we are matching the spec and reference rendering as closely as is possible for us.

I'm pretty sure that you will find that it's possible to generate significant texture shimmering with the D3D reference rasterizer when set to LOD 0.

You can certainly ask for better filtering in future hardware and future APIs, and that's fine since we're always looking at ways to improve quality, but even then we can never reach the reconstruction quality of something like a sync filter, because it's infinitely wide and we can't take infinite texture samples in finite time. Hence you're always going to trade off aliasing and blurring, and this requires LOD manipulation.

Complaining about filtering quality doesn't solve any issues with aliasing with current hardware that only has linear filters. Understanding the limitations of current filtering techniques means that developers can, and should, work around those limitations if they are bothered by the image quality.

 

There is no spec for anisotropic ... I really dont see what is wrong with expecting it to work correctly with 0 LOD bias. With everybody second guessing everybody in that respect it just creates excuses to avoid anyone being able to test the actual quality of the filtering.

Sinc filters are hardly ideal BTW.

(When I said lowest level I meant in a numerical sense BTW.)

 

Define correctly. It works correctly - it filters anisotropically.

Obviously you'd like a tighter spec. That's fine - as I said it's always fine to ask for better things in future hardware.

Anisotropic filtering currently uses the same linear filter hardware as any other mode. The mipmap blend function is still explicitly defined as linear. It's still prone to the same aliasing as any other current hardware filtering mode at LOD 0. In fact, since it preserves the high detail texture map over more of the screen it is more prone to large amounts of visible aliasing than standard isotropic filtering.

I didn't say they were ideal - I just said that it was difficult to achieve that level of reconstruction quality.

 

Ah - now it makes more sense!

Terminology at crossed purposes.

But if you apply a low pass filter to the top level to remove an appropriate amount of high frequencies then it seems to me you would then want to generate the lower mip levels from that version - if the blur was necessary at the top level then why would you then want to generate the lower mip levels from data that hadn't been appropriately band-limited? If you decide that the top level needs the high frequencies removed then it seems to me that this should propagate down the chain.

 

Depends a bit on what they use to generate mipmaps.

Anyway, the difference between aliasing and not aliasing is a +0.5 bias here ... positive biases aren't really what I was interested in, I am more interested in why developers are requesting ridiculous negative biases here.

 

I would be willing to bet the problem is not enough testing. Texture aliasing just never happens all over the place (except with absurd LOD biases).

 

What's the point though? When you dont see it it is only because you are effectively point sampling a low detail texture, and when you do see it it is annoying.

All loss, no gain.

 

Tough to say, really. There are lots of japanese developers who don't believe in mipmapping because they like the extra "sharpness"... Looks awful to me, but to each their own.

 

Interesting conversation.

Anyone care to clarify why moire patterns like in the screenshot to follow appear? That stuff is hard to cure that I couldn't get rid of it even with 16xSSAA, nor with a positive LOD bias:

http://users.otenet.gr/~ailuros/HQ2048.jpg

(kudos to LOLMAN for pointing it out)

 

Gah!!! Somebody should beat them over the head. Again and again and again.

 

It may be from aliasing due to the bump map, and you need to tackle that in the shader.

 

Careful, they might actually like that too LOL.

 

Meaning I'd need anti-aliasing within the shader theoretically?

 

If that is the case, this area should also shimmer on ATI Hardware. But thats something I would like to see before wondering, what this effect causes.

/edit
Shot from a x800 card. So its really the shader that shimmers.
http://img160.imageshack.us/img160/6038/moire1qd.jpg

 

If you use OGSS, then you aren't going to be able to get rid of all of those types of artifacts because your samples aren't being placed optimally. Essentially what you need is anisotropic filtering of the shader results.