Static Batching vs. StaticBatchingUtility vs. Mesh.Combine - when to use which?

Unity Engine
1

I’m looking for some advice in which cases to use which tool to reduce the amount of draw calls in a rendered scene. I know the basics, but I’d like to dig deeper into the topic, beyond what the documentation provides.

Sources (Unity 5.5)

Static Batching vs. StaticBatchingUtility
Does the utility method do the same thing on GameObjects as settings the Batching Static flag in the inspector? As far as I understand, I can let Unity do everything at build time, but when I have procedurally generated meshes, I can use the utility call to perform batching when my mesh is generated at runtime. Is there any other difference or something to be aware of? Would I have any reason to use StaticBatchingUtility at edit time?

Static Batching vs. manual Mesh.Combine
Given that all meshes already exist at build time, what reasons could I have to prefer manual batching and what downsides would it have? Generally, I would only create a custom batching tool, if it could be run during the build process, so it wouldn’t interfere with level design (just like Unity’s batching works).

  • Static Batching requires the same material on renderers within a batch. Does this mean, that multi-material renderers will not be batched at all or does Unity take apart the individual submeshes?
  • Creating custom texture atlasses appears to be a solution to provide more batching-potential for any solution. Say, I have created a tool which creates a well-suited compromise of shared materials vs potential memory overhead - would the be any performance difference between combining the meshes manually at edit time vs using the static editor flags?
  • Shadow casters are batched differently than regular geometry. Does this mean, Unity handles everything for me or can I achieve better results by manually separating drawn geometry from shadows? This would mean, I’d have to create a copy of each mesh and then batch both groups separately. In the end, I would be able to create larger groups for shadow casters, because all opaque materials can share the same. Is this something Unity already takes advantage of?
  • Static Batching already handles occlusion and frustum culling. Manual batches would need to be separated into smaller, local chunks, to provide a similar effect. Is this generally desired or could I possibly want giant shadow batches and smaller geometry chunks in combination to get even more out of it?
  • Does it make sense to batch physics mesh colliders together? In theory it would be possible to combine all mesh colliders into a single giant mesh (split it up into groups of 64k). Would it be more efficient to send this big chunk over to physics processing or could it even mean another bottle neck? As far as I know, all static colliders aka “the physics world” need to be build as one big thing anyway, which is why it’s so bad to move a static collider, as it means the whole world needs to be recalculated.

Summary
I’m trying to get a feeling for when it might make sense to create a custom batching solution vs using Unity’s builtin tools; not only from a performance perspective, but also workflow.

Of course, the best thing to do would be to profile the final game and decide upon each permutation. I do honor my own testing, but I believe there a understandable reasons, why it’s not always possible to judge by experiment: When writing a tool for future projects and others to use, I don’t know their specific requirements, but I might want to provide them with a custom solution. Often, measurements are not precise enough so that they can be isolated down to the real cause, e.g. reducing the number of draw calls vs increasing memory might make sense in one level on a specific platform, but in different levels and other platforms and might not work. Add to this a few dozen possible combinations of settings and it becomes very difficult to judge. How do you guys deal with these issues? Just with regular profiling concrete scenes and changes stuff until it gets better or do you create automated tests, which record data and then compare?

PS, I’d be happy to post more of my own findings, if others are interested, hence the elaborated post. :wink:

1 Like
2

About the physics collider thing, I know from experience that extremely broken up meshes are bad. You discover this when it comes to SketchUp3D models, which often have thousands of polygons broken up into sections with a few polygons. If you don’t merge the meshes and just import them straight, you can have insane performance problems. Breaking up a mesh lets you have more sections that can be culled from raycasts, but it also means more time put into culling calculations. The same problem happens with camera culling for very broken up meshes. Obviously you shouldn’t be using Sketchup3d models for games but it will let you get pretty specific models for free that aren’t available free anywhere else.

I personally only break up my larger models like buildings and even then it’s normally just a few sections. I set them as static and the engine culls off sections of the building, saving rendering time. In the case of mobile games I also use blender to “decimate” models by removing faces that show detail that is unnecessary.

1 Like
3

