It seems the material buffer is re-created each frame, instead of being reused and only the new content re-uploaded if necessary: https://github.com/JonahPlusPlus/bevy_atmosphere/blob/f85f3a5414862b077164ef8225f1e02ff578fa6d/src/material.rs#L123-L131

On a beefy developer machine I see some ~22ms frame time with bevy_atmosphere, a single cube, and a single tiny UI text showing the FPS. On a more mid-range laptop config this climbs to >50ms. Not sure this create buffer is the cause but it likely doesn't help.

You may already be aware of this, but since WebGL 2.0 isn't standard yet, web builds fail at runtime because there isn't support for compute shaders. I know you just switched over to compute shaders, but is there a way to also support wasm?

Here is the error I get:

panicked at 'wgpu error: Validation Error

Caused by:
    In Device::create_bind_group_layout
      note: label = `bevy_atmosphere_associated_bind_group_layout`
    too many bindings of type StorageTextures in stage COMPUTE, limit is 0, count was 1

When I started this, I didn't know too much about dual licensing, or its benefits. In order to keep this project in line with the Bevy project, I would like to "relicense" this project under the same licenses. I'm going to follow the same path for relicensing as Bevy (see here) and ask every contributor (as of this message and minus the bot) to give their consent by leaving the following comment:

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

Once I get consent from everyone involved, I'll merge this PR. Hopefully, it'll be done by the time I'm finished with the 0.4 release.

Contributor Check-off

• [x] @JonahPlusPlus
• [x] @Shatur
• [x] @cryscan
• [x] @Aceeri
• [x] @kbieganski

Edit: Changed this to a tracking issue.

0.4 update changes:

• [x] Update dependencies to bevy 0.8 compatible versions
• [x] Rename AtmosphereMat to Atmosphere
• [x] Rewrite material creation
• [x] Rewrite shaders in WGSL
  • [x] Create exports for shader module
  • [x] ~~Default feature gate plugin and material resource~~
  • [x] Add noise via hash function to remove banding (been a while, but I think this was an issue)
• [x] Use texture target and update texture when resource updates
• [x] Update LICENSE to be dual-licensed under both MIT and Apache-2.0 (optional, needs consent from prior contributors)
• [x] Update example
• [x] ~~Feature gate dynamic~~

It's a bit unclear which version of bevy_atmosphere is compatible with which version of Bevy. I would suggest following Bevy's own Plugin Guidelines and adding a badge and/or a compatibility table to help users pick the right version of bevy_atmosphere more easily 😊

Bevy 0.6 features a new renderer, so the changes are quite extensive. Mostly just followed the official examples for custom shaders.

In the shader, I put all the uniforms into a single bind group and separated combined fields.

I modified the system that moves the sky sphere to use GlobalTransforms. This is needed for cameras whose position is affected by their parents.

Also changed the way the shaders are loaded. Taken from https://github.com/ForesightMiningSoftwareCorporation/bevy_transform_gizmo/blob/main/src/gizmo_material.rs#L18

In the example, I changed the point light to a directional light.

Updates bevy_atmosphere to use Bevy v0.9

Change Summary:

