Why did my render time increase after lowering the vertex count?

UPDATED: Revised question with new numbers after getting both high vertex objects and low vertex objects to dynamically batch.

I have around 80 animated objects on screen. They are composed of about 13 submeshes that are used to create the animation. Each object used to be 1630 verts and is now 600 verts.

My framerate did not improve at all after optimizing the meshes.

Unity’s internal profiler on iOS reveals this about my game:

BEFORE

cpu-player>    min: 38.2   max: 43.0   avg: 40.2
cpu-ogles-drv> min:  9.0   max: 10.4   avg:  9.4
cpu-present>   min:  0.4   max:  2.8   avg:  1.0
frametime>     min: 48.3   max: 53.6   avg: 50.9
draw-call #>   min:  17    max:  17    avg:  17     | batched:  1106
tris #>        min: 68662  max: 68662  avg: 68662   | batched: 60988
verts #>       min: 51097  max: 51097  avg: 51097   | batched: 45583
player-detail> physx:  6.1 animation:  0.0 culling  0.0 skinning:  0.0 batching: 12.8 render:  9.9 fixed-update-count: 1 .. 1
mono-scripts>  update:  8.8   fixedUpdate:  0.7 coroutines:  0.0 
mono-memory>   used heap: 19111936 allocated heap: 29650944  max number of collections: 0 collection total duration:  0.0

AFTER

cpu-player>    min: 36.7   max: 39.8   avg: 38.5
cpu-ogles-drv> min:  4.6   max:  5.5   avg:  4.8
cpu-present>   min:  0.9   max:  3.8   avg:  1.5
frametime>     min: 42.9   max: 50.0   avg: 45.3
draw-call #>   min:  14    max:  14    avg:  14     | batched:  1232
tris #>        min: 40236  max: 40236  avg: 40236   | batched: 32560
verts #>       min: 35614  max: 35614  avg: 35614   | batched: 30096
player-detail> physx:  0.4 animation:  3.4 culling  0.0 skinning:  0.0 batching:  7.2 render: 15.2 fixed-update-count: 1 .. 1
mono-scripts>  update:  9.3   fixedUpdate:  0.7 coroutines:  0.0 
mono-memory>   used heap: 20541440 allocated heap: 29650944  max number of collections: 0 collection total duration:  0.0

You can see that the render cost is quite high in the After state. In fact, render time is reporting as HIGHER in an environment where draw calls and vertex count were lower! What gives?

What does that render number refer to specifically and how do I improve it? The docs don’t delve into enough detail.

It looks like you just have trouble to correctly interpret your results here. Almost all values have improved after your optimization. Those values are in milli seconds. The lower the frame time the higher the frame rate. The relation between fps and frame time is

fps = 1/frametime;

frametime = 1/fps;

So a frametime of 50ms equals ~20fps (1/0.05 == 20)

If the current result isn’t satisfying, you might just have reached the limit of the used hardware. In the past there was a draw call limit of 2 - 3. On newer hardware it’s around 30 - 50. However it’s always the sum of everything in your app.

So it turns out that the number of mesh renderers was the cause of the high render time.

As I explained at the top of the post, each object is composed of 13 pieces that animate - this means 13 mesh renderers in a game object hierarchy.

Reducing these 13 pieces to 4 pieces significantly improved the render cost (from 15.2 ms in that sample down to around 5 ms). I’m not exactly sure why the more complex meshes handled this better, but it doesn’t really matter. Now that the render cost is down, the batching cost of complex meshes makes them absolutely less performant.

Cutting down the number of individual pieces in an object did mean that the animation fidelity took a hit but seems manageable.

I won’t mark this as the answer however, because it does not explain why the render cost is higher with less complex meshes. I would still really love to know why that makes any kind of sense.