Since the very beginning of the project, we have focused a lot in the side of the factory, providing better designs for the machines, and expressive animations that give a sense of life and credibility in this area. We put a lot of effort also in the environmental side, adding different tile sizes, improving textures, adding doodads, cliffs, trees, decals, and constantly improving the map generation for a better feeling.
But apart from biters and the factory, nothing else moves in this Factorio planet. So the environment is nice looking but it feels somehow unreal due this lack of motion.
Today we proudly present the first experiment in this area: Animated water. This animation doesn't try to grab your attention, it's just there. Slowly moving. I personally bet that this animation, with the proper sound design, will provide the natural feeling that the planet needs.
Animation was always one of the most powerful creative tools we have. Animation is how we communicate with our audience about functionality, it creates interest and emotions people like. So let us talk about water and how the current representation might be missing something. Some of you with an eye for detail might have noticed that water in Factorio is static. It has foam, which is static. There are also some static reflections. Due to the fact that making animated water was considered polishing, we never took the time to make an actual solution.
But now we are polishing Factorio, trying to make it as beautiful as we possibly can given our constraints. I am glad to talk to you a bit about us solving animated water!
Christmas of 2018, I decided to gift myself with solving water animation in secret. Based on past conversations with Albert the goal for it was clear:
In the past I was experimenting with this cheap clouds shader. It used fractal Brownian Motion and only sampled a noise texture, instead of the usual approach of calculating Perlin noise. With a low iteration count, it was almost as cheap as drawing a sprite. So I started MonoGame (lovely framework) and implemented a tile-based world using the same technique for the shader, the only difference being I clamped noise values to simulate brighter and darker areas. For the noise I used our water sprite.
Original - Noise - Clamped
To save GPU power, water was drawn the same as tiles, one after another. The position was easy to solve also, I simply used UV coordinates to represent the game world position. With some trial and error, water was recreated with a moving effect.
At the beginning of 2019, I pitched the prototype to the team. Sadly it was not really accepted mostly because of the movement. However, I sat down with Albert and talked and tweaked values to more appealing ones. After that, we basically forgot about it. Half a year passed and that solution was back on the table, I only had to solve reflections, foam, transparency, out of map transitions, and some other stuff.
Solving reflections, transparency and foam resulted in using a render target to save information for water shader. A render target is just a texture on which you can draw. Using three channels RGB, I am able to save three kinds of information. Red for reflections, green for transparency, and blue for foam. All drawing is additive to account for multiple tiles drawing on top of each other. This way we are able to add information not only for shore, but also for entities.
For out of map we updated our jelly feeling with waves on top. Basically we left the old graphics on the bottom and added animated water on top. For cutting/masking out water where we want, I used another shader that generated green waves in the water render target. Now some of you might ask why we did not use a waterfall. I mean it would look nice having a waterfall to this pitch-black hole of nothing. The reason is waterfall was the first thing we tried, and concluded that the jelly looks better and cleaner.
For a long time, in order to make terrain rendering fast, we would keep an offscreen buffer with terrain that was rendered in the previous frame, and reuse it to render terrain in the current frame. If the players view didn’t change at all, we would use the offscreen buffer as is, if the player moved, we would shift the buffer accordingly, and render just the bits that were not visible before. Zooming or changing tiles in the view would invalidate the content of the offscreen buffer, and the terrain would have to be re-rendered for the entire view. But that happens only in a fraction of frames, so it’s not a big problem.
You may have noticed this optimization is incompatible with rendering animated tiles, so for the initial integration of Ernestas’ water effect, I had to force a full redraw every frame.
This created a performance issue, as the tile render prepare step would take up 3ms (almost 1/5 of total frame time) when zoomed out. Why does that matter?
The game’s main loop runs in 3 major stages:
Luckily, I already had an idea how to solve this. The water animation depends only on global time, and the vertex data of water tiles doesn't change in between the frames, so instead of caching the finished terrain render in a texture, we can cache the data resulting from prepare render, which we call draw orders. To make it work, we cache draw orders per-chunk, and we only run prepare render on chunks that have just entered the player view (and weren’t in the cache already).
That pretty much solves the problem of the render prepare and has some nice side benefits. First of all, changing render scale doesn’t need to invalidate the new cache, so zooming doesn’t cause prepare render to run for all tiles in the entire view. Secondly, it creates opportunities for other future optimizations - for example, we can start caching tile draw orders that are likely to enter into the view in advance and spread this work over multiple ticks, or we can generate tile draw orders for each chunk in parallel as they are independent of each other now.
Even though the water effect is relatively cheap, some of our players play the game on really weak hardware, which already struggles with the current state of the game, so we needed to add an option to turn the effect off and essentially revert back to the old behavior. Initially I thought we would even use the old water sprites, but because we had to change the tile transition definitions, the old water would look really bad. I have decided to always render water using the new effect, but if you disable the animation, it will render frozen in time and will be cached to the offscreen buffer.
Since we were keeping the offscreen buffer logic around, we could utilize it for everyone if possible. I added a flag to cached per-chunk tile draw orders, that determines if the chunk contains a dynamic effect (and therefore needs to be rerendered each frame - if the animation is enabled) or if it can reuse pixels from the previous frame. This means when rendering chunks without any water (E.G, the middle of your factory), the new water effect will have no impact on performance.
When seeing this you might get excited about the possibilities for modding. Well, don’t just yet. The system has been setup for making it possible to define different tile effects, but at the moment it is limited to allow just 1, which is used to define the water effect. I plan to lift this restriction in the near future, but in the end you’ll be limited to only changing the properties of the effect we made. But that still might be interesting enough, due to ability to change the ‘noise texture’.
There is still no plan to support custom shader definitions before 1.0.
As always, let us know what you think on our forum.
