Add background blur

[dligr]

Brief Description of What This PR Does

Adds a Gaussian blur to microbe backgrounds (only enabled if distortion is on).

Related Issues

Closes #5641

Progress Checklist

Note: before starting this checklist the PR should be marked as non-draft.

• PR author has checked that this PR works as intended and doesn't
  break existing features:
  https://wiki.revolutionarygamesstudio.com/wiki/Testing_Checklist
  (this is important as to not waste the time of Thrive team
  members reviewing this PR)
• Initial code review passed (this and further items should not be checked by the PR author)
• Functionality is confirmed working by another person (see above checklist link)
• Final code review is passed and code conforms to the
  styleguide.

Before merging all CI jobs should finish on this PR without errors, if
there are automatically detected style issues they should be fixed by
the PR author. Merging must follow our
styleguide.

[dligr]

Some screenshots:

[hhyyrylainen]

Could this be implemented as a second render pass or directly baked into the background shader? I ask because we'll hit a rendering performance problem at some point if we just throw subviewports at any problem.

[dligr]

Actually, it seems possible to re-implement this without viewports. I've just found out that it's possible for a shader to get it's texture from a CanvasLayer instead of a viewport (the docs), which should be more performant.

[hhyyrylainen]

In case that's not usable, I think putting the blur code directly into the background shader would be the right way to go. That would also quite neatly I think expose how expensive in terms of texture reads it is actually to perform a blur.

Edit: and as an added benefit the blur could be only applied to the layer that has the distortion on it (so only layer0).

[dligr]

Putting the blur code into the background shader would be bad for performance, because it would then need n*n texture reads (for blur diameter of n), and for each of those reads it would also need to calculate distortion.

The current implementation does blur in 2 passes (vertical and horizontal), and because of that only needs 2*n reads. This difference in calculation costs should probably compensate for viewports' performance.

[hhyyrylainen]

Still it will now blur the moving bubble layers that are separate from the furthest background layer as well, which is probably not the best. Also it could maybe be possible to use a cheaper blur method combined into the distortion math to do a reasonable enough blur with high performance at the same time as applying the distortion math?

I guess I'll let you investigate first what is actually possible to do before dumping more ideas.

[dligr]

Apparently the way of making multi-pass shaders with CanvasLayers requires reading the screen texture, so there still needs to be at least one viewport.
The background plane can also be optimized into a ColorRect (which needs a scale argument passed to it, but it's probably still more performant than rendering 3D geometry).

This is what the resulting scene hierarchy looks like:

[hhyyrylainen]

After thinking about the situation more: I guess the most optimal way to implement this feature is to use the subviewports, but I think that to balance that out we should add a graphics option to control the blur amount and if the blur is zero the subviewports should be skipped entirely so that the game is no slower than it currently is on computers where rendering to texture ends up harming performance a lot.

[dligr]

I've made the background plane change it's parent in the node tree to either the SubViewort or the camera depending on if blur is enabled. Blur planes' viewport texture is also being removed when blur is off, as it seems to be the only way to disable subviewports rendering.

I have also moved all microbe background-related logic to a separate class as keeping it in the camera class wouldn't be clean.

[hhyyrylainen]

Doesn't subviewport have the render mode property that can be set to none / never to disable rendering it? At least I recall doing something like that with the PhotoStudio where I can trigger the subviewport it uses to render just a single frame and then auto-disable.

Well the camera class is called MicrobeCamera, but I suppose separating out the complex background handling is a good idea anyway.

[hhyyrylainen]

I had just that one minor comment about the code for now, so the code so far written now looks good to me. I didn't notice any of the viewport resizing etc. code or allowing blur even without distortion enabled, so I guess those aren't done yet? I think it would take a bit of crunching if this is to make it into 0.8.0 so it is fine if this needs more time in a relaxed manner to get done, which I'd also prefer as I'm still not fully done with the re-added mac support so it would be a pretty big squeeze to fit this into 0.8.0.

[Deus-Codes]

Looks really nice. I think it might be worth it to increase background distortion speed now, as the movement of the background is even less obvious now. The blur should help alleviate worries of disorientation we had before, where the background might have moved too fast for the eye to be comfortable with.

This isn't relevant to this pull request, but in the future, it would be nice to create some sense of depth, as it can sometimes seem obvious that the background is the background and the plane the cell is on is the foreground.

[hhyyrylainen]

I think that as the blur might be performance sensitive, we need either a toggle for the blur to be lower resolution. Or we should allow separately toggling the blur and distortion effects so that someone on a lower power device can still play with the distortion on even if the blur takes too much performance.

[dligr]

Maybe it would be a good idea at this point to make a separate graphics options section for the microbe background? It would probably be more clear that way, and would allow not writing "background" before each of the new options' labels

[hhyyrylainen]

Yeah that probably makes sense. Translation keys should still be clear and include the context that they are about a game background for translators to be able to translate correctly.

[revolutionary-bot]

We are currently in feature freeze until the next release.
If your PR is not just a simple fix, then it may take until the release to get reviewed and merged.

[revolutionary-bot]

The lead programmer for Thrive is currently on vacation until 2025-01-07. Until then other programmers will try to make pull request reviews, but please be patient if your PR is not getting reviewed.

PRs may be merged after multiple programmers have approved the changes (especially making sure to ensure style guide conformance and gameplay testing are good). If there are no active experienced programmers who can perform merges, PRs may need to wait until the lead programmer is back to be merged.

[hhyyrylainen]

I've now again reviewed all of the code here and it all looks good to me. There's just the problem of the missing render target size update code. I think it would be good enough to update it like 5 times per second if the window size has changed and call that good enough so that this PR can finally get merged.

[dligr]

I have added the resolution updating. I decided that it's better to update the resolution at 1 second intervals though, so that there is less artifact flickering.