Mesh.CreateVBO Frame Rate Spikes

[pbaker]

Hi,

I'm getting frame rate spikes in some areas and solidly bad frame rate in others due to Mesh.CreateVBO (according to the Unity profiler) on iPad 1, similar to:
http://forum.unity3d.com/threads/118723-Huge-performance-loss-in-Mesh.CreateVBO-for-dynamic-meshes-IOS
Any ideas on how to solve this when using 2D Toolkit?

I'm using Unity 3.5.2 and 2D Toolkit 1.57 final + patch 1 (thinking I might upgrade to see if that helps).
Thanks

Paul

[unikronsoftware]

How many sprites / dynamic meshes are you using? What are you doing with the sprites? Any other dynamic meshes outside 2D Toolkit? The more info you can give me here the better it'll be to track this down. If you'd like to move to the private support / email that'll be fine.

I've investigated something like that in the past, and while ping-ponging between meshes does help, it isn't the best solution on all other platforms - there are other problems which happen on certain Android devices which become significantly worse when doing that. Ultimately its a problem the Unity folk need to sort out, but I'll be happy to provide some form of a workaround.

[pbaker]

Typical scenes have I have 6-12 static sprite batches + ~12 sprites with ~5 animated sprites from two different sprite collections. I don't have any dynamic meshes outside of 2D Toolkit. It seems to happen whenever there is only one animated sprite on screen per sprite collection. Also happens when I update the text in a tk2dTextMesh, and in a scene with just a tk2dTextMesh, updating the text gives a 2.54ms Mesh.CreateVBO spike.

[unikronsoftware]

This is very weird indeed. I was profiling on iPhone4 just now, and while perf has dropped slightly from earlier releases, I was still getting 60fps with around 70 animated sprites animating simultaneously. Moved to email to further investigate this.

[arkanoid87]

Hi,

I'm facing the same problem:

when displaying one or more tk2dTextMesh or even a single large one (500 or more characters) I have per-frame Mesh.CreateVBO spikes on iPad1 that cause stuttering and eventually crash (see attached screenshot). The problem seems not visible while profiling the application inside the editor.

Actually I'm working with Unity 3.5.2f2 and 2D Toolkit Version 1.7 final + patch 2.

Upgrading is not never my favorite choice in the middle of a production, so I'd like to ask if I could solve the problem by upgrading Unity or TK2D (any  preferred version?).
Otherwise I'd like to ask any possible solution for my problem: I have to display kind of in-game manual, so I need a lot of static text.

thanks

[unikronsoftware]

Ok. The answer to this isn't straightforward I'm afraid.

First we need to identify the problem. There is more than one potential problem here.

