Hey guys,
I have a 2048*2048 texture for UI that i would like to split into multiple smaller textures like i was doing in unity in the far past (for mobile). To save draw calls.
How to do that in unreal ? (5.4.4)
i don’t see how adding more textures (of smaller size) would save draw calls. that’s pretty much the opposite of virtual textures.
i think you can split them with any image editor.
In unity you can take 1 texture, and split it into many smaller ones. they all track into that 1 draw call of one texture.
You dont split them into different files.
Unity can do that since forever, i want to do that in unreal for my mobile game
i don’t think you need that in ue.
i have no exp with that feature on unity. but i see no benefit in splitting the texture. specially not for drawcalls.
using virtual textures and/or mipmapping will give you the same result, it seems.
but even if you didnt used that, and used only one 2k texture. it will still be one drawcall.
In that 2048 texture i have many UI elements. how can i get them separately without that functionality like in unity?
VT is not good, it throw memory into the storage. cant use that in mobile.
oh ok, now i understand what you try to do.
oh you’re talking about spritesheets.
well you use spritesheets or texture packing (though sometimes texture packing is used to mean channel packing and i would usually not recommend this since ue does a much better job at optimizing textures). you can use flpbook if they are all the same size.
otherwise i think you can group multiple textures in a virtual texture, which is kinda the same as “splitting textures” if you look it from the other side. but i don’t recall exactly how to. i think ue has an automatic texture packing somewhere, i can’t recall exactly how it was used.
that’s the whole idea with virtual textures.
having said that, it won’t reduce drawcalls (unless you are using meshes, that have the exact same material, and it’s not using material instances with different dynamic parameters, which i don’t think it’s the case for ui, since each element will redraw anyway).
you might want to consider a retainer, but i highly doubt you have performance issues because of the ui.
texture atlases might be what you want How to use Texture Atlases and Spritesheets in Material Blueprints | Community tutorial
just in case i’ve added the texture atlas link that might help you.
Thank you, but i think its way to complicated for an indie developer to use (need to progress fast).
This guy made a tool that do what i need (even if in a reverse workflow, it combine them instead of separate)
good yes you can use whatever tool you want.
that’s basically exactly what i told you. you build an atlas. (there are so many different ways to call these stuffs).
if you’re an indie, i would advise you to be cautious with the amount of plugins that you use and add. as they also might add time to maintain, and will block you from upgrading engines. if moving fast is so important that could be a blocker.
if your ui elements are the same size you can import each texture separately. select. then right click and use “create texture array”.
in any case. i really think you’re wasting your time. you won’t save much performance by building an atlas, if you’re lucky maybe you get less than 1%.
the only case where it might help is if you use the exact same material (not dynamic) for all your elements, and somehow that ends up being a draw call. but again, ui elements shouldn’t redraw every frame, and most likely will trigger a draw call each anyway. so unless i’m mistaken about the being able to batch drawcalls for ui elements, i don’t think it’ll help much.
and i would strongly advise against building atlases of “items” (as it’s shown in the video). as you end up loading stuff you don’t use, and bloat the device vram which is worse than an extra drawcall.
a 2k texture sounds more like a redflag than a feature to me.
also i can’t recall exactly so i might be wrong, but ue already builds attlases in some cases.
Agree. its will be the first one i add.
”i really think you’re wasting your time. you won’t save much performance by building an atlas, if you’re lucky maybe you get less than 1%.”
1% * 100 different cases on a mid phone from 2020 is a lot.
When developing on mobile you should save everywhere you can.
not really. one percent is one percent. regardless the phone. one percent is below the error margin.
that means it’s imperceptible. there are so many other things that are far more important.
i said 1 percent as a way to say it has no impact.
though in any case depends on your project and how you use it.
hmmmmm there are no objective shoulds. not always. Is–ought problem - Wikipedia
if you are an indie, and you care about moving fast as much as you’ve said. i think you should put that into the table. these are conflicting goals, and soft dev is a matter of trade offs.
in any case, i was just giving you my recommendation and experience, as i tried to help you.
i think the technique has been discussed already. so you know now an option and can choose which ever suits your project the best.
i hope my suggestions helps you. whether my suggestion of using an atlas, or not using an atlas helps you, consider marking as solution.
good luck 
Im not fully agree with that. in my personal opinion everything you do should be balanced. you should care to a reasonable extent about most important things in your game. speed of creation is high on the list. but reasonable optimizations is also there. clicking few times on this plugin is definitely “reasonable” in that context. digging into docs for it might not be. ( i actually never go to docs just ask CGPT to dig them for me)
(post deleted by author)