Combining Mesh at Runtime via Script causes temporary FPS drop

In the game that I am making, a common task is to create new meshes to add to a pre-determined object. (The code for how I am currently doing this is included at the bottom of this post).

I create meshes by calculating the vertexes at 8 points on in the game, and generating a new temporary object mesh between those points (Parallelogram), then I create a new temporary empty gameObject, combine the master mesh with the temporary mesh in that object, then finally save the new temporary mesh back into the master mesh.

Obviously this is an extremely memory process, and when I test the game my FPS averages between 250 and 300, which drops to 25 while making objects (1 per frame, yes it is necessary), then immediately returns to its previous higher number when I stop creating. My question is: is there a more optimized process for creating meshes and adding them to an object?

//temp1 is the First Temporary Mesh (in which I set vertices), temp2 is the second, and Master is the gameObject I am attatching them to.
var meshFilters = temp1.GetComponent(MeshFilter);
var combine : CombineInstance[] = new CombineInstance[2];
combine[0].mesh = meshFilters.sharedMesh;
combine[0].transform = meshFilters.transform.localToWorldMatrix;
var meshFilters2 = GameObject.Find("Master").GetComponent(MeshFilter);
combine[1].mesh = meshFilters2.sharedMesh;
combine[1].transform = meshFilters2.transform.localToWorldMatrix;
var temp2 : Mesh = new Mesh();
temp2.CombineMeshes(combine, true, true);
GameObject.Find("Master").GetComponent(MeshFilter).mesh = temp2;
GameObject.Find("Master").GetComponent(MeshFilter).mesh.RecalculateNormals();
GameObject.Find("Master").GetComponent(MeshFilter).mesh.RecalculateBounds();
GameObject.Find("Master").GetComponent(MeshFilter).mesh.Optimize();
GameObject.Find("Master").GetComponent(MeshCollider).mesh = GameObject.Find("Master").GetComponent(MeshFilter).mesh;
Destroy(temp1);

Thank you all very much for tolerating my wordiness. I just thought more information would be better than less.

Also, I have gone through it, by just creating thousands of gameObjects that each have a meshRenderer and a meshCollider on them with 8 vertices, (ie. my code but without combining them) my RrameRate hardly drops until the obvious memory issues with that catch up to me a few minutes later. Again, Thanks!

1 Answer

1

I don't have your project so I can't really pinpoint what is consuming most resources here. Some obvious ones are you're finding GameObjects several times, and looking up components several times. I rewrote your code (I hope it is still the same) to fix some obvious (potential) slowdowns, and renamed some variables to better reflect their purpose.

// Cache the results.
var master : GameObject = GameObject.Find("Master");
var masterFilter : MeshFilter = master.GetComponent(MeshFilter);
var masterCollider : MeshColider = master.GetComponent(MeshCollider);

var oldFilter = temp1.GetComponent(MeshFilter);

var combine : CombineInstance[] = new CombineInstance[2];

combine[0].mesh = oldFilter.sharedMesh;
combine[0].transform = oldFilter.transform.localToWorldMatrix;

combine[1].mesh = masterFilter.sharedMesh;
combine[1].transform = masterFilter.transform.localToWorldMatrix;

var newMesh : Mesh = new Mesh();

newMesh.CombineMeshes(combine, true, true);
newMesh.RecalculateNormals();
newMesh.RecalculateBounds();
newMesh.Optimize();

masterFilter.mesh = newMesh;
masterCollider.mesh = newMesh; // Potential bottleneck?

Destroy(temp1);

I know since before when I was working on some voxel system in Unity that assigning a mesh to a MeshCollider is a real pain performance wise. You'd have to profile your game to see exactly what calls here are too expensive. Also, you might sometimes be better off without Optimize() since it is quite heavy to perform.

This operation might take a while but will make the geometry displayed be faster. For example it generates triangle strips out of the triangles. You should use it if you generate a mesh from scratch procedurally and you want to trade better runtime performance against higher load time.

With other words, it's not always a good idea to call it while the game is running.

Also, are you sure you need to recalculate normals on the combined mesh? Are you sure you need to recalculate bounds? Can you try without, does it yield any errors?

call the generic version of those 3 getcomponent calls. boxing and unboxing ain't free!

Thankyou very much for the quick reply, and after doing some tests with your code here are my results. RecalculateNormals() is not needed, RecalculateBounds() is inorder for it to display, and Optimize() is not needed. I went on to change around the order of calls so the RecalculateBounds() is after the masterFilter is set, and then the masterCollider command became "masterCollider.sharedMesh = masterFilter.sharedMesh;" With your script and the slight tweaks I mentioned (discovered by trial and error) the Frame Rate now only drops to 35 FPS...Any other tips?

If possible, use smaller meshes. Maybe you don't need to combine every mesh, you might do with a limit on how large meshes are. If they become too large (and too expensive to combine), create a new GameObject or renderer or collider that you parent to the object.

@harmless, actually, using GetComponent.<Collider>() is slower than GetComponent(Collider). Try it yourself. My measurements show about 33% slower. I did two loops with 1000000 calls to GetComponent, both variants. My readings are approx 200ms for the generic one and 150ms for the nongeneric one