Do your 2D atlases even work?

Sorry, it’s been a long time. There will be a lot of emotions.

Guys, I’ve been in IT for 15 years. Mostly desktop programming, some multithreading.
Also about 5 years in web - HTML/CSS/SCSS/Gulp/ PHP / Symphony . OOP, paradigms, GOF/DRY/KISS…etc.

First - dear developers - what about the documentation?
For 15 years I have read tons of documentation and yours is one of the worst. Zero examples, zero best practices. Poor localization (2025-age of neural networks).

Half of the article is in Russian, half in English. What kind of attitude to work?

Open the Symphony framework documentation and see how it is written. This is a good example.

No good documentation, no good examples - it is not clear how to work.
You think I’m the only one? Look what’s on YouTube - 90% of Unity videos contain terrible code. I am a member of many communities, in telegram chats - everywhere there is misunderstanding and invention, homemade solutions.

I came from web development - there is no such thing even close, because there is documentation. Normal, good documentation.

Now to sprite atlases.
I spent about 2 weeks. And I, who can learn the framework in 1 month, don’t know how to work with your atlases. I don’t know how the hell Unity works with them!

You write 1 atlas per scene. Are you serious? Those are your words - ideally 1 atlas and that’s it. And in the non-ideal case? It’s a mystery!

Let’s go to the gpt chat. It says 1-3 atlas per scene. All right, let’s believe him… you don’t have documentation.

Minimize the load on the video system, rendering, switching. To do this, we create each scene its own atlas. Isn’t that perfect?
Each scene has its own folder for images.
We put all prefabs and images in this folder.
Add the folder to the atlas.

We’re I.T. guys, it’s cool! 1 scene, 1 atlas, 1 folder. Perfect?

\Assets\Scenes\Scene1\Img1\1.png This Img1 folder add in Atlas1
\Assets\Scenes\Scene2\Img1\1.png This Img1 folder add in Atlas2

Start unity…and… atlas 2 are loaded! How?

And unity decided that on its own!
Images in different folders. Each folder has a different set to minimize the atlas. And yes some of them can overlap and that’s normal.
What is Unity doing? Loads a random atlas!

Tell me, where in IT , system product is this behavior?
Nowhere.

I in Windows 2 times click on a file, and I will open a copy of it, if it is somewhere on the disk? What?
I will access /home/somefile.php in php and I will execute /home/www/somefile.php if it is there? What?

What about atlases? Why is there no documentation, where are the examples?
Why does working with atlases violate the reuse paradigm, why does the behavior of atlases include elements of randomness - who designs systems this way?

Atlases are related to rendering optimization.
It should have nothing to do with file names, sizes, signatures. I clearly specify the files, their number and atlas.

Unity itself loads that, atlas, with a different image. It is different - its location in the file system is different. It is not for this atlas, it is not included in it.

Are you testing in the editor?

The editor is not indicative of memory usage and behaviour in a built project.

Do a build and test your memory there.

Why do we need an editor then? Maybe we should remove it from the next Unity releases?

Seriously… testers are sitting on a project - running load tests, unit tests, etc.

Then the team leader comes and says - guys, your entire development environment, all your utilities, all your tests, testing frameworks - all nonsense.

Now we’ll launch the project for compilation… upload it to the release (the test environment may also not show the actual resource usage)… and that’s where you’ll take performance metrics.

How is that even possible?

You’re talking nonsense sorry.

If you want to profile accurate performance and memory usage… you do it with a built project on target hardware. The editor is doing tons of extra stuff to manage the editor environment, adding extra overhead and keeping things in memory that otherwise might not be in memory in a built project.

The memory profiler even has a big warning saying, “Hey, you’re doing a profile in the editor. If you want more accurate results, you should profile a built project!”

This has always been the case for Unity.

Don’t you think my “nonsense” is based on some experience?

Don’t you think that having some experience and raising issues of documentation, training, best practices, including writing code with neural networks…I’m implying that it shouldn’t be like this?

