Add RayMarch volumetric cloud?

[GeorgeS2019]

Currently, there is no cloud and could not find a good example of a 3D volumetric Raymarch cloud

[Zylann]

I'm interested in having this, but it should probably be developped as its own plugin, or as part of the atmosphere plugin.

I tried experimenting a bit with clouds already but I wasn't able to obtain good performance for acceptable quality, every time FPS tanked way too hard. Perhaps I need to find a different technique, maybe using more memory and storing cloud data into 3D textures...

[Zylann]

I just added it https://www.youtube.com/watch?v=uzjHcIbDXJQ Developed in this repo: https://github.com/Zylann/godot_atmosphere_shader

[GeorgeS2019]

@henriksod @BastiaanOlij

If both of you have time, please feedback @Zylann implementation => we can combine multiple brains into the challenges discussed by him.

https://github.com/godotengine/godot-demo-projects/pull/938#issuecomment-1656733395

https://github.com/godotengine/godot-demo-projects/pull/938#issuecomment-1656767955

[BastiaanOlij]

@GeorgeS2019 I'm waiting until we can merge https://github.com/godotengine/godot/pull/80214 That will make it much easier to implement some of the post process effects.

[Zylann]

Currently I'm not sure what that API adds that would help here, since the atmosphere effect is already a single pass of either a fullscreen quad or a box not taking the full screen (both running the same shader) without using any viewport (apart from optical depth baking, which is done only once on startup). Unless maybe the API includes, amongst other things:

• Access to depth and other rendering textures from the effect or different passes of that effect
• Allows for multipass/temporal effects, sometimes using different resolutions, which seem to be the next area of improvement when it comes to volumetric clouds (current clouds might work really well, they still lack detail/realism, are quite noisy and relatively expensive considering that there are many more things this demo will need to render in the future on ground)
• Allows to define an explicit order of effects (minor, but is welcome when many effects need to be setup or when they have dependencies)

Another thing I was wondering is making cloud shadows and other kinds of custom shadows (like planet ones so we dont have to rely on a gigantic DirectionalLight shadow distance from afar). Using a custom shader on every node of the game is quite a painful solution (yet spatial shaders can't even affect their shadowed areas directly), when all we need is injecting custom shader code in the area where shadowmaps darken rendered pixels, but I'm not sure what form an API like that would take (might not even be part of a post effect API?).

[BastiaanOlij]

@Zylann I was mostly refering to Georges wish to bring Henriks demo up and his approach would greatly benefit from the new API.

That said, Yes to all three, you have full access to all internal buffers used during (3D) rendering, and you can insert a callback right before the sky renderer does its thing, in this step you have full access to the depth buffers and can add any of your own buffers that will allow you to prepare data you then use when rendering the sky. It just means having your sky shader use the data provided by the RenderingEffect.

The shadow issue is much harder to fix however, it is indeed something that would require serious changes to the build in shader code.

We are working on a system where you can replace the inbuild template code with your own versions but that is a two edged sword, it would allow you to customize the shadow code, but maintaining that with future version of Godot that change the build in system will be a PITA. Well to some extend because we're planning on moving the bulk of the logic into include files that you can also include into your own templates.

That however is a subject for an entire other day when we're more closely to having fleshed out that approach.