Flexible Blur URP

Do you need a URP UGUI blur solutiuon that is performant, high fidelity, flexible, and hassle-free?

When I found myself in this position, the only solutions I could find were able to satisfy, at most, perhaps two of the above requirements to a satisfactory level.

And so Flexible Blur was born!

Flexible Blur does not constrain you to any one way of doing things.

Other solutions either:

1️⃣ Limit you to a single, fullscreen blur per camera that needs be shared across all the elements of a canvas. This limitation isn't always a bad tradeoff, but it's a trade-off that you are forced to make and work around. It can be performant when overhead can be shared between many elements. But there are serious downsides. Besides significant artistic constraints, any time you only have a few elements covering a small area, you end up doing far more work than necessary. Or,

2️⃣ Handle each blurred element individually. The trade-offs are the opposite of 1️⃣. You gain artistic flexibility and better performance when only need to blur a small region across few elements. But then when you have dozens of elements that require blur, all the overhead and drawcalls can be crippling even on higher end hardware.

Enter Flexible Blur.

•By default, Flexible Blur works on individual elements. But it also gives you the ability to mark compatible elements as "batchable," so they share overhead. You have the best of both worlds. Batching is oppurtunistic and dynamic, so you still have the artistic flexibility to vary blurs individually.

•While other solutions that work in the manner described in 1️⃣ sometimes provide the option to only calculate blur for some rectangular portion of the screen (for example, if blurred elements will only show up on the lower portion of the screen), even when Flexible Blur acts similarily it automatically finds the smallest area needed to cover batched elements.

•A main goal of Flexible Blur is to aggressively reduce performance impact whenever possible. Flexible Blur looks for situations where it doesn't need to work (eg. blurs are all offscreen or inactive) and early outs. Reducing overhead is especially useful in contexts where you would otherwise suffer compounding overhead (for example, a multi-camera setup with layers of stacked blur).

•With Flexible Blur, you don't need to adapt your UI around the limitations of a blur solution. The blur solution will adapt to fit your UI.

•You have the option to use compute shaders. The compute shader path is appreciably faster on most hardware than traditional shaders, and can drastically reduce draw calls when you need multiple distinct blurs. (There is still some overhead, so while compute shaders reduce the use cases for batching, they don't eliminate it all together). As of this writing, Flexible Blur is the only asset of its kind that is able to leverage the performance benefits of compute shaders.

•You are able to create presets that react to the current quality level. This is a hugely important feature that I haven't seen in other solutions. Blur is generally not the cheapest effect, and there can be a large performance difference between "good enough" blur and "beautiful, high fidelity" blur. Given large disparities between hardware configurations, if you lack the ability to be responsive to quality level you either need to sacrifice fidelity on the altar of low end hardware, or low end performance on the altar of fidelity.

•Choice between UIBlur and UIBlurImage components. UIBlur is lightweight and writes directly to camera output, but has fewer features. UIBlurImage reproduces all the features of standard Image components.

•Support for stacked blur (blurs that blur other blurs), both as a part of a multi-camera, multi-canvas setup, but also for blurs that share the same camera and canvas (with limitations).

•Simpler setup than the popular alternatives. You do not need to add components to your Cameras, and you do not need to create materials for blurs. Applicable cameras only need the Flexible Blur Feature added to their Renderer.

•Supports dithering, to reduce banding on large blurs. Another important feature that I believe is unique to Flexible Blur.

•Source code provided.

CAVEATS

• Does not support built-in or HDRP render pipelines.
• Does not yet support Unity 6 render graph, but support is planned in the near future.
• VR support is still in development and has not been extensively tested. Currently only supports multi-pass.
• As opposed to other assets, will not make the claim that Flexible Blur is "the fastest UI blur solution on the asset store." It certainly is the fastest solution for a large number of scenarios, but it's not going to be fastest in every situation.
• Flexible Blur provides a superset of the functionality of other solutions, which means that the subset of features that corresponds to a competitor may be less optimized, and that's the cost of flexibility. This isn't to say that Flexible Blur will necessarily be slower when limited to the best case scenario of some other asset (especially if that other asset does not use compute shaders), but rather that everything else being equal, if I were to write a solution with more limited functionality, I would expect that to excel inside its niche relative to a solution that enjoys a wider scope.
• What Flexible Blur uniquely provides is the tools you need to agressively optimize for just about every situation. You should be able to target just about any sort of device. The fine grained control over blur properties generally makes it easier to balance performance and fidelity.