Dolphin Custom Texture MipMaps

[Bighead]

I think this is the proper place to post this since it deals with the way Dolphin is currently handling mipmaps. Basically I want to point out a serious flaw which may currently be perceived as an "enhancement", but in my opinion this is not the case. If anything, I would call this a bug.

So to get right down to the issue: depending on the IR setting, Dolphin will load different mipmap levels at different distances. This is great for the game's stock textures, and it's great that Dolphin can now detect arbitrary mipmaps and load them at fixed perspectives, but this is VERY BAD for custom textures. Allow me to make my case.

---

CASE 1: LOADING THEM FURTHER BASED ON IR DOES NOT IMPROVE IMAGE QUALITY

In fact, it actually has a negative impact on quality. I will start with a texture and mipmaps idenitified with colors and the levels in text.



Loading them into the game, resolution set to 1x IR, everything is as expected.



Now let's crank up the IR to 4x. Suddenly, we no longer even see past level 1. This creates a "shimmer zone" between about the 2nd and 4th rows of the "Level 0" mipmaps all the way out to where Level 1 finally starts. The nearest row does not display shimmer since it is closest to the camera.



Cranking up the resolution to 8x and we may as well not even have mipmaps. This creates a LOT of shimmer. This is not an improvement to visual quality.

---

CASE 2: NO ABILITY TO CONTROL CUSTOM ARBITRARY MIPMAPS

A long time ago a contributor the Xenoblade pack decided to use mipmap effects in Xenoblade. This was a great idea, but now as hardware is getting stronger, 4k is a thing, 3x and 4x IR may not be the top end anymore, etc.. It's easy to see that his effects are now unpredictable.

This window for example, should have a glare from a distance that disappears as you get near it. At 2x IR, the glare is easily visible.



Bump it up to 4x IR, and the glare is still there but it has faded a bit. The only reason we can still see it, is because of some trickery I did to extend that mipmap to one more layer.



Bump it up to 8x IR, and the effect is completely gone. Looking closely at some of the other environments, you can clearly see some of the other dynamic effects also fade in and out of existence (like the railing and the back wall to the right).

---

CASE 3: REPLACING ARBITRARY MIPMAPS IS IMPOSSIBLE TO GET THE ORIGINAL EFFECT

So now we come to the issue which made me realize Dolphin is doing this all wrong. As we all know, Super Mario Galaxy uses mipmap effects. An example is this sky texture which has the final few mipmaps completely black (which in this case means transparent).



I believe razius retextured this, but the result without mipmaps is less than ideal...



So I added arbitrary mipmaps, which at 2x IR looks pretty great and very close to how the original textures look.



Unfortunately, the quality starts to degrade at 4x IR and original effect is now gone.

---

CASE 4: NOT CONVINCED YET?

I thought it would be cool to create a simple texture for this area in Super Mario Galaxy 2. Unfortunately, I was not able to do this.



The next set of images is this same texture at 2x IR, 4x IR, and 8x IR.





And if we don't use arbitary mipmaps at all, we get this mess.

---

THE CONCLUSION

The way Dolphin handles mipmaps for custom textures seems very wrong. It does not enhance the quality at all (rather it creates shimmer), and it does not allow any control over mipmap effects as they are unpredictable at different IR settings. I think that custom texture mipmaps should follow the same rules as arbitary mipmaps, and load at the same distances as 1x IR. I don't even know if that is possible or not, but I figured it was worth a mention because the way Dolphin is handling mipmaps for custom textures just seems wrong. The current method is fine for the game's default textures, as it does increase the image quality. But for custom textures.. it's just a nuisance.

[MayImilae]

Didn't you complain about the arbitrary mipmap fix making trees and things worse? Do you still think that is true?

[Bighead]

I wasn't complaining, just pointing out the fact it has a negative impact on Xenoblade's stock textures. Honestly it's a win/lose situation. I really didn't want the mipmap change to be reverted because it's a blessing for Super Mario Galaxy (and fixes a few other games), and as far as I know, Xenoblade is the only game that is affected negatively. Plus, it can be worked around using "GPU Texture Decoding" to disable the arb mipmap detection except in D3D11, which is why I created a pack that "fixes" those textures for users of D3D11.

But this has less to do with the arbitrary mipmap change and more to do with how custom texture mipmaps are loaded. I used the arbitrary mipmaps change as an example of how custom texture mipmaps should be handled (meaning, load them just like how they would be at 1x IR).

To sum up my thoughts:
- For stock mipmap textures that all contain the same image, extending how far the top level is drawn is ideal to increase image quality.
- For stock mipmap textures that contain different images, the arbitary mipmap fix is probably the most ideal as it does things more correctly (although it reduces quality in Xenoblade).
- For custom textures, extending the top level has a detrimental effect: it creates shimmer, and makes custom arbitrary mipmaps unpredictable.

