Greetings, Citizens ~ As mentioned in our previous Dev Blog, this is an optimization update where we are improving the chunk system, among other changes. We expect performance gains of up to 50%, in the best cases even close to doubling frame rates on some structures.

Chunk32

With this update, all worlds will use the new chunk format, which (among other things) increases the chunk size from 16x16x16 to 32x32x32. Code wise, this was probably one of the biggest changes in a long time because it affects such a huge portion of the codebase: we needed to update pretty much every area that interacted with chunks. Not only that, but we also had convert old worlds and blueprints and make sure everything is still fully functional. A new object always starts at the center of a chunk, so moving to 32-block chunks means all blocks in every object had to be shifted by 8 blocks in all dimensions. But not only that: all logic, connections, rails, and a lot more had to be adapted as well. The reason for centering objects within their chunk is simple: small objects only consume one chunk (instead of eight), not only saving memory, but significantly improving the performance of nearly every operation (physics, lighting, etc.) as well. This change also requires converting all files, which happens while initializing the universe. All existing blueprints are fully compatible with the new system, and are converted while initializing, or when used in-game if needed. They will also migrate on the fly if you upload an old version of a blueprint, or if you copy one directly to the blueprint directory.

• Note: Converted blueprints are not backwards-compatible; however, the game retains backups of the chunk16 blueprints, so downgrading is not an issue.

The new format considerably reduces both the amount and size of files stored in the database, resulting in a significantly smaller overall size. As an example, the test server shrunk from 49GB to 9.2GB with the new format -- 81% smaller! Other servers can expect similar reductions. The migration process automatically creates a backup of all old databases and blueprints in the installation directory before touching anything, preserving your data should anything go wrong. The migration might take awhile depending on the database size, so expect updating servers to be down for a bit. (The test server takes between 60 and 90 minutes)

• Note for servers: If you have already made backups yourself, you can turn off the automatic backup by adding the following lines in the server.cfg, if not already present: BACKUP_WORLD_ON_MIGRATION = false BACKUP_BLUEPRINTS_ON_MIGRATION = false We’ve also renamed ASTEROID_SIZE to ASTEROID_SIZE_MAX. We’ve lowered its default value from 4 to 1 because of the new larger chunk sizes. (Addendum: as it’s a radius, it doesn’t include the center chunk. We will switch to a by block radius in upcoming versions)

On top of all the conversions, we needed to make sure the new system can work with every prior version of the game as well. One of the hardest things to adapt was the planet generation, which in its current state may not see performance gains. However, the update greatly improves frame rates while looking at already-generated planets. The new chunk size also made it difficult to adapt physics, requiring large changes and improvements to get everything to work. However, we’ve already surpassed the previous performance for turrets and rails. The same performance update will follow for the regular (non-rail) physics in the coming update. This will improve performance for collisions, and things such as flying inside a hangar. There are still a lot of ways to optimize the physics engine, so we can continue to improve performance in the future. You may ask, “Why stop at 32-block chunks? Why not 64, or even 128?” Apart from diminishing returns, the biggest reason against this is that the gains from larger chunks begin to negatively affect any operation that looks at chunks as a whole. Not only would a larger chunk have more wasted space, the size would significantly slow down other lighting calculations, meshing, etc. The 32-block chunk size is the sweet spot, providing significant gains with only minimal performance losses. The only thing that may temporarily suffer a bit is the lighting calculations. If the slowdown is too much, or if you’re having too high CPU when objects are loaded in visually, you can reduce the ‘Block light quality’ in the in-game options. We’ve already planned methods to eliminate any performance loss from this issue, and will include them in a future update. One last thing we did, was implementing and upgrading the shaders to be able to handle the larger chunks. The new shaders make use of more modern Open-GL calls, speeding up drawing even more. However, as always, there is a fallback for older graphics cards.

New translation

We’ve added Portuguese-brazilian to our supported languages. A big thank you to all the contributors on our Crowdin project!

Gamma

The gamma setting is now available in the ingame graphics options.

Bug Fixes

• LoD models act like rails
• Cargo space/area trigger display issue
• Teal standard armor config fix

What comes next

We will be looking at NPC factions, and doing an overhaul of the the fleet system. We plan to make fleets much more stable and functional, and further: to also allow NPCs to use them for their own ends. Nefarious pirate armadas, here we come! We will also include bugfixing rounds along the way. As always, thanks for playing StarMade! ~ The Schine Team