We are displaying cards in a UMG menu. Those cards are with a material that layers 3 textures (background, portrait image, text) to minimize memory usage, and those 3 textures are square power of two in size.
However, the mipmap that is selected when the menu is called seems semi-random.
You should be setting your texture compression type to TC_UserInterface and set your mip gen settings to no mipmaps. UI textures should never be mipped as they will always be at one resolution and zoom level.
Well, since the UI is resolution independent and scales to fill the screen, I don’t think disabling mips is a valid approach. In addition, those textures are also used on the same card in the 3D world once the menu is dismissed.
If they are used in the 3D world as well, then yea, mipmaps may be necessary, but if they are always flat in viewport, they shouldn’t be. Its not about resolution of the screen, mips are there for objects being far away from the camera, and for objects at angles.
As far as the wrong mipmap being chosen when the object comes close to the camera, I don’t have an answer. Is this for mobile?
I’m not sure to understand why mips don’t make sense in UI. Texture filtering reconciles the texture’s source resolution with the displayed resolution. As widgets using the texture scale smaller, filtering of the level 0 mip produces more artifacts, thus the need to switch to smaller mips. Aren’t mips basically high quality precomputed scaled down images, using better filters than the hardware runtime ones? Downscaling easily produces artifacts with cheap filters. Correct me if I’m wrong…
Yeah, that is true…hmmmmmmm is the texture compression set to ui and did you change the MIP scheme at all? If they are accurate…maybe its a bug? Is this in a cooked build?
Hey, thanks for the ongoing help. The compression is set to UserInterface2D, changing it does not affect mipmapping in my experiments. So I also tried all kinds of other things this morning. This is not a cooked build, but I can reproduce in the cooked build.
Forcing no mipmaps, makes the texture crisp in the UI, too crisp even, and in the 3D world the usual artifacts appear when the object is far. So what you`d expect.
Playing with the Texture Group, using the UI one. Does not work.
Leaving mips enabled in the texture, but forcing mip-map level 0 in the material itself, since TextureSample blocks allow you to do that. That’s where it got interesting as the problem was still apparent. So it seemed like the required mip was not loaded by the streaming system.
Then setting “Never Stream” to true in the texture. This seems to work so far, I might just be lucky though.
So my current hypothesis is that UMG (or Slate probably) fails to tell the streaming system which mips it needs, and in turn uses the closest ones available, which is dependent on the 3D view. I say this because if at the same time the cards are visible at close distance in the 3D view, then good mips are available in UMG…
Tried to look up the engine code for where that would happen, but I’m still lost.
I received some new information in regards to your set up and issue. It was brought to my attention that you are using a widget component to render your UI.
The widget component uses a render target so the texel density is constant. Mip mapping won’t ever work for it while it remains a render target. You should be using meshes instead.
The mip level is picked based on texel density compared to pixel density. A level is picked that most closely matches what is on screen.
Nearest/Point filtering means no mips are being considered, you’re just picking the closest pixel to the UV coordinate. I hope this clarifies your issue.
Thanks a lot Andrew. If you talk with the responsible devs again, tell them that mipmaps would be a wonderful way to make resolution-independent UI, especially for PC where the resolution of the shipped product can vary a lot at runtime. Shipping multiple sizes of the same textures and selecting the right one manually would basically require some form of automated system to be written in order to remain sane and avoid content bugs, but such a system is uncomfortably close to mipmaps.
Is there any recommended workaround for this Andrew? I’ve got a level that has several 3D widget (screens) with small icons on them. Closeup they look nice and sharp and work as they should. From a distance however the screens look like a flea circus with all the small icons turned into flashing and flickering pixels in the locations of highest contrast. I’ve started manually swapping textures based on the players distance from these screens (my forced mip mapping) but it is pretty tedious to do this for all the textures.
