Dynamic Batching Bug #2?

Unity Engine
,
1

Hi folks,

Here’s the situation:

I have an array of 10 quads and 2 materials (5 to a material). They all sit at 0,0,0 and the DrawCalls show as 2 (10 batched). All good.

My script moves the objects to touched areas of the screen. This is where it gets weird, and Dynamic Batching appears to break:

If I move five Material_1 quads, they remained batched. However, if I alternate between moving Material_1 and Material_2, they sometimes leave their batch group and appear as unique Draw Calls.

Because the behaviour is inconsistent, but always testable, I can’t believe it’s a natural limitation of Dynamic Batching (which supports moving batch members).

I’ve tried this with the quads parented to a root, unparented to anything, running a script, without a script…no avail.

Any ideas or revelations before I submit this as a bug?

(Unity iPhone Basic 1.5.1)

Cheers

Update:

Attaching the quads to a rotating empty GameObject, the Draw Calls and Batch count goes up and down. Unity is re-calculating the batching on the fly (note: it only does this after I’ve moved the objects, thus breaking the batching).

I’ve seen several disagreements over whether Unity batches objects within a spacial proximity, but that still shouldn’t be what I’m seeing, since the parent is doing the moving, not the objects themselves (so they’re always in the same proximity).

Would anyone from UT like to share more details on the expected behaviour of Dynamic Batching?

2

Unity batches opaque objects regardless of their spacial proximity.

However it is a little bit different with transparent objects since they have to be sorted by distance (from camera) first - in other words batching and transparent shaders do not come together well.

3

Ah … That explains why I got so many unbatched small objects …

Thanks for the info :roll:

4

Yes indeed, thank’s for the info ReJ.

That would definitely be a good tip for the docs.

So on the same subject - drawing lots of transparent objects (a custom particle emitter/handler if you like), would something like Sprite Manager do the job? (given that standard particle emitters can draw hundreds of particles in 1 draw call, we should be able to too).

5

sprite manager 1 would do that if you use 1 material only

but that does also mean that alpha can bite you if the order isn’t fine

6

Put to a ToDo list :wink:

7

Particle system can help you to achieve better batching, but you can get visual artifacts due to the wrong sorting order - particles are sorted per particle system, not globally. In other words particles with material A will be always render on top of particles with material B.

8

Not sure if it’ll help, but at the end of http://forum.unity3d.com/viewtopic.php?t=38140&start=0&postdays=0&postorder=asc&highlight=&sid=52c060e3db8215c1fbf0befbc1aea3c8 I showed how moving thru different shaders allowed me to have batched transparent objects. It was sort of a guess and check method but eventually worked.

9

This isn’t true, at least in 3.4. Any chance of some updated rules? It’s been a few years without a ruleset. I know you guys don’t want us to focus on batching, but if it weren’t important, there would be no point in showing the stat.

10

The most up to date ruleset to my knowledge contains at the time:

  1. An object must have 900 or less float values (a float value is a component of position, a component of normal, a uv coordinate or whatever), for a position + color + uv vertex that means that something up to 310 vertices would basically batch. In reality though you barely never have that little, you always generate Normal and at worst tangent too, reducing the number significantly.

  2. Not a rule but a fact: anything touched by pixel lights gets redrawn once again → adds one drawcall (per object hit, not per batch!)

  3. Non uniform scaling will disable batching (be it on the object or a parent object of it)

  4. Touching any value on .material or .materials will generate a clone material and thus remove batching

  5. Skinned Renderers don’t batch at all

It has been reconfirmed that transparency has no impact on drawcalls pretty recently (U3.3) where I tried to get some hard infos out of one of the devs on a rather lengthy thread (1. was what I could get out and at least to me its worth gold)

11

Thanks very much!

However, that doesn’t address proximity. If I have two objects (and nothing else in the scene) close together, using one draw call, they use two when moved farther apart. I can upload a package if you don’t believe me.

12

I do believe you, thats why I sought for clarification as I’ve seen that earlier too

But I’m still not sure whats the root behind it as it being real proximity related batching optimizations was denied, although I would definitely expect it on any transparent based shader material, cause they just need to split it by proximity to get an even halfway working depth sorting (as that bases on the objects 0,0,0 point, which with a batch would be just somewhere but edefinitely not in a meaningfull place)

13

try me :wink:

14

In this scene, if you move the cyan cube past 400 in the Z axis, the two cubes batch. However, the same doesn’t happen if you move the magenta cube.

That’s only in the Editor, though; I built to the device, and it seems that they always batch (there’s a script on the cyan cube to move it back and forth when you touch the screen). That’s what’s important, but it’s not helpful to have the preview stats be incorrect (and isn’t batching supposed to work for standalone/web builds now anyway?).

What’s especially not helpful, is that the numbers are different across different machines/OS’s. So, for example, a teammate and I were looking at the same scene the other day, and whereas he saw somewhere around 200 draw calls, I was seeing less than a third of that. Differences like that, I don’t consider trivial, and are not helpful for assessing what needs to be worked on.

653802–23333–$Batching Proximity Test.unitypackage (60 KB)

15

hm, works perfectly fine for me 8-
cubes are batching from beginning and always (until i move one from view)
well, there is something fishy [potentially]

16

Attached is what I’m seeing. The weird part is, they’re batching when farther away, today, and when I tried the other day, it was the opposite. I tried to replicate that scene from that other day, where two objects were at about the same Z-depth, but moved in X and Y, and only batched when near each other, but didn’t have success, today.

Another thing is, I’ve got plenty of meshes that are over 900 floating point values, but still dynamically batch. On the other hand, I can make meshes that batch, or don’t, when, for example, I change the normals import setting, or change how many UV sets they have, pushing the sum below or above 900. Lots of inconsistency. I’m not so concerned, for these larger meshes, whether or not they batch, but the vert counts for objects on my biggest current project were planned out with batching in mind, so when inconsistency occurs for the smaller meshes, and it does, at least according to Editor stats, it can be disconcerting.

653983–23343–$Aug 8, 2011 3-16 PM.zip (972 KB)

17

So the solution is not to worry about it? But this definitely seems to be a legitimate bug. I can’t image why it has all of a sudden stopped working. I never had this problem in unity 3.3, but in 3.4, I have this problem often.

18

what problem?

Until i see repro i prefer to call it “something wrong on your end”

19

Alexey,

Could you please tell us how dynamic batching of transparent materials/shaders is supposed to work… or what the rules are? Because I’m able to verify, in 3.4, that two or more instances of the same transparent materials add a draw call per instance. In the editor and on the iPhone.

Thanks

20

the same way. Apart from the fact that transparent is always sorted by depth so if you have somethin in between - no batching