Hi,
Please, allow using texture atlas for UI textures ! Ideally I would like to pack all my buttons and other UI stuff in a texture instead of using 1 texture for each button.
I don’t know if there is a way to use texture atlas in UMG (I experimented with Flipbook nodes materials and stuff like that but it didn’t work well, at least in mobile).
I really think it is very important (square textures requirements for compressing PVRTC, etc)
Yours
Dredok
Hi Dredok, we’re thinking about it.
Having a single texture at editor time is not a desirable workflow. We don’t want users manually making their own atlases, and needing to specify all the UV coordinates when it’s an automatable process. It needs to be improved for UMG to handle UTextures (We do it already for raw pngs for Slate). The goal is to hopefully generate atlases at cook time in whatever format is needed. We may have to have a setting, or maybe there’s an “Atlas” file that you don’t ever really manage, you just specify a bunch of UTextures that it needs to hold and we take packing and compressing it from there. I also don’t want users choosing to organize or pack an atlas when a computer could be better at it. All too often users will break up their atlases based on commonalities that may have nothing to do with efficiency of the atlas for runtime purposes. Additionally some platforms handle differently sized textures better, for example, I think if it’s under 1024x1024 you can use the faster and less precise texture sampler in the shader on some mobile platforms. If the cooker got to choose the atlas size on a per platform basis it could make those kinds of optimization decisions.
If you’d like to author all UI components in a single texture, I’ve seen a UI artist here setup a Photoshop so that named regions could be written out as separate textures. So there’s no reason your source art need be independent textures.
Autoatlasing can be good, but getting the right behavior all of the time can be troublesome (you need an override path, the Atlas file suggestion sounds good for that). One solution I’ve used in the past with a WPF-like UI framework was using Texture Packer to output a resource dictionary that split the atlased textures into brushes. Artists specify the brush in the the UI, so no real point of pain there. Since the brush is referenced by resource name, even if it moves textures, no breakages occur. I think a resource dictionary style definition asset would make this kind of path very straight forward, as well as satisfy much of the benefits using the Slate Brush assets did in the earlier versions of UMG (and setting via binding, so it can still be reset inline).
I would very much consider the creation of some kind of bindable property asset (eg. Resource Dictionary), as it would greatly improve workflow, I feel. You can almost get this kind of behavior now, but you still have to explicitly create binding accessors for the subproperties which discourages the usage.
Well actually I’m concerned about performance and APK size.
If the cooking process will transparently group all my UI textures and make atlases (square in case of PVRTC etc) and compress them then I will be happy with that !
Hey guys,
in the meantime, is there some automated texture packing for UMG textures?
Hi there,
I wonder if there has been anything going on with implementing automatic texture atlases. When you make a mobile game which contains a menu with a lot of icons (for example a skill tree menu) it can get quite slow, while having an atlas would allow to batch everything into few drawcalls in best case, allowing to put even a complex 3d scene in the background.
Actually atlas support is the only pain i have right now with the system, but maybe i will try to work it around with rendering a material on UI which will use custom UV’s to render only a part of manualy made atlas.
just to push this thread a bit…
I think in every game that has an inventory and therefore needs icons for its items this is simply necessary, mobile or not. Think about 500 icons for the whole game (seems realistic to me), size 128x128 each.
Using 2048x2048 you need 2 textures, currently you need 500. Two textures are loaded fast, 500 (with all the metadata) not.
Should also be true for rendering. GPU caches textures and shaders, so rendering your Inventory with 2 textures should be much faster than lets say having 50 textures (for 50 different icons in your inventory).
Ditto - any progress on UMG texture atlas support?
I don’t know if there have been any official statements about this, maybe it got implemented and I missed it in the release notes, but having a texture packer do some magic while cooking content would provide a substantial runtime impact.
In the meantime, I am using a kludge based on FSlateTextureAtlas, which, incidentaly is what is used in slate for Fonts.
I guess you want us to use paper2D sprites for atlas in 4.13?:eek:
Is this something that ever made it into the engine?
Yes and no. A texture atlas interface was added a while ago, and UMG accepts those as brush textures, but Paper2D sprites are the only implementors so far. So the core support is there for people to implement atlasing without modifying the engine, but a plugin and tools for it aren’t there yet. There goes a good opportunity for a marketplace plugin.
Well, I do just that. Combining my UI textures for button etc. in a s ingle texture and using a flipbook material node to select through them.
I just divide an input index by the product of row and col count and feed that into the animation phase pin. No real magic… and works like a charm.
NO custom UV hassle needed.