Edit: Here's a better way to look at it I think. Assume the custom texture is 2048x2048. If mipmaps were loading in the same way as 1x IR, the downscale of each level will be closer to the actual number of pixels we are seeing.



Level 0: 2048x2048 - 1100
Level 1: 1024x1024 - 600
Level 2: 512x512 - 350
Level 3: 256x256 - 160

This to me makes a lot more sense than extending Level 0 all the way back to where Level 3/4 should be at 8x IR, which essentially means....

Level 0: 2048x2048 - 1100
Level 1: 2048x2048 - 600
Level 2: 2048x2048 - 350
Level 3: 2048x2048 - 160

When 2048 is smashed down to 350, you get a lot of glittery pixels.

[JonnyH]

When increasing the IR it's expected that the dFdx/dFdy get "larger" as there are more fragments per end result pixel - but these samples *should* be blended when downscaling to the display resolution and not cause "shimmer". Is there something wrong with that downscale? Without the higher sample rate you end up with fragments effectively returning the same value and only being used for effective coverage, turning into an inefficient version of MSAA....

Naturally, this interacts badly with things that use mip levels for effects other than simple texture downsampling - but I don't believe there is a general solution for this. I feel that the only solution to this would be to provide multiple custom texture mipchains, one for each different IR scale.

(01-04-2018, 12:34 PM)Bighead Wrote: I think. Assume the custom texture is 2048x2048. If mipmaps were loading in the same way as 1x IR, the downscale of each level will be closer to the actual number of pixels we are seeing.

(image)

This to me makes a lot more sense than extending Level 0 all the way back to where Level 3/4 should be at 8x IR, which essentially means....

Level 0: 2048x2048 - 1100
Level 1: 2048x2048 - 600
Level 2: 2048x2048 - 350
Level 3: 2048x2048 - 160

When 2048 is smashed down to 350, you get a lot of glittery pixels.

I'm not sure what you mean here - a mipchain of non-decreasing sizes is insane and would obviously cause issues? As the 'shimmer' avoidance is *why* mipchains exist - to select the correctly sized level for the coverage of each fragment?

If that's a typo - I guess you mean to say that "at 1xIR 350 screen pixels cover approx. 512 texels, but at 8x IR it covers approx. 2048!" - which is expected, as at 8xIR that should generate (350*8) 2800 fragments, which then should be blended together to make the 350 screen pixels. The blend should counter any shimmer that could be caused by the sampling.

[MayImilae]

Does Anisotropic Filtering deal with the shimmering?

[JonnyH]

Actually - is the IR more than 2x the resolution of the display resolution (window size)? As the current code uses a filter that will cause aliasing in this case (possibly causing the "shimmer" you are referring to?)

[Bighead]

Look, I don't really know how to explain it correctly, I just know what I see. I'm not going to pretend I'm right, I don't know if I am or not, that's why I am having this debate. When level 0 is drawn across the entire region at 8x IR, that looks like a problem to me. Maybe it isn't? But how is shimmering reduced if the lower mipmaps are not even being used? Drawing custom texture mipmaps like this at 1x IR at all IRs to me seems far more ideal, but only for custom textures. For the game's stock textures extending the distance of Level 0 definitely improves visual quality.

I tried to explain it the best I could, and maybe I'm saying things incorrectly. I recorded a few videos that can better illustrate what I mean other than me trying to explain it. 1080p resolution, 16x AF, no AA, videos are recorded at 4x IR and 8x IR respectively. 2048x2048 custom texture with a full mipmap chain. Shimmering is clearly visible in the distance (but not up close), especially at 8x IR, which is greatly reduced at 4x IR where smaller mipmaps are drawn closer. Whether or not it's visible will depend on how bad YouTube butchers the quality.

4x Resolution Video
8x Resolution Video

The thing is, shimmering is NOT even my main concern here, but we seem to be focused on that above the bigger issue. I only brought it up because it ties into the way Dolphin handles mipmaps for custom textures. The fact that there is no control over how far custom arbitrary mipmaps are drawn is far more important. If you look at the examples from my first post, that Xenoblade window will never have a glare at above 4x IR, that Mario Galaxy sky will only look "correct" at a 2x IR, and that Mario Galaxy 2 retro effect can never be retextured in a sane way that will compensate for every IR. This is only a few examples, but I was hoping it was enough to make my point. Having custom arbitrary mipmaps drawn at different distances based on IR means there is no way to create a consistent effect. This is why the arbitrary mipmap fix was even introduced to Dolphin for stock textures in the first place. That same issue applies to custom textures, but the fix does not apply to custom textures, it may even be too demanding to apply the heuristic to custom textures.

