Progress Update #14
Bug Fixes... Hurray!
The past week I have been fixing various levels of issues, from engine breaking corrupt files to making the orbit debug just a little more accurate.
Fixing the Orbit Calculation
In progress update 12 I started trying to calculate orbit velocities, this time however I was determined to finish it and get it right. So as I said in that update I started with the gravitational two-body problem.
Just to recap the orbit section of update 12; I wasn't able to use the standard calculation for orbital velocity because neither mass in my game was negligible, so instead of that I tried to make an approximate equation based on manually acquired velocities of different masses, but it didn't work for all masses because of the sample size.
The gravitational two-body problem, "concerns the motion of two point particles that interact only with each other, due to gravity" where the masses of the particles are significant enough to effect the movement of the other. I spent about a day sifting through different related Wikipedia articles, but I kept coming up with the standard calculation:
So I went back to my test level which was blank except for two planets. Here I started playing around trying to see what it was that I was missing that was causing the calculation to be so extremely incorrect. What I noticed was that the orbit velocity seemed to be independent of radius. If I set the velocity of a moon of mass 1 to 100m/s, it would orbit a planet of mass 100 perfectly at a distance of 3000 units. But I could move the moon away from the planet, not changing any variable but the radius, and the moon would still orbit in a perfectly circular manner.
This was very odd but because of this realization I took the r out of the equation, leaving just sqrt(GM). And believe it or not, it worked! The calculation returns the exact velocity for a perfectly circular orbit.
I'm not really sure why this is the case but to be honest I'm not complaining. I used this new calculation on all of the planets in the main level and all of the coplanar planets worked fine, but Mars, which I had at a slightly inclined orbit, was not orbiting perfectly. This had to be a problem with the SetToOrbit() function. I used the debug arrows that I had put there to see that the tangent vector was not normalized. Normalizing it means that now any planet, at any point in space can be set to orbit any other body.
Fixing the Asteroid Belt Initial Velocity
Now knowing the correct formula to calculate initial orbit velocity I had to apply it to the asteroid belt. Before now, the asteroid belt was very unstable. Meaning that over time the asteroids would come closer to the sun then further until eventually they were shot out of the solar system. This was not ideal. The asteroid belt should be 99% stable and stay where in the orbit that it spawned.
To do this I essentially just applied the sqrt(GM) formula from earlier and it worked straight away. There were two things about it that I found too perfect though.
The first was that the asteroids would always stay perfectly within a circular orbit. Which was kind of the point for the planets, but it makes the asteroids look fake. During my research into orbital mechanics from earlier I found that orbits can be defined by their orbital eccentricity (aka how far the orbit is from being perfectly circular). For the asteroids I intend to implement this with RNG per asteroid but also to add it as a parameter to the planet's orbit.
The second thing I didn't like about the asteroids is that they were really just booking it. Like they had to go so fast to orbit the sun; which makes sense given the scale of the in-game solar system. To "fix" this I cut the sun's mass by 10 just for the asteroids. Doing this made the asteroids look better at the cost of being technically less realistic.
Side note about Niagara: During this process messing with the Niagara particles I tried to get the particle system to read the mass and position of the Sun directly from the actor. Keyword tried because it was basically advanced trial and error with the level of documentation for Niagara. I will get this to work but it will be another time.
Fixing Corrupt Project Files
The day after I had dine all that stuff with the asteroids, I went to open the project and Unreal spit out the error: Bulk Data compressed header read error. This package may be corrupt! I thought this would be a small inconvenience as I backup to source control at least once a day. So I discard my changes and revert to the last commit but it still gave the same error. Uh oh.
In this case Google didn't help very much as it was mostly people having trouble with Steam cloud back-ups. The source code, call stack, and output log weren't that helpful either. All I could surmise was that somewhere in loading the level, the editor crashed. So I deleted the main level from disk, opened the project and that worked.
I then went through manually reconstructing the level (which also showed me what processes need to be streamlined for UX) and while remaking the Mars planet I got the same crash. Going back into the editor I tried to delete Mars and crashed the editor again. Because I had only applied the textures to the red planet I deleted those from the disk and couldn't crash the editor again. So... problem solved I guess. I don't know what caused those textures to crash the engine but I'm now keeping my eye out.
Making the Orbit Debug More Accurate
I had noticed that the orbit debug gave a pretty good approximation of the paths that celestial bodies would take, but the further into the simulation it went the further the actual positions of the planets would get from those predicted by the debug. This was because I was using 0.05s as the time step for the debug, but the simulation was running at ~120fps or ~0.0833s time step. Changing 0.05 to 0.0833 made the debug 99.9% accurate (not 100 because of slight fluctuations of framerate during simulation). I intend to make sure the physics simulation is framerate independent at a later date.
Fixing Pixelization of Gas Giant Related Objects
When I first made the ring systems, I remarked how the colors weren't quite smooth:
To fix this I started out thinking it was some compression problem or something to do with the gradient texture. I tried a few different things, al with no success. I then realized that the texture I was using to make the UVs into a ring shape had some imperfections; that it wasn't quite a perfect gradient from green (V channel) to black:
Doing a quick google search lead to me finding out about the radial gradient exponential node. This gave a mathematically perfect fuzzy dot and fixed the pixilation:
I then went on to try to do the same for the gas giant's storms as they didn't look great and had the same pixilation problem, again due to the same reason:
This problem however could not be solved in the same way as there was more than just one fuzzy dot to make. That said, this problem could be solved by changing compression settings that I was trying to do with the ring systems. I don't exactly know which of the 14+ types is the best for cost to result, but for now I chose HDR (RGB, no SRGB).
Adding this line of code:
VoronoiTexture->CompressionSettings = TextureCompressionSettings::TC_HDR;
Resulted in this fuzzy dot:
And this storm:
It's defiantly an improvement but by no means perfect. Looking at images of storms on gas giants like Jupiter's big red spot, it's very apparent that the storm has more turbulent disruption in the midst of the swirl. Someday I will implement this but for now this is viable.
Scheduling!
For the past few months I have been working on this project I haven't really had many concrete goals or deadlines. As I've mentioned though in game jam post mortems, these things can be a significant motivation to get things done. Thus I have made a list of features I want to get done before starting on the "game" part of the game. These features have deadlines of anywhere form a day to a week depending on how long I think they'll take, and all of them combined should take me through the end of April. My overarching goal then is to have a playable alpha done by the end of May. I will probably have a Trello or something up next week showing the progress on these features.
Comments
Post a Comment