

- KERBAL SPACE PROGRAM 2 SWITCH UPDATE
- KERBAL SPACE PROGRAM 2 SWITCH VERIFICATION
- KERBAL SPACE PROGRAM 2 SWITCH CODE
Now we're looking at how much overhead we're looking at. Orbits - With above in mind, can easily dedicate 15ms per frame leaving a good safety margin. Again, most of the exciting stuff that has to do with any new KSP2 features, like colony state, can easily be split between frames.
KERBAL SPACE PROGRAM 2 SWITCH CODE
40ms is actually a ton of time even if you have to write your code in C#. Life support, etc can be even less frequent.
KERBAL SPACE PROGRAM 2 SWITCH UPDATE
You don't need fuel to update at 30Hz, for example, it'll do just fine at 10Hz, so you can do only 1/3 of computations per frame. Yeah, a lot of that might be eaten by aerodynamics and such, but then we can stagger some of the work between frames. So that's 33ms/core or about 67ms of total compute per frame for all the jobs.Ĭomponent updates - lets dump most of our compute here. I'm not sure how well Unity uses the co-processor on Switch, so I'm going to assume the worst and plan for everything to run on just the four main cores with no hyperthreading. We also have two logical cores effectively spoken for with rendering and main threads. Orbits - As we don't need to consider interactions, this can safely be don in jobs.īecause physics, animation, and UI all live on the main thread, we want to move everything we can off. UI - This is basically part of component update in Unity, and it's light enough.

World State - For KSP2 all colony stuff should happen here. Fortunately, not a lot to do.Ĭomponent updates - The calls happen on main thread, so this is definitely something you want to unload to jobs, as this includes aerodynamics, resource use, etc. Physics - solver needs to happen on a single thread, collisions and BVH updates could be spread out, but PhysX sucks, and bottles up main thread.Īnimation - can be safely distributed, but Unity might not. Rendering - lives on its own thread, takes up a logical core, and we don't need to consider it further. And doing iterative solutions for the few pieces that did encounter an SoI boundary or came close enough to have to check, is still very reasonable.ĭon't forget, the orbits is one part of many others that run on a frame, and you only have a few milliseconds per frame, and if you simplify the orbit calculation too much, it becomes too imprecise. Most of the time, debris are going to be nowhere near SoI boundaries, and you'll be able to reject it really early.
KERBAL SPACE PROGRAM 2 SWITCH VERIFICATION
The great thing about all of the above is that while the verification steps get progressively more complex, they also get progressively less common. If you found a potential intersect, the final step is an iterative algorithm that finds the exact time you've entered new SoI. First step is to break trajectories into segments, inflate the SoI a bit to correct for curvature, and see if there's an intersection there. For any SoI that are still feasible, we have to start doing real work. Feasibility of each AABB collision can be evaluated with just two SIMD instructions, but even if you have to do it with managed C# code, it's done in a few CPU cycles. Next, it's very easy to construct an AABB for each SoI you need to check. So if you're orbiting star, only check planets, and if you're orbiting a planet, only check moons. You don't need to consider very SoI in the game - just children of current SoI. While that can cost a few thousand cycles, it's going to be a rare occasion in practice.Įntering SoI is more interesting, but there are a lot of simplifications here too.

If you are out, you need to do a bit of extra work to find the exact time you've left the previous SoI, and then simulate forward from there. You update the position for new frame, and simply check against SoI radius. Well, exiting SoI isn't really a problem. I also don't know exactly what KSP calculates, but I not only believe the orbits of the current time, but also in the future to calculate when, for example, one leaves / enters the sphere of influence of a planet / moon.
