Rocket Science News

Hey, folks.

I’ve finally finished encounters prediction. Here how it looks:



Technically, encounter prediction is all about root finding of the distance function. But evaluating distance between two celestial bodies at a certain point of time is a bit expensive, so not all existing methods from calculus are suitable for solving this problem. Firstly, I tried approximating distance function with a Chebychev polynomial and then finding the real roots of that polynomial using eigenvalues of the companion matrix of the Chebychev coefficients. This sounds very complicated (and it was), but computationally, it should have been the fastest method. But due to large scales of Solar System, or because of lack of my experience in math, it gave very inaccurate results or didn’t even predict some encounters.

So I abandoned this approach and choosed more simple, but more expensive one. At first, I am searching for a closest approach to the body for half an orbital period using the Golden Section method. If approach is found and it is within a sphere of influence of body, then I am using few steps of Bisection method to get closer to an actual encounter. And to get a precise results I am refining calculations using the Newton–Raphson method. This worked great, and since all orbit calculations for scaled space are parallelized, searching for encounters is almost not affecting game performance in any way. But since I am not mathematician neither physicist, it took almost half a June to research, experiment and come up with this solution.

But this was beginning of a journey. I completely forgot about frame of reference during encounters prediction. For example, if we are looking for transfer from Earth to Moon, and predicted orbit is in the SOI of Moon, it is not enough just to draw this orbit, because Moon is moving around the Earth in this frame of reference. And we should translate every point of orbit, all orbit nodes and maneuvers on it relative this motion in the future.

Without Earth reference frame

With Earth reference frame

I am calling this Dynamic Frame of Reference. And it is working only for parabolic or hyperbolic orbits, because they have start and end points. For elliptic orbits we need to translate only origin of the orbit.

Final elliptic orbit is in Static Frame of Reference

And if maneuver was placed on elliptic orbit we should switch from Static to Dynamic Frame.



Encounters search is also repeating each time your spacecraft is passing the maneuver node. So you can place maneuver, get predicted orbit and just wait for encounter.



After some time and fixing tons of bugs and edge cases, I found that still a lot of things are missing. Like I should draw where planet will be during encounter, make target system, closest approach and ascending and descending nodes, provide more tooltips with useful info, make more precise deltaV controls and actually connect this all to the flight system. But I was a bit tired of orbit stuff and decided to switch to other tasks. Since what I have done is enough for Moon flight, I am planning to only connect maneuvers to the flight system and navball for the next release. And other missing features will be moved to the one of the next one.

I could finally work on something else. Firstly, I changed temperature map, that I am using for Earth’s procedural texturing. I got L3 TERRA/MODIS and AQUA/MODDIS datasets from NASA website in higher resolution, combined them, processed to fill up missing data and converted it to 16-bit temperature maps. Going from 8-bit maps to 16-bit greatly improved procedural texturing. Transitions between biomes became more smooth and there was less noise and artifacts. Also texturing became more realistic. No more sand deserts in the middle of Siberia.

Before

After

I still need to improve Earth materials by re-selecting them and tweaking a lot of parameters. But this is big task and not that necessary for now, so I will return back to it later.

The next task was the Moon. As I mentioned in the release blog post, the Moon’s heightmap is already in the game. But there were a bunch of bugs, that blocked it from loading.

There is no textures on the Moon right now, but still it looks gorgeous

I am using is 32kx16k heightmap but this is still not enough, even the Moon’s surface area is 13 times less than Earth’s. So I needed to work on appropriate noise for it, to add more small details.

When there is too much noise

After that I switched to fixing and improving interplanetary flight. This was not as complicated as orbits were, but still, you need to properly load and unload celestial bodies, heightmaps and collisions for them, switch atmospheres and clean all assumptions from the code, that there is only one possible main body.

Right now I am finishing noise for Moon and will start working on the texturing. Since there is no climate on the Moon, I need to adjust my approach to procedural texturing for it. And also choose appropriate set of materials for its surface.

As for release date for this update, I moved it again to the end of August, sorry about that. I made a great progress this month, but still there are more things that need to be done. After finishing the Moon, I will start making new rocket parts. Some of them will be easy to add, other (like parachute) will not. I also need to rework some of existing parts. But I will try to adjust the scope and make only MVP tasks, so I could release an update even not everything I want will be there.

Thanks, and, hopefully, I'll see you at the next update release.

This is the small patch, that should fix the most critical problem for the game: instant crash on almost all laptops. This was engine issue, introduced by Unity almost six months ago and they finally fixed it. Initially I wanted to ship this fix only with the next update, but since I have no release date for it yet, I decided to backport all the necessary changes to the latest stable version of the game. This will bring some improvements to the game graphics stability and perfomance as well. Note, that this patch will not include any gameplay changes (it is a bit hard to backport those, so they will be included in the next big update).

