x

Search in
Sort by:

Question Status:

Search help

  • Simple searches use one or more words. Separate the words with spaces (cat dog) to search cat,dog or both. Separate the words with plus signs (cat +dog) to search for items that may contain cat but must contain dog.
  • You can further refine your search on the search results page, where you can search by keywords, author, topic. These can be combined with each other. Examples
    • cat dog --matches anything with cat,dog or both
    • cat +dog --searches for cat +dog where dog is a mandatory term
    • cat -dog -- searches for cat excluding any result containing dog
    • [cats] —will restrict your search to results with topic named "cats"
    • [cats] [dogs] —will restrict your search to results with both topics, "cats", and "dogs"

Bad mipmaps in UMG

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. alt text

If I then close the menu and force the larger mipmaps to load by looking at those cards up close in 3D in the viewport, then it looks better. alt text

I'm not sure how to diagnose and fix this. Any ideas? All other materials seem fine in UMG.

Product Version: Not Selected
Tags:
bad.png (479.7 kB)
better.png (519.5 kB)
more ▼

asked May 12 '15 at 09:18 PM in Rendering

avatar image

joelr
251 21 25 191

avatar image nickpetersonfx May 12 '15 at 10:45 PM

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.

avatar image joelr May 13 '15 at 01:45 AM

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.

avatar image nickpetersonfx May 13 '15 at 01:52 PM

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?

avatar image joelr May 13 '15 at 02:40 PM

This is for PC.

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...

avatar image nickpetersonfx May 13 '15 at 05:58 PM

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?

avatar image joelr May 13 '15 at 06:33 PM

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.

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

1 answer: sort voted first

Hey joelr,

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.

Thank you,

Andrew Hurley

more ▼

answered May 30 '15 at 06:56 PM

avatar image joelr Jun 01 '15 at 01:26 AM

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.

avatar image quality Apr 04 '16 at 09:23 PM

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.

avatar image SDRLabs Dec 16 '16 at 12:40 AM

no solution right? goodness, ue 4 is such a waste of time to get simple things working

(comments are locked)
10|2000 characters needed characters left
Viewable by all users
Your answer
toggle preview:

Up to 5 attachments (including images) can be used with a maximum of 5.2 MB each and 5.2 MB total.

Follow this question

Once you sign in you will be able to subscribe for any updates here

Answers to this question