If it's preferable to extend custom texture mipmap draw distance at higher IRs, that's fine. My proposal was to force all custom textures to behave the same way at all IRs as 1x IR, but if that's not ideal, I'm at least hoping for some way to have control over it. I used the arbitrary mipmap fix as an example because it overrides the way Dolphin is currently drawing mipmaps at higher IRs to match the way mipmaps are drawn at 1x IR at any IR. It doesn't HAVE to be the default behavior, but there should be some way to control the behavior because right now there are just some textures that can never properly be retextured as a result, and we are severely limited in what we can do with custom mipmaps effects.

Allow me to go off on tangent and bring up another somewhat related issue that could be used to our advantage. Right now if GPU Texture Decoding is disabled, the arbitrary mipmap fix is in effect. Dolphin will dump these textures with an "arb" suffix. As it stands, Dolphin can't even use these texture names, the "arb" suffix has to be removed. But, this also opens up an opportunity to make use of this "arb" flag.

Eventually, Dolphin will either have to NOT dump these textures with "arb" in the name since they are unusable at the moment without being renamed (and I'm sure most users won't have any clue on this), or, the texture loader will have to be updated to actually load them. A crazy idea that I had, is that maybe we can use this "arb" flag to force custom textures to load mipmaps in the same way as 1x IR at any IR, even if the texture did not originally have "arb" in the name (meaning, it was not originally a texture with arbitrary mipmaps). This would at the very least, solve the issue of not having any control over custom arbitrary mipmaps, it will allow us to add mipmap effects to textures that did not have them AND allow them to remain consistent at any IR. And it wouldn't even have to affect the way Dolphin is currently handling mipmaps for custom textures (although the current way does seem to introduce shimmering, but I guess that's debatable and far from my biggest concern).

[degasus]

(01-05-2018, 12:21 AM)Bighead Wrote: 1080p resolution, 16x AF, no AA, videos are recorded at 4x IR and 8x IR respectively.

And this is the issue. Dolphin always use linear filtering on downscaling. This is terrible bad, especially if the ratio of IR and output resolution is close to 2 or bigger. For such a high ratios (8xIR to 1080p is like 3:1), you need a good blur to filter the higher frequencies.

So no, this isn't a bug about which mipmap level is choosen. Is is a wrong expectation that a higher IR yields the better result. For 1080p, you should pick 3xIR, not more.

[JonnyH]

(01-05-2018, 08:37 AM)degasus Wrote: And this is the issue. Dolphin always use linear filtering on downscaling. This is terrible bad, especially if the ratio of IR and output resolution is close to 2 or bigger. For such a high ratios (8xIR to 1080p is like 3:1), you need a good blur to filter the higher frequencies.

So no, this isn't a bug about which mipmap level is choosen. Is is a wrong expectation that a higher IR yields the better result. For 1080p, you should pick 3xIR, not more.

(Edit: damn forum ate my reply)
I believe there are 2 issues at work here:

- The "speckling" when the IR is more than 2x the "display" resolution - as you said this is caused by the undersampling of the framebuffer when rendering to the window. Having a IR larger than the display resolution is a pretty odd use case, effectively being SSAA, and more than 4xSSAA (which would be 2x the resolution in both X and Y) which is required for this speckling seems like it's starting to get pretty pointless..

- Games that (ab)use miplevels "effects" instead of just texture downsampling look different in different IRs.

The second is a fundamental part of how mipmaps work - /by design/ a higher rendering resolution would select a larger miplevel, as the whole point of higher IRs is to provide better image quality. Selecting the "same" miplevel would effectively remove the point of higher IRs. If you want to make those games look the "same", you'll need to match the mipchain effect "transition" to the IR - e.g. a 2x increase in IR would require a corresponding 2x increase in the size of the mipmap level where the transition happened. This naturally makes the custom mipchain IR-specific. This is a fundamental part of how mipchains work, and I don't think there's a sane "workaround" (as said above, forcing it to select the same miplevel as 1x IR kinda makes the IR increase pointless...). This is just something that custom texture creators are going to have to deal with for games that use these miplevel-based effects.

[AnyOldName3]

Okay, so here's a completely bizarre idea: allow mip levels for custom textures which replace mipmaps. This would mean that when a game would use the 256x256 mip level of a texture at 1x IR, we look for a series of textures which replace the 256x256 mip level in particular, and choose the one closest to the display resolution of the texture for the actual IR we're using. This would allow the separation of custom texture mip levels from original game mip levels, which basically seems to be what we want.

We'd probably want some way for either texture pack creators to specify that they want this behaviour for a specific texture (as otherwise, most textures would just be duplicates) or for Dolphin to only enable it when it detects that the original texture has non-trivial mipmaps.

In terms of the texture dumping and loading system, that could be done by making it consider non-trivial mipmaps of a texture to be a different texture. I think we could handle the GPU side texture selection by using the same maths as the GPU does under the hood to select mip levels, but instead of using the hardware provided screen-space derivatives, scale them to match 1xIR screen space and use that to select a texture from a sampler array.