Don’t you think the unity editor is…lying a little bit?
And it is a bit, judging by thousands of posts on forums and very doubtful answers from the support team - are we working on providing more detailed information on this bug/message in the future?

Sometimes the editor lowers fps, and quite strongly, sometimes displays errors that do not exist…shows names in small font that cannot be seen properly…needs add-ons like OdinInspector and Fast Reload…

Don’t you think so?
Don’t you think that even small companies provide better documentation and quality of products for development, have a chat bot based on neural network?

It’s 2025. It doesn’t work like that.

Your personal experience and gripes have nothing to do with this and nothing to do with my point.

If you want accurate profiler results: profile a build.

And to answer this question:

We need it to make the project, obviously.

Anyway, not going to respond any more. You don’t seem to want answers you seem to just want to vent.

OK I have the ideal solution that will make all your problems go away and everything make sense.

Open up the Frame Debugger. This is the tool that should make it ALL make sense. It helps you understand both general and particular cases, no matter how you have your scene laid out.

What we want to do for any particular scene is make this have as few draws as possible. The more that can be batched together the better.

Why do batches break? And how do Sprite Atlases help? Batches break principally for TWO reasons: (1) materials change, (2) textures change. That means if two sprites are rendered with either different materials/shaders or textures then the batch breaks. Sprite Atlases help with the textures part.

In your fullest scene, open it up while playing. It freezes the Play and shows you how your scene is drawn. For a scene with sprites, it’s drawn back-to-front. You can arrow down in the Frame Debugger to see how the scene evolves as it’s drawn.

At some point, there’s a part where most of your sprites are drawn.

Here’s the key step where Sprite Atlases help. Usually most sprites use the same material but NOT the same texture. The biggest optimization is to try to help the rendering process use the least number of textures. The Atlas as you probably understand combines the textures.

This is optimized for TWO reasons: (1) a large cost for rendering is needing to break up the batches, (2) combining textures saves memory.

That’s why you might see 1-3 Sprite Atlases as being ideal. It varies by scene. And by game. And by how many different materials you use. But ideally, you can get your scene to render in a few batches as possible, which usually means smartly grouping your assets into as few atlases as possible so that typically with what the player is seeing there aren’t so many batches.

This can NEVER be perfect. Don’t try! But it can be better. Some games (isometric) may have a very difficult time, b/c the sprites’ ordering is less predictable. But most other 2D games have some predictable pattern:

  1. draw background elements
  2. draw middle ground elements
  3. draw foreground elements

There may be other stuff interspersed in between or particle effects here and there. Or huge sprites that aren’t worth putting in an atlas because they’re so big as to swamp any gains. But this (1), (2), (3) organization leads us to 3 logical Sprite Atlases.

It depends on the game but this might be per scene or for the whole game (if very small sprites). So it depends a lot on the art.

But the key tool to use in understanding your scene and where you might be able to combine textures is the Frame Debugger. It also works outside the Unity Editor too.

Hope that helps!

1 Like

A couple additional thoughts:

It might be helpful to find a small video on how to interpret the Frame Debugger since maybe it is overwhelming if you haven’t seen it before.

Often the Frame Debugger can provide a reason that is a little cryptic. Search for it.

Like I said before, there are really two main reasons batches break and sprites can’t be batched together: changes to textures and materials (or both). So those are the ones to concentrate on. If there’s some other reason listed, it’s probably from a Particle System or something which is doing stuff that you can’t optimize further.

1 Like

Not saying that docs couldn‘t be better, far from it, but in my 30 years of developing with games I have seen far, far worse documentation. :wink:

Mostly by open source developers.

As to tutorials, let‘s be frank: 90% of those suck big time. They are literally by the same kind of person who wouldn‘t even be able to pullmoff a badly documented open source project. Also, most of them are kids. You‘ll notice the best tutorials are almost exclusively from 30+ aged people, ideally with a professional or senior indie game development background.

Regardless of that the quality of YT tutorials not on Unity‘s channel is not something Unity has much control over.

As to atlases I think you misunderstand the recommendation. One atlas is tze best case scenario. You do not need to make sperate atlases for every scene. Just don‘t make 100+.