1. Do you need OpenGL ES 2? If you don't use shaders, switching to GLES1.1 will magically fix the problem. There'll still be an overhead of updating the mesh (and the managed -> unmanaged switch, etc, but it shouldn't be as high as this).

2. In Unity 3.5.2, you can work around this by double buffering the mesh. This increases the script update cost a fair bit, but almost entirely eliminates the CreateVBO issue. I have a patched for 1.7 + patch2, should you wish to try this. Drop me an email if you do. Its not destructive, and shouldn't cause any issues. You can always revert should you find the tradeof isn't suitable for you.

3. In Unity 3.5.3, I think the CreateVBO overhead is a LOT lower, but I haven't properly profiled it to make sure. Well I haven't seen the issue with my test which was slowing down significantly in 3.5.2 (on iPhone4 specifically), but there are so many other devices around and its hard to predict what Unity does with a particular device.

But the solution could be simpler. What do you need with this in-game manual? Do you update the text every frame? If not, you could just precache the meshes (all of em) and don't update them live - that way, you sidestep this entirely.

I can't publicly release any fix, as Unity really need to fix the fundemental problem - that being the inconsistent behaviour on different modes / devices.

Hope that helps.

[dotbunny]

3.5.5f2 has horrific spikes still on Mesh.CreateVBO ... and for some reason i cant compile in armv6 ;(

[unikronsoftware]

You can switch to GLES1.1 without compiling in arm6, just
#define USE_OPENGLES20_IF_AVAILABLE 0
in AppController.mm

[unikronsoftware]

Update:
@dotbunny tried GLES11 and that made things fast again.

There must be certain combinations which make trigger this in GLES2, as I was unable to reproduce this in my test with around 120 animated sprites, all animating at the same time. Anyone else having similar issues, please post.

[theHost]

I have the same problem for my 2D side-scrolling game. I am using 2D Toolkit for my backgrounds and animated sprites. This is a mobile game targeting iOS and Android, though focusing on iOS first.

On my iPhone 4, I get CreateVBO spikes that range from 20 to 40 ms, resulting in frame rates from 20 to 40 fps. I am aiming for 60 fps. I tried with arm6 (ES 1.1) and the frame rate held steady at 57+fps, but definitely I need ES 2.0 for the shaders so this isn't a viable solution for me.

Do you have any suggestions? Are you able to send me your modified code so that I can try it out on my end? I am close to finishing this project (eta of release in 2 weeks), so this is a high priority item for me as it's the last thing left to do.

Side note: on iPad 2 and 3, I get a solid 60 fps with everything on screen. God I wish I can just target those.

[unikronsoftware]

Hi, the code changes should get rid of the CreateVBO spikes completely, but script cost does increase a bit. No surprise spikes though. I'll merge the patch with the latest version (they were targetting an older version), and email a new patch to you, probably sometime this weekend.

The situation is a fair bit more nasty than is immediately obvious. The patch double buffers the meshes, meaning the mesh data has to be fully updated on animations instead of incrementally as on the other versions. There are a few other catches and gotchas though - mainly to do with sprite visiblity. Unity will switch to a different codepath (non-batched) when there is only one sprite of a particular sprite collection is visible, and this changes performance characteristics yet again! Anyway try this patch when you get it, and we'll take it from there.

[theHost]

Ok sounds good.

My setup is such that I have 2 kinds of sprites being used: level (static) sprites, and animated enemy sprites. It seems most of the CreateVBO time is taken up by the level data than the enemy sprites, since removing those completely gets me a nice 60 fps. Also I made the large background use the tk2d/SolidVertexColor shader which actually improved the performance quite a bit. Unfortunately I can't make the rest of the level data use that same shader since they require the alpha. I am wondering if there are any other shaders I can use for those.

[unikronsoftware]

Hmm... this is likely to be something completely different to the one the patch fixes. The patch fixes an issue with Unity 3.5.2 where updating a mesh dynamically caused spikes. The level data is unlikely to cause this, as you say it happens with static sprites. I need some more info about your level data to work out what is going on, but my guess (which could be totally off base) is -

You have large chunks in there, where at some points only one sprite from a collection is visible, or they have different transform.localScales on them in such a way that only one of batchable sprite (batched meshes need to have the same transform.localScale) is visible. At this point Unity switches from the batched render path to the regular render path. I have seen spikes occur when this happens.

Questions:

1. Do you use localScale? Using the scale parameter on the sprite is fine, its just the normal scale on the transform component which breaks things here.
2. Are there cases when the above occur? Are your sprites big/long enough that only one from a collection is visible at times?
3. Create 2 duplicates of all your background sprites and simply push them back in the Z (i.e. draw overlapping sprites at all times, so 2 copies will always be visible). I don't suggest doing this long term, but will be a good diagnostic.

Let me know and hopefully we'll be able to track this down further.

p.s. I've emailed this reply. Best get this sorted as soon as possible - I'll be away at Unite next week.

[matt]

I'm also seeing a drop of 20fps due to CreateVBO.  Any news on the double buffer fix being released?  I've been pulling my hair out trying to find a solution.

[unikronsoftware]

Drop me an email and I'll send it your way.  (support@unikronsoftware.com)

The Unity guys said this is likely to be a bug when I spoke to them at Unite, but I haven't got around to creating a repro case for them. If you have good, simple test case where this happens, I'd like to hear from you - it could save me loads of time building one for the Unity guys.