It’s now well understood in the Unity world that having multiple meshes is much worse for performance than a single, large mesh. This suggests that it might be quicker to render a mesh with several discrete regions in place of separate objects as long as the material was the same for each (eg, combine multiple propellers into one child object of an aircraft).
This is OK for static objects but what about animated ones (eg, propellers all rotate separately but not around a common origin)? Animation could be achieved using runtime manipulation of a Mesh object in the object’s Update method, but does this gain you anything?
In other words, how does the overhead of switching meshes on the GPU compare with the overhead of generating mesh geometry on the CPU? I am guessing that you save time with a single mesh when it contains several small, simple “mini-objects” but I don’t really know how fast the GPU is in relation to the CPU.
I’d be grateful if anyone could shed some light on this!
Probably the best solution in combining moving objects would be to turn the combined one into a skinned mesh in your 3D application. So if you have four propellers, then create a skinned mesh with four bone skeleton; with each propeller bound to just one bone.
In Unity just animate the bones, and the skinned mesh will update accordingly.
Thanks for the reply. I am wondering about the general case, though - how does the overhead of switching meshes compare with the overhead of generating them?
I am writing about runtime mesh generation in Unity and I was about to recommend it as a technique that could enhance performance in some cases (ie, combine several similar objects into one and animate with a script). However, it suddenly occurred to me that I don’t know for sure if it really has any benefit!
I am thinking that this technique could, perhaps, improve performance at least on the Mac Mini (with its reasonable CPU but poor GPU). Obviously, I won’t recommend people use it if it doesn’t really work!