Hello everyone and welcome back to another Stellaris development diary! This week’s dev diary was supposed to be about future Stellaris development, but we decided to delay that for a week so that our Art Director Aerie can talk about some nice new graphical additions to the Asimov patch. This dev diary will be a bit more technical and in-depth than most dev diaries. One of the major changes that you will notice in the Asimov patch, is the changes to the background environment, usually referred to as the skybox. A major issue we had with these at launch was the lack of variety between system appearances. Since they all have the same skybox they more or less all feel the same. Systems have different amounts of planets, in different configurations, with different owners etc. but the skybox makes up for 95% of all pixels on screen, at any given time, so it is by for the most visually significant factor. So, just make more skyboxes right? Well, a problem with skyboxes, is that they are very expensive memory wise. They each “cost” about 12.5 megabytes of video memory. In comparison, all the UI in the game is about 90 MB. The memory cost is due to the texture being 12280 x 2048 pixels large. That is what it takes to cover a 360 degree environment all around you. And then you still look at the image at 150% magnification. Despite the size of these files, they are still fairly heavily compressed, and with the skyboxes we had, you could easily tell. Because of the size of the skyboxes, we were reluctant to add more. What we could do however, was recolor them. We could use what is called a LUT (Look-Up-Table), where you use a reference texture to recolor everything. With this we can make all the adjustments we want in photoshop, using color balance, hue / saturation, levels, curves etc, and have this affect the textures in-game. LUT’s are a very powerful tool to change the mood of a game. LUT though, comes with a big drawback: it compounds the issue of compression artifacts even further.
Like I mentioned earlier, the skybox we had was not that good to begin with, it looked nice aesthetically, but quality wise, it was flawed from the very beginning. What we did when we created it, was we created a large panorama image of 4000x2000 pixels. This image was then wrapped around a sphere in maya, and rendered with 6 cameras each with a 90 degree field of view, to capture the information needed for the skybox.

But a 4x2k texture is not enough for a 12x2k skybox, we would have needed a 8x4k texture to start with, at the very least. The problem went even deeper than this. Even before we rendered it, the panorama texture was created in photoshop by painting and stitching together clouds and nebulae using levels and masks. Because of this the texture had some banding issues, before we even imported it into maya, which is another step that degrades the texture’s image quality. We considered for a moment creating a new skybox with the same technique as before, just with higher resolution, and better source textures. But working in 8x4k is very taxing on the hardware and as the layers would add up, even a good computer would start to struggle. Much more significantly, there were no guarantees that it would actually yield any good results. So back to square 1. We needed to do something completely different. We chose to try working with fluid simulation, using this to build an environment, and then simply render that out. We had only limited previous experience with fluid dynamics, but it's always good to try new solutions. Using fluids we could eliminate the entire first step, thereby removing a lot of texture degradation. Working with fluids in maya is surprisingly simple, and after some learning and simple tests we had a scene up and running that would give us roughly what we needed.
Before we added the new skybox to the game from maya, we did some additional work in photoshop to add more detail. So now we had a new skybox, looking similar to the old one, but of higher quality and with less compression artifacts. For recoloring purposes though, this new skybox was still not enough. The recoloring still caused enough artifacts to make it unsuitable. We had more variation, but it was 3 steps forward, 2 steps back.
Talking to the engine team, one of the coders suggested using YCoCg compression. What this does is, instead of saving the colors as RGB (Red Green and Blue), it saves the information as luminance, hue, and saturation which works a lot better for the color shifts in our skyboxes. A fun aside is that YCoCg is not dissimilar to how human eyes actually process colors. Anyway, besides being a good way to lower the information degradation, it was a cool idea, so we had to try it. Getting that up and running was also fairly easy, and it did indeed produce good results. These new textures are twice as big, so 25 mb each, but with these textures covering so much of the screen it is totally worth it. If any part of the game deserves more graphical resources, it’s the skybox. But it was still not enough. The thing that caused the most artifacts was drastical changes in hue, but we had to be able to move from a blue-ish green background, to a yellow, orange or red. So, instead of doing this change with the LUT- color correction, we do this in-engine in an earlier rendering step and then add a bit of color correction on top. This way, we can also subtly influence the colors of the ships, which makes them blend in a lot better. All in all, it produced a great result.
Beyond just changing the colors, we did want to do some more work to increase variety. We created some new skyboxes with different star densities, a dense one used closer to the core, a “mid-range” one which is similar to the one we had, and finally one for the rim, where the background stars are a lot more sparse and the skybox feels darker. With these changes, each system will be a bit more unique, and it will be a be a bit easier to know where you are in the galaxy. Original Post [quote]Useful links Official Website Stellaris Wiki Developer Diary Archives [/quote]