[Unity 5.3] Static batching not batch draw calls

Hi,

I've just test Unity 5.3 with empty scene and static batching seem not working correct.
Step :

• Create new project and new scene
• Create Cube + Sphere + Plane
• Disable all light, shadow, quality setting is simple

Result:

• Unity 5.1.2 : SetPass Calls : 2 Draw Calls : 2 Total Batches : 4
• Unity 5.3 : SetPass Calls : 2 Draw Calls : 4 Total Batches : 2

Test with my game build on android, fps drop from 40fps => 15fps
Please check this case!

 

Yes, all object were marked as static

 

dynamic batching appears to be on the fritz for me (OSX)

 

It seems like i missing something.
Release note of Unity 5.1.4 :

• (716978) - Profiler: Fixed Rendering detailed stats. Stats for Draw Calls and Total Batches were previously swapped.

So Draw calls stats is total draw calls before batching! Am I understanding correctly?

 

So any news about it?

 

I tested with some cubes, here is result (Unity 5.2.2 f1):

If i use dynamic batching with 3 cube same material, i have :

• SetPass Calls : 1 | Draw Calls : 2 | Total Batches : 2

If i use static batching with 3 cube same material, i have :

• SetPass Calls : 1 | Draw Calls : 4 | Total Batches : 2

So, static batching not batch draw calls? Can someone explain me about static batching? If it isn't reduce draw calls, what it does?

 

Guys, please, explain what is wrong with static batching in 5.3? Why I have 11 dc with only 4 materials (all is set to mobile\diffuse) if we see that meshes is combined in one?


The same scene in 4.6 (it still the questions why we have 6 dc instead of 4 but it is even lower than in unity 5)
http://ybex.com/index.php?c=start&m=pic&key=hlinlhaghzi3fwc1xpoe7f0pvakmykqqcyzj0ovo

 

Create 2 default particle system prefabs...

Unity 5.2: One batched
Unity 5.3.1p1: None batched

 

I am not complaining as I have tested a rather complicated particle effect on a (relatively new) mobile phone and it runs surprisingly at 60 fps. I just want to confirm one thing: Does the multi-threading use more power for processing? This can be quite sensitive on mobile platforms.

 

Pushing this.
Does this mean if i compile without multiple threaded settings, particle systems will be batched?
Wasn´t there a thread were multithreading lead to crashes?

 

Is there any way we can have an option in the Player settings for "Particle System Batching" that would use the old system when enabled and allow particles to be batched?

Our game has lots of particle systems for weapon effects, foot impacts, and all kinds of stuff. Each particle system usually has only a small number of particles. A lot of effort has been spent ensuring that all particle systems use an atlas and share the same material so they will be able to batch.

This change has drastically increased the number of draw calls, especially since we are developing for VR and the draw calls are doubled. It has impacted us to the point where we would probably have to use a third-party solution for particles going forward.

I'm curious why calculating particles in a thread would exclude them from being batched. Is it calculating *each* particle system in a separate thread? If so, this seems like an overly aggressive optimization that would only be beneficial in certain circumstances with a small number of particle systems that have many particles each.

 

Yes. We are targeting 90Hz on VR and 144Hz for regular screens. In a real-world scenario, I find that as the number of batches increases we essentially get cut off from reaching those higher frame rates.

An increase in batches in one part of the engine means we need to reduce them somewhere else.
Particle effects are an especially bad area for this to happen since the number of particle systems on screen can fluctuate wildly once the action starts, as opposed to predictable things like characters and pieces of environment.

The batching page in the online manual also still says that particles will be batched, so this might be confusing for someone reading.

I don't suppose there is any chance of getting this new particle batching in 5.4? You'd have a new #1 fan.

 

That sounds wonderful, thank you for your efforts!

 

For our Gear VR game this is killing us on performance. Anxiously awaiting updates. It's unlikely we can ship without a fix. I tried going back to legacy particle systems, but they seem to be broken as well .

 

Hi,

