Is it worth creating texture atlases for mobile with URP?

We have a project that also targets mobile platforms. In the past years, to reduce draw calls we have been working a lot to have dynamic batching to as many objects as possible.

For this, we have always created texture atlases for almost every object and many objects share the same material. We try to have as little material count as we can. I will give 2 examples;

1st example: Traffic lights, street light, all traffic signs, bus stop, trash bins all share a single atlased material. All traffic cars share a single atlased material. Vegetation is also atlased.

2nd example: We have an object with 4 color variations, instead of making 4 materials, we made a single larger texture that includes 4 colors in it.

These all currently batch with dynamic batching and helps a lot in CPU performance cost.

But we are going to switch to URP soon, and when doing so, (if I understood correctly) SRP batcher can batch objects that share "same shaders" instead of how dynamic batching does with "same materials".

So for the 4 color variation example, if I use a texture with single greyscale material but use 4 materials that have different colors (from material property), these would still batch with SRP batcher and I wouldn't lose performance.

And for the 1st example, then it doesn't make sense to work on atlasing such objects. We can just have unique materials/textures for every object. If they share the same shader they will still batch.

Am I correct with these assumptions? And does making texture atlases for first case also reduce the GPU's load?

Does SRP batcher have a vertex limit like dynamic batching (in example 300 vertices limit)

Thanks,
Mehmet

 

We are also in the process of switching to URP and that's exactly what we are investigating as well. Going through the docs it seems that it is still beneficial to reduce amount of materials, since each material adds memory overhead (both RAM and VRAM). However once everything is set up, there is no longer the need to upload material data from CPU to GPU since they are already uploaded unless there is modification (e.g. color changes etc.)

 

I also think having more materials in the way you explain should have more memory overhead. But a better comparison would be like that.

1) Texture atlas for 4 different objects: 2048x2048 texture and 1 material
2) 4 unique 1024x1024 textures and materials for 4 objects but has same shader.

I think both options should be pretty similar in memory overhead. But with dynamic batching 1st one batches better. I'm not sure about SRP batching.

There are also cases like this;
There is a big building with lots of detail. For versatility I want to make a 2nd version of this building using another buildings roof texture. And lets say the only way to have it is by adding a second material submesh to the building.

We hesitate doing this because of draw calls. But perhaps with SRP batching there isn't an additional cost for adding a second material (that's already used for other buildings) to this building

 

Was there ever a definitive answer to this question? Can we ditch the atlas and focus on keeping shader variants to a minimum, rather than materials?

 

+1 Would like to know this as well.

 

+1 here as well.

 

Testing this at the moment, but would love to hear other peoples experiences as well. Thus a bump.

 

did you ever get this tested?

 

It really depends on the memory overhead.

This is a simple comparison but in actual use-cases, it usually gets composed from
1) 2 unique 1024x512 textures
2) 1 unique 512x1024 texture
3) 1 unique 1024x512 texture

The atlas packing sometimes pack with too much unused space.

It really depends on how your textures are being managed.

 

I have done a bit of testing with this, unless I missed something, this is what I understand to be correct --

Case 1: Not using the SRP Batcher whatsoever (Dynamic batching, Static batching)
In this case, texture atlasing will provide a huge benefit due to static & dynamic batching per material.
From my testing, the more atlases used will reduce the batcher performance, for example if you have 2 different vegetation atlases, & vegetation objects from different atlases are overlapping, dynamic batching will separate out things into significantly more batches than the expected 2 in this case. So, if all your last LOD levels were on the same atlas and met dynamic batching requirements, every single one of those could batch in 1 drawcall. If you had say 5 atlases for this, I don't believe it would only be 5 batches, more atlases = more batches, non linear.(could be wrong here, but seems this way from my tests). A final note here is that I still find dynamic batching to perform excellent when setup for correctly.

Case 2: SRP Batcher
I have geared away from the SRP batcher so a bit more unsure here, I believe the priority is Static batching > SRP Batcher > Dynamic batching. I do wonder if static batches are then pushed through the SRP batcher as well, and if that has any performance gains(maybe thats what this thread is asking) but in this case I can see atlasing could still have some benefits, and more so when using dynamic batching along with the SRP batcher. It seems the necessity & worthiness of atlasing in this case is certainly somewhat less than the first.

The best yet boring answer though is to just profile it yourself & see what suits your project best, because besides people that have some very strong knowledge of how things work under the hood in Unity combined with knowledge of the target hardware, I don't think anyone really knows what the best route to take is until they thoroughly test it, there are just too many variables and differences in each project/platform, so what works for one project won't work for another, for whatever reason it may be.

All the best

 

A bump from me: I've dropped atlases almost entirely and have sometimes ungodly amounts of materials involved in rendering. These materials all use the URP lit shader, many of the meshes drawn are static batched, and thus also use the SRP batcher, and have texture sizes around 128 to 512. However my performance is still incredibly good. No difference from when I was rendering the same scenes with atlased textures.

So from my side, given the above set of circumstances and variables yada yada, SRP has done away with the need to atlas textures.