Standard Shader for Mobile

Big problem we face now. We made a big mistake but it’s too late to go back in time. Hope someone is able to provide some insight.

We have upgraded to Unity 5.2.2 and already released an update to Google Play. We did this as the documentation encourages us to use the standard shader so that’s what we did. We tweaked everything for the sake of the new standard shader, rebaked, etc. Looks great!

We are now getting lots of complaints from players with older devices that the game is very laggy(low fps).

We statically bake lightmaps for everything, except moving objects. Moving objects don’t use dynamic lights, just light probes.

I believe the slow down is due to the standard shader. Here are my questions:

1.) Do the statically baked scenes which uses standard shaders cause the slow down? Or is it only the dynamic objects that use standard shaders the culprit? From my limited understanding once you bake the scene, the shader doesn’t really matter anymore.

2.) For what I’m I’m currently using for my dynamic (light-probe ON) objects, Is there a replacement shader I can use to replace the standard shader? I know I can replace it with mobile->diffuse which is what we used to use for dynamic object, but since Unity 5 the light probed objects are lit up so bright it’s practically all white due to a bug in Unity right now. With standard shader I can work around that by making the shader use a darker color. But there’s no such option for mobile->diffuse. Perhaps there’s a way to tweak mobile-diffuse shader code to be darker for this work around?

Sorry for bad English.

Thank you for any help.

p.s. I already tried Unity 5.3 but there are way too much problems I don’t even want to look at.

p.s. If there’s no solution then what we plan to do is switch back to mobile shaders. We’ll tweak the scenes by lowering all the lights of the entire scene and bake the scenes until the light probed objects are properly lit, e.g. no longer all over exposed and white looking. This will give us normal looking dynamic object, however the scenes will be way too dark now. So then we will use Photoshop to adjust the baked lights to brighten it so it matches the dynamic object.

This is a very hack way of doing things, but it’s our last resort. Does anyone else have these issues?

It’ll be the StandardShader, it has a lot more instructions on the GPU than the Mobile ones, you can use the same bake though, just switch the shader to the Mobile ones, do note as well, that Directional lightmaps and realtime GI on in the lighting window add 3 times the extra overhead than Non-Directional with realtime GI off.

Really if you have the guts to try or you know shaders well enough you would be better to write your own, as you can be more specific on what they are doing, if not maybe try the ones from ShadowGun that are lightprobe only, and then the Mobile Unlit (supports lightmap) for static.

Try this for your dynamic objects maybe:

http://forum.unity3d.com/threads/light-probes-only-shader.171679/

Thanks I’ll give that a try.

If you are okay with some shader hacking you could try copying the ES 2.0 shader variant from Unity 5.3 and use that. It was tailored to run on low-end devices. It’s still slower than the (old) mobile shaders but may give you a better result depending on your setup. For devices with weak GPU you may also want to consider dropping the resolution a bit. There are some really nasty devices out there with very highres screens running an underpowered GPU.

ES 2.0, what’s the names of them shaders?
Also I have upgraded to 5.3 since that’s supposed to have optimized version of Standard Shader. Is the optimized version supposed to be as fast as the mobile versions in 4.x?

What is the best practice for mobile in 5.x anyways?

The shader from a Unity perspective is the same but it has a fast-path specifically designed to run well on low-end hardware.

In general the mobile shaders will still be faster in most cases because they simply do less calculations (and/or less texture sampling). The performance should be comparable to non-mobile legacy shaders.

And for a “best practice for mobile in 5.x”, I think it really depends on which devices you are targeting. If that’s “as many as possible” then using the Standard Shader for all materials is probably not a good solution.

With some shader hacking you can disable specular highlights in the “fast path” version of the Unity 5.3 standard shader for Materials where you don’t need it, like very rough materials.
This actually helps quite a bit on some older GPUs (e.g. Mali400). That can be done by defining SPECULAR_HIGHLIGHTS to 0 in your shader (renamed copy of Standard.shader from the builtin shaders).

Thank you I have a few more questions I hope you can help with.

1.) So hacking the fast path version of the Std Shader will still not be as fast as the mobile shaders correct?
2.) Does using Std Shader for baked static object still have the same performance impact? e.g. Performance will not change whether I use Std shader or mobile shader for statically baked objects?
3.) I don’t see any reason to use Std Shader for our dynamic objects. So I want to use old legacy shaders, but they are way too bright compared to the baked objects. They fixed this for the std Shader in 5.3, is there any way I can fix this for mobile shaders too? Can you help with hacking the mobile shader to lower the lighting?

Thank you.

When I drop resolution I get messages like these:
“Hardware resolution scaling not supported, falling back to software scaling (blit).”

Is software res scaling going to help with performance?

Yes, it’s still going to help with performance and also make you use less power. Of course hardware scaling is always better. What device are you running on?

I think I saw that message on Asus ZenPad. I also notice ios build doesn’t have the “auto(best performance)” option anymore in 5.3. So we are now

  • scaling resolution for any device that is over 1080p down to 1080p. For both Android and iOS.
  • Default with antialias 2x but if we detect fps under 40(during first 30 seconds of game play) we’ll turn off antialias automatically
  • Player has the option to turn resolution down to 720p manually

I have actually not seen any performance improvement scaling down an iPad 3 from native down to 1080p, but 720p does help. So that’s why I wonder what setResolution is really doing behind the scene…

May I please ask, regarding iOS the Standard Shader is not optimized yet, like the Android in 5.3 correct?

What version? Do you mind grabbing the build fingerprint for me?

adb shell getprop ro.build.fingerprint

On iOS I think you may hit an extra blit, so if you are fill rate bound or the resolution is fairly close to native you may not see much of a performance boost. This is not the case for Android. On Android you get the upscale for free. Either by using hardware upscale, which gives best performance. Or you will piggyback on the already existing blit to back buffer.

Correct

I’ll get you the fingerprint in my next post.
What does “upscale” mean?

asus/WW_P01Y/P01Y:5.0.2/LRX22G/WW_ZenPad-12.26.4.34-20151022:user/release-keys

I googled “Hardware resolution scaling not supported” and I found (only) this post.
I got the same problem after trying to scale resolution on a Galaxy Note (N7000) and a Galaxy S3.
An additional and more critical issue is that screen space overlay UI is scaled completely wrongly (almost unusable) when software scaling is applied, while it scales fine on devices where hardware resolution scaling works.
Could someone confirm it is a bug? Any fix on the way? I am using Unity 5.3.0f4.
Thanks in advance!

scale up from a lower resolution buffer to the native resolution of the screen

thank you! I’m talking to to my contacts to see if maybe they can fix the driver.

I’ve never seen a bug like that. Please submit a bug report and the fingerprint of any device experiencing this behavior.

Thank you, Martin! I’ve submitted a bug report: https://fogbugz.unity3d.com/default.asp?753916_qo5pjd2k7vifdtq3
You can find the fingerprint of one affected device in the report.
Could you take a look at it?
Thanks again,
Fabio