Bloom doesn't work on android build with URP

Hi, I’m making a game and I usins URP for the first time, every on the editor looks good but when I make a build and test it on android the bloom effect doesn’t work, even on high quality. Any solution? :frowning:
This is how it looks in editor (Unity URP Template):


And this is how it looks on android build (Unity URP Template):
(I’ve exaggerated the effects to do it more noticeable)

Interesting. May I ask what device this was tested on? Our project until now did not have this issue on android but I’m concerned that ours may not work on some devices as well.

I have noticed this before with Bloom on my S5. All other post processing effects of several I had enabled at the same time were working, and Bloom was working fine on other platforms - I just assumed it was because of some other setting (I currently focus on lightweight or mobile concepts, where any post processing can be disabled by user in their graphics options anyway and is just a form of progressive enhancement). I’m not sure which version of URP it was, I use 10.1 currently but most likely it was 7. or 8.something. I’ll enable it in my next build for Android and see if it still looks different from how it looks for Win64 and WebGL 2 with URP 10.1.0-preview.2 then post again… later tonight or late afternoon tomorrow.

Just tested with Android S5, URP 10.1.0-preview.2, 2020.2.0a19. Bloom is working.


6198451--680080--opengles3_android_bloom_settings.jpg

I should note that I have OpenGLES3 as my first in the list for Graphics APIs, and a function that disables Post Processing / hides the toggle from user graphics options if unavailable - for Android I test this way:

bool supportsPostProcessing = (SystemInfo.graphicsDeviceType == GraphicsDeviceType.OpenGLES3);

I don’t know if it’s supposed to work with other graphics APIs for Android or not.

1 Like

I got my Galaxy S3 working with bloom and URP but drops drastically fps also without any post-process. Do you have any urp profile recommended for android?

There are a few things you can do with Android for performance that I’m aware of. The first is that the default frame rate might be 30. To set that to 60 for your app you can do this any time:

Application.targetFramerate = 60; // default framerate: -1

Keep in mind that Android does throttle performance as the device heats up and a higher framerate will make that happen sooner. To learn more about handling that I would suggest reading up on the Adaptive Performance package, also Sustained Performance Mode… the first option will make it easier to set up your own approaches to keeping the device cool (adjusting LOD bias, drawing less effects or switching to less complex materials etc.), but it’s not implemented in the majority of current devices iirc. The second option will effectively lower your overall framerate in favor of avoiding thermal throttling - you’d have to look into what else it does since I don’t personally know much else about it.

Make sure all settings for mobile platforms really are the lowest you can tolerate. It’s temping to be like “well that looks a bit better” about some option and the next thing you know it’s the reason you’ve lost 10fps (and on mobile that’s obviously a big deal). In relevant pipeline asset settings you might want to have Opaque and Depth textures turned off (both have a noticeable performance impact) although some shaders require one or the other or both so depending how far along you are / what the implications might be, disabling those might not be reasonable. Disable anti-aliasing unless quality suffers too much (depends on what else you’re doing - if you’re going to have Post Processing effects you might notice it has no effect anyway / scene is already soft enough from one effect or another). Make sure Shadows are only being cast by the main light and your shadow resolution is reasonably low (personally I wouldn’t go higher than 2048 for a mobile platform) and that you’re not casting shadows with additional lights if there are any etc… keep in mind the resolution is spread out over the shadow distance you specify - so 2048 might look great with a distance of 100 but if that’s set to 1000 it won’t. Maybe you only need shadows to a distance of 50 and a resolution of 1024 is enough - you’ll need to experiment, but the point is each small thing contributes to less processing and will help not only with performance but also throttling. I’ve found Android frustrating this way but the problem is not unique to Unity and will almost inevitably come up unless the game is about as minimal/simplistic and/or well-optimized as other mobile games that run well.

Something else to think about is how to make good use of any idle time (such as when the user is in your menus before/during/after a stage etc.) to cut processing demand down as much as possible - you can capture the world with a RenderTexture and render that capture in a RawImage component behind the menus (or whatever you want), anything possible to let the device cool down. The framerate will go back up as it does.

If you’re not already, try to be get comfortable using the Profiler to keep GC allocations minimal and optimize wherever possible. GC will cause noticeable stutter on low end devices - there’s a build option called “use incremental GC” you might want to consider especially if you’re not calling GC yourself during opportune moments or have long-running scenes. It’s not easy getting a mobile game to keep running at the performance you want and some great ideas just won’t be possible - it might run smoothly for a few minutes and then the framerate takes a dive for no apparent reason. That’s what thermal throttling can do to great ideas :smile:

Maybe provide graphics/performance options to the user - allow disabling shadows or post processing, add a “detail” slider that you can use for particle system complexity or the far clipping plane, whatever. Keep materials simple… poly counts low… anything else I can think of right now would just be progressively more generic and border on obvious so … yeah.

Edit: Also make sure Blit Type is set to Auto (Always is slowest - Auto will only use Always when Never isn’t supported).

So, just to clarify, what exactly do you mean by “without any postprocess”?

Side note: Galaxy S3 is an 8-year-old phone with a 12-year-old GPU. Don’t expect much from it.

2 Likes

Yes i know, i use this Galaxy S3 because it has 1gb ram and with unity analytics we see there is 12% users with devices with 1gb ram. That let me to know better and in real device when i was using excesive resources.
About post-processing apologies about my english, i mean when i use URP i have no much difference in performance, also in this s3 i have 25-30fps in one scene, and with built-in 60fps. Without any effect of post-processing i mean.

Just want to drop by and share how I got post-processing to work in my project using URP:

1.) Go into the Universal Rendering Pipeline Assets that you’re using
2.) Check HDR in the Quality section and set Grading Mode to “High Dynamic Range”.

Note: I had to to this to all the fallback rendering pipeline assets (high, medium, and low quality) because it was falling back on the lowest quality asset on my particular testing device.

This is by far the only working solution for me, thanks a lot.