koobas.hobune.stream
dynamic draw call batching
I want to improve my understanding of dynamic draw call batching. For my game the situation is as such: I've up to 800 small moving UI objects (images) on the screen, coming (randomly) from 10 prefabs (they only differ in texture). If I keep the textures separate, I got around 400 draw calls in the profiler. So there is some batching depending on texture. But I would expect around 800/10= 80 draw calls, one draw call for each texture, not 400.
The same is true when combining the textures (using same packing tag). Draw calls are greatly reduced, but not to 1, like you might expect it. In the profiler, "(Dynamic Batching) Batched Draw Calls" is always 0, so no info here.
Can someone give me an idea what's going on here?
Thanks so far!
Hi, using Unity 5.6 new feature you may have more information: https://blogs.unity3d.com/2017/04/03/how-to-see-why-your-draw-calls-are-not-batched-in-5-6/
Note that UI batching is somewhat different than mesh/sprites batching, as far as I know.
The article stated that UI- batching is a different process. Would be interesting to know how that works. In the meantime project was finished successfully and rendering proved fast enough for even mobile WebGL.
Thanks for your help.
thank you. I have test frame debugger with Unity 5.6 and for Unity UI the frame debugguer does not show why not batching. It only works for 2D sprite or 3D.
Also I have found that if you do not play then Sprite Packing is not taking in account and batching is not made. We must enter play to really show the dynamic batching of a scene.
Do not forget to set Sprite Packer always enabled in the project settings -> editors
Note that UI batching is somewhat different than mesh/sprites batching, as far as I know.
yupp, that pretty much nailed it. Probably UI draw calls (at least screen space overlay) are batched differently and not part of the dynamic batching system. This batching is pretty efficient it seems and does not show up in the profiler as dynamic batching. In the end this kind of batching was working good enough for me even in my mobile-webGL scenario (max 40 draw calls in UI-only game) and so I didn't dig deeper.
