Problem in optimization / We must be doing something wrong

Hi everyone!

Well, my team is new to PlayCanvas and we are developing our first proyect. We have a pre-alpha version and wanted to test in some devices.

We’ve checked that it is running too slow, we’re almost sure we are doing something bad, because other proyects seem to be far more complex (for example, Swooop or SeeMore) and they run astonishingly perfect in both mobile devices and PC.

We are checking the ARM tools for optimizing, but I really think we are doing something the wrong way. Would you check our project and give us some feedback? Thank you!

Here’s the link:

Wow, that looks pretty. :smile: I can’t run the PlayCanvas Profiler on a published app (append ?profile=true to the app URL as launched from the Editor to see it) but I did use WebGL Inspector in Chrome to see that you have 15 lights enabled in that scene (!).

That’s a lot of lights and will generate very long, complex fragment shaders that take a long time to execute on the GPU. Do you really need that many? I suggest baking your lighting into lightmaps where possible. You can do this in Max/Maya/Blender.


Thanks you so much for the compliment! :smiley:

In fact, my mistake, I linked a ‘wrong’ version, beforehand, we disconected every light we had, (instead of “SOL”), and it ran much faster (in fact, my partner is working on the lightmaps that you have just suggested) , but it stills runs very slow.

Here you go! :smiley: here is the ‘one light only’ version

And thank you so much for answering in such a short time, this community is great!

So I’m seeing a solid 60FPS with a render time of only 1.65ms:

I wouldn’t say that’s slow. What stats are you seeing? And on what devices/OS/browsers?

One thing to say is that there are 133,507 triangles being submitted per frame. That’s quite a lot for mobile. Perhaps the game is limited by vertex transform, especially since some of the vertices are also skinned.

Yes, in PC, playback has improved so much!

In tablets (Samsung SM-P600), it has also improved a lot:

but in mobile phones it drops to 2 fps (bq AQUARIS E5), (in some others, the browser just breaks away, for example HUAWEI P8 lite) in fact thats our ‘issue’, we want this project to run in as much mobile devices as we can. It is true that in Mobile phones (chrome browser, to be more specific) WebGL still has too many limitations…

I see… in fact, we had previously studied some other projects that worked just fine in mobile (for example, swooop works much better and has 166.000 triangles, according to profiler, and even SeeMore works perfect in ) so we thought that was a proper optimization.

So… to be more specific: we want to optimize this project as much as possible for mobile browsers, can you give us ay tip?

Thank you so much Will, we really appreciate your help.


That’s very odd and makes me think there is something wrong with those two devices specifically. Because those phones were released this year, so performance ought to be good. I just ran your scene on a Nexus 4 (released Nov 2012) and I got reasonable performance:

Can you run non-PlayCanvas WebGL content on the P8? Does the same thing happen in both Firefox and Chrome on the P8? What happens if you go to

In Huawei P8, it is supposed to work, but the cube does not appear:



But then, in firefox:

(Couldn’t even make a proper screenshot, the mobile phone was blocked while loading the page)

We’ve tested in some other HUAWEI, with simmilar results… :’(

In AQUARIS E5, webGL,org runs perfectly, Swoop works ok (11 fps), but Our project only runs at 2fps…
Aquaris E4 is just like Huawei :frowning:

So we’re a bit blocked here. We want to achieve a playback similar to swooop in cell phones, but we are failing somewhere (and it’s more than a coincidence that all out devices around here fail to load… there is something we’re missing, I guess)

We’ve been trying to follow some of the steps you gave here; but we are “lost in data”…

I have seen something weird!

The VRAM texture counter is increasing nonstop! In other projects, we’ve seen it should be static.


  • We had skinned the “dinamic objects” (with one bone only) , it was easier for us to move them with an animation instead of scripting. Do you think we should renounce animation and imitate the movements by scripting? Would this improve performance?

Ignore atm increasing VRAM, it is calculating problem rather actually leaking VRAM :slight_smile: we will fix that soon.

Great, one thing less to care about :stuck_out_tongue:

Sorry if I am being annoying, but I am quite stuck here. Doubts I have atm:

  • Does animation affect playback considerably? The ‘floating’ effect of the yellow objects are animations, should we make the same effect by scripting?
  • Researching a bit around, we’ve seen that some optimization can be done using custom shaders … but we are completely lost there… any suggestion where to start?

It depends, but I don’t think there is big performance issues related to animating using animation or script.
Your bottleneck is more related to different things.
If rendering is bottleneck, then there are few major things to look at:

  1. Number of draw calls (mesh instances in screen) - keep them down. If there are too many of them, then it will get slow due to many webgl commands and a bit of cpu bound for switching states.
  2. Dynamic shadows - those are usually the worst for mobile.
  3. Number of triangles rendered - mobile gpu can sometimes struggle a bit. Especially for many mesh instances with loads of triangles.

Optimization is all about determining where the bottleneck is.

The first thing to do is determine whether you are CPU or GPU bound. If you are GPU bound, are you vertex bound or fragment bound.

You can use either the PlayCanvas Profiler or the Chrome Timeline panel in Dev Tools to see if your app is CPU bound. If not, you’re GPU bound. If you can turn off shadows and maybe point the game camera at something simple to draw like the skybox (but turn camera frustum culling off), and you still get the same framerate, you’re probably vertex bound. Essentially, you’re rendering too many vertices. If the frame rate goes up, then you’re fragment bound. This means the GPU can’t process all the fragment shader instructions for all the pixels on the screen fast enough. Things that reduce the load here are disabling or doing simpler shadows (lower resolution/hard edged), reducing the number of dynamic lights, doing less transparency, turning off anisotropic texture filtering (if you use that) and so on.


Wow. @will and @max, thank you so much for your help. I think we have tons of data to work on now.

We’ll keep you informed on how our project is progressing.

Cheers! :smile:

1 Like