SunshineClouds2: procedural volumetric clouds for Godot

What the add-on is

SunshineClouds2 is a procedural cloud system for Godot 4.4 and later, written as an add-on, and it is the second version of the author's earlier work.

The features list gives the case for it. The clouds are fully volumetric, and extendable as far from the camera as you want with the correct settings, which is the property that separates a volumetric system from the billboard clouds most engines ship with. Setup is described as easy, coming down to about three clicks once the add-on is installed. The performance claim is handled with a specific mechanism: resolution options with upscaling and depth handling, which allow soft clouds at low resolution that you can still fly through. The visuals can be soft or cartoony, with styling options for a wide range of results. And the clouds are entirely procedural, or you can paint them in with the editor tools, being able to paint in density as well as colour so that you can tint clouds differently depending on the region.

That last item is the one that makes this more than a shader preset. A purely procedural system gives you a statistically generated sky, and a painted system gives you a diorama. Being able to do both, and to paint density as well as colour, means the same system serves a flight simulator's sky and a stylised scene with a hand-placed cloud bank, and the difference is in the authoring step rather than in a separate asset.

The painting is worth one more detail, because it explains a file in the repository root. There is an image file with an environment map extension and its import sidecar, and there is a resource file for the new clouds node. Those are the baked artefacts of the system: the mask that says where the painted density is, and the resource the driver node points at.

The project is MIT licensed, the last push was on 2026-09-27, and there are no tagged releases, so the add-on is distributed through the engine's asset library and the repository. There is a beginner tutorial and a half hour deep dive video, and the author also runs a community space for questions.

The version history, and what a rebuild means

The updates section is the most informative part of the readme, because it shows what the project has been through.

Version 2.0 was rebuilt from the ground up to use the engine's compositor system, which the author says improved performance and visuals. That is a big change to make to a visual add-on, and the reason is instructive: the compositor is the part of the engine that owns what gets drawn and when, and a system that renders a volumetric effect through it can integrate with the rest of the scene lighting and depth in a way a system that draws on its own cannot.

Version 2.1 was mostly bug fixes, following an asset release on the asset library. Version 2.2 was larger: a lot of bug fixes, more sampling functionality, support for Apple hardware through the Metal backend, better support for AMD hardware, improved performance, and automatic handling of version changes.

That last one deserves a note. An add-on that talks to engine internals, and that bakes a resource, breaks when the engine changes underneath it. Handling those version changes automatically is the difference between an add-on that keeps working and one that the user has to reinstall after every engine update, and it is the kind of maintenance that never appears in a feature list but decides whether the project has an audience a year later.

The jump from 2.2 to 2.7 is where the author admits the list is too long, and then names a few. There is support for multisample antialiasing, a slider for compatibility with the engine's own fog, view distance discarding that lets a camera's far clipping plane be shorter without affecting the cloud rendering, a lot of performance increases inside the compute shader itself, and a minor overhaul of that compute shader.

The multisample antialiasing work and the shader overhaul were done by a community contributor, and the author names them and thanks them. That is worth noting for a project of this size, because a compute shader that renders volumetric clouds is the part with the most room for a skilled contributor to make a real difference, and the credit is recorded in the readme rather than only in the commit history.

The view distance discarding item is the most interesting technically, and it is the kind of problem that only shows up in a real project. If the camera's far clipping plane is pulled in for performance, everything beyond it is discarded, and a cloud system that renders at long range would lose the distant sky. The fix lets the cloud rendering ignore that limit, which means the artist can shorten the clipping plane for the rest of the scene without changing the sky.

The seven step setup

The installation is seven steps, and the readme's framing is that setup comes down to about three clicks, which is not quite the same thing as seven steps. The difference is that six of the steps are configuration in the editor and one is a download.

You download the add-on, either from the repository or from the engine's asset library by searching for its name. Then you activate the plugin, which is the Project menu, the Project Settings, the Plugins tab, and the entry for the clouds. Then you add the driver node to your scene. Then you make sure the scene has a world environment in it. Then you press the generate resource button on the driver. Then you add a directional light to the tracked lights array on the driver.

The two steps that are not obvious are the third and the fourth. The driver node is the control surface for the whole system, so it has to be in the scene. And the world environment is a requirement rather than a suggestion, because the system needs the scene's environment to know about fog and about the light, and the setup list says to ensure it is present.

The last step is the one that connects the clouds to the sun. A directional light is added to an array on the driver, and the name of that array says what it is for: the lights whose direction the clouds track. So the clouds are lit by the same sun as the rest of the scene, and adding a second directional light is how you get a second set of shadows or highlights without a second sun in the sky.

The generate resource step comes before the light is added, which is a small ordering detail that would otherwise cost somebody a rebuild. The resource is a separate artefact, and it carries the baked state, so it is generated from the settings at the moment you press the button rather than continuously. If you change a setting afterwards, you have to generate it again, and the fact that the button is a separate action rather than an automatic thing is what makes that visible.

And the closing step of the list is worth quoting for its tone, because it says the whole thing in two words: have fun.

Performance, and what the resolution options really do

The performance feature is described in one line and needs unpacking, because the way it is phrased is unusual.

The claim is that the author uses resolution options with upscaling and depth handling, which allow for soft clouds at low resolution that you can still fly through.

Three things are bundled there, and each solves a different problem.

