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

Add RayMarch volumetric cloud? #12

Open
GeorgeS2019 opened this issue Jul 19, 2023 · 6 comments
Open

Add RayMarch volumetric cloud? #12

GeorgeS2019 opened this issue Jul 19, 2023 · 6 comments

Comments

@GeorgeS2019
Copy link

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

@Zylann
Copy link
Owner

Zylann commented Jul 19, 2023

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

Zylann commented Aug 8, 2023

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

@GeorgeS2019
Copy link
Author

@henriksod
@BastiaanOlij

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

godotengine/godot-demo-projects#938 (comment)

godotengine/godot-demo-projects#938 (comment)

@BastiaanOlij
Copy link

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

@Zylann
Copy link
Owner

Zylann commented Aug 9, 2023

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

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants