Announcing: Galaxy Explorer
Following up on my test post, the picture included was an early shot of the alpha of my next app, which is called Galaxy Explorer.
It all started a bit over a week ago, while I was poking through the samples that came with Space Graphics Toolkit plugin for Unity to see what it was capable of. One of the examples caught my eye: it was a demonstration of a component that would render a large cloud of “star” textures in a very efficient manner, giving the appearance of a Galaxy. It occurred to me that it looked a bit like the star cloud that I used in Exoplanet Explorer, so I compiled an Android APK and ran it on my test devices. It worked great and ran very fast because of the way it was designed.
This was intended to be a quick look, but I wanted to know how close it was to what I needed for the rewrite of Exoplanet Explorer, so I created a duplicate of my learning project, and installed the galaxy component into it to see how it looked.
Further research revealed that it wasn’t quite the same, but with some tweaking, I was able to get it to import and render the 120,000 or so stars in the HGYXYZ database. Although trying to run this on my crap-tastic tablet caused it to crash (presumably, it ran out of memory), the full 120K stars rendered at 12fps on my Galaxy Note 1, and 30fps on my Transformer Prime.
Seeing as I’d written half an app in a few days, I decided to finish it off. Although it steps on some of the Exoplanet Explorer’s turf, it has a distinctly different purpose, and it will let me test out how an Exoplanet Explorer like app will work across all the different Android devices.
Rather than using the HYGXYZ data, I’ve decided to use the XHIP data which has a lot more relevant information about the stars.
Because the app is memory hungry (it is a huge database), it’s only going to ship with a few tens-of-thousands of the closest and most interesting stars. I might be able to include more stars, I just want the default setup to work well on as many different devices as possible.
It’ll be free, with ads, and for anyone that wants to try out the full 120K star database, you can unlock an importer function which will let you import the full XHIP or HYGXYZ data, or even let you build your own database of stars in a CSV file, using any number of fields you’d like to include, so long as you provide basic info about the stars: some sort of ID or name, right ascension, declination, distance and spectral type.
As an added bonus, unlocking the importer will also remove the ads.
Because I’m fairly up to speed with Unity now, I’ve blasted through this project and it’s probably about 80% complete at the moment, after 10 days. The major things remaining are tweaking and polish, so I’m hoping I can release it for Android by the weekend.
Now that I’m “experienced” with Unity, I’ve found that being able to work in a complete programming language makes the development process a lot quicker. One of the other flaws with Shiva was its use of a custom version of LUA which is missing a lot of the basic functionality that you’d take for granted in a modern language. I’d been using Shiva so long that I’d gotten used to figuring out convoluted workarounds for otherwise simple programming tasks. I’d forgotten how bad it was when I first started out on Shiva.
It’s not all fun and games though. Unity is a never-ending crash-fest, dying on me four to six times daily.
A particularly annoying instance occurred to me yesterday after I’d typed in about 80 lines of text that described the structure of the HYGXYZ and XHIP files. Monodevelop decided that one of the lines of text had a fatal error in it, underlined it in red, yet it compiled fine and ran. I’d have ignored it, but the error broke autocomplete, so it made working on that particular source file painful. In an effort to fix it, I highlighted everything I’d typed, pressed Ctrl+X to cut it, then, automatically, and without thinking, I hit Ctrl+S to save it while I silently mouthed “oh-sh**” as I realised that it was probably a bad idea to save the blank file. Yep, Monodevelop locked up, wiped the clipboard and left me with an hour of lost work.
About a week ago, Unity decided to break an early version of the Galaxy Explorer app, in a very clever and original way. The app ran fine in the editor. Unfortunately, when it was exported, Unity trashed one particular texture that was used to render the points that are used to draw the stars at a distance. The end result was that upon export, running the app on my phone or tablet, all the points were draw with a flat, white texture, so the sky was full of little white squares instead of stars. After export, running the app in the editor would have the same result, and the only way to fix it was to re-import the texture, but it would just break again when I next exported it for testing. I never did figure out what was doing this. The solution was to create a new scene and set it up as a duplicate of the “broken” one. I’ve not had an export issue since.
I’ve also had Unity eat files in my project. A couple of days ago, I hit play and Unity froze while starting the app. After I killed it, and restarted Unity, the app wouldn’t run anymore because a number of key files in the Resources folder were now missing. It seems that Unity had somehow deleted the files when it crashed.
I make sure that I backup several times each day after seeing that happen.
One other thing I should mention is that I’ve been having a few issues with shaders on Android. The particular problem I had was with the Sun model as seen in the attached picture. The custom shaders supplied with Unity Space Toolkit are very elaborate and have fields that control the appearance of the star using all manner of different settings. Unfortunately, this meant that the shader wouldn’t work properly on my Galaxy Note, while it looked fine on my Transformer Prime. I ended up discarding the supplied shaders and faked the appearance of them using geometry + textures (thankfully supplied with Unity Space Toolkit) and a simple transparent rim lit shader that I wrote, after learning how to write shaders to solve this particular issue. The end result was quite similar to the supplied shader, not quite as accurate to real life, but a lot more compatible with my testing devices.