The resolution scale is the obvious one. Rendering volumetric clouds at full screen resolution is expensive, because the cost is proportional to the number of pixels and to the number of steps taken through the volume. Rendering the cloud pass at a fraction of the resolution and upscaling the result cuts the cost by the square of the scale factor.

Upscaling is what makes that acceptable. The reason a low resolution volumetric render usually looks bad is that the cloud edges are hard, and the result reads as a blocky mess rather than as cloud. A proper upsample reconstructs a smooth result, and the author is claiming that with the right settings the result is soft rather than blocky, which is a much stronger claim than simply being cheaper.

Depth handling is the third, and it is the one that makes the flying-through case work. A volumetric cloud has a depth, and a screen at a given pixel can contain cloud in front of and behind other geometry. If the depth of the cloud is not tracked properly, then when you fly through a cloud, the geometry inside the cloud appears in front of it, or the cloud appears in front of the geometry that should be behind it. Handling depth means the cloud integrates correctly against the rest of the scene.

This is also where the range claim from the features list comes in. The clouds are extendable as far from the camera as you want, with the correct settings, and the view distance discarding work in the recent updates is what makes that possible when the camera's far plane is short. So the two features are connected: a long cloud range needs the cloud rendering to be independent of the camera's clipping distance.

The performance work inside the compute shader, mentioned in the update notes as a set of increases, is the third leg. Everything about this system happens in a compute shader, and the arithmetic in a volumetric integrator is a loop over samples through the volume, so the cost is a multiple of the sample count. Reducing the cost per sample, and reducing how many samples are needed for an acceptable result, is where the gains come from.

Painting clouds, and the editor workflow

The painting feature is the one that separates this add-on from a preset, and the readme describes it in two clauses that are worth separating.

You can paint in clouds using the editor tools, and you are able to paint in density as well as colour, to tint clouds differently depending on the region.

So there are two channels. Density is where the cloud is, and colour is what it looks like where it is. The two being separable is what makes the difference between a cloud that is white in one place and grey in another, and a cloud that is simply lighter or darker overall, which is what you get if you can only paint one channel.

The region qualifier is the important part. Tinting by region means the effect follows a shape rather than a screen position, so a painted cloud bank keeps its colouring as you fly past it, which is the difference between an art asset and a projection.

The files in the repository root explain the implementation. There is an image file with an environment map extension, which is the format the engine uses for floating point image data, and it is the mask: the density and colour you paint. It has an import sidecar, which is the file the engine writes when it processes the image, and that file is committed, which means the import settings travel with the asset rather than being regenerated differently on each machine.

There is also a resource file for the driver node, which is the saved configuration of the system, and it is committed for the same reason.

The repository also contains a full Godot project rather than only an add-on. There is the project file, an export configuration, a directory for the add-on itself, and a directory for the images used in the readme. And there are the built artefacts of a Windows export: an executable, a console variant of it, and a package file, which is what you get from exporting a project.

That last detail is worth pausing on, because it means the author ships a runnable build of the test scene so that you can see the effect before you install anything. For a visual add-on where the difference between the right settings and the wrong ones is a matter of taste, being able to look at a reference implementation is worth a great deal.

The open problems, and how the project is run

The readme ends with a list of current outstanding issues, and it is short and specific, which is the mark of a project that knows what it has not done.

The first is screen space shadows. That is a specific and expensive thing: a shadow computed by tracing the scene depth buffer rather than by rendering the light's view, and it is what lets a cloud cast a shadow onto the ground below it, or let the sun be occluded by a cloud.

The second entry is the more interesting one, because it is about waiting for something in the engine rather than about doing the work. When shadow cookies are available, the work can proceed. A pull request for them is currently live in the engine repository, and the author will pursue the implementation whenever it is merged.

So the author is blocked on an upstream feature, has the pull request open, and is explicit about the dependency rather than quietly shipping a partial version. That is a good way to run an add-on, and it also tells a user something important about the timeline: the shadow work is not going to arrive until the engine change does.

The contribution section is warm and informal, and the ask is specific: pull requests and issues are welcome, the author will fix them as able, and questions can go to the community space. The closing line thanks the people who support the project.

The licence is MIT, and the plugin is released under it. There is also an editor configuration file and a git attributes file in the repository, which are the marks of a project that has been through a few contributors and has picked up the usual habits about formatting and line endings.

Taken together, the project is a piece of visual work with an unusually honest changelog, a real contributor credit, a named upstream dependency, and a shipped reference build. The reason it exists is the one in the readme's own tone: the author wanted clouds they could fly through, and shipped the tool that makes them.

Editorial conclusion

SunshineClouds2 fits a Godot project that needs skies with real depth, whether that is a flying game, a driving scene, or a first person walk where flat cloud cards fall apart. It does not fit a project on an engine version older than 4.4, and it does not fit a mobile project with a tight frame budget unless you are prepared to spend time on the resolution and distance settings. Verify first that the clouds node sits in a scene with a world environment, because the setup list makes that a requirement rather than a suggestion, that the directional light you want the clouds to respond to is added to the tracked lights list, and that you generate the cloud resource after changing the settings, since the resource is what carries the baked state.

Frequently asked questions

Official sources

1. Bonkahe/SunshineClouds2 on GitHub
2. Issues
3. License: MIT
4. README