Galaxy Explorer: Running out of things to fix
The polish is always the hard part in a project… it’s where the boredom becomes an issue.
Yesterday, I went back and recreated the default database from the original XHIP data. The main.dat file that the app uses contains all of the interesting stuff, except it’s only got the Hipparcos number for the star. I decided that I wanted to include the proper name as well, so I added a new field to my version of the XHIP data, and merged in the name from the biblio.dat file. While I was at it, I also replaced the group code that each star is assigned with the full name of the constellation.
After doing this, I decided that the information window needed to be tweaked to make it more readable, since there’s so much data now, it just looked like a jumble. Back to the data file, I changed the names of most of the fields, and then added a new mode that automatically groups and sorts fields by the first word in the name, making it a lot easier to read.
I also added in an option to toggle between displaying distances in parsecs or light years. The imported data expects parsecs, but some people are more familiar with light years.
Apart from that, I finally conquered the last outstanding “real problem”, which was that users could open a menu and still click on buttons from the menu underneath. The simple fix would be just to manually add a full-screen collider behind each menu, but to make it easier to maintain, I wrote a function that moves a shared, full-screen box collider and places it underneath the top most menu, any time a menu opens or closes. This worked out very nicely, and there’s no more risk of people clicking things they shouldn’t, such as when the import process is running.
Using fog to hide pop-in and pop-out
There’s about 15,000 stars in Galaxy Explorer, which is too many to render onscreen at once. I’ve set up the camera so it has a fairly close maximum viewing distance, which stops the majority of stars being rendered when they are far away. The only problem is that it’s obvious when an object goes out of view, because it just vanishes.
To combat this, I contemplated messing with the alpha to fade the star away as it approaches the vanishing point. Then it occurred to me that I could probably get away with using fog, since, even on a slow device, only a small percentage of the pixels on screen will be affected. This is because only the distant stars need to gracefully fade away, when they’re about three or four pixels in size.
This same solution also applied to the text labels that appear under the star objects, except I had to modify the text shader I obtained from the Unity wiki, to account for fog, which just meant that I needed to remove the flag that told the shader to ignore fog.
Here’s a shot of the 99.99999% complete app with a nice spacey skybox added.
Unity crashing update
Over the past couple of weeks, I’ve been experiencing a productivity-sapping periodic crash that would randomly destroy Unity’s IDE configuration or worse, destroy the project I was working on.
I reported it to Unity, but wasn’t sure what was triggering it.
Now I can make Unity crash on demand (don’t try this on a project you like):
- Load a project, open a scene, find a script that runs from that scene, and open it in Monodevelop.
- Attach Monodevelop to Unity for debugging.
- Place a breakpoint in code that will run when the app is started.
- Go back to Unity, and execute the app.
- When the code breaks, make a change to the script that will not compile due to syntax errors.
- Save the script.
And that’s it.
Unity got back to me and told me that they can’t reproduce it.
I hope it’s just something specific to this project, and when I start the next one, the problem will go away.
At least I now know the process that causes it, so if I forget and accidentally save a code change while debugging, I can restart Unity before it crashes.