[Unity 5.3] Static batching not batch draw calls

Unity Engine
1

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!

2

Did you mark the objects as static?

3

Yes, all object were marked as static

4

OK. Could you open the empty project you created, go to the Help menu, and choose ‘Report a Bug’? It’s going to be much more reliable if you can send us the project where you’re seeing this behaviour, instead of us trying to create it and maybe missing steps (like marking the objects as static…) Once you’re done, let me know the bug number and I’ll see if I can look at it.

5

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

1242×92 4.66 KB

6

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?

7

So any news about it?

8

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?

9

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

10

Create 2 default particle system prefabs…

Unity 5.2: One batched
Unity 5.3.1p1: None batched

1310×641 157 KB

1 Like
11

Particle systems are not batched now as we have a multi-threaded particle backend so its not possible. If you do notice a regression in performance between the 2 methods then do please let us know however it should be better overall.

12

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.

13

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?

14

No batching does not work with particle systems any more. The multi threading is done before rendering, its for calculations of each particle’s properties, positions/sizes etc. The rendering happens after this stage so they are 2 seperate things. I am not aware of any crashes related to particle threading. Do you have a link?

15

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.

1 Like
16

Have you actually noticed a regression in fps?

We are prototyping a version that does both threading and batching. This will be in a future release though, not something we will backport as its a substantial feature change.

17

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. :slight_smile:

18

Hard to make any promises about when the feature will be available at this stage. It was only implemented today so it’s going to take some time to test and iron out any issues. We will update the docs though.

19

Hey, I wanted to provide another update on this.

We have been working on reinstating dynamic batching for particle systems, to work with the new multi-threading, and have made good progress. We are currently testing a solution, and assessing the risks with putting the change into various Unity versions.

We will update you again when we have more to report.

7 Likes
20

That sounds wonderful, thank you for your efforts!