[h3]Changelog[/h3]

• Fixed instant crash of the game on most notebooks's GPU, that are bellow the system requirements.
  
• Fixed an issue where a changing sun position any frame may not update the ambient light of the scene.
  
• Fixed assembly floor flickering.
  
• Fixed wrong graphics settings assigned to Low quality level. Now it is really low.
  
• Improved game perfomance in the spaceport.
  
• Improved shadows during flight.
  
• Fixed various memory leaks on the graphics side.
  

If you encounter strange bugs in the game after update that were not there before, try to verify integrity of game files using Steam. Somethimes it doesn't download all the necessary files for some reason.

If the game still instantly crashes on your laptop, plase send me the contents of the %USERPROFILE%/AppData/LocalLow/unbeGames/HDYLIEM/ folder at [email protected] so I could continue to investigate this issue and pass information about this problem to Unity.

Developing a game is always a journey. You can never tell exactly how long the next task will take and how much research you should do before you actually start working on it. This is because of unique nature of games. No matter how many games you made before each time you will face some problems you couldn't even think of.



One inaccurate change and the whole Solar System is broken


This was exactly what happened with me, when I started developing a maneuver planner. Initially I thought that it would take at most three or four weeks to develop it. But the more I researched how to actually make it, the longer the task list became and the more missing features I found in the orbit system.

The first one was an orbit section. For example, rocket on the suborbital trajectory can not fly through the surface of planet, so the section of orbit under the surface should not to be calculated and drawn. This feature is also the main building block of the maneuver planner, because sections of orbits are extensively used in patched conic approximation.



After I've implemented calculating and rendering of orbit sections, I started applying them to every spacecraft’s suborbital trajectory. And I immediately discovered, that orbit section has to be recalculated every frame, when the rocket is in atmosphere or accelerates, because orbit constantly changes. Also section calculations are differs between elliptic and non-elliptic orbits. Thanks to total orbit system rewrite I did last month, it will have almost no effect on the game FPS, even with a dozen parts decoupled at once.



The next thing required an improvement, was orbit nodes. Apoapsis and periapsis have to respect orbit sections and should not be placed on the hidden ones. There is also no apoapsis on hyperbolic and parabolic orbits. And it have to be easy to add the new node types in the feature. So I’ve added impact node, and will add sphere of influence nodes soon.

After that I reworked orbit nodes tooltip. Finally, time of arrival and the celestial body name was displayed when hovering mouse over the node.



Afterwards I fixed a bunch of bugs, that prevented smooth transitions between elliptic and parabolic orbit.



Finally, all the preparations have been completed and I started working on actual planner. In theory, it based on three concepts: maneuver nodes, predicted orbit and encounter. In practice, it was a little more complicated than that.

Adding just a maneuver node was easy enough. It is just like a regular orbit node, but it specified by true anomaly and holds velocity change in it.



Then we need some handle to control velocity change. Every colored element on it corresponds to six vectors on which to burn (prograde, retrograde, normal etc).

When we are able to get velocity change, we could calculate predicted orbit using total velocity (actual velocity plus velocity change) and node position at orbit point.



Making a dotted line in Unity is a task that deserves a separate article


So everything is done? Not quite. Player have to be able to plan trajectory ahead. It means that maneuver could be placed on the predicted orbit. And then on the next one. And the next. Each time predicted orbit should be converted to orbit section. And each new section and node have to have different color, otherwise the planned trajectory will be not readable at all.



Don’t forget about inserting maneuver in between of two existing.



And they could be removed at any moment.



And the most important: you could move the whole chain!



This was a small glimpse of all tasks related to maneuver planner I had. Here is a list of tasks I done last two weeks:



The good news is: that only encounters was left out of the big tasks after it the planner will be almost ready. But I don’t even know, how long the task list will be this time. But I am pretty sure that this is very important part of interplanetary flights and it's not likely to change much in the near future.

When the planner will be done, I will switch to finishing the interplanetary flights themselves. After that I will deploy the game to private branch on Steam, so some players can try it out and give me feedback and tell me about found bugs. I hope it will happen at the end of June.

As for releasing an update: additionally, I need to make a bunch of new rocket parts, especially for landing on Earth and Moon. And I want to improve rocket assembly a bit, because this process is painful right now. But I really hope it will be easier, than the maneuver planner.

P.S. Congratulations to SpaceX on the perfect launch of Crew Dragon! This is really inspiring and makes me believe in humanity. And also make the game faster.

Since flight UI improvements I did for v0.7.6 and rocket controls rework in v0.7.8, I was able to finally start working towards interplanetary flights. And the first thing I needed to do is to rewrite Math simulation.

