Static Batching bloats the build size when building in batchmode

Unity Engine
, , ,
1

Hey there, we have a quite annoying problem regarding building in batchmode.

The situation is as follows: We have nightly builds that we run on our build server, with a build server license. Those builds run in batchmode, without an UI.

We are using static batching, which helps a lot with rendering performance. Unfortunately, building in batchmode somehow doubles our build size when compared to building with UI.

As an example:
Our windows build, with static batching enabled, is 3.26 GB when building with UI on the build server and 5.78 GB when building in batchmode on the build server. Both builds use the exact same player settings and both are using the same build script function. If we disable static batching, the difference is no longer as big between the two versions (the difference then is like 100 MB or so), so we guess it is a bug with building a project with static batching in batchmode.

I did some checks to see what exactly boats the build size so much, and I see a huge difference when looking into the built Game_Data folder. This is the folder where it puts sharedassets.assets, resources.assets and the level files. The level files are WAY bigger when building in batchmode. Random example: There’s a file called level25.resS from the batchmode build that is 334 MB. In the build with the UI open, the same file is only 17 MB.

I know that static batching puts the meshes of static assets in scenes together so they can be rendered in one batch, increasing build size but helping with performance. But in both builds, static batching is enabled and in both builds, static batching works. It’s just that the batchmode build packs way too much in those level files and it seems like a bug to me.

Has anyone encountered this before? Why does building in batchmode lead to such a different resulting build with otherwise the same settings?

Here’s the command we’re using to build for windows in batchmode:

&$unityPath -projectPath $repoPath -quit -force-driver-type-warp -batchmode -buildTarget Win64 -executeMethod $buildScript -logFile $logFile | Out-Null

Unity Version is 6000.0.31f1

Any help would be greatly appreciated!

2

I can’t tell you that, but I would recommend (if you haven’t already) to issue the same batchmode command on the local system to see if this is reproducable on any system.

My only hunch is that there may be a script that alters the build (settings) based on whether the project is running in batchmode and perhaps also checks the static batching flag. Maybe this rings a bell.

You could also use one of those Unity build extractor tools so you can export your build’s assets to see exactly what’s in there that shouldn’t be, respectively which asset’s sizes are bloated.

Be sure to report this as a bug with the bug reporter (see Help menu).

3

Thanks for your answer.

There’s nothing in our code that uses Applicaton.isInBatchMode (other than some FMod stuff that is totally unrelated), but it was a good heads up.

It is not related to the build machine either, it also does it on my local computer in batchmode.

I actually downloaded an asset ripper and it shows me the contents of that level25.resS file, and I see many many of those “combined assets” meshes. I know exactly they’re coming from static batching and this is what I expected. It is as if static batching would do weird stuff in batchmode.

I’m definitely going to open a bug report if no one can help me here.

image
image863Ă—789 24 KB

4

Yeah, well, the build in batchmode got 175 of these Combined Mesh assets. The build in normal UI mode has 2 …
It’s definitely that.

image
image888Ă—209 7.89 KB

5

It also happens with Unity’s URP example project.
I just filed a bug report for this (IN-95316).
https://unity3d.atlassian.net/servicedesk/customer/portal/2/IN-95316