Hello ev!
Can someone help me to understand how txt atlas works? I know its purpose but I’m not sure about how many textures can stay within the same udim without quality loss.
If I’m baking my textures at 2k for example, how many textures can I compress into one atlas? Only 4? Or even more?
Thank y’all! 
Hi @Cykablatta,
Well, a texture atlas traditionally shouldn’t exceed 4096, though with Virtual Texturing (which actually works really well in conjunction with atlases because of the way it loads samples), you can expand this limit.
Assuming the traditional 4096 limit, the amount of standard textures you can fit in is relative to your required texel density. If your asset textures need to be 1024 to retain maximum quality, then you’ll only be able to fit 4 textures in.
However, the more common version of texture atlasing is to use variable texture sizes. This allows small 128 decals to exist within the same atlas as major assets. Generally with this method, any hero assets should not be atlased.
If you have access to any of the Marketplace Polygon asset packs, you can look at their main texture atlas, as it’s a great example on how to get the most out of a single texture.
Here’s a good video that goes into how to determine your texel density:
Good luck! Let me know if you have any more questions.
Hi @sarahlenker ! Thank you for answering!
I asked because I’m trying to reduce txt sampling and draw calls, I’m doining it trought a unique master material to instance dynamically, this material I made adapts itself to any mesh using mat functions. In this case, I’m talking about architect mesh, so they’re not so big but not so small also, so I tought 2k for their txts was better. My idea was to create atlases with trim sheets I made in Blender because I’m generating a procedural map. So, If I got properly what you said , in this my case, it’s better for me to have separated textures ? Because I’ve few txts but high res. Right?
Hi @Cykablatta,
Sorry I missed your response.
A few things here, and sorry if I’m repeating infomraiton you already know, not sure where your skill level is at.
Texture samples do not increase draw calls. Things that do increase draw calls is every unique material on screen, the number of un-instanced meshes on screen, and the number of material slots on each mesh. The best place to start for reducing draw calls is limiting your material slots per-mesh and instancing as many meshes as possible.
The number of texture samples increases the cost on the VRam and GPU, which is still very important, but this is why Unreal has a built in texture pooling system (the texture streaming pool). This system caps the amount of memory allocation textures can use, so you never really have to worry about textures affecting performance, only visual quality- because if there are too many high-resolution textures on screen at once, Unreal will automatically mip down to the next resolution for some textures, resulting in low-quality textures (though if this happens you will get the “Texture streaming pool over budget” warning).
Now, if you are trying to limit your project’s VRam use as much as possible, (a very common example being for VR and Switch development as these platforms usually have a shared VRam and Memory) you may want to reduce the size of your texture streaming pool with the console command “r.streaming.poolsize ####” (in megabytes). You can also see your current texture streaming allocation with the command “stat streaming”.
If you are trying to optimize your streaming pool, which is only necessary if you are encountering issues with it, the best place to start is making sure all of your textures are power of 2 and “Never Stream” is unchecked in the texture settings so they are able to be Mipped. Then, make sure you are using your texel density wisely and reduce the default size of any textures that are larger than they need to be. Only then, once these other optimizations are done, is it worth it to look into texture atlasing.
That being said, if you are building your processes from the ground up, it is never a bad idea to start already atlasing. Just do not make any quality sacrifices at this stage. For your given scenario, I would say it’s probably not worth it to atlas major architectural pieces, but if you have the room in your texel density, using trim sheets for assets that are going to usually be in close proximity to one another wouldn’t hurt.
It does sound overall like your main performance concerns are unrelated from general texture optimizations. From the sounds of it, for now I would focus more on mesh and material optimization. I would also mention that 9 times out of 10, the real optimization problems I see from new users is related to lighting and shadowing and an over-reliance on features like Lumen, VSM, and Nanite without understanding proper optimization techniques for their pipelines. Not saying this is you, but just keep that in mind.
Here are some additional resources if you like reading:
@sarahlenker Don’t worry about the miss. Let me say you’re really gentle and I really appreaciate your answers. They’re helpfull! 
About the texture samples and draw calls I missunderstood, now is clear. Anyway, I’m already working with hierchical instanced static mesh and few master materials to instance dynamically via bp. I already streaming textures and also I already set max streaming poolsize changing value in the config folder directly. (I tried with 4000). I’m already working to optimizing uv scale based on dimension of mesh in the scene and their importance, trying also to have all uvs in the same udim. Now I’m realizing a texture atlas with 1k normals map and 512 roughs for my rooms, the rooms being the largest assets in the scene I wanted to texture them at 2k to be safe, but I decided to try with 1k not knowing in more detail the impact of textures on non-high-end PCs. Probably the only thing I’m missing is to merge all material slots in one. About this topic actually I really don’t know how to iterate on each slot after merge them. About lightning, I’m using Lumen, because I want a bit of reflections and to avoid baked lights not reacting to players and moving stuffs like AI/Objs. I’m working with stationary lights and I’m trying to reduce the numbers of total lights using emissive textures also.
What do you think about it, Am I doing well? Let me know!
It sounds like you’re already using a lot of optimization techniques, which is great! Are you actually encountering any performance issues?
As far as where you could optimize even more, material slots can be a big one, but only if draw calls are an issue. The best way to think about material slots is to separate them out by material type- not texture type. If you have an object that needs an opaque material and a masked material (the most common example being a tree), then this asset needs two material slots. If the only difference in material slots is the texturing and maybe some small effects, you’re better off combining these textures. If you have two different effects in one material, it’s common practice to replace the Metallic or the AO (whichever you need less) in your ORM map with a mask between the two original slots, then you can use that mask to determine the differences.
Less of an optimization and more of a heads up- Lumen can’t use stationary lights, this is a very common misconception. Stationary lights are a mix of baked and moveable lighting, where you can bake the bounce of the lighting into the lightmap but then still change the intensity and color dynamically. Since Lumen removes the use of baked lighting, it just turns stationary lights into movable lights. To save yourself any confusion, I would recommend just switching those lights to moveable.
That’s a great note on the emissive texturing! Yeah, from my understanding the emissive lighting is calculated by Lumen’s GI so it does not have to do any of the expensive shadow casting.
Overall, it sounds like you’re doing great at optimizing your project. This is a step a lot of people miss, but it’s also the most important, so truly great job paying attention to this.
That being said, are you experiencing any performance hitches? If you send over some information, I may be able to help you narrow down where it’s coming from since you’ve hit most of the go-to optimization methods.
@sarahlenker I’m really happy to hear that! Thank you so much Sarah! Also models I made in Blender are extremly lowpoly(no lods) , I’m managing only culling distance to stop rendering far hism from player and actually deactivating static meshes via bp. I don’t think I’m having performance issues. Fps are higher than 50. I’ve not pool alerts. Also when I go in simulation using stat tracking tools, they’re showned in green (is a good status right?) and values are low (materials memory, texture memory ecc..) . In general, I’ve few unique stuffs because I’m randomly reusing and customizing the same textures via scalar parameters and a material function for example.
AH 
So Can I use moveable lights for my indie project? Because I knew they’re not performance friendly. There’s something else should I do to optimize lightning? Idk why, maybe it’s just me and the fact I’m still learning but often I feel like what I’m doing to make the project lighter and accessible to everyone is never enough.
Do you mean something like unique textures in the same atlas? Or another method?
Yeah, if you’re using Lumen you can only use movable lights. They’re not great on performance, but Lumen does help to mitigate the cost in comparison to traditional rendering. There are a lot of optimizations you can make for lights and Lumen, but I really wouldn’t worry about it too much if its not hurting performance. If you want a full breakdown on optimizing Lumen lighting, you can take a look at my response here:
I do think that’s a common sentiment haha. There is always more to optimize, and that’s why it’s really important to start optimizing during your production pipeline, and to know where to focus your time.
This page is actually a great guide on how and when to optimize:
Well, less of an atlas and more of a trim sheet since the goal is to only use one material and one UV set. Let’s say you have a house material that has 4 material slots- 1 for wood, 1 for metal, 1 for glass, and 1 for wallpaper. You’re better off combining the materials for wood, metal, and wallpaper and just baking the textures in Substance Painter. The glass would need to stay a separate material slot since glass is a completely different material type and not reliant on textures.
Really? I didn’t knew that! But honestly, I’m a bit confused rn about what lightning methods would be better for me in terms of perform, because basically I generate procedural maps, and their size depend on last reached record before the loss. A mix of emissive txt, few spot/area lights (I know they’re lighter than points) and a directional light that in some way, affect indoor spots , could help?
Hm if you’re using a directional light, then that means it is forcing a shadow cast on every object in the scene within a certain distance to the camera. I would recommend turning off “Cast Shadows” on any objects that you know won’t be affected by shadowing (small objects, objects against walls, large exterior architecture that is not casting shadows into the interior, etc). I agree that Lumen is probably your best bet here. You could technically use baked lighting with a moveable directional light, but you would have to deal with seams in the procedural pieces. Better off just using Lumen.
Another trick you can use is to change the “Skylight Leaking” in your postprocess volume. This allows the Lumen GI to cheat additional ambient light into your interiors and can help minimize the number of moveable lights you need to add indoors.
Overall though, sounds like you’re already optimizing your lighting pretty well.
G morning @sarahlenker !
Thank you so much! And forgive me, curiosity got me and a simple question became a discussion for this I ask you, can I continue? because there are other things that I would like to ask you, thanks again for all the sources you have attached, I will gradually recover them all! Instead, regarding the atlas, I have heard/found opinions that I find a bit contrasting and confusing. For example,a guy told me that it doesn’t matter how many textures you put inside an udim, what matters is that they have the same res and shape.
Now I’ve created 1 set of 12 colors/normals/rough baked at 1k, so it would be 3 atlas (one for each channel) of 12 txt. Can I scale them and insert all 12 in a single file/udim?
Yeah of course! Always happy to answer questions.
For an atlas, yeah he’s pretty much correct. The only thing limiting the number of textures within an atlas is their texel density. Again though, it is important to be smart about your atlasing. If you’re atlasing a texture that only appears in one room and another texture that only appears in another, then these two objects will never be on screen at the same time and thus you are wasting space.
If you are committed to atlasing a lot of textures and your materials are relatively simple, then I would suggest you consider switching to virtual texturing. This will allow your atlases to be unconstrained by the normal 8192 limit (though I would still be smart about it) and does a much better job at optimizing atlas space by only loading areas of the texture currently visible. It’s also great for memory optimization. The trade off is a hit to shader calculations, as each unique texture needs to be sampled twice now.
@sarahlenker basically I’m creating a couple of variations for each material slot of each room. So each atlas will be used multiple times by a room type that in turn will be present multiple times as hism. For example, a room type can be customized via atlas, with a type of wall, floor, ceiling. So each room has its own atlas, and in the reference atlas there are only textures for the slots of that room. My idea was this. So that I could have a random combination for each slot. I wanted to create a unique material that through a function and a parameter defined which atlas to use for that room. I hope you understand what I mean.
@sarahlenker Another doubt I have is the size of the atlas file, I mean its final resolution, to make sure that each atlas inside it does not lose detail. If I am putting 9 1k textures, so 3 rows and 3 columns (they are all square), the resolution of the atlas file must be the sum? So 3072x3072 px, right? Or Am I still missunderstanding?
@sarahlenker
Consider that before exporting to ue, I do a check of the textures that I create and bake directly on the models concerned with the uvs ready. To make sure that as you also suggested, that the density is correct. Also because the Texel Density addon of Blender is not always reliable. In fact it is also reiterated in the video you linked.
This would technically be the correct atlas size, but since you want to keep your textures as a power of two, you would want to upscale it to 4096x4096. If you would like to instead fill that extra space with more textures, you could get a 4x4 grid (or 16 textures) for the same texture size.
@sarahlenker
rn what you said in the beginning about atlases is more clear!
So, I’ll make 4 more txts to close it. Idk if you read, but I’m thinking to manage this atlas for example, to txt each room’s mat slot and to randomly customize identical hism. In this way I’ve more comb between walls/floors eccetera..
@sarahlenker
Anyway, thank you so much again! I learned a lot from you and I’m happy there’re ppl like you in this community. Pro and gentle. Respect! 
Yeah this sounds like a great use of atlasing! Best of luck on your project, and just let me know if you have any other questions.