I implemented it in the early days, when I thought that there will be very simplified rocket physics in the game. In short, during spacecraft acceleration only the full thrust of all engines was taken into account and aerodynamics was absent at all. When the engines were off, rocket position was calculated using orbit. So, when I’ve added complete Physics simulation to the game, I decided to use Math simulation, when engines are off and rocket is not in atmosphere. It allowed time to do more than 10x time warp and had a great performance as well.

But these systems began to diverge in supported features more and more over time. For example, math simulation had no access to rocket parts, their properties and physics shape. Because of that, it could not properly calculate inertia tensor and rotate the rocket to the correct angle. As a consequence, energy consumption was incorrect too. So, I had to switch to Physics simulation every time any torque was applied to rocket. As a result, rocket could not continue to infinitely rotate in the space, when auto stabilization was off.

The last important thing, that was missing in Math simulation was the access to the whole game world in addition to the access to gravity and the radius of all the planets it had. This means that I can’t check if the rocket fell through the surface of the planet using heightmaps or noise. It is not a problem for the planets with the atmosphere, because rocket will be always simulated using Physics in it (however, there was a funny bug when the rocket switched to the Math simulation at the last moment before the collision with the surface and begin the flight to the planet’s core). But there is no atmosphere on the Moon, Mercury and on many other moons in the Solar System, so I needed to solve this too.

So I rewrote Math simulation to fix all these problems and then I launched the game to enjoy the perfect, stable result. But the first thing I saw, when the rocket reached the space, was:

-.-)

Actually, It was expected. Every time you make such huge changes, a lot of bugs and regressions immediately occur in any project. But if you make an extra effort and deal with encountered problems, everything becomes more solid and extendable in the future.

^_^

I finished development of Math simulation and decided to visit my parents, who live in another part of the country. As soon as I got to them, the COVID-19 outbreak happened in Russia and I stuck there in quarantine far from my development PC. But at least I had a laptop. It has no graphics card and able to run Elon at 15 FPS, and barely run Unity Editor. But I had an idea how to deal with it.

The next task was a Maneuver Planner. It is quite separate from the entire game, because the only information it needed are the orbits, celestial bodies and changes in the velocity of the spacecraft.

So I moved all related code to the separate new Unity project and start to build the Maneuver Planner foundation. I could quickly make changes, run the project, test it and repeat this process. The first thing I’ve added, is the proper support for parabolic and hyperbolic orbits:



Parabolic Orbit




Hyperbolic Orbit


After that I’ve changed they way the orbits calculated, generated and updated. Previously, the game could support rendering and updating around 50 orbits at the same time without significant impact on FPS. After that I tested 100 orbits:



250 orbits:



1000 orbits:
https://youtu.be/MxT9BYQ3Kvs

These all are synthetic tests, but now I am pretty sure, that the game will support a lot of orbiting objects and I will be able to tackle such problem like space debris. This also means, that the Maneuver Planner will support bigger conic patch limit.

The next problem I needed to solve was an orbit raycast. You need it to select the point on orbit, where you want your maneuver to begin. I can’t use Unity Physics for that, because on such scales it would be too inaccurate. It would be also too expensive to rebuild the colliders for spacecrafts, because during acceleration orbit is changing every frame. This actually was a hard problem: you basically need to go through all visible orbits and calculate possible raycast position on each of them, project back to screen and then look how far projected position was from the original mouse position. But the new orbits architecture handled it great:



The foundation for Maneuver Planner was ready. Three days ago I built a new PC to continue to work on the game at the same pace as it was at home (because I don’t know, when the quarantine is going to end and when I could return back to home). I swapped the old orbit system with the new one in the game and checked, that everything is working as expected:



The next steps are to develop patched conic approximation, encounters, system for adding maneuver nodes not only to the current spacecraft orbit, but to the predicted ones too. And all of this is multiplied by Solar system scale and accuracy requirements. It sounds hard, but every problem seems to be hard until you start to solving it.

The last thing I want to tell you, is that I started to work with Artur (the composer of Elon’s original soundtrack) on additional tracks for Assembly Shop, orbit, interplanetary flights and planets with and without atmosphere. They will be included into the game and OST on Steam with the next update.

That’s all for now, see you in the next update.

Hello, guys.

It was supposed to be another patch and I planned to release it last week, but some changes to the game required implementing missing features, some new features added more things to fix, some fixed bugs showed, that the game needs more changes and so on. I didn’t even notice, how all this work suddenly become an update.

I started dealing with the most common complaint: rockets are hard to control, especially in the lower atmosphere. It was pretty obvious, that reaction wheels alone can't handle it. So I needed to implement thrust vector control (TVC) for engines. While changing the angle of engine’s nozzle was simple, a lot of problems appeared when I tried to add TVC to spacecraft auto stabilization system. The problem is that the torque, generated using TVC is much stronger, than if you are using reaction wheels. And it depends not only from engine thrust and nozzle tilt, but from the engine position relative to the center of mass of the spacecraft. Thus I spent days trying to make stabilization system responsive, but so that it does not overshoot or wobble all the time. Only after I started to calculate all possible torque, that engines can generate, I could send correct values to PID controllers, that auto stabilization system uses, and spacecraft became more or less stable in the flight. As a result you can finally start to make gravity turn pretty much at any moment if you have enough engines with TVC and positioned them correctly on the spacecraft.

