# Sky3D: a GDScript day and night cycle addon for Godot 4 > Sky3D is a Godot 4 addon that drives sun, moon, stars, atmosphere, fog and camera exposure from a single time of day value, with moon phases and per-node settings that follow the cycle. It is the continuation of the Godot 3 TimeOfDay plugin, revived and ported, and it needs Godot 4.3 or newer. **TokisanGames/Sky3D** — Atmospheric Day/Night Cycle for Godot 4 - Repository: https://github.com/TokisanGames/Sky3D - Stars: 917 · Forks: 70 - Language: GDScript - License: NOASSERTION - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/tokisangames-sky3d ## One plugin owns the sky, so your scene does not need a shader stack Sky3D is a dynamic day and night cycle for Godot Engine 4, written in GDScript. The framing that matters for an adoption decision is what it replaces. A typical hand-built day and night system in Godot means you are animating a DirectionalLight3D for the sun, a second one for the moon, a WorldEnvironment with a ProceduralSkyMaterial, and probably a separate script or shader to keep the sky colour, the fog and the star opacity in step with the time of day. Every one of those is a separate thing to keep consistent, and the consistency is what breaks. Sky3D consolidates that into a set of nodes that drive each other from a single time value. The README lists the consolidated controls for managing lighting and camera exposure, and the management of game time, covering current time, day length, and whether it is day or night. For a small team or a solo developer, having one authoritative clock that everything reads from is worth more than any individual feature here. ## The node tree is the API, and there are six nodes to learn Using the plugin means creating a Sky3D node in your scene, after removing any existing WorldEnvironment node so that the two do not fight over the environment settings. Under Sky3D sit five child nodes, and each is a separate concern you can adjust: Sky3D/Environment, TimeOfDay, SkyDome, SunLight and MoonLight. The environment node holds the atmosphere and fog configuration, the dome holds the sky shader settings, the time of day node holds the clock, and the two light nodes are the actual DirectionalLight3D instances for sun and moon. One detail catches people out and the README calls it out directly. Settings such as light energy, colour and angle on the light nodes are driven by Sky3D and are not directly changeable there, and you know they have been reset when the time updates. To change them you adjust the corresponding settings in Sky3D or in SkyDome instead. That is the plugin working as designed, but if you arrive expecting to tune the sun colour on the light node you will spend an afternoon confused. ## Moon phases come from the cycle rather than from a texture swap you manage The feature list says the sun, moon and stars rotate automatically, with moon phases. That is the difference between a plugin that moves a light and one that models a celestial cycle. A rotating moon light is easy; a moon that shows a waxing crescent and then a full disc is not, because it depends on where the moon is relative to the sun rather than on the clock alone. Shipping phases as a built-in part of the cycle means the phase follows automatically from the time value, and a designer changing the day length does not have to reconcile a hand-authored phase track with the new timing. The stars are part of the same system, so the sky at night is consistent with the moon that is supposedly casting the light. The screenshots in the repository show a windmill scene and a forest scene lit differently, which is the kind of difference that either sells the plugin or does not, depending on your art direction. ## The Compatibility renderer needs two settings nudged to look like Vulkan This is the one real caveat in the documentation and it is handled with a short, specific instruction rather than a vague note. The Compatibility renderer needs a bit of adjustment to show similar results to Vulkan, and the README gives the two values to set: Sky3D / Sky Contribution = 0.75 and SkyDome / Fog / Fog Density = 0.01. That is the kind of documentation note that saves hours, because the alternative is a scene that looks washed out in the Compatibility renderer with no indication of why. The addon supports Godot 4.3 and newer across the Forward, Mobile and Compatibility renderers, so the platform question is answered; what changes is that you apply those two values if you are on Compatibility. Note also that the plugin requires 4.3 or newer, which excludes anyone on an earlier Godot 4 release without an upgrade. ## Installing is copying one folder into addons and ticking the plugin checkbox There is no package manager step and no asset store purchase. You clone or download the repository, open the project in Godot, and run the demo scene to see the cycle before touching your own project: The scene to run is demo/Sky3DDemo.tscn. To use it in your own project you copy the addons/sky_3d folder into your project's addons directory, creating that folder if it does not exist, and then open Project, Project Settings, Plugins and enable the plugin. The addon also carries a default_env.tres resource at the repository root, which is the environment preset the plugin expects to work against, and an icon.png with its import file. Documentation is built into the engine itself rather than hosted on a separate site: look for tooltips in the inspector where available, or press F1 and search for Sky3D, SkyDome or TimeOfDay. For support there is a Discord server. ## Sky3D is the successor to a deleted Godot 3 plugin, which explains some of its shape The credit section carries the useful history. The original version of the plugin, TimeOfDay v1, was made by J. Cuéllar for Godot 3, and the original repository was deleted. The current maintainers revived it, ported the GDScript version to Godot 4, and continued building on it to produce Sky3D. The Godot 3 original is still available on a godot3 branch in the same repository. Two things follow from that. First, you are not adopting something built from scratch for Godot 4, you are adopting a port with several generations of changes on top, and the older branch is available if you need to compare behaviour. Second, the node naming still carries the older design, which is where the SkyDome, TimeOfDay, SunLight and MoonLight structure comes from. The developer credit goes to Cory Petkovsek of Tokisan Games, along with the contributors listed in the repository, and the project is presented as developed for the Godot community. ## Licensing is MIT for the addon with a separate credit condition on the star maps The README states that the addon has been released under the MIT License, with the licence text in LICENSE.txt at the repository root. The licence field on the repository carries a custom licence that GitHub cannot classify, so the file in the tree is the reference for the actual terms rather than the repository listing. There is also a separate condition on one specific asset. If you use the star map textures, you must credit the author, and the README links the licence and attribution for those third party textures inside the addon's assets directory. That is a narrower obligation than the plugin licence itself and it applies to a specific asset rather than the code, but it is the kind of thing that is easy to miss and awkward to unpick later if you have already shipped a build. Nothing here is legal advice; read LICENSE.txt and the asset licence, and if you are redistributing, check both. ## Where Sky3D is the wrong tool Two situations stand out. The first is a project that needs a fully custom sky, such as a procedurally generated nebula, a volumetric cloud simulation or a multi-planetary orbital model. Sky3D models one planet with one sun and one moon on a fixed cycle, and the whole design depends on that. Driving its time value from your own simulation is possible, but you are then the source of truth and the plugin is a presentation layer, not the model. The second is a project that only needs a directional light to dim at night. That is a ten-line script with an AnimationPlayer, and adopting an addon means accepting its node tree, its environment expectations and the rule that the WorldEnvironment node must be removed. For a small scene that is a reasonable trade. For a small scene that only wants a darker night, it is not. ## Conclusion Sky3D suits a Godot 4 developer who wants a working day and night cycle in a scene today, and who is comfortable with the fact that the lighting values on the light nodes are driven by the plugin rather than edited directly. It does not suit a project that needs more than a sun, moon and stars, or one still on Godot 3, since the addon requires 4.3 or newer and the Godot 3 original lives on a separate branch. Before you adopt it, run the demo scene to see the cycle on your own hardware, read the README note about the Compatibility renderer settings, and check the licensing terms in LICENSE.txt, since the licence field on the repository carries a custom licence while the README describes the addon as MIT and the star map assets carry their own credit requirement. ## FAQ ### How do I install Sky3D in a Godot project? Copy the addons/sky_3d folder into your project's addons directory, creating it if missing, then open Project, Project Settings, Plugins and enable the plugin. The plugin supports Godot 4.3 and newer on the Forward, Mobile and Compatibility renderers. ### Why can I not change the sun colour or energy on the light node? The README states that settings such as light energy, colour and angle on the light nodes are driven by Sky3D and are not directly changeable there, and you know they have been reset when the time updates. Adjust those values in the Sky3D or SkyDome node instead. ### Does Sky3D work with the Compatibility renderer? It is supported, but the README says the renderer needs a bit of adjustment to show results similar to Vulkan. The two settings to change are Sky3D / Sky Contribution = 0.75 and SkyDome / Fog / Fog Density = 0.01. ### What licence applies to Sky3D and its star map assets? The README says the addon is released under the MIT License with the text in LICENSE.txt, though the licence field on the repository carries a custom licence GitHub cannot classify. The star map assets are separate and require you to credit their author if you use them. ## Sources - [Issues](https://github.com/TokisanGames/Sky3D/issues) - [README](https://github.com/TokisanGames/Sky3D/blob/main/README.md) - [Releases](https://github.com/TokisanGames/Sky3D/releases) - [TokisanGames/Sky3D on GitHub](https://github.com/TokisanGames/Sky3D) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tokisangames-sky3d