Dynamic batching depends on order of Instantiation. Bug?

I'd like a second opinion on whether this is a bug. I've posted a short video showing my experiences with the frame debugger. I've discovered that the order at which objects are created breaks batching, and I don't see any mention of this in the docs, which is why I'm curious if it's a bug or expected behavior?

http://docs.unity3d.com/Manual/DrawCallBatching.html

I show in this video that creating 1000 of SpriteA and then 1000 of SpriteB results in 2 draw calls. If I alternate between creating SpriteA's and SpriteB's 1000 times, it results in 2000 draw calls.

https://goo.gl/photos/wPVjZL91ZcPuWe5x9

I submitted this to Unity several weeks ago but haven't gotten a response yet.

 

I did some additional tests and tried sorting the objects in different ways in the hierarchy. It makes no difference.

 

I am a little confused as to why I haven't gotten a single response from anyone. If this is a bug, wouldn't it be a huge deal for everyone? Am I misunderstanding how batching is supposed to work?

 

Draw calls won't batch well (or will be first come first served) unless there's depth to sort them by, because they're using different materials.

As it is transparent queue, it has to batch by sprite transform depth or sorting is screwed visually. This is because transparent does not write depth, so if batched it becomes one mesh, which means you would have rendering errors if Unity did not sort the sprites by origin. Therefore they're batched by depth as well, which explains what you see.

move one set of sprites behind the other and you should see that set will batch with itself properly as it doesn't need to split the batch because a different material/sprite was in between.

 

Did you watch the video I posted? Please do, It's only a minute and a half long. What you said might be true, but that wouldn't explain what I'm seeing in the video.

All I'm doing is changing the order in which the sprites are created and Unity goes from 1 draw call per sprite texture rendered to 1 draw call per sprite created, regardless of what is being rendered. The positions are the same on all the sprites created, and all of the sprites I'm rendering are at the same depth in both scenes.

In other words:

• If you create sprites in this order - (A, B, A, B .. ) where N = count of sprites created, then your draw calls will always be N.
• If you create sprites in this order - (A, A, A, A ... B, B, B, B) regardless of the count, dynamic batching works and your draw call count will be 2.

So what I'm asking is, is there an additional requirement for dynamic batching to work? And that requirement is all sprites with the same image on them have to be created in order? And you can't go back and forth between creating different sprites?

Seems kinda weird, and it's not listed in that page as a requirement.

 

I did verify that if I take all 1,000 of one of the sprite groups and just change the z position to be different from the other sprite group, it drops from 2,000 draw calls back to 2.

Thanks for the suggestion, it fixes this particular situation.

However, I also did a test where I do the same exact thing in the video, but only using sprites with no transparency and I get the same results. So, transparency has no factor in this issue.

 

This is still happening for me in 5.3.2. I still haven't gotten any reply on my bug ticket.

 

In 5.3.4 still exist problem. Looks like this bug have low priority if it at all accepted as bug.

 

Thanks for telling me how to fix this, this bug also happen when i setActive two type of 2dprite rotate (one by one)

 

still exist in unity2018
Dynamic batching does not sort objects!

 

Can I achieve front to back rendering in dynamic batching like without batching? (all have the same mesh and materials (opaque))

 

this can be fixed as crutch - if each material set to own queue (like car body1 = geometry+1, car body2 = geometry+2, wheels = geometry+3), can be solved for small material count projects.