We've released a hotfix for 1.2 that we hope will address most of the issues you have been having!

Changelog

##############################################################
####################### VERSION 1.2.1 ########################
##############################################################

###################
# Features
###################
* Forming a Defensive Pact now cancels guarantees and non-aggression pacts with that country
* Primitives nuking themselves now properly affects pop count
* Risk of Malcontent Slaves faction effect "Interstellar Railroad" now scales from 1% to 5% risk with 5 to 11+ owned slaves, down from 2-10% risk with 4-8+ slaves

###################
# Balance
###################
* Upgraded Nomads arsenal and ship designs. Reduced Nomad Fleet HP and damage bonus modifier from +50% to +25%. Overall they should be stronger than before
* Reduced HP of Nomad ark ships and gave them basic weapons

###################
# AI
###################
* Fixed AI not properly signing white peace in some wars that would just drag on forever
* Fixed AI not declaring prepared wars
* Fixed a case where sectors could get stuck due to lack of energy tiles and respect tile resources
* Multiple fixes for AI combat behaviour

###################
# User Interface
###################
* Fixed spelling in English localization for Attitude Map Mode

###################
# Bugfixes
###################
* Fixed a bug where merging fleets would prioritize the smallest fleet
* Fixed a bug where Gaia world spawn chance was not explicitly reduced for inhospitable stars
* Fixed issues with democratic elections alternative parties, issue caused the alternative parties to be invalid
* Fixed a bug where the display height of a galactic object wasn't being restored after loading a savegame
* Fixed so that democratic elections check the correct policy flags
* Fixed Xeno Integration tech weights
* Fixed upgrade arrow incorrectly displayed as greyed out for certain buildings on non-capital planets
* Fixed a bug where migration pacts between subjects and overlord were not allowed
* Fixed AI sometimes initiating a vote to kick right after a new member joins the alliance
* Fixed max trust not being properly set to 100 when forming an alliance
* Fixed issue with Nomads building too many new ships
* Fixed issue with Nomads not setting an end point for their journey when playing in a tiny galaxy
* Technology database patches tech_repeatable_improved_core_planet_cap -> tech_repeatable_improved_core_system_cap if save file version is below "Stellaris v1.2.0"
* Fixed CTD due to invalid pops on planet
* No longer wait for research in ALL tech areas to be halted before updating technology research alternatives
* Survey fleet order checks if fleet can move to system, so players can no longer reach out-of-reach systems using fleet view survey button

###################
# Graphics
###################
* Improved skybox quality

Old versions are as always available under the beta tab in Steam.

Asimov update (1.2) Released post

We've released a hotfix for 1.2 that we hope will address most of the issues you have been having!

Changelog

##############################################################
####################### VERSION 1.2.1 ########################
##############################################################

###################
# Features
###################
* Forming a Defensive Pact now cancels guarantees and non-aggression pacts with that country
* Primitives nuking themselves now properly affects pop count
* Risk of Malcontent Slaves faction effect "Interstellar Railroad" now scales from 1% to 5% risk with 5 to 11+ owned slaves, down from 2-10% risk with 4-8+ slaves

###################
# Balance
###################
* Upgraded Nomads arsenal and ship designs. Reduced Nomad Fleet HP and damage bonus modifier from +50% to +25%. Overall they should be stronger than before
* Reduced HP of Nomad ark ships and gave them basic weapons

###################
# AI
###################
* Fixed AI not properly signing white peace in some wars that would just drag on forever
* Fixed AI not declaring prepared wars
* Fixed a case where sectors could get stuck due to lack of energy tiles and respect tile resources
* Multiple fixes for AI combat behaviour

###################
# User Interface
###################
* Fixed spelling in English localization for Attitude Map Mode

###################
# Bugfixes
###################
* Fixed a bug where merging fleets would prioritize the smallest fleet
* Fixed a bug where Gaia world spawn chance was not explicitly reduced for inhospitable stars
* Fixed issues with democratic elections alternative parties, issue caused the alternative parties to be invalid
* Fixed a bug where the display height of a galactic object wasn't being restored after loading a savegame
* Fixed so that democratic elections check the correct policy flags
* Fixed Xeno Integration tech weights
* Fixed upgrade arrow incorrectly displayed as greyed out for certain buildings on non-capital planets
* Fixed a bug where migration pacts between subjects and overlord were not allowed
* Fixed AI sometimes initiating a vote to kick right after a new member joins the alliance
* Fixed max trust not being properly set to 100 when forming an alliance
* Fixed issue with Nomads building too many new ships
* Fixed issue with Nomads not setting an end point for their journey when playing in a tiny galaxy
* Technology database patches tech_repeatable_improved_core_planet_cap -> tech_repeatable_improved_core_system_cap if save file version is below "Stellaris v1.2.0"
* Fixed CTD due to invalid pops on planet
* No longer wait for research in ALL tech areas to be halted before updating technology research alternatives
* Survey fleet order checks if fleet can move to system, so players can no longer reach out-of-reach systems using fleet view survey button

###################
# Graphics
###################
* Improved skybox quality

Old versions are as always available under the beta tab in Steam.

Asimov update (1.2) Released post

Today we are super happy to release the Asimov 1.2 update for Stellaris!
If you are feeling unsure what this update will bring to the table I suggest you check out the info-graphics below or have a look at our changelog posted here.



Related Development Diary
Stellaris Dev Diary June 27th - New Skyboxes
Stellaris Dev Diary #37 - Asimov Patch part 2
Stellaris Dev Diary #37 - Asimov Patch part 1

Today we are super happy to release the Asimov 1.2 update for Stellaris!
If you are feeling unsure what this update will bring to the table I suggest you check out the info-graphics below or have a look at our changelog posted here.



Related Development Diary
Stellaris Dev Diary June 27th - New Skyboxes
Stellaris Dev Diary #37 - Asimov Patch part 2
Stellaris Dev Diary #37 - Asimov Patch part 1

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

Useful links
Official Website
Stellaris Wiki
Developer Diary Archives

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

Useful links
Official Website
Stellaris Wiki
Developer Diary Archives