Such turns and stabilization after it would be impossible without TVC on that altitude

After that the second problem immediately arose. Because of how camera is locked on the rocket and since there are no other references in the flight except spacecraft itself, there's the illusion that the center of mass of the spacecraft is located at the camera focus point. And since the rocket is turning pretty fast right now, it was painful to see. So I rewrote camera targeting system and now it focuses at spacecraft CoM by default. And you can switch it to any rocket part or move along the spacecraft during the flight.

The top of the engine is in the camera focus right now. And there is an illusion, that CoM in that point too

There are a lot more, that I did during the past two weeks (like velocity and orientation markers on navball, oh yes), but you can read about this in the update notes bellow. A small note about this update. I’ve tried to not introduce breaking changes to the game, so your save games should work, but all the spacecrafts you’ve created will not receive new features like TVC or changed stabilization parameters. So it is better to create the new ones. Also some new key bindings could be missing because of how controls settings saving are working. So it is better to check it or just reset controls to defaults.

Now I want to tell you about future plans a bit. The next most important features are: the Moon landing, improvements to orbit system, maneuver planner and symmetry tools for rocket construction. While the Moon are almost there (I need to fix a bunch of bugs and prepare textures for it), other systems are pretty big. Also I need to rewrite a mathematics simulation (when you are on orbit and engines are turned off) a bit, because I created it almost a year ago and it does not properly support a lot of new systems that I added later (like electricity, or checking spacecraft collision with the planet surface). Because of that I have currently no ETA for the next update, but I hope it will be in April and it definitely be huge.

That’s all for now, I hope you will enjoy this update!

[h2]Changelg[/h2]
Features:

• added engine trust vector control for all engines except "Zarya-352" Liquid Fuel Engine;
  
• autocorrection system uses engines to turn spacecraft if TVC is available;
  
• added thrust limiter to engine window (previously it was just throttle with wrong name);
  
• added velocity and orientation markers on navball;
  
• you can remove parts using Delete hotkey in Assembly Shop;
  
• you can toggle auto stabilization using T hotkey;
  
• you can switch camera focus to any rocket part in the flight using ALT + left mouse button click;
  
• you can move camera along spacecraft using ALT + mouse wheel;
  
• you can reset camera focus to default position using ALT + C;
  
• the Moon can be seeing from the flight camera now (but it still not reachable yet :/ );
  
• added "remove spacecraft" and "enter into flight" buttons to the list of spacecrafts in the Control Center.
  
• new part category "adapters" in assembly shop;
  
• new connector type "rectangle".
  

New parts:

• basic fin;
  
• advanced nose cone;
  
• adapter 1.2m radius to 0.55m;
  
• adapter 0.35m radius to 0.55m;
  

Changes:

• flight camera will focus at spacecraft's center of mass instead of command pod by default;
  
• to be consistent with the flight mode, hotkeys in Assembly Shop were changed:
  
• - focusing camera on the part is ALT + click now instead of SHIFT + click;
  
• - moving along the building is ALT + mouse wheel;
  
• some parts was moved from decouplers category to adapters;
  
• improved connector/slot selection during part attaching in assembly shop.
  

Fixes:

• planet generation memory leak when orbiting around Earth a long time with in the time warp;
  
• one of the fuel tanks has incorrect connection position, which lead to rocket flip over;
  
• one-socket part can be incorrectly connected to triple connector part;
  
• rocket part outlines stays when switching to map;
  
• lightning artefacts on Earth on map view;
  
• parts sometimes stay connected to the rocket after removing;
  
• new part is not selected from list, when another part was detached from rocket and stayed selected;
  
• bottom visual slots on side fuel tank are missing;
  
• decoupler and adapter attached to command pod have wrong alighment;
  
• engine turn on after changing throttle, even if it was manually turned off;
  
• missing alpha gradients from orbits;
  
• spaceport camera stop rendering if selected spacecraft was removed in control center;
  
• selected value in dropdown sometimes not localized properly;
  
• wrong engine name in the tutorial;
  
• click on detached part opens part's window;
  
• close button not worked in spacecraft stats window.
  

Known issues:

• sometimes rocket receives huge side force on launch (need more evidence to solve this one). If you encounter this, you can try go to Control Center and remove any bugged spacecrafts.
  
• it is impossible to reattach part with socket from one connector to another (you can detach part and place it before attaching to another one as a workaround);