Performance Questions

Quick update: I found out that SSAO effects don't play nice with the orthographic camera and cause the SetPass number to explode. I'll have to re-evaluate if I can use the perspective camera instead.

And I did a test setup with the brown shipping containers from my screenshots above. I made a grid of stacks of them, almost filling the screen. The model has 280 vertices (yeah, I know it's overkill), so it should be ok for dynamic batching. I got these results:

no batching at all: 49fps
only dynamic batching: 30fps
dynamic & static batching: 69fps
only static: 62fps

I had all of them marked as static, which is not going to work for my game. I did another test that I didn't wrote down numbers for, but fillrate/overdraw (is that the right term?) seems to be an issue. I still have to A/B test how big the issue of different textures/materials increasing the SetPass calls is without any form of batching. I might still benefit from using texture sheets, even without batching enabled. I have to do more tests.

I see why the "how to optimize" questions are always so tough to answer. A big part of it seems to be "it depends...".

 

An important question here - how are you measuring those numbers? (Apologies if I've missed this earlier.)

Are you measuring in the Editor? If so, keep in mind that results are useful for comparison at best. Sometimes other overheads in the Editor make them unreliable even for that. So, first up, you want to do important measurements in a build. Secondly, the build you use for measurement should be on your target platform, because if it's not then you're not actually measuring the right thing.

As you can see from your results, dynamic batching isn't always a win. It moves work from one area to another, and it seems that in your case it's moved it from somewhere underutilized to somewhere fully utilized... on your development platform. I would guess that results will be similar on most target platforms, but guesses aren't useful when it comes to performance questions.

The whole thing is "it depends".

Optimizations rely on a detailed understanding of the thing being optimized, which we can almost never get from a few forum posts describing a thing. They also rely on the person doing the optimization understanding a lot of background information which also can't be effectively explained in a few forum posts (it comes from experience, technical expertise and quite a bit of study).

Also - especially as project scope grows - optimization has to be about more than just the code running fast. Things like operational cost, workflow changes, impact on existing content or data, and expertise barrier all need to be considered. What's the overall value of an optimization which (contrived example!) doubles your game's frame rate but forces your art team to re-build all of your levels and thus pushes your ship date back by months? Well, that depends on...

 

It's simple enough if you can answer the question "What does it depend on?"

Hint: It's the same answer.

 

I had just recently found out that the build performs better than the editor (at least for GC tasks) but of course I already had lost sight of that and did that test in the editor . When I saw your post I repeated it in the build (only testet dynamic batching vs no batching) and it was about 30 fps vs 60 fps, dynamic batching being slower.
I guess you are spot on with the underutilized / fully utilized thing. I assume the CPU here is the bottleneck and will continue to be for most things. I have afforded myself the luxury of only targeting specs like my pc and above for now (and only windows). I assume it will take a few years if my game ever makes it to steam, and by then hopefully an i7, gtx 670 and plenty of RAM will no longer be at the higher end of the spectrum. It would be nice to get a stable 60fps on my system so that on slower systems maybe stable 30fps are still possible.
I've done some preliminary guesstimates (backed by profiler attached to a build) and rendering 1 million verts including particles should be doable if I don't have too much overdraw. And it should leave enough headroom for physics and pathfinding. I hope the lit particle thing that I have an eye on in another thread won't be too big of a performance hog.

Yes! I'm doing my best to catch up on the things I'm lacking, but ultimately it will stay difficult to optimize something before even a fraction of it is really finished. I'm sure I'll hit a few more bottlenecks down the road. I'm just hoping none will force me to throw away large parts of what I made till that point. But with all the amazing help I'm getting from you guys I'm cautiously optimistic that it'll turn out ok.

I absolutely agree! Figuring out an efficient art asset pipeline is one of the major concerns I still have. It just would be too much work if I can't automate/streamline a good portion of the process or make other compromises. Quixel Suite 2 should be released within the next months and I'm undecided if I should wait and see if that will be a game changer, or if I should commit to using the Substance tools.

 

Quixel Suite 2 has been released yesterday, but I'm going with Substance Painter. Here are my first test assets:


It seems I have found a workflow that is an ok'ish compromise. I'm modelling/kitbashing highpoly models in blender, apply material masks as blender materials, convert them to vertex colors with a script, build lowpoly meshes in the same file, auto-unwrap them and scale the UVs down and move them so that I can fill one texture with 4x4 mid sized assets, or 8x8 small ones or 2x2 big ones or any combination that fits. I'll keep the batches together sorted by type of asset, so that I have one substance painter project file per batch of objects. And I'm using the material ID masks baked from the vertex colors of the highpoly to automatically get the right masks in substance painter. I import the textures and the low poly exported fbx of the whole batch into unity and there I can find the objects with their mesh names.

 

If you're "batching" things manually, be REAAALLY careful with mipmapping. Mipmapping downscales your textures, so one asset texture will start bleeding out into another at some mip level. However, turning off mipmapping will result in performance hit.

 

I could make the margin between the UV islands bigger but I think with the rather fixed camera perspective and distance I can probably just turn it off.

 

You should test that, but I wouldn't recommend turning mipmapping off, unless you're dealing with sprites and scene cannot be zoomed. You might get unpleasant noise AND reduced performance.

 

Thanks for the warning! I found this more in depth explanation:
http://answers.unity3d.com/questions/22491/how-do-i-turn-off-mip-mapping.html
(from 2010 but probably still valid). I also did test it and it is astounding how much crisper everything looks just by turning off mip mapping.

Middle square shows mip maps turned off.
I think I don't have enough textures and models yet to meaningfully test performance. I guess I'll just increase the margin on the UVs to be safe and play around with the mip map, filtering and compression settings later down the line. I've seen that the difference between box filtering and kaiser filtering for the mip maps is visible. Kaiser looks crisper.

 

I would not recommend turning mipmap off.

Instead of turning off mipmapping it is generally a better idea to look into mipmap lod bias or anisotropic filtering.
Mipmapping significantly speeds up texture rendering and few years ago turning mipmapping off could halve your fps (because GPU had harder time caching texture reads).
Also, you'll get pixelated noise in distance without mipmapping, (some indie games used to have this issue, it is usually indicates coder's inexperience, if the game has perspective camera).

You do have enough objects in the scene to test performance.

Also, if camera in your scene cannot be rotated, consider using sprites instead of 3d objects. You'll get crisp look and less polys.

 

Yeah, this would be my primary concern. Make sure that in your quality tests you cover motion cases. It might look "crisper" with no motion, but it will almost certainly introduce "buzzing" with motion, as is explained excellently in your linked thread.

 

I will, thanks for the advice! In my last test I had the camera slowly move forward because I happened to have a script for that lying around. That looked ok, but I'll be sure to leave mip maps on for now, build more mechanics into the game and make sure I can test all relevant edge cases before I make a potentially bad decision on this.

Originally I was going for the ortho perspective and to be honest I only deviated from that plan because the depth buffer / drawcall issue that I got from using the ortho camera. With ortho cam some things might have looked ok as sprites (except for SSAO and shadowcasting maybe), but with a perspective, even if it is a very low fov, it would look out of place I think. I remember the old Diablo 2 had a mix of perspective and sprites and I didn't like that option at all. I'll somehow make it work with meshes.

Mipmap lod bias sounds like a thing that I really need to look into, I'll do that right away.

Thanks for your help guys!