Today we released three large features and we want to tell you more about how they work and how we implemented them.
We are really happy to be able to deliver this to you as a Christmas gift :-) Hopefully there won’t be any major problems.
Super-large worlds
Even before we implemented “super-large worlds”, the size of a world in Space Engineers was not limited, but for practical reasons it was recommended to stay within a 10km radius of the origin. The reason for this was that floating-point calculations (vector and matrix multiplications) were gathering numerical imprecisions and after 10km you would experience shaky movements and rotations.
Super-large worlds are increasing this safe radius up to 1,000,000,000 km, which equals to 6.6 AU (AU stands for astronomical unit; 1 AU = 150,000,000 kilometers and it’s the distance from the Sun to Earth). For your illustration, 6.6 AU is slightly more than the distance from the Sun to Jupiter.
If you decide to use your ship to travel from one side of the game world to the opposite, and you will fly on maximum speed (115 m/s), it will take you 552 years (checking calculation: 2 x 6.6 AU / 115 m/s).
For all practical purposes, “super-large worlds” could be considered “infinite worlds”, but the limit is still there and we don’t want to lie to you.
How did we increase the precision of numerical computations?
- Until now, Space Engineers and its physics engine (Havok) were using single-precision 32-bit floating point numbers. This data format has a certain precision, leading to visible imperfections on objects located further than 10km from the origin
- We have modified all game objects to support double-precision 64-bit floating point numbers -- this was the easy part
- The harder one was to change the integration between Space Engineers and Havok (so Havok can keep using 32-bit floating point numbers). We solved it by clustering the game world into independent clusters of objects (minimal cluster size is 20km). Depending on dynamic objects density, cluster size can increase its size without limits. Common cluster size should be 50-100km. A clustering algorithm guarantees that no dynamic object can be closer than 2km to the cluster border. Clustering is totally transparent to users, it runs in the background and you won’t see it.
- In other words, the world in Space Engineers is split into independent clusters, wherein each object has its own coordinates relative to the cluster center. As a result Havok doesn’t need to use double-precision math (physics calculations are faster in single-precision mode).
Procedural asteroids
The “procedural asteroids” feature adds a practically infinite number of asteroids to the game world. On top of that, all these asteroids are fully destructible and don’t consume RAM/memory.
Until now, Space Engineers supported only asteroids that were fully loaded during the loading phase and then kept as voxels and triangles in memory. There were only a few basic asteroid shapes.
From now on, there are two types of asteroids:
- old version - that can be used for handcrafted asteroids in future scenarios/missions
- new version – asteroids that are procedurally generated at the moment they are required (player enters an area near the asteroid, random floating object gets in a collision with the asteroid, etc.). This type of asteroid doesn’t occupy memory (except some small data for noise seed, position, etc.). Even after it’s generated and inserted to the game world for physics simulation, the voxels are not kept in memory. Only if something alters the shape or material on the asteroid then these changes are made permanent. Unaltered asteroids are removed from the memory, but when a player returns they are re-inserted with the exact same shape. Players won’t see a difference, for them all asteroids appear persistent
This new asteroid type should also reduce saving and loading times (because these asteroids are represented by a noise function, instead of an array of voxels).
We also implemented a new voxel LOD system (LOD = level of detail). The old one had only two levels of detail and required voxel data in memory. The new one has many levels of detail and helps with optimizing polygon meshes and voxel data as well (e.g. when generating geometry for procedural asteroids at a distance, the game requests only coarse low-detail procedural generation which is faster than high-detail voxels). In other words, distant asteroids use fewer polygons and fewer procedural generation calls.
There’s also an “asteroid field generator” – which is used to allocate and deallocate asteroids as you travel through space. We can configure it to generate dense or sparse asteroid fields, or areas with no generated asteroids (this will become useful once level designers start creating scenarios).
We had changed the background skybox to not contain those “fake” asteroids anymore. We still keep quite bright fog, but you are free to alter it through modding.
Exploration
An exploration feature adds a practically infinite number of ships and stations to the game world, so there will always be something to discover, explore, acquire and conquer. You can imagine it this way: you are traveling in some direction and there is an asteroid, so you decide to check it and see if there’s something in its tunnels, in its proximity or on its surface. Or you just fly around in empty space and boom, a lost wreck shows up near you.
Almost all ships used in this first phase of the exploration release are player created content downloaded from Workshop. Everyone can find his name in game credits.
More info in my previous blog post: http://blog.marekrosa.org/2014/12/space-engineers-exploration-call-for_3.html
Conclusion
“Super-large worlds, procedural asteroids and exploration are among the largest and most complex features we have implanted in Space Engineers / VRAGE engine.
This is just a first phase; we plan to keep improving after your feedback.
--
Thanks for reading this! For the latest news, follow Space Engineers on Facebook or on Twitter.
