Pixi v4 textures atlases

[Insi]

Hi.
I have a question about texture batching in pixi v4. I'm developing mobile game with great amount of different skins (more than 200).
I have expirience with gl frameworks (starling), and as usually I put textures to different texture atlaces according to scene layers. This approach allows to batch sprites from one atlas layer by layer.
Is it suitable approach for pixi? As I read here Pixi4 automatically batch sprites. But how it detects which one should be batched? Could I disable autobatching and control this process manually?
Which way to split textures to atlases to maximize performance in pixi4? Any restrictions exists for atlases sizes?
Also drawcount property disappeared from renderer in v4. I've add it to sources as i can (before each gl.drawElements call), but it's not very comfortable to add. Hope to see this parameter again in next versions

[xerver]

Quote

Is it suitable approach for pixi?

Yes!

Quote

As I read here Pixi4 automatically batch sprites. But how it detects which one should be batched?

It does it linearly when rendering. Each time it is asked to render something, it checks if it can batch it. If so, it buffers it to be flushed out later. If the new sprite being rendered is too different to be batched, the current batch is flushed and a new one is started. Similarly if it is asked to render something that uses a different renderer (like a Mesh or Rope) it flushes the sprite batch to render the new type.

Quote

Could I disable autobatching and control this process manually?

There isn't an easy way to do this without writing your own renderer, no.

Quote

Which way to split textures to atlaces to maximize performance in pixi4?

Similarly to what you do in starling. A big difference is that pixi v4 also supports multi-texture batching, which means instead of everything having to use the same 1 texture we can actually batch sprites of different textures. How many different textures we can use in a single batch is GPU dependant, but it can be as high as 16 on Desktop. Less texture uploads means more performance, so still pack as much as you can. But, if you can get your 200 skins into ~5 texture atlases then all your sprites should be in one batch (assuming they are drawn sequentially in the scene tree).

Quote

Any restrictions exists for atlases sizes?

Only the GPU texture size restrictions. http://webglstats.com/ scroll to the bottom and see MAX_TEXTURE_SIZE.

[Insi]

Thank you for your answer!

One more easy question - it's is important to remove objects with .visible==false from scene, or they absolutely excluded from render process?

And one more hard question:
So, I use atlases direct from my starling app. Largest of them is 2048x2048, and few atlases 1024x1024-512x512 (there is a places to reduce theirs sizes, but it's not a case).
Usually all works perfectly, but in the game process when ~5-6 atlases involved (and all works perfect), I have a moment when I need to change visible for few elements with textures from largest atlas to true (at this moment I already have few textures from this atlas on screen). All works good in desktop browsers and andoird browsers, but on ios devices page starts lags for a second and then tab crashed and reloaded (both on chrome browser and safari). Reproduced on iPad3, iPhone5, iPhone 6 (Chrome & safari at least). Doesn't reproduced on Desktop (Chrome, Firefox), Mac (Safari), And a lot of android devices.
I've try to remote profile through safari web inspector - but it also closes when page crashed (brilliant solution from Apple! )
Then I've try to split my largest atlases to few lower resolution atlases - in critical moment app starts to lag for 5-10 seconds, and then works ok.
Then I've try pixi3 - all works ok with original atlases (but performance is aloud lower).
Looks like a bug in pixi4, but I don't know how to reproduce it in a simple example.
If your have no ideas, I'll try to make the sample when it possible.

[ivan.popelyshev]

Look into https://pixijs.github.io/docs/PIXI.WebGLPrepare.html  , "renderer.prepare.upload". That will deal with lag, pre-loading stuff into videomemory.

I think crash happens because there's not enough memory sometimes. You can also set baseTexture.source.src="" after you upload atlases, that will remove uploaded atlas from regular memory.

[xerver]

Quote

One more easy question - it's is important to remove objects with .visible==false from scene, or they absolutely excluded from render process?

They are still in the scene tree, but we don't update their matrices or render them. To phrase it another way, when iterating the tree, we still hit those nodes, we just skip over them.

[Insi]

Thank you for advices, I'll try it on monday

UPD: I'm not absolutely ready with experiments, but if I manually load all atlases through Prepare without GC - app crashed more often. So, we are on right way with lack of GPU memory 

Edited September 26, 2016 by Insi

[Insi]

I've just solve my problem at all. Chrome plugin WebGL inspector helps me to debug.
The problem was in my own resource loader, which creates new BaseTexture for each Texture.

But! Even when 80 objecs on scene (and as a result of my mistake 80 1024x1024 atlases loaded to gpu) - performance was good (it's a miracle), until crashed on ~100 atlases  

Now performance is much better. Thank you.