We are using UMG widgets to build our UI and frontend within our pixel art game. When Paper2D sprite support for UMG widgets was added we switched over but discovered that the UMG widget appears to force anti aliasing on images within UMG, even though the source texture is set to to “unfiltered” and appears to be unfiltered (as expected) within the sprite editor. While we can see this behaviour is desirable in the majority of cases, however when going for pixel art aesthetic, it is necessary to be able to disable AA.
Could you try right clicking and creating a material out of the “DefaultDiffuse_TC_Masks”. After this you will need to set the domain to User interface. After applying this as your image in your brush settings, you will get the effect that you are looking for. I hope that this information helps.
Make it a great day
Thanks for the suggestion. However, I have gone back and created a material from the texture and set it to the User Interface material domain but it doesn’t appear to have made any difference, the asset still appears anti aliased within the UMG widget.
Did you check your results in a UMG widget as the asset will appear to be aliased in Texture, Sprite and Material editors, it is only when it is used in a UMG widget that it’s appearance is anti aliased?
I have attached an updated content example from the the base Unreal Editor 4.14 to help demonstrate the problem. link text
My apologies Rudy, it does display correctly when using your method. We were passing a Paper2D sprite to UMG which used a material instance derived from a parent material (Parent Material → Material Instance → Paper2D Sprite → UMG) which seemingly will not render aliased in UMG widgets, even when the materials were adjusted to the User Interface domain and the texture and sprite were set to render unfiltered with no mips, where as your method of supplying the material directly (Material → UMG) does indeed give an aliased, unfiltered image.
The only problem is we have a lot of our menu and UI assets banked up onto one texture sheet and we use in game sprites (such as background art) where they are the same for optimisation and organisational reasons. Your method seems to be use the older method of multiple textures and materials to supply the elements which can balloon quickly. This was something we were hoping to avoid when it was announced Paper2D sprites were being supported in UMG.
Is there any way we can use Paper2D sprites for our UI AND have the aliased pixel art aesthetic or is the multiple texture and material approach, and not really using Paper2D sprites at all, the only way we can go to get our pixel art look?
Yeah that sorted it out perfectly, thank you very much Rudy!
I had left the filter section on “Default (set by texture group)” as it is hidden in the advanced drop down section by standard and I assumed that by setting the texture group to “2D Pixels (unfiltered)” that it would pass that setting through but seemingly in this usage within UMG it doesn’t? Maybe a bug there?
Either way the problem is now resolved, thanks once again. You can have the rest of the day off!
I tested this in the widget as well as in game. It appears to be working as you requested. I was able to get the assets provided to show the same results. I have provided the sample project below. If you open the project and play in the editor you will see a fullscreened widget that has the pixelated look that was asked for.
In this example you will see on the left the look that was requested and on the right you will see the look that you are getting. These are an example that was run in PIE. The left is the material that has been set to use the user interface domain and the on one the right is using the texture itself.
I ran a few more tests and after doing so was able to come up with a solution. You will need to set your Texture filter for “DefaultDiffuse_TC_Masks” to “Nearest”. I have provided an example below. After this you can simply apply the sprite being used to the image in your widget as you had originally. I have provided a project as well.