• Add #[derive(Resource)] for all resources
• Temporarily use https://github.com/BlackPhlox/bevy_flycam until merged into https://github.com/sburris0/bevy_flycam
• Replace spawn_bundle() with spawn() and simplify insert() logic (I've conformed to Option 2 as mentioned here https://bevyengine.org/learn/book/migration-guides/0.8-0.9/#accept-bundles-for-insert-and-remove-deprecate-insert-remove-bundle)
• Minor fixes for the Timer in the cycle example

This is my Cargo.toml:

[package]
name = "projectname"
version = "0.1.0"
edition = "2021"

[dependencies]
bevy = "0.6.0"
bevy_atmosphere = "0.1.3"

And this is the error I get when running cargo run:

$ cargo run
    Updating crates.io index
error: failed to select a version for `syn`.
    ... required by package `darling_core v0.13.0`
    ... which satisfies dependency `darling_core = "=0.13.0"` of package `darling v0.13.0`
    ... which satisfies dependency `darling = "^0.13"` of package `ndk-macro v0.3.0`
    ... which satisfies dependency `ndk-macro = "^0.3.0"` of package `ndk-glue v0.5.0`
    ... which satisfies dependency `ndk-glue = "^0.5"` of package `bevy_asset v0.6.0`
    ... which satisfies dependency `bevy_asset = "^0.6.0"` of package `bevy_audio v0.6.0`
    ... which satisfies dependency `bevy_audio = "^0.6.0"` of package `bevy_internal v0.6.0`
    ... which satisfies dependency `bevy_internal = "^0.6.0"` of package `bevy v0.6.0`
    ... which satisfies dependency `bevy = "^0.6.0"` of package `projectname v0.1.0 ([my project path])`
versions that meet the requirements `^1.0.69` are: 1.0.86, 1.0.85, 1.0.84, 1.0.83, 1.0.82, 1.0.81, 1.0.80, 1.0.79, 1.0.78, 1.0.77, 1.0.76, 1.0.75, 1.0.74, 1.0.73, 1.0.72, 1.0.71, 1.0.70, 1.0.69

all possible versions conflict with previously selected packages.

  previously selected package `syn v1.0.65`
    ... which satisfies dependency `syn = "=1.0.65"` of package `bevy v0.5.0`
    ... which satisfies dependency `bevy = "^0.5"` of package `bevy_atmosphere v0.1.3`
    ... which satisfies dependency `bevy_atmosphere = "^0.1.3"` of package `projectname v0.1.0 ([my project path])`

failed to select a version for `syn` which could resolve this conflict

Updates the requirements on bevy to permit the latest version.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Updates the requirements on bevy_flycam to permit the latest version.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Here is a patch to the examples/cycle.rs file to show the issue. Shadows are turned on to help see the different angle of the directional light and the rendered Sun.

diff --git a/examples/cycle.rs b/examples/cycle.rs
index e52a5f1..4ca88ce 100644
--- a/examples/cycle.rs
+++ b/examples/cycle.rs
@@ -56,6 +56,10 @@ fn setup_environment(
     // Our Sun
     commands
         .spawn_bundle(DirectionalLightBundle {
+            directional_light: DirectionalLight {
+                shadows_enabled: true,
+                ..default()
+            },
             ..Default::default()
         })
         .insert(Sun); // Marks the light as Sun
@@ -94,7 +98,7 @@ fn setup_environment(
     // Spawn our camera
     commands
         .spawn_bundle(Camera3dBundle {
-            transform: Transform::from_xyz(5., 0., 5.),
+            transform: Transform::from_xyz(5., 0., 5.).looking_at(Vec3::new(0., 1., 0.), Vec3::Y),
             ..default()
         })
         .insert(AtmosphereCamera(None)) // Marks camera as having an atmosphere that isn't on a specific render layer

There should be a feature-gate and perhaps a runtime option to disable the automatic rotation. Some games have special scenarios where the skybox rotation needs to be controlled.

I've been looking at the repo, the docs, and some examples, and I'm still unsure how the system works overall.

In previous versions before the rewrite, the plugin recalculated a camera "background" each frame, unless auto-update was disabled in which case it was calculated only once. At least I think.

In this new version, which by the way looks a lot better from what I grasped, it also seems like this is still true? But there was also some mention of "update every 50ms" somewhere, so...?

Then there's the whole "skybox" thing. My two conflicting possible understandings here are:

1. The system calculates one cube map image every so often, then save it into a texture, which is sampled every frame from a giant inverted cube representing the sky. Efficient! But requires quite a big resolution...
2. The system directly writes the atmosphere calculated into the render target of the camera reach frame. Optionally, it can also save that data into a cube map for e.g. IBL, but that cube map is not consumed by the atmosphere system. Maybe less efficient, definitely less memory, more dynamic, forward-looking!

So, not sure which one it is?

I'd be also interested to understand, for optimization purpose, when that rendering to the camera render target happens. I suspect it's not cheap, so would be best done after all opaque rendering, to leverage the depth buffer and reject as much fragments as possible.

I'm really looking forward to integrate this new version in my project, but for now I'm unsure how. Thanks! 😊

Looking in the docs I see https://docs.rs/bevy_atmosphere/0.4.1/bevy_atmosphere/skybox/struct.SkyBoxMaterial.html which has a public field for the skybox texture. So I naively tried to just replace that texture with one of my own (obviously not going to work).

Is it possible to have a custom skybox?

Currently I am adjusting the ambient light brightness based on the directional illuminance.

I would also like to adjust the color the directional and ambient lighting so sunsets for instance become more realistic in my scene.

Would this be possible?