Official Unite Now - Optimization Tips for Maximum Performance – Part 2

A direct link to the session would have been nice. The video is unfortunately marked as unlisted, so I can't seem to find and watch it on my TV.

 

https://resources.unity.com/unitenow/onlinesessions/optimization-tips-for-maximum-performance-part-2

 

I have some questions

Avoid mobile native resolution

I've experimented with this a while ago and I found some issues that I wasn't able to solve. Perhaps you've solved them.

Question 1

How can I render a native resolution UI on top of the lower res 3d scene? Just using Screen.SetResolution affected both in my tests.

I then started to come up with a custom render setup. I kept the screen at native resolution, but rendered the 3D camera to a lower-res RenderTexture. I then stretch-blit the lower-res RenderTexture and draw the UI afterwards.

This did work, but 1. didn't make it faster and 2. caused all sorts of Physics screen to world issues.

Question 2

I noticed using Screen.SetResolution to lower the resolution caused on some android devices actually performance problems. Or let's say it made it slower and not faster.

It's been a while and I can't remember why. I guessed Unity perhaps just renders to a lower-res RenderTexture and then stretch-blits it to the native-res frame-buffer? Like the setup I described above. Is that the case? Have you seen such worse performance on some devices too?

How can I solve the above two issues?

 

@AskCarol Hi mate could I ask you a out of topic question. Will be summer sales in asset store in next days?

 

Use built-in rp. Render "main" camera to a render texture with a resolution of your choosing, render UI camera on top normally without any post. This is still viable, even though it is becoming slower to do in later version of Unity (maybe to prove their point that stacking cameras is slow?).

With that said, if you are mindful of your fillrate (which generally means avoiding any Unity provided shaders and post effects), you can render at native resolution everything just fine, with AA on even. Just turn off as many Unity features as you can.

 

That's pretty much what I described above I ended up doing, but it didn't make things faster, hence the question

 

Then you were not fillrate bound? In fillrate bound devices (like say, Samsung Galaxy S6) limiting the resolution for the main cam was a clear win for us. If you are not seeing performance gains, then you were not fillrate bound, which means lowering resolution does little for you (and is why "don't use native resolution" as general advice is not very useful)

 

on 3D Camera,

OnPreRender,set a smaller camera rect.
OnRenderImage,setback rect before blit to dest

 

On ultra low end devices (like granny Mali 400), blitting off-screen can have a significant overhead, which can outweigh the cost of of rendering at native res. But those GPUs are usually far too slow to run any effect that would benefit from a lower resolution anyway.

The advice is valid for more modern, but not premium GPUs, specially if your game is in the business of using per pixel lighting, shadows, and post effects.

Mobile games which target "console like" graphics simply cannot do native rendering even on the very best mobile GPUs, because those are often paired with ludicrous high resolution screens.

Using dynamic resolution on your camera and setting your UI canvases to overlay did the trick for us: 3D rendering resolution can be changed at any time and UI is always at full res. Works like a charm on consoles too.

 

Why are you recommending Low Quality texture compression? My understanding (which may be wrong) is that the textures will be the same disk/file size but that the texture compression processor will have different settings set on it depending on the quality setting. Certain quality settings may use an unsupported texture compression (BC7 vs DXT5) but I am not aware of why the texture compression would matter in any optimization other than editor import times as long as the target compression is supported on the target device.

 

What? That’s false. It’s only true if you’re using ASTC which isn’t the default for any mobile platform.

Edit: I guess iOS switches to 2bit pvr if you set it to low, so I guess there is a valid use case.

 

This thread is really useful I got to catch up those techniques