unity-frosted-glass icon indicating copy to clipboard operation
unity-frosted-glass copied to clipboard

Make blur distance independent of resolution & FOV

Open omgitsraven opened this issue 7 years ago • 5 comments

Previously, the image would always be blurred by a certain number of pixels, which meant that as the resolution increased, the apparent amount of blur (relative to the world/image) decreased (by staying the same as the resolution went up).

This new approach takes the resolution and FOV into account when determining how far across the texture to sample for the blur; this means that a given view of the world will always look (essentially) the same regardless of how "big" it's rendering.

The one problem that this fix reveals, is that for a sufficiently high resolution (or sufficiently narrow FOV), the step between blur samples may be noticeably larger than a single on-screen pixel, which would introduce a visual 'echoing' effect. In this case, the blur step distance value may be decreased until the problem is no longer visible -- the only downside to this is that doing so will decrease the distance over which the image is blurred (in world terms), which may be undesired. (This could be compensated for by adding more blur iterations, but as that's hardcoded into the shader as well as the CommandBuffer, there's no simple way to change that without manually editing the shader's code, as far as I'm aware.) Of course, users can also choose to adjust the blur step distance for purely aesthetic reasons, to change the range of possible amounts of diffusion that the values in the texture correspond to, so that's just a fun freebie :)

omgitsraven avatar Jun 22 '18 01:06 omgitsraven

(edit: this is now fixed, see below)

Just FYI, the more I look at this in real-world scenarios, it seems to have a slight screen-aligned aliasing issue (which is extra noticeable in VR), that I'm not sure how to approach fixing... I think it's still an unambiguous step up over the previous screen-relative blurring, but I might be opening an issue for my own code once this is accepted, in hopes that someone with a bit more knowledge of these things can tweak its look just a bit more :)

omgitsraven avatar Jun 22 '18 01:06 omgitsraven

hang on, I might have found A) a workaround, and B) an unrelated issue that only happens in VR :) Stay tuned.

omgitsraven avatar Jun 22 '18 01:06 omgitsraven

Hahahah, the "unrelated issue" was NOT unrelated at all, it was in fact the cause of the quality problems I was seeing too. Glad I caught that. Quality is now perfect in VR as well as in 2D, no more screen-space aliasing, no "quality" fixes needed after all. Good to go.

omgitsraven avatar Jun 22 '18 02:06 omgitsraven

Not to be a pest, but is anything wrong with this PR? (Only asking because the last one went in right away..)

omgitsraven avatar Jun 25 '18 17:06 omgitsraven

@omgitsraven I was quite busy recently and didn't had much time to review this PR, will do this week.

andydbc avatar Jul 03 '18 14:07 andydbc