Better (Parallax) Backgrounds

[thombruce]

I've just reimplemented Parallax Backgrounds (#117) since removing a crate that previously did this for me. My solution allows for parallax backgrounds to be layered and move at different rates, but we're currently only using one layer.

To implement better backgrounds, we should:

1. Add a second layer with cloud-like nebulae drifting across the distant starry background
2. (Optionally) add a third layer with local space dust

Consider also whether or not the parallax implementation as it stands can at all work outside of the scope of our current single star system instance - we should be able to change the background in different regions of space. Eventually, we should also be able to generate the background procedurally as we go (use noise to do this?).

[thombruce]

There appears to be a regression in the WGSL analyser plugin I'm using in VSCode:

• https://github.com/wgsl-analyzer/wgsl-analyzer/issues/108
• https://github.com/wgsl-analyzer/wgsl-analyzer/issues/100

Despite having configured the list of wgsl-analyzer.customImports in my VSCode workspace settings, these are apparently not found and the analysis is therefore outdated and not massively helpful...

Might have to put a hold on new backgrounds until this is resolved. 🤔

[thombruce]

Having toyed a little bit with a shader borrowed from Kataster here, it actually didn't take a lot to get it working. The only change required was to modify the import path, and given that I had already compiled a list of shader imports for WGSL analyser this was easy to find and change what needed to be changed (just the name of the imported item)...

Actually, on observation, this has been brought up to date in the main Kataster branch too. My local copy is stale...

Anyways, the shader works. It just isn't quite what I need... and naturally I would like to understand it better (the effect is pretty bloody impressive for a small amount of code).

I would like to toy with the values a little and see what changes as I tweak the shader code.

I would also like to consider whether we can make the shader position-variable rather than time-variable... That is to say that... if we could ensure that the background mesh followed the camera centred on the player, and extend its shape up to or over the maximum zoom scale... could we feed it the player's X and Y coordinates and update the shader accordingly as the player moves?

Having asked that question, the first thing I now notice is that the time value is not actually native to any Bevy component - instead, both the shader and the module implementing it are defining a custom asset struct (BackgroundMaterial) which contains time as an attribute. The time value is updated by an update_background_time system. So we could certainly extend this to also update a Vec2 with the position of the player... These values could be used in place of or extending the time values in this line:

from_ = from_ + vec3<f32>(time * 2., time, -2.);

...and that should achieve something like what I'm after. _Because the shader itself is a continuous... "thing"... the gradual change in X and Y coordinates should result in a similar effect of motion to the time values currently being used.

Then, yes, so long as it follows the camera/player, what we should then have is a fixed-in-place mesh that appears to be a moving background.

Once we have that, we can just adjust some of the values to our liking.

Do be wary though that changing the scale of the mesh (which is currently how we dictate its coverage of screen space) does distort the results of the shader - the shader clearly having been written for a fixed size/aspect-ratio. This needs to be addressed somehow, as we will ultimately want to render the game at different window sizes and aspect ratios for all of which the apparent effect should be consistent... I'm sure one of the variables in the shader code has some control over this (maybe scale) but we should remain aware that the mesh may need to be of a fixed aspect-ratio and size, which raises other questions about how it ought to respond to camera rescaling (zooming in or out).

All of that said... though the code isn't necessarily clear, it is brief and that gives me some confidence that I can tweak this and learn how it works. I think I can get it to achieve the results I'm after and learn from it in order to implement similar shaders for planet generation a ways down the line (assuming we want something like this - landable planets in-particular might require a different approach for their terrain generation, but might well use something like this for their atmospheres).

[thombruce]

See #120 for the progress so far.

[thombruce]

Added to v0.1.0 milestone because the PR #120 is pretty much ready to go.

If I were to criticise it at all... I would say the pixel planets we've been using now no longer look the part. These were always only temporary, but it gives us cause to talk about something I have been thinking about for a little bit - I now longer think the pixelated look is the final look. For interiors and planetary surfaces... still maybe, but for space I think a simpler and prettier style is going to be something smoother.