Hello again! I come bearing news of many positive updates to the Space Game engine. In the last few weeks, I have managed to flesh out some of the more difficult features that will pave the way forward. The game itself continues to be much more stable with every passing week. Let’s hop right into some of the most interesting improvements from the coding dungeon.

First of all: terrain generation is getting much better. It now includes a fairly accurate and efficient vector data system. Right now that just means roads/runways, but in the future it could open many exciting avenues (pun intended) for surface level details. The system conserves memory usage by making use of higher resolution terrain pages. This of course revealed a huge bug in the high LOD terrain request pipeline where precision appeared to drop at sub-meter resolutions. Luckily, this was a fairly simple fix, and the results are great! Stable sub-meter page resolution allows for much more detailed terrains without using significantly more memory. As long as your computer can handle it, sub-centimeter details are not out of the question!

Terrain page selection has also seen some minor updates. Loading into the world was pretty painful for the last few minor versions because of the way terrain pages were requested and selected. The previous algorithm was aggressive; tiles were selected before their height data was parsed. A maximum bounding box extent was assumed for these pre-loaded tiles, which caused a cascade of tile selection in the quadtree. The new algorithm will abandon selection if a tile is not yet loaded. I had avoided this in the past as it does not guarantee that quadtree nodes are always within one level of each other as CDLOD requests. However, my terrain LOD scheme has become a kind of CDLOD/Chunked LOD hybrid with skirts, which allows me to hide most of the terrain issues while also taking advantage of CDLOD’s morphing on the bulk of the terrain.

Another huge improvement was in the GPU-side terrain generation shaders. Terrain page data is generated on the GPU on a 32-bit float texture with four components (RGBA32F). The height was stored in one component and the normal was stored in the remaining three. Using 96 out of 128 bits on normal data was pure insanity. I can afford to use much lower precision when processing normals, so I decided to pack them into a single component. The X and Y components of the normal each use 16-bits and are packed into one 32-bit float. The final component, Z, is determined when unpacking by working backward from unit vector normalization. In normal space, the Z direction is always positive, so it is easy to infer the sign. After these changes, I have 64-bits available in the data page for accessory terrain data. I have not quite worked out how I will be using these components, but it will likely be in generating a more visually interesting terrain.

Physics feel pretty stable. There are some open issues with the physics system, but overall, you can take off, land, crash, do flips, or whatever and you probably will not notice the deficiencies. Although the collision system will have to be written before a major release, it is fine for now. I have some plans for an orbital dynamics HUD display that will help visualize your current orbit. This is where things will start to get interesting. It’s hard to do anything in space without knowing your current orbit. Hopefully this will lead smoothly into prograde and retrograde guides among others to aid the player in making adjustments.

There are many other performance, visual, and stability updates that have been made in the past few weeks. I am working hard to put out a playable v0.2 in the near future. This will feel a lot more like a playable game/simulator than previous iterations. I am super excited to share it with everyone. Please stay tuned!