Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better (Parallax) Backgrounds #118

Closed
thombruce opened this issue Nov 21, 2023 · 4 comments · Fixed by #120
Closed

Better (Parallax) Backgrounds #118

thombruce opened this issue Nov 21, 2023 · 4 comments · Fixed by #120
Labels
art Improvements of additions to art and music assets
Milestone

Comments

@thombruce
Copy link
Owner

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 thombruce added the art Improvements of additions to art and music assets label Nov 21, 2023
@github-project-automation github-project-automation bot moved this to Inbox in Verse Nov 21, 2023
@thombruce
Copy link
Owner Author

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

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
Copy link
Owner Author

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 thombruce mentioned this issue Nov 24, 2023
5 tasks
@thombruce
Copy link
Owner Author

See #120 for the progress so far.

@thombruce thombruce added this to the v0.1.0 milestone Nov 24, 2023
@thombruce
Copy link
Owner Author

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.

@github-project-automation github-project-automation bot moved this from Inbox to Done in Verse Dec 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
art Improvements of additions to art and music assets
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

1 participant