Day/Night Cycle with Procedural Scattersky

I’m putting a strawpoll here to help me determine which of these two features you would prefer for me to focus on next. Please read the second to last paragraph to understand exactly what each would involve and require before voting (http://strawpoll.me/6632748).

Okay, sorry for the delay without any further significant update, but I started working on one of the features I’d promised in December and really wanted to get it working as a functional prototype before doing anything further. Here’s a video of it being shown off with some music generously contributed by OnlyWednesdayMusic. What this feature is is mainly a skydome with the sky’s colour and atmospheric scattering determined through algorithms rather than a static cubemap as it was before, primarily Rayleigh and Mie which are a tried and tested approaches to a feature like this. To my knowledge, this is the first time such a feature has been implemented in the Godot engine, and while some aspects of this implementation were inspired by the implementation in the Torque 3D engine, it is mostly implemented from scratch in the engine’s own intermediary shader and scripting languages.

This feature should be easy enough to implement in anyone’s Godot project now, but the only exception is two features exclusive to my fork of the Godot engine, that is the ability to create a single render viewport out of multiple cameras ordered with a new ‘depth’ property, and the ability to tint the baked lighting in realtime for the full effect. The way it is structured is there is another spatial scene in the root of the tree which contains the skydome, the sun model, another camera, and a directional shadow-mapped light which acts as the primary light source for an entire scene. This scene is hooked into the already existing timeflow system which determines the state of clocks in the world, and then I use node groups (which is a very useful feature in Godot I wasn’t even really aware of before hand but really helps in managing such complex game logic) to update the skydome state. The first thing it does is run this information through an algorithm which, along with specifying a latitude and longitude value, theoretically provides the correct azimuth and elevation properties of the sun for a particular time of day based on where the scene would be located in the world, I then take that information and use it to determine direct and ambient colour based on customisable colour ramps, the direction of the sun, ect., and use this to map the appropriate values. Finally, I update the sky shader uniform with this information and apply the scattering algorithms in order to determine the final colour of the sky, which is rendered first and the rest of the scene rendered on top of it.

The sunsets can actually look quite appealling at times.

There are still some issues which I would like to tweak and polish further, but on the whole, I think it looks quite convincing for what it is. I still plan to include clouds and precipitation as part of this system, and while clouds should be fairly easy to do, precipitation will be more of a challenge due to the feeling that it would need to affect materials in the world itself to truly look convincing. Two more pressing issues I’m still working through are the facts that the character shaders have some serious problems when rendered at night time (basically coming out practically all black), and that since shadow mapping is largely a brute-force rendering technique requiring the scene to more or less be rendered twice from an orthogonal angle, the performance issues are again a large concern depending on the direction of the sunlight. I’ve also switched the default shadow mapping algorithm from PCF to ESM due to the shadows looking slightly off at certain angles, though you’ll be able to easily switch back to PCF even though that is not the primary source of the game’s performance issues; they still seem to be mostly related to scene traversal and skinned mesh rendering.

Now this brings me onto another participation-related request. Usually I have to take authority on where my efforts are going to be focused simply because I feel it’s necessary to develop a game as complex as this somewhat as a pyramid of features, focusing more on the foundation before implementing more game-specific elements, meaning a lot of the time I feel obligated to focus on one feature before it feels appropriate another as it would depend on the existence of the previous feature. In this case, this feature opens up a lot of possibilities of implementing stuff in the game related to time management. The core of the game, while more open-ended than most similar dating sims, is still going to based around balancing stats over the course of ingame months and even years, and having the game visually change to convey that certain actions results in time passing should help make these mechanics more convincing and impactful, as well as making the world feel more dynamic and realistic.

Exploring the school at night time gives it a very different atmosphere. It actually feels slighty foreboding now.

That being said, I am now at a situation where I could focus on two main areas: I could continue to attempt to implement gameplay related activities which would include things like attending classes, studying, travelling between locations, and balancing stats over the course of several ingame months, and this feature, along with the fact that the protagonist’s apartment is mostly finished and just pending being prepared for the game itself, would make this viable direction to go. The other option is to attempt to implement something which I was going to hold off until later due to the perceived scope and complexity of what I wanted to get out of this feature, but would consider pushing it forward due recently discovering a quirk of the engine I might be able to exploit in order to cut out a ton of effort required to make this feature as powerful and flexible as I wanted. The game already has a rudimentary visual novel parser based off the Ren’Py scripting language, and it’s used right now for examining objects but not much else. The main thing that Ren’Py has that my implementation does not have is the ability to embed native Python code inside of the scripts which is what makes it so powerful. While it does not use Python, it does use a very similar language, and I may have discovered a way to dynamically execute native script code inside my custom VN script files in the same that Ren’Py does. This would automatically give me the full power of the game’s scripting language inside my custom Ren’Py-esque implementation without the need for any fancy parser of virtual machine which could potentially save a ton of effort and give practically unlimited flexibility. In fact, while I won’t promise anything, this may even result in the visual novel aspect of the game becoming robust enough that it could be spun off into its own independent project, giving VN creators access to familiar framework built on the foundation of a powerful, 3D-capable engine. Getting this feature in would primarily require three things: implementing this ability to embed native script code, creating some new idle animations, and writing some script for said scenes. I consider both of these features equally important to the overall experience, but I’m going to let my readers help determine what I should focus on first. I was going to add optimization overhauls as one of the potential options, but I decided I’d rather focus on something which would result in something more gameplay-related first, and neither feature should result in any further significant performance implications.

I still intend to put out another playable update of the game soon, but I feel I need to solve some of the newly introduced issues beforehand.