Going back in time

Going back in time

It been a long painful one this time around. We have stepped back in time to fix up some of our old projects, so lets jump in and tell you what we have been doing over at bitshift.

Dog Fight

As we have recently updated our company name, I decided to dig our our previous project: Dog Fight. I figured it should be easy to just pull it out, update the version of the Unreal Engine it is running on from 4.11 to 4.18, change the splash screen with our new company logo and possibly add Vulcan support (which we hoped to release with but never made the cut).
Unfortunately I have forgotten how painful and slow using the UE4 Engine was/is. I've wasted a good half a week just trying to get the game open in the editor. The frustrating part is that it takes so long to do one thing, and if you do not get it right I need to go back and try again - which has happened a lot! But at least I now have this running on the latest UE4 engine but have put this on hold.

QLaunch

I updated to Android 8.0 knowing that the launcher we wrote many years ago, called "Grenade Launcher" did not support this version of Android. I again (perhaps you are starting to see a pattern here) thought it would be a simple job to update it. It has been less painful than getting UE4 up and running but it has thrown up many challenges itself. While in the code we are renaming it to QLaunch in the hope it will be easier to find on the Play Store when we release it. Again the work here has been put on hold as it is in a state that is not pressingly urgent.

Normal Mapping Terrain

Finally, some T&T news! With Trains & Things coming along nicely, we started looking at adding more content, in particular another map. Our lead Artist took the opportunity to raise a very important point: the difficulty involved in generating a normal map from a height map will likely be a significant barrier to modders and mappers. Custom mod and map support is vital in giving a game a long and healthy life span. To this end I have spent many long hours attempting to automate the generation of the normal map from a height map. Again, *sigh*, this should have been an easy task in theory yet has proven quite painful.

You will probably need to click to expand this image to see the problems we have been facing. Here is a height map of Hawaii, the red square in the centre shows the region where I have zoomed into the normal map of A, B and C.

In A you will see this sort of banding effect. This was my first attempt at exporting a normal map generated from the height map in Godot.
So we moved on from using PNG height map to trying a EXR height map. PNG is 8-bit while EXR we have at 16-bit. Yet this still had the same banding issue.

Seeing this problem and believing it something within the Godot pipeline, I created a Python script which took the EXR height map and generated a normal map. The result can be seen in B, as you can see there is no banding confirming my hunch.

After further investigation, I saw the Godot would load the EXR texture, the loader would load it as a 32-bit, then Godot would compress it down to 16-bit. This compression step seemed to be the cause of the issue. So I have worked around this by copying their code, modifying it so it bypasses the compression step and just leaves the texture as 32-bit.
Then once I generate the texture, the result can be seen in C - perfect!

But using an EXR for the height map made the map load times too long and another solution was needed. Using QGIS to work with high resolution maps of earth is quite snappy, and I noticed it was using geotiffs behind the scenes so I also have moved the pipeline over to work with geotiffs. This seems to give us a good compromise between height map size on disk and load times.

I have also integrated support into the Godot editor, so there is no need to hack around in the console (although you can still do that if you like!)

That is all for this week!