Download

IOS limitation

Good day

I would like to know some important limitations to the levels under ios, like this:

  1. Maximum memory for textures
  2. Limit on the number of light sources
  3. Maximum number of vertices on scene

And i think developers know a lot trick&tips about this and other stuff for ios develop.

In addition. Whether - there was any acceleration when rendering a large number of identical objects? Or maybe good practice to do that (something like instantiation in 3d max)?

Hi Disa,

There are no hard limits for (1) and (3). Available GPU memory depends on the kind of Apple device, though no more than 128 MB of total VRAM usage (textures, meshes, frame buffers, etc…) is a good rule of thumb for mobile in general (many Android drivers limit it to something around that, even if they have far more memory). If you are only targeting newer iOS devices, you can go higher, etc…

RE: (1), the limit for a single texture on ES2 is 2048x2048, but using a lot of large textures can quickly bloat your download size or runtime memory usage.

RE: (3), it depends on what other stuff you are rendering, but it is rare to end up vertex bound on iOS (shadowing skinned meshes can be, but static geometry will probably never be bottlenecked here).

(2) does have a hard limit: You can have one dynamic directional light at runtime. Every other light needs to either be static and baked, or it will not affect the lighting at runtime.

RE: Batching: Multiple meshes using the same materials and textures will be sorted together, reducing CPU side overhead on the render thread, but they not be instanced on the GPU/driver side as ES2 doesn’t support instanced rendering. Merging meshes together can be a real benefit on mobile, although you have to balance the CPU savings versus the GPU overhead of drawing extra stuff that could have been culled otherwise.

Cheers,
Michael Noland

If you intend to support lower-end devices (iPad 2, non-retina iPad Mini, iPhone 4S and cheaper Android devices), I strongly suggest you use unlit materials for your dynamic objects and disable lightmap directionality support if you use static geometry. In my tests it turned out these devices have very poor fragment processing capability and keeping the shader instruction count under around 25 is needed to keep a solid 30fps. You can get away from “flat” looking if you bake ambient occlusion into your textures or use baked lightmaps/AO in your static geometry. We can also afford to use “fake” directional lighting in our unlit materials (just calculate a dot-n-l in a material function), so they aren’t completely unlit.