How many drawcalls should one scene stay under?

Unity Engine
,
1

Can someone tell me how many drawcalls should one scene stay under in order to run at 30fps on Android phone (Nexus One)?

Thanks!!

2

Here’s a good read on the topic. It applies to android as well.

3

Draw calls seem much less important than fill rate on the android devices I’ve tried. Draw each pixel as few times as possible, with the simplest shader.

4

This is a great article, thank you! :slight_smile:

5

Hi all… that link was a good read, but I am wondering if things have changed given that is almost 4 years old now? Surely the same concepts apply, but what kind of polygon counts and draw calls should I be considering on today’s hardware as soft limits? Sorry for the necro but I couldn’t find a good thread other than this offhand.

Quick questions:

-Should I be using diffuse fast, or the mobile diffuse, for my shader for normal objects?

-Are more complex shaders able to be used with the newer devices and baseline in general for Android devices having gone up (Tegra 2, snapdragon, etc.)?

6

mobile diffuse. I use mobile vetex lit with out light source.

7

Well, I think the general guideline is

  • Keep drawcalls below 60
  • Keep transparent shaders to minimum (fillrate)
  • No particles close to camera (1 particle close to camera which fills the whole screen is worse than 50 particles far away)
  • Use simple shaders. Diffuse shaders can be quite expensive, especially with pixel-light (a light source set as “Important”). Mobile Diffuse is cheaper than Diffuse, Mobile VertexLit is cheaper than Mobile Diffuse. Mobile Unlit is cheapest, because it doesn’t use lightning at all.
  • Physics calculations are quite costly on smartphones, so keep them down. Even a small scene with many active rigid-bodies (i.e. an Angry Bird like game) will cause a bigger fps drop than a few draw-calls more.
  • Use dynamic batching whenever possible
8

Thank you both for the tips/advice, much appreciated :).

9

With hardware getting more powerful every year, it’s best just to choose a minimum target platform and make sure it runs in real gameplay with the FPS you are aiming for.

I’m not so huge on effeciency of draw calls and polycounts. If it runs smooth, then I don’t see what the problem is.

10

The problem is, that if you start optimizing once very late in development (i.e. when most of the game and asset is done), you will have a hell lot of work to change it. Most important optimization must be taken into account BEFORE starting to create assets, like instead of having a model with 5 skinned meshes, you could mostly have it with 1 skinned mesh too. Saves drawcalls, saves cpu time.

Also if you want to take advantage of dynamic batching you have to assure that the models in question are less than 300 polys and use the same material. If you must have to change this late in development, you have to rework a big part of your assets.

So if you prepare and do the important optimizations early in development you will have less work later and won’t waste as much time, hence development costs.

11

Really? Coulda sworn the docs says 300 verts , not polys.

12

Seems error in the docs.

Check out this thread/post

13

Intersting , i have had a few objects that broke 300 vertices , and they didnt seem to batch , but good link, more insight , thanks tseng

14

Hm, that’s from years ago, wonder if it was fixed? Good info to know. Thread said it was due to be back then.

As I am beginning work on a project that will be for mobile, these sorts of tidbits are critical to know.

15

Pretty sure it’s verts. The reason it seems like polys is because verts are counted as: position, uv and normal, that is 3 verts right there, which “feels” like a triangle half the time.

The limit is 900 verts, which if you take a typical model pretty much means 300 verts. That’s my understanding of it.

16

Hmm , that would make more sense, cause as i said , i have broken the 300 verts, and batching stopped.

This is 300 total verts or less on mesh exported out of max.

17

I wasn’t suggesting to not optimize AT ALL, but because the hardware is constantly changing and improving rapidly, I don’t see the value in hard caps on this stuff.

In this case just you build some placeholder assets, and pile them into a scene (on your minimum target platform hardware) to see how much it can handle before the performance drops to unacceptable levels. Tada, you now have your theoretical polycount/drawcall/shader limit. Now you build your future assets with these limits in mind and give yourself some wiggle room.