Any news on this? Need to release my iOS game in few days. Just want to know when this dynamic batching will be back. Please let me know.

Thanks

 

Thats good to know thank you!

 

Great to hear. Thanks!
I've since moved on to 5.4 beta for the VR features included. Any idea when it might make it into 5.4?

 

Awesome thanks!

 

So even line renderers are batched now? If so awesome!

 

Will lines, trails, and particles cross-pollenate and batch with each other if they meet batching requirements? Just an idea.

 

As far as I concern, the default trail renderer does not batch before 5.3. You can try the free "Melee Weapon Trail" on asset store which is quite old already but still works fine in 5.4.0b10 and batches multiple trails of same material.

 

Batching is happening, but I would appreciate if there is any indication of "saved by batching" in stats like in 5.2.

And thanks for making the default trail renderer batches now.

 

Because 2 or more particle systems with same material only generate 1 call, I assume batching is in effect. I've submitted a report anyway about that "saved by batching" stat.

 

I wanted to say thanks again for this feature, and let you know that it has resolved the performance issues we were experiencing in our game. It seems to reduce to a few draw calls instead of only one, but I assume this is because it is batching the particles per worker thread? In any case, it is reduced enough to not be a concern. Thanks!

 

draw call is still 2 in 5.4 when i created 2 particle system with the same material, and set their 'texture sheet animation'.之前用5.1的时候这样做的话DrawCall是只有1的。draw call is 1 if i do this in 5.1. can somebody tell me why?

 

Can you capture a screen shot of a bare scene (no light) with 2 identical default particle system objects?

你可以像我上面那帖般截张图看看吗？从最简单场景（没有灯光）建两个预设的粒子系统物件。还有你的Unity 5.4是b几？

 

this is the state in 5.4.0b12：（它在5.4.0.B12里是这样的）


and this is the state when i do the same things in 5.1.1：（同样的做法在5.1.1里drawccall只有1）

 

I'm using Unity 5.3.5f1 and getting 0 in saved by batching, the framerate is constantly dropping below 60fps. When I was using 5.2 saved by batching was always between 50 and 70 and the game ran at a solid 60+fps. I was wondering if this issue will be fixed or if I should revert to using Unity 5.2. Thanks

The images show the batching issue in a simple scene with a directional light source.

 

i have 110 cube with default material , i found batching only 3 so i thought there is something with my material when i used my material have same result (3)

After adding my modeling has 3 batches like 1 cube so after add same number of cubes (110) and with same material give me 15 batches :/


so why cube after 110 have only 3 and for my modeling it's 15 ?

 

Each batch has a limit on the amount of vertex data it can hold. Higher poly objects (or more complex shaders) reduces the number of objects that can be combined.

 

1.Are there any guideline about the vertex data limit?
I am on Android and different mesh results different static batch number.

The only difference of the test below is the meshFilter's mesh.
The more the vertices, static batching results more batches( about 7k vertices per batch)
-Camera no distance sort
-all mesh renderer same material
-all static

2.Is there a way to make static batch works on more vertices?
I tried cut vertex data like tangent,normal,uv, but no difference

 

so is there anyway to decrease vertices to make all Objects use save batching ?

 

@karl.jones thanks for replying to the question!
I understand Unity's mesh has a limitation of 65535 vertices per mesh so everything fits into the unsigned 16-bit binary number range, so memory usage is optimal for most case, which is good!

But from the test I posted above, and a new test below, Unity's static batching's batch is not containing vertex number close to 65535. Stat from different test:
1. 10k vertices produce 2 batches (expectation is 1)
2. 70k vertices produce 7 batches (expectation is 2) = average 10k vertices / batch
3. 160k vertices produce 21 batches (expectation is 3) = average 7.6k vertices / batch,
4. 1.0M vertices produce 121 batches(expectation is 16) = average 8.3k vertices / batch

There is 1 batch from glclear, which is ignored.

summary:
Unity Static batching is not reaching its vertex limit(65535) per batch, but rather 7.6k~10k vertices per batch, are there any other limitation other then vertex number?