Excellent questions!
Just for the static batching case I am wondering if there is a benefit to combining static geometry in the modeling software or if Unity’s batching is sufficient. In the later case I would still have a large number of GameObjects in the hierarchy, but aside from that is there any other performance impact?

1 Like
4

So I’m not a fan of the poll choices… I’d say it’s a combination of 1 and 2. It’s not impossible, it doesn’t require science, just some thought.

So… for one, yes, USE STATIC BATCHING. May you do it automatically or manually, use it, it gives great performance gains.

But if you should use it manually or not… well. I’ll say this, we recently had some issues with performance as it goes with our static batching and lighting.

Our current game is built all out of tilesets that are put together procedurally through code. This means a room is technically multiple models:

887×752 622 KB

This was costing a lot of draw cycles, so of course needed to be statically batched.

We then started adding lots of lights, but this would cause lots of slow down on lower end machines. So we reduced the number of lights that lit a pixel with forward rendering:
Project Settings->QualitySettings->Pixel Light Count

Down side was that because our tiles were technically different objects we got this as a result, even when statically batched:

Note the shadow difference from wall segement to wall segment. Because the wall on the left has multiple lights near it, it gets fully lit. But the next wall tile is picking up lights on the other side of the room and appears darker.

So we needed to weld the verts of these tiles together instead. So I slapped together this script:

using UnityEngine;
using System.Collections.Generic;

using com.spacepuppy;
using com.spacepuppy.Collections;

using com.mansion;

[Infobox("Does not work on static meshes, make sure all meshes you want included are not flagged as 'batched' in their static settings.")]
public class MeshMerger : MonoBehaviour
{

    public enum AlgorithmType
    {
        Disable = -1,
        Unity = 0,
        OldSchool = 1
    }

    public AlgorithmType Algorithm;

    private void Start()
    {
        switch(this.Algorithm)
        {
            case AlgorithmType.Unity:
                this.MergeUnityAPI();
                break;
            case AlgorithmType.OldSchool:
                this.MergeUsingOldschool();
                break;
        }
    }
  
    private void MergeUnityAPI()
    {
        var table = new Dictionary<Material, HashSet<MeshFilter>>(ObjectInstanceIDEqualityComparer<Material>.Default);
        foreach (var f in this.GetComponentsInChildren<MeshFilter>())
        {
            if (f.HasTag(Constants.TAG_IGNOREMESHMERGER)) continue;

            var mesh = f.sharedMesh;
            if (mesh.GetInstanceID() < 0) continue; //this means it's a combined mesh

            var renderer = f.GetComponent<Renderer>();
            if (renderer == null) continue;

            var mat = renderer.sharedMaterial;
            HashSet<MeshFilter> grp;
            if (!table.TryGetValue(mat, out grp))
            {
                grp = new HashSet<MeshFilter>();
                table.Add(mat, grp);
            }

            grp.Add(f);
        }

        foreach (var pair in table)
        {
            var mat = pair.Key;
            var grp = pair.Value;
            var combine = new CombineInstance[grp.Count];
            var worldToLocal = this.transform.worldToLocalMatrix;

            int i = 0;
            foreach (var f in grp)
            {
                combine[i].mesh = f.sharedMesh;
                combine[i].transform = worldToLocal * f.transform.localToWorldMatrix;
                f.gameObject.SetActive(false);
                i++;
            }

            // hook up the mesh renderer
            var go = new GameObject("Mesh*" + mat.name);
            go.transform.parent = this.transform;
            go.transform.localPosition = Vector3.zero;
            go.transform.localRotation = Quaternion.identity;
            go.transform.localScale = Vector3.one;

            var me = new Mesh();
            go.AddComponent<MeshFilter>().sharedMesh = me;
            me.CombineMeshes(combine, true, true);
            go.AddComponent<MeshRenderer>().sharedMaterial = mat;
        }

        //cleanup
        table.Clear();
        table = null;
        System.GC.Collect();
    }




