The post processing stack v2 bloom has a paramter that can control the blur times of the effect.
But after i upgrade to URP.The bloom does not contains that paramater.
So the drawcall of Bloom is increasing from 2 to 22.
It’s performance awful.
I can’t use it anymore.
3 Likes
PostProcessPass.cs
const int k_MaxPyramidSize = 16;
this controls the downsampling times.
this should not be a const value.
Because of the purpose the URP,it should be performance friendly to mobile or vr platforms.
7 Likes
A 16-texture bloom is absolutely insane, that’s movie-CG level bloom, overkill for just about any existing use case tbh. As you mentioned, there’s no reason that should be a constant - but looking at the naming scheme, it looks like Unity intend for it to be like that 
If I recall correctly you have worked with post processing a bunch so I trust your experience 
, do you have any manual tips to squeeze better performance out of URPs post processing?
Seeing stuff like this is very concerning, as I imagined Unity would atleast have options for the fastest possible settings.
Cheers
1 Like
Given the lack of real customization options they give you in-editor, you have one choice if you stick with URPs post-processing: Edit it and maintain your own version. Decreasing the bloom k_maxBloomPyramid (IIRC) var from 16 to 8 will instantly save you 8 passes for instance, the rest of what you save is up to you.
2 Likes
Hey,
So in practise you would think this, and when you think of it as pure number of draw calls then yes it seems a bad idea, but I would suggest you profile it, as 80% of the cost of bloom is the initial sample down and the last sample up in the pyramid, the successive iterations become exponentially cheaper, which is why we have so many, if you were to change it to 8 vs 16 I would be surprised if you gained more than 10% performance.
I have looked at this myself in the Boat Attack demo as I though it was insane too and when I asked the developer about it I was explained this, so I then went back to profiling to see the cost of each sample and saw that it indeed becomes was less costly with the huge benefit of being able to have very wide blooms that can cover the entire screen.
If you want to speed bloom up the number one solution is the initial resolution you start with, and if developing on mobile you might be hitting the issue of silly screen resolutions.
One thing that could be improved is that we could skip right down to quarter res rather than going to half res for the first/last iteration but this will impact the quality severely as it will skip any small details completely and lead to massive amounts of flickering.
We know bloom is our most expensive post processing effect by large, but without crippling the quality we are still tossing ideas up on the best compromise.
5 Likes
That’s all true, including what your developer said - but they obviously haven’t thought about all the use cases for bloom in a universal render pipeline.
Mobile bloom, more often than not, just requires a small glow around objects - even modern mobile games like TES:Blades don’t use more than that, which can be achieved in ~2 textures, maybe 4 for very high quality bloom. Even if the extra individual passes in the GPU profiler don’t look like they add up to much, any mobile dev will tell you that looping through two for loops ~12 more times than they need to, while adding 12 extra passes, is far from best practice. It is trivial to at least add in the option for mobile users to set the maximum # of passes and maximum bloom texture size - something that as you mentioned is also an issue, and should be controllable in the pipeline (as it is in some 3rd party assets, like PRISM).
9 Likes
Interesting, can we use use some sort of SRP batcher, that we no need to bother of draw calls number for post process effects?
I agree - stop running the URP demos on giant PC monitors and run them on 5" mobile and Nintendo Switch screens - which is what we are all using URP for. The default should be maximum performance for all settings first and foremost. Much easier to ramp up the visuals on our end (the game developer side) than to examine every minute setting to squeeze out performance.
9 Likes
Physical screen size != Render resolution
There are 5" devices from 2013 with current average PC monitors “1920x1080” resolution, the switch does 1080 tv to 720 hand held.
Question… is all of this poor performance due to depth texture being forced on by the render pipeline???
Yes, it is far too costly for mobile platform currently
Yes please options to choose half or more or full
2 Likes
Wasn’t “performance by default” supposed to be a thing that Unity is trying to achieve? What if we don’t need “very wide blooms” on the screen, but much more subtle glows? We pay for it regardless. Please expose the quality options instead of shipping your tech demo code and calling it production ready.
7 Likes
I think it will ultimately come down to the choices. Just enable the iteration numbers etc exposed as public value so the developers can choose the value they like.
I was waiting for the “optimized” URP PPv3 just to see this, interesting. Can you just expose as much parameters as you can instead of telling us that already heavy PP effect should have more draw calls for a sake of nothing. I already have 20 FPS with only bloom being enabled (and 2 static sprites on the scene) with current LWRP PPv2.
It’s obvious you’ll never be able to develop a performant mobile game using URP + PPv3. Look at any developer conference out there and see how people achieve performant bloom on mobile devices. There are so many hacks, they fighting for every ms and you just waste precious resources on unnecessary stuff. Look at the Raid Shadow Legends speak from your OWN conference for example.
It’s an another proof that if you won’t start developing your own production ready games you will never provide anything good for us.
9 Likes
Well whenever this kind of thing happens in Unity we had plan b called asset store… but the problem with current case is that the asset store developers cant make alternative solution (yet) for the post processing in urp. Which, is ironically, in my opinion the worse situation to worry about… Personally I never used ppsv1 or ppsv2 in non srp applications because of either lesser performance or lesser quality of it. Sometimes it makes me wonder if this is actually a business model? Dont get me wrong. I still like Unity for its flexibility and as a tool.
2 Likes
I disagree. They renamed it to Universal Render Pipeline from LightWeight because it was meant to target a wide range of devices. If they keep removing features soon we’ll be left with monochromatic 16 shades of grey rendering and a max display of 640x480.
It’s a universal solution (allegedly… I don’t know how universal it is, the results are below expectations so I’d expect it should be able to run on a potato), not mobile only. Plus Android is not a phone only OS, you can have Android on a TV device.
1 Like
The most universal solution is to expose as many performance-related parameters as possible. Not to keep such basic performance sensitive parameter under the hood. I have no problems seeing 16-texture bloom on URP as default as long as I can control that option without creating my own PP effect.
8 Likes
I do tend to agree. Personally I think it’s maybe not the best time to be using Unity… the old render pipeline is not getting any more love - there’s been issues with flickering shadows since like 2010 and they still persist to this day, except the current stance is “move to URP or HDRP instead, we’re not fixing that” except when you go to URP the shadows are pretty much even worse… I don’t know. Maybe one day they’ll get it right
Nope. Grand strategy games and RTS games need optimization for everything. Please dont make assumptions like this.
But I agree. URP is because we want fastest, not prettiest. So default should be fastest.
4 Likes