Reduce Draw Calls for many Materials


Our studio wants to switch to the Unreal Engine for our next games.

One essential part of our content is the procedural creation of buildings. Our tools create meshes with a lot of individual textures. In our current engine we use Texture Arrays to reduce draw calls. So we can draw a building in one draw call even if there are more than 100 textures. The index of the texture is coded in the vertex color. The performance is very good.

In UE4 I cannot find such a feature. In the source code I found FTexture2DArrayResource but this seems to be unused in the engine.

Is there a possible solution to render a lot of textures in one material?


Hi Mathias, I don’t think we have it but I added an internal ticket for this feature; writing the code to do it should not be hard, I think the most complicated issue is exposing it in the Material Editor (and having the array as an engine/editor resource).

These are very good news. Thank you!
Is there any way to get information about the state of the ticket? A Trello board or similar?

How many are you using exactly? As of 4.6 I believe, Unreal has shared texture samplers which work in a funky way to bring in a bunch of textures at once, rather than as separate calls or something. It allows you to get up to 128 textures in one material if that helps in the meantime?

Currently we have more than 400 Textures in one Array, but we can adapt our scripts to get only 128. What about the performance with shared texture samplers? Will they all be sampled in pixel shader or only the used one? What is the technique behind this feature?
Thank you

From what I understand, shared texture samplers must load all of the textures being shared all at once, so even if you’re only displaying one texture in a shared sampler, it will load all the other shared textures with it into memory. The pixel shader only considers the textures being used, however, and you can use whatever texture sizes you want in the array. The only information that must remain consistent between shared textures is filtering method. It would be nice if there were more arrays available to reduce the memory overhead when using many texture with different filtering options becomes a necessity, but those cases are typically very rare. For 99.9% of cases, shared samplers are the way to go.

I believe you cannot have more than 128 different textures using shared samplers in a single level.

Oh the texture limit is global and not per material? So we have a problem. We are not able to reduce our building textures globally to 128. Also I think we get a big performance problem when all textures that are in a single material are sampled in pixel shader and the shader will be very complex when connecting 128 sampler nodes. Our current texture array shader is very simple and only samples two times (diffuse and normal map).
In past projects (DX9) we generated texture atlases for the buildings but there we had problems with mipmapping artifacts. Is there any different solution than texture arrays? We consider to make tablet games in the future and there we cannot use texture arrays or shared texture samplers.

Hey, has there been any progress on those arrays?

I am also very interested in this feature - is the ticket for this still active and how far off is it?

Hey guys, it’s still on our TODO but we haven’t gotten around to it; I’ll try to bump up the priority :slight_smile:

Hey guys, I had wrote a feature about texture-atlas
You can try it freely

Hey RCaloca, I just wanted to check in about texture arrays. I have an open PR for them, that I updated/resubmitted from an older PR.

They’re fully running and I use them daily for my current project. The editor support is kinda lacking, but I didn’t want to put a bunch of effort into it if Epic was going to do their own, or wasn’t interested in it. If this is indeed something that could be merged I would be willing to go back and extend editor support. Right now you have to import the entire array as one .DDS texture and you can’t really edit it in the editor. The material functions are fully running, and other than one minor fix that I’m going to push to that PR, probably tonight, they’ve been completely stable for me.

For anyone that want’s to use them. I have them running on 4.11, 4.12 and master in my repo, just find the TextureArrays_(EngineVersion) branch. If anyone has questions on it, feel free to PM me or find me in unreal slackers chat. My Repo ( )

Just to clarify one thing. I didn’t write 90% of it, I just cleaned up, updated and bug fixed several things with it, then reopened the PR.

Thanks Koderz! I’ll ping the person who might be working on it to make sure he’s aware of this PR.

Thanks RCaloca! Like I said above, if there’s certain missing parts that Epic would want before accepting it, I’d be happy to attempt the remaining parts, including better editor support. I just hadn’t heard much about it so I left it alone.

I think we’ll first work on 3D textures, then arrays, but your PR will certainly help :slight_smile:

Ok, any ideas on when that will play out? I realize it can change, just wondering if you had a guess. Also, any particular reason for waiting until 3d textures for that? Just wondering since the core of the arrays are already in the engine (FTexture2DArrayResource), this just adds the resources and material support. Even for how hidden it is currently in a older PR and randomly mentioned on 2 threads not necessarily directly related, I’m getting people asking me how to get it so they can go ahead and use it. The only thing it really lacks currently is the ability to build the array in editor instead of importing an entire DDS file.

The staging of 3D textures vs. arrays mostly has to do with what order I do them in. I’m working 3D texture support, and the work for texture arrays is pretty similar. Given this pretty complete pull request for texture arrays, I may flip those and do the texture array pull request first.

Hey Koderz, when I click your links I get 404 Page Not Found. Just a heads up.

If you got a 404, make sure you have your github account linked to the UnrealEngine repo as my fork holds the same restrictions. If you can access but can’t access mine let me know, but it appears to be working for me right now.

The only thing that isn’t really complete is the texture editor support. which I’m happy to help with if you want. I just left that alone since it works enough for me and wasn’t sure about Epics plans. Also I’m around the unreal slackers almost all day every day if you have questions or I can help in any way.

I know it’s been a while for this thread, but wanted to first thank Koderz for the work on editor support for texture arrays. Support for them is one thing that I had in Unity that Unreal was lacking so this helps a lot with it.

I was wondering, anyone ever setup a texture array in C++? I’m playing with a lot of procedurally generated textures as well as man-made ones and the need to combine textures into arrays as things are loaded (so as to get efficient groupings). Which means generating the whole array of textures in C++.

Any ideas?