    private void MergeUsingOldschool()
    {
        var table = new Dictionary<Material, Group>(ObjectInstanceIDEqualityComparer<Material>.Default);
        foreach(var f in this.GetComponentsInChildren<MeshFilter>())
        {
            var mesh = f.sharedMesh;
            if (mesh.GetInstanceID() < 0) continue; //this means it's a combined mesh

            var renderer = f.GetComponent<Renderer>();
            if (renderer == null) continue;
          

            var mat = renderer.sharedMaterial;
            Group grp;
            if(!table.TryGetValue(mat, out grp))
            {
                grp = new Group();
                grp.material = mat;
                table.Add(mat, grp);
            }

            grp.filters.Add(f);

            grp.vertCount += mesh.vertices.Length;
            grp.normCount += mesh.normals.Length;
            grp.triCount += mesh.triangles.Length;
            grp.uvCount += mesh.uv.Length;
        }

        foreach(var grp in table.Values)
        {
            // allocate arrays
            Vector3[] verts = new Vector3[grp.vertCount];
            Vector3[] norms = new Vector3[grp.normCount];
            Matrix4x4[] bindPoses = new Matrix4x4[grp.filters.Count];
            BoneWeight[] weights = new BoneWeight[grp.vertCount];
            int[] tris = new int[grp.triCount];
            Vector2[] uvs = new Vector2[grp.uvCount];

            int vertOffset = 0;
            int normOffset = 0;
            int triOffset = 0;
            int uvOffset = 0;
            int meshOffset = 0;
            var worldToLocal = this.transform.worldToLocalMatrix;

            // merge the meshes and set up bones
            foreach (MeshFilter mf in grp.filters)
            {
                var mesh = mf.sharedMesh;

                foreach (int i in mesh.triangles)
                    tris[triOffset++] = i + vertOffset;
              
                bindPoses[meshOffset] = Matrix4x4.identity;

                var matrix = worldToLocal * mf.transform.localToWorldMatrix;

                foreach (Vector3 v in mesh.vertices)
                {
                    weights[vertOffset].weight0 = 1.0f;
                    weights[vertOffset].boneIndex0 = meshOffset;
                    verts[vertOffset++] = matrix.MultiplyPoint(v);
                }

                foreach (Vector3 n in mesh.normals)
                    norms[normOffset++] = matrix.MultiplyVector(n);

                foreach (Vector2 uv in mesh.uv)
                    uvs[uvOffset++] = uv;

                meshOffset++;

                MeshRenderer mr = mf.GetComponent<MeshRenderer>();
                if (mr != null)
                    mr.enabled = false;
            }

            // hook up the mesh
            Mesh me = new Mesh();
            me.name = gameObject.name;
            me.vertices = verts;
            me.normals = norms;
            me.boneWeights = weights;
            me.uv = uvs;
            me.triangles = tris;
            me.bindposes = bindPoses;

            // hook up the mesh renderer
            var go = new GameObject("Mesh*" + grp.material.name);
            go.transform.parent = this.transform;
            go.transform.localPosition = Vector3.zero;
            go.transform.localRotation = Quaternion.identity;
            go.transform.localScale = Vector3.one;

            go.AddComponent<MeshFilter>().sharedMesh = me;
            go.AddComponent<MeshRenderer>().sharedMaterial = grp.material;
        }

        //cleanup
        table.Clear();
        table = null;
        System.GC.Collect();
    }

    private class Group
    {
        public Material material;
        public HashSet<MeshFilter> filters = new HashSet<MeshFilter>();

        public int vertCount = 0;
        public int normCount = 0;
        public int triCount = 0;
        public int uvCount = 0;
    }

}

Well really… my artist took it upon himself to go out and find a script to do it for free on the web. And it was glitchy as all hell because it accounted only for one material and deleted all other meshes (cause that’s how you do it!), so he asked me to make it work right… and I did. But then was like, wait, unity has this utility built in to do this… so I wrote a method using that instead, but kept the old algorithm so that my artist could play with both and pick which he preferred.

Anyways… no longer has the problem:

1005×778 397 KB

(note - screencaps are from a debug room that I toss junk into to test if it works… hence junk like a weird floating sphere, and a bathroom sink just in the middle of nowhere)

My point being that we had to use the manual technique in this situation because the standard static batching that unity does when you tag it doesn’t weld the models together.

So sometimes you just have to be aware of these situations where even though static batching is giving you that performance oomph, you might have to do a little extra because you visually need more.

4 Likes