Mip level bias (lodbias) should scale with rendering resolution

[hrydgard]

When resolution doubles, since each pixel covers a smaller area, we effectively go down one LOD bias level.

For example, Burnout applies a bias of -3.0 to avoid a blurry look, at the cost of a lot of shimmering in the distance. When we double resolution and still apply the same bias, we effectively apply a bias of -4.0, considering the level that we look up in the texture, and get excessive shimmering that could simply be avoided by reducing the lod bias to -2.0 (or even better, use anisotropic filtering if available which also avoids the blurring while simulataneously not shimmering).

For the best filtering quality we should probably:

• If aniso available: Use it and remove all negative lod bias, at least in auto mode
• If aniso not available: Add log2(rendering resolution scale) to the lod bias. This should probably be done in slope mode as well, if we ever figure that one out completely.

This of course disregards those annoying games that use full-size mipmaps and lod bias to fade between mipmaps...

[Leopard20]

I always thought it is negative LOD bias that results in shimmering, and higher positive lodbias value results in blurriness.🤔

[hrydgard]

Uh, yeah. I've got it backwards here I think... Point still stands :)

[hrydgard]

Reversed the signs in the text :)

[unknownbrackets]

For const, shouldn't we not affect the bias? This bias issue is only a problem for auto mip levels - if we're using CONST level 2, we don't need any resolution-related bias, right? 2 is 2 is 2, at any resolution. That was why the min/max level clamping.

For auto, I can see a detail argument (like with 24 bit depth.) But only really for non-aniso.

Consider a simple case:

• At 1x, a texture would be drawn at 2:1 and therefore select mip level 1.
• At 2x, without any special biasing, it would increase detail to mip level 0 (arguably desirable), giving me 1:1 pixels since the texture is truly being drawn 1:1 now.

Specifically for negative levels, I think it makes sense to force those to aniso/auto instead, but I'm not sure it's as true for zero or higher. This assumes that all mip levels are actually valid (i.e. something with a mip bias of -5.0f that is never drawn when farther away than that might have, for example, forgotten to update the other mip levels.)

-[Unknown]

[hrydgard]

Hm, you're right that for CONST we shouldn't do the resolution bias. I do think it makes sense to do it for auto/non-aniso and slope/non-aniso - slope usage seems to be a thing in PS2 ports mainly, probably because it doesn't do auto and most of the time we're better off forcing auto anyway though a few games become a bit too blurry (wipeout in 1x resolution, for example).

That's true about positive levels that might be missing, though I've never seen such a case.

[unknownbrackets]

We probably catch most (all?) of the cases by validating the sizes, since they'd likely be off when forgetting.

-[Unknown]