Hi
I need to include playcanvas content into showpad. Showpad is a sales acceleration platform with iOS apps but also accessible via a web app.
I uploaded a 60mb file and it seems to work just fine in the web app. But when I launch it on my iphone 6, the app crashes.
If anyone have tried this before, I’d love to hear some caveats.
How many and how large are the textures being used in the project? It’s very possible that you are running out of VRAM. The physics engine is known to potentially cause some issues. It’s a bit difficult to tell without seeing the project.
Ok, I see. The phone probably have less Vram than my laptop then I take it?
How can I troubleshoot or even monitor the performance of this in terms of Vram? So I know where to start compressing and so on.
I tried the Launch profiler, and under VRAM this is what’s showing:
Is that a lot? I have nothing to compare with. These are my first endeavors into game dev/ realtime 3D.
I managed to get it down to this just by making sure I ticked every compression box for all of them. I guess it seems like my biggest ones are the ambient occlusion textures which are 4096x4096px. They’re eating a lot of VRAM.
And does it still crash on mobile?
Haven’t tried uploading that one to Showpad yet, but I’m trying the published version in safari on my iphone and that one hasn’t crashed yet.
However, I’ve only yet added an AO map on one of my meshes, and I have a lot more to do, so I’m still worried I’m going to have to do something more drastic.
Well, just to be clear, 4096x4096 is a ridiculously high resolution texture. 
1024x1024 may well be sufficient for your purposes (which is obviously occupying 1 sixteenth of the VRAM…or 2048x2048 at the most).
Good to know. I have no ballpark idea about this really. I just though it was hard to render the AO of this object onto a texture smaller than that and still get a decent resolution. But since these 3D parts are from a CAD package and not modeled for realtime 3D, perhaps there is still a lot to do in terms of optimizing to utilize the UV space more effectivly…
Looking at that unwrap, it looks extremely not efficient, with tons of tiny object wasting space with padding around UV blocks.
Perhaps figuring out better unwrap technique - will save a lot of texel space, and will allow to make that texture smaller.
AO is smooth - so usually does not need to be that large, as there is no much details to preserve.
You can combine different black&white textures into single texture using RGB channels per texture. That will save loads of VRAM.
Then consider resolution: 2k really is rarely ever needed, especially on mobile.
If you do get models from CAD, they are high-poly indeed. Most important is to get good unwraps for them, and make them reasonable polycount for real-time.
Texture Compression is another feature soon will be available to public. Right now it is available to all paying customers. And compressed textures occupy 6 times less VRAM.
Thanks a lot for your insight!
So I’ll have to put a lot more work on optimizing the polygon count I guess, but also UV unwrap.
What is a too high polycount for an app like this? What’s a decent range? It’s a model viewer with feature hotspots, should run on iphone.
Here are some notes on optimization http://developer.playcanvas.com/en/user-manual/optimization/guidelines/
Good question. Maybe check out some other PlayCanvas apps on mobile to get a feel for what’s possible. Let’s take the BMW i8 app. That has about 180,000 triangles. That works pretty well on mobile devices, although it starts to struggle on iPhone 4S. I’d say that’s a fairly reasonable number.
You also have to keep in mind that GPU performance is only one consideration. Loading time is another. The more vertices/triangles in your models, the longer it will take to download them. You really want your users to get into your content as soon as humanly possible, so do be conservative with how your build your scenes.
Good to know! I’m above 1 million right now 
Loading time won’t be as much of a problem though since my app will run locally from the iPad and can be preloaded before used. Also, it’s not as bad right now, about 2-3 seconds which feels ok.
Normally, when you deal with CAD data, you use a workflow whereby you take a very high resolution mesh and retopologize it down to low resolution (often by hand). You use the high resolution version to bake out your normal map, AO, etc. Are you using the CAD meshes directly?
I see. Somewhat directly. I’ve tried to optimize them but I see I stil lave a long way to go. 
Allright, after a lot of work, I’ve added all the geometry to this project, but I’ve optimized it both when it comes to triangles and texture sizes. Now I’m down to these numbers:
FRAME
FPS 59
MS 17.00
Cameras 1
Cull Time 0.030
Sort Time 0.080
Shaders 44
Materials 61
Triangles 443,592
Other Primitives 0
ShadowMaps Updates 1
SCENE
Mesh Instances 61
DRAW CALLS
Total 121
Forward 61
Skinned 0
Shadow 60
SHADERS
Linked 26
Compiled VS 26
Compiled FS 26
Materials18
Compile Time 252.605
VRAM
Index Buffers 1.49 Mb
Vertex Buffers 15.4 Mb
Shadowmaps 4.19 Mb
Lightmaps 0 B
Texture Assets 46.0 Mb
Textures Other 131 Kb
Textures Total 50.3 Mb
Total 67.2 Mb
I still feel it takes some time to load, but it doesn’t crash on the iphone anymore atleast.
If you post a link to the scene or a published app, one of us can take a quick look at what’s being loaded to see if there are any straightforward savings.
Sure thing, that would be much appreciated. Perhaps there are some low hanging apples one could pick:
Here’s the published version:
I just had a quick look. I use Network tab a lot in Dev Tools to identify what is very large.
You have 16.3Mb of download size. That is a lot. In the web, with every Mb - you will get less and less people getting to your content, especially on mobile.
Waiting - is a luxury in the web.
So here is screen of Network tab:
Largest file is 2K texture of ground plane, PNG with alpha. Absolutely - no no. You do not need alpha there, it is black & white, and even if you do need what in alpha, you can put it in Green channel, and use JPEG for it, and surely 1K wont make almost any difference if seen from such distance or angle. Try even 512 JPEG.
Then the skybox faces. If you use Prefiltered data of the skybox, then untick “preload” on each face texture asset of that skybox. That will prevent their loading, as they are most likely not needed.
You are loading ammo.js (physics), just to make sure - there is no physics required in this type of application, make sure to disable it in Settings.
Looking around, some of other assets, like paint_noise_normal can be optimised as well, it is 1K very “same” texture, you could have tiled 512 or even 256 without introducing visually recognisable pattern.
I believe you can make this app no more than 6MB, without sacrificing perceivable quality.
