koobas.hobune.stream
Android: what is a reasonable triangle and drawcall count?
I am working on an Android game. I read so many things about drawcalls and polygon count, I don't really know, which is true, which is right. I am a little bit confused.
My game will probably aim mid-range to high-end devices. It'll be a racing game and I am doing some experiments nowadays. Now, I have a scene with some (flat) trees, and low poly terrain, road and kerbs. Also I have a car, around 2200 triangles. Now, my full scene tri-count is around 8-14k. Drawcalls are around 40-70, depends on where I am on the track. Runs perfectly on my Nexus 7 2nd gen, but I didn't try on less powerful devices. Also, there is only one car now and probably it'll be higher poly than now, because the model is unfinished, and I can't really reduce the polycount without losing detail. Someone told me that 14k tri-count is too much. However, I doubt games like Real Racing 3 has lower polycount.
Also, what about drawcalls? What is ideal? Unfortunately I can't use static batching, I am on Unity Free. I had stable 12k-14k tris before I started to separate the road into pieces, but lower drawcalls (max 60-65), now, I have 8-14k tris, but 70-75 drawcalls. Which is more imporatant for mobile? Lower drawcalls, or lower polycount? And in theory, for a mid-range device, what can be an ideal value? Also I read this, but I am curious about your experiences.
I think, it's important to mention, I am using vertexlit shader on the car and mobile diffuse on the terrain, and transparent vertexlit for trees and other vegetation (usually flat quads, for more detail, crossed quads). Cars will have LOD.
I don't think there is really much of with the poly count.I had one scene for testing the fps on my samsung s3 $$anonymous$$i.I created a little city with around 200k poly! and 4x AA.Since they are all static the fps was around 40-50.When i added 20 lights to the scene my fps dropped down to 7-12.So i don't really think the poly count is a matter of performance.
Your stats seem within the guidelines published at http://docs.unity3d.com/Documentation/$$anonymous$$anual/OptimizingGraphicsPerformance.html , but there's really no alternative to testing on actual target devices. Also note that LOD support requires Unity Pro.
Thanks for the comments!
Well, I mainly asked about drawcalls and triangles, as I will use simple shaders and only vertex light and if I use vertex light, only a very low amount. So in ideal case there will be only one directional light for sun and that's all. In rare cases there will be point light (vertex light) for tunnels for example. I won't use any expensive shaders. At least I don't plan to use them.
"Also note that LOD support requires Unity Pro." I can write my own LOD system, can't I?
Anyway I feel, sometimes I underestimate the devices.
So I don't think it is about draw calls and triangles. I read a lot about it but I seriously think that you can't really measure performance with that.
For example: I have a game on iPhone 4S running 3,4 Million triangles and over 400 draw calls. So I only have one directional light and not more then 10 rigidbodies at a time and I have 30 fps.
But it all depends. Do you want realtime shadows? How often do you calculate the physics? What kind of shaders are you using? How many triangles are there per inch on the display at the same time?
So if you only have diffuse materials with 8-14k triangles then I think you can go a lot higher. On a game I am currently working on I use 5k car models on which I calculate normals and tangents with unity to get the surfaces smoother.
I am not sure what you consider lower devices. The lowest device I currently have is an LG F5 but it already has plenty performance.
So to get back. If you use shaders with real time reflection as in real racing 3 and you use a couple of light sources then 20 k triangles might be the most you can go on older devices.
The only way to find out is to try it. What I keep doing is checking on every test build I do, where I leak performance. On graphics, on Physics or even on Code.
My problem used to be physics which I think is harder to solve then graphics. As If you have problems with the graphic performance then you can turn down the quality settings, which is a powerful tool at the beginning. Also changing the materials depending on the device you are running on, is a very optimal way too increase graphic performance and still provide great content.
If you leak performance on Code, then you need I think it mostly comes when you compare large arrays, or use many functions using Mathf. (by many I mean you use it a couple 1000 times a frame).
If you want to get close to Real Racing 3, then I think that you need to be very good. But I think that they used a couple of work arounds to get those results ^^
I hope that helped you a little.
Thanks for the answer and tips!
Well, good to know, you could run a scene with 3.4 millions of polygons on that device. I didn't plan using real time shadows. Probably I will use some kind of blob shadows (maybe with projectors, but hopefully I'll find a better solution as projectors can increase draw calls a lot which is not my aim). For cars, probably I'll use reflective shader (no real time reflection, or just simple diffuse, but only vertex lit). $$anonymous$$y aim is not realistic rendering, but a little bit cartoonish. Some kind of hybrid. I just came up with RR3, because I feel that game is pushing the boundaries and I can measure and compare, how it runs for example on my device.
So cars probably will get reflective shader (optional) and the track itself will be mainly mobile diffuse and some alpha tested shaders for trees, fences, spectators, etc. Also, I think, I'll use reflective shader for higher lods, lower detailed cars should get only simple vertex-lit.
About the physics. $$anonymous$$y current car has only one box collders (well, I increased it to two, but I didn't test it on my tablet) and 4 wheel colliders, not the built in ones, but the one from the car tutorial from the alternate physics section. Honestly, I don't know, how it performs compared to the built-in wheel colliders, but I tested my device with 25 rigidbodies (cars) and 100 wheel colliders (the built-in ones), and I got usually 60 FPS, but as my models weren't optimised and I forgot to use vertex lighting ins$$anonymous$$d of per-pixel, ooops. Sometimes, when a lot of cars were on screen I got only around 30 FPS. But clearly, I didn't think any optimalization at that stress test.
