Integrating Trajectories for Low-Thrust, Long-Duration Burns

[sciencecompliance]

I have recently gotten fairly deep into KSP 1 and built a couple of ion (DAWN) engine-powered test probes to determine the viability of using ion engines in-game.  I avoided using the ion engines for a while because I saw how little thrust they produce and just knew it would be tedious as hell to do long-duration burns before being able to time warp to the next maneuver / sphere of influence.  Well, lo and behold, I was right.  Ion enignes are virtually unplayable with the way KSP 1's game mechanics work.

It got me thinking, though:  why couldn't you just do a time warp with a trajectory that is integrated over the time of the burn or uses some discretized approximation so that a player doesn't have to be limited to the 4x physics warp and could actually let the player plan out a trajectory with a constant, low-thrust burn rather than winging it or waiting for a very long time for a burn to complete?  Obviously, the game engine would have to be able to determine whether you would have enough electrical power and whether the solar panels would be occluded at any point in the trajectory.  But, taking into account these considerations, I feel like there is a way that such maneuvers could be implemented that would be true to the real technology (and even more so than the current ion engines in KSP) and make them fun to play with rather than a tedious bore.

Anyone have any thoughts?

(Image included as an example of what a trajectory for such a transfer orbit would look like)

[The Aziz]

Warp under thrust will be possible.

[Superfluous J]

9 minutes ago, The Aziz said:

Warp under thrust will be possible.

Have they said if/how they will handle direction of the burn in warp?

Will the ship only thrust in the direction it was facing when warp started? Will it follow prograde/retrograde/etc if you have the ship locked to that?

For the diagrammed orbit change maneuver, you'd need to continuously thrust prograde for multiple orbits, for example. It also won't be obvious (unless we are given those tools in-game) at the point of starting the maneuver how long it would take to complete.

[shdwlrd]

5 hours ago, Superfluous J said:

Have they said if/how they will handle direction of the burn in warp?

Will the ship only thrust in the direction it was facing when warp started? Will it follow prograde/retrograde/etc if you have the ship locked to that?

For the diagrammed orbit change maneuver, you'd need to continuously thrust prograde for multiple orbits, for example. It also won't be obvious (unless we are given those tools in-game) at the point of starting the maneuver how long it would take to complete.

I forget where this is mentioned, but persistent rotation will be a thing in KSP2. It will be necessary for the whole thrust on rails thing.

[TheOrbitalMechanic]

8 hours ago, shdwlrd said:

I forget where this is mentioned, but persistent rotation will be a thing in KSP2. It will be necessary for the whole thrust on rails thing.

 

There's footage in this video (around 3:10) of a ship that seems to be timewarping and maintaining its same orientation relative to the planet.

R.I.P. killing rotation with timewarp, probably 

[Superfluous J]

Now all we need is confirmation that this will all work while we're not in the immediate area of the vessel, so I can do other missions while my xenon probe is slowly spiraling its way to high orbit.

And if there's some sort of way we can auto cut thrust and/or set an alarm when the vessel or Apogee reaches a certain altitude, because I don't think this will be doable with maneuver nodes

Edited December 1, 2021 by Superfluous J

[The Aziz]

Okay, why would this be any different for conventional means of propulsion if interstellar mission will have that? You don't expect to watch your Untitled Space Craft go all the way to another system, even under timewarp, do you?

[K^2]

On 11/29/2021 at 1:32 PM, sciencecompliance said:

It got me thinking, though:  why couldn't you just do a time warp with a trajectory that is integrated over the time of the burn or uses some discretized approximation so that a player doesn't have to be limited to the 4x physics warp and could actually let the player plan out a trajectory with a constant, low-thrust burn rather than winging it or waiting for a very long time for a burn to complete?

As pointed out, that's the plan, but I also wanted to chime in to mention that this is actually a very hard problem, which is part of why KSP limited physics warp so drastically.

To start with, each craft is a simulated object. Applying thrust can cause parts to flex, changing orientation of the engines, potentially, altering the net force if there are multiple engines working in concert. Even with a good simulation and optimizations, running this at 100,000x might be problematic to put it mildly. If the simulation still runs on PhysX, it's flat impossible. Of course, there are ways to work around that. Likely we'll see craft simulation "frozen" once it settles down and you can then increase the warp to a high factor.

In a similar vein, orientation of the craft matters. If your craft is tumbling at a few revolutions per minute, well, your effective time step can't be larger than a few seconds. Again, if you're trying to run simulation at 100,000x for long transfers, this will be a problem. This is another place where we'll probably see orientation frozen, just like it gets frozen under time warp in KSP. Will this lead to players cheating and time-warping ships with unbalanced thrust? Maybe. Though, perhaps, a similar solution will be employed where your ship has to remain in fixed orientation for a bit before you can warp.

Then we get into problems that are harder to work around. First, gravity is inherently a hard problem to integrate. Standard methods, even ones that are a touch fancy, like RK4, introduce fairly large integration errors. Even without thrust, an object you are simply integrating as it orbits a planet will be gaining energy. There are very clever methods, like ones used by JPL in their Solar System simulations, that do much better, but it gets computationally heavy and complex. For a game, you can get away with just making sure your time steps aren't too large. And it helps that this is more of a problem when you're close to a massive body, where you usually have a lower warp.

Next we have SoI transitions. This one's a bit of a nightmare, as a glancing pass through one can give you wildly different results depending on where exactly you entered the SoI, and if your integration step was too large, you're going to miss it. Worse, as your integration step changes as you adjust warp, your predicted trajectory will jump. It also means that SoI checks are part of your integration routine, and while not terribly expensive, it's significantly more math than each integration step would have been otherwise. So it's going to be a significant CPU hit both in terms of computation complexity and reduced time step to preserve accuracy.

Finally, the part that wouldn't be so bad on its own, but which can be a huge pain in the rear if you take all of the above into consideration. What happens if you are flying multiple missions in warp? Even in single player, ability to switch between several probes that are accelerating under thrust would be desirable, so you want to be able to time-warp multiple ships at once. In multiplayer this is absolutely a must. But does that mean you can't go to higher warp on your current probe if another is flying too close to a planet? What if the one you're currently piloting gets very close to something causing everything to drop out of warp entirely? What happens to all the other probes currently under thrust? Does their physics simulation remain frozen? If not, how do you fix any that might become unstable?

This is one of these problems that becomes more complex the more detail you consider. And it has to be solved right in order for the game to be playable. So we'll just have to see what happens with all of this. I suspect, we'll have some hilariously broken exploits at the release that will get patched out as the game matures. Hopefully, nothing that will prevent people from having a good time with the game from the start, though.

[Pthigrivi]

7 hours ago, K^2 said:

As pointed out, that's the plan, but I also wanted to chime in to mention that this is actually a very hard problem, which is part of why KSP limited physics warp so drastically.

Thanks for this (slightly scary) breakdown. Just from a gameplay perspective I feel like the priority would be making sure you can warp at fairly high speeds with as little error as possible. Freezing part flex and rotation seems fine, even if it causes exploits. After all we've all been using timewarp to halt rotation for years now. I can't think of a reason you'd want to time warp with a craft rotating rapidly but it would be nice to timewarp while locked on prograde or retrograde, which changes your vector over time. Do you see a reason this would be a big problem?

And yeah... over the course of a long save I could foresee dozens of craft simultaneously thrusting under warp. Makes me think if they are integrating automated milkruns it's probably best to simulate them in the least expensive way possible. 

Edited December 1, 2021 by Pthigrivi

[sciencecompliance]

11 hours ago, K^2 said:

This is one of these problems that becomes more complex the more detail you consider. And it has to be solved right in order for the game to be playable. So we'll just have to see what happens with all of this. I suspect, we'll have some hilariously broken exploits at the release that will get patched out as the game matures. Hopefully, nothing that will prevent people from having a good time with the game from the start, though.

If this were to be done right, I'd think there'd have to certain conditions that would have to be met for this to be possible, both to avoid coding in ridiculous exploits and having stable solutions that aren't too computationally intensive.  I kind of alluded to this in my original post where if you were to do this with ion engines, you would have to make sure that you had enough electrical power over the entire trajectory to maintain a certain level of thrust.  If not, you would only be able to warp under thrust to the point at which the requisite conditions weren't met.  You could also do this with the ship's dynamics under thrust to make sure that it didn't have some divergent control condition.  Shouldn't be too difficult to determine whether a craft has enough attitude control authority to be dynamically stable and maintain a specified heading.  I'm not saying this won't make the development more difficult--it certainly will--but it won't be so difficult as to make this problem someone's Ph.D. thesis.  As long as you can maintain thrust along one of the cardinal directions (prograde, retrograde, radial out, radial in, normal, anti-normal), that would be enough for me.  I just want to see technology like ion engines included in the game in a way that is both (relatively) true to reality and fun to play around with.  As it currently stands in KSP 1, ion engines both have a lot more thrust than they do in reality and a lot less thrust than is necessary to make them fun.

[OHara]

The plan in 2019 was to integrate thrust (under "automation") and continue rotation ("persistent rotation") during time-warp and when focused on another craft:

 

The realistic possibility of thrusting while rotating would, I think, frustrate new players so much that I doubt KSP2 implements that.  I guess they will implement at least a constant thrust holding a constant direction.  Maybe they will implement thrust while holding prograde, although in this case they might need to auto-zero the thrust upon SOI changes.

I don't want to worry in advance about exploits, like tricking KSP2 to hold prograde during time-warp on a craft with insufficient control authority, because now is the time for the KSP2 developers to handle those worries.

The way time-warp freezes rotation in KSP1 is a little un-fun. When I was a new player it was very difficult to stop rotation in early career without SAS, so a quick time-warp is a tempting cheat that makes the player feel guilty.  Better to have rotation-damping SAS come earlier in the game, I think. 

More complicated loopholes, like maybe holding thrust orientation despite insufficient battery power, might not be worth preventing.  When KSP1 tries to enforce rules about sufficient power and cooling for its ISRU systems, I suspect it does so wrongly, or maybe I don't understand the rules, resulting in my simply cheating my ore tanks full because the ISRU maintenance mini-game is no fun for me.

[shdwlrd]

1 hour ago, OHara said:

The plan in 2019 was to integrate thrust (under "automation") and continue rotation ("persistent rotation") during time-warp and when focused on another craft:

 

The realistic possibility of thrusting while rotating would, I think, frustrate new players so much that I doubt KSP2 implements that.  I guess they will implement at least a constant thrust holding a constant direction.  Maybe they will implement thrust while holding prograde, although in this case they might need to auto-zero the thrust upon SOI changes.

I don't want to worry in advance about exploits, like tricking KSP2 to hold prograde during time-warp on a craft with insufficient control authority, because now is the time for the KSP2 developers to handle those worries.

The way time-warp freezes rotation in KSP1 is a little un-fun. When I was a new player it was very difficult to stop rotation in early career without SAS, so a quick time-warp is a tempting cheat that makes the player feel guilty.  Better to have rotation-damping SAS come earlier in the game, I think. 

More complicated loopholes, like maybe holding thrust orientation despite insufficient battery power, might not be worth preventing.  When KSP1 tries to enforce rules about sufficient power and cooling for its ISRU systems, I suspect it does so wrongly, or maybe I don't understand the rules, resulting in my simply cheating my ore tanks full because the ISRU maintenance mini-game is no fun for me.

Thanks for finding that interview.  

Yes, the frustration in arresting the rotation of an out of control craft is real, but not only for new players. Anyone who has built large stations knows about that pain too. The availability of the right parts and better SAS in the beginning would help avoid that situation for beginners. Better physics and joint behaviors would help with the giant crafts and stations that you will need to build. 

I've never played with the persistent rotation mod. But if it works as advertised, I don't see how you can use that and thrusting on rails as an exploit. The only thing I can see happening is spinning fast enough to tear the ship apart. With the advanced collision detection that was featured a little while ago, I can't imagine many exploits coming from this specific topic. 

Manually controlling a craft under warp, I don't see that happening. I think you will need a flight plan or maneuver setup for thrusting in time warp to actually see a controlled flight. If there isn't anything setup, you're at the whims of the physics engine and whatever comes from that. (Errors and all.)

[K^2]

13 hours ago, Pthigrivi said:

I can't think of a reason you'd want to time warp with a craft rotating rapidly but it would be nice to timewarp while locked on prograde or retrograde, which changes your vector over time. Do you see a reason this would be a big problem?

The only reason I can think of that this might be slightly problematic is if you want to start keeping track of resources required to adjust orientation. If we are happy with a fiat that the ship at this point has enough authority to adjust and maintain orientation with vectored thrust or what have you, then it's no harder to integrate e.g. prograde hold than a fixed orientation. So long as the direction of acceleration doesn't change much from one time step to another, it's fine.

[Bej Kerman]

16 hours ago, OHara said:

The realistic possibility of thrusting while rotating would, I think, frustrate new players so much that I doubt KSP2 implements that.

I think that keeping craft rotation under control is a challenge that shouldn't be zapped away using timewarp. There's challenges all over KSP 1 like this that, now we've gotten accustomed to overcoming them and coming up with small cheats (like this one), the prospect of having to actually deal with things like this in KSP 2 looks scary. I don't believe it's scary - if the prospect of having to deal with rotation properly is scary, you'd better start coming up with solutions soon. I, for one, welcome these new challenges such as landing near bases propulsively and doing interstellar burns. I don't think these things should be worried about.

[K^2]

4 hours ago, Bej Kerman said:

if the prospect of having to deal with rotation properly is scary, you'd better start coming up with solutions soon

Honestly, I'm more worried about the game handling it than players. Rotation is inherently non-linear and does bad things to numerical integration. It's fine when your simulation runs at a framerate much higher than the rotation rate, but for long voyages under warp, that just isn't an option.

On a related sort of note, I do hope we'll eventually get some programmable parts. Building custom scripts to help with some navigation and control problems could be an interesting challenge for some. Though, that's another thing that I don't think will be available under warp as fun as it would be.

[t_v]

Yeah, rotation seems like a nightmare, but going back to the problem of stuff like SOI changes, I’m optimistic because we’ve seen that the devs have already implemented systems that do better than simple steps in the form of collision detection. As @K^2 has pointed out, there are many problems with managing short-time events at high warp, because depending on the step size, the events will play out differently. To fix this, an algorithm can be run to detect the times at which the time step needs to be reduced, such as when flying through a ring or entering an SOI. As people pointed out, an algorithm like this is computationally expensive, but I think that can be countered by the fact that it only has to be run when changing parameters, and not throughout the course of the trajectory. So overall, I think that attaining realism doesn’t require a smaller time step all the time, just a one-time-run function that will determine when to apply those smaller time steps. 
 

Another thing that I want to bring to the discussion is UI. I don’t want to see my trajectory for if I continually thrusted for most craft, only the current trajectory so that I can cut off thrust at the correct moment, but for really weak ion engines I would appreciate it. So how to differentiate it? First, I don’t want two trajectory lines at once, because that would be really annoying and all the nodes would clog the screen. Second, I don’t want engines to be preset one way or the other. Maybe I want to use my Daedalus as a landing engine and want to see my landing trajectory without having to contantly cut the engine to check it. So I think there should be a key bindable toggle to switch the trajectory mode. It is really not a perfect solution and adds to the mass of functions that have to be memorized because they ate bound to keys, but the point of this is to start a discussion on how to best handle trajectories in the UI

[K^2]

6 hours ago, t_v said:

To fix this, an algorithm can be run to detect the times at which the time step needs to be reduced, such as when flying through a ring or entering an SOI.

Mhm. The unfortunate consequence is that as time step goes down, at some point, you'll have to start reducing warp factor as well if you want CPU to keep up. Which means that if you are flying multiple missions, a probe that's doing a slow burn to raise it's orbit in the home system could be limiting maximum warp of your interstellar mission. But this might be something we just have to live with, and you'd have to plan your missions accordingly. Or there could be some other workaround that I'm not thinking of. *shrug*

[t_v]

Well, as long as that probe is burning at a constant thrust, it’s trajectory would be set (as in you could see the trajectory spiral that the initial post was proposing, and that spiral is not changing) and the times it would need to slow down warp would be already calculated and stored, so likely the worst interruption to your interstellar mission is a probe that is slowly spiraling from a ringed planet and passes through the rings, slowing the warp, although this interruption probably wouldn’t last more than one pass through said rings. Other than that, most missions can simply follow their pre calculated trajectories without worrying about time step, similar to how it is done in the current game. Essentially, thrust under time warp will work just like regular time warp but with a different looking trajectory, and in some rare cases will just end up slowing your time warp down for a few moments. 
 

Edit: for the UI, a simple toggle probably wouldn’t work. One user story that I want to submit to the devs is “I want to be able to rendezvous my (normal?) craft with one that is under constant thrust” which means that I need to see on my map screen both a normal orbit and the constant thrust orbit, so it cannot be a toggle. Either there needs to be an automatic way to identify a craft as constant thrust, or there needs to be a way to set it on a craft-by-craft basis. 

Edited December 3, 2021 by t_v

[Bej Kerman]

2 hours ago, t_v said:

“I want to be able to rendezvous my (normal?) craft with one that is under constant thrust”

Not an ideal situation for a rendezvous scenario

[t_v]

1 hour ago, Bej Kerman said:

Not an ideal situation for a rendezvous scenario

Decidedly not, but say I had a large craft spiraling through the system, I would want to be able to take my depleted craft and hitch a ride towards a planet, and I could turn off the thrust for a few hours while I get around to docking

[SciMan]

I have a feeling that a lot of this will be helped immensely by the fact that they're still largely using only patched conics for simulating orbits, and when it's not that, it's the "restricted N-body" problem where you fix the orbits of the planets and let the sole independent variables be linked to just the vessel itself.

This (restricted N-body) is the method that Orbiter Space Flight Simulator used (Hail Probe!), and that was sophisticated enough to let you have many many vessels in orbit of any combination of the planets of the IRL solar system, and it had options to use the RK8 integration method, as well as accounting for non-spherical gravity sources and gravity-gradient torque (making orbital plane precession manifest itself naturally, as well as allowing passive gravity gradient stabilization of something like a space station).
Really, it was quite amazing just how well it ran considering the complexity of the math it was doing regarding vessels traveling along their orbits.
Time warp in Orbiter worked at up to 1 million or 10 million times faster than real time (been a long time since I played it), and back when I was playing it (around 2008) even on the computers of the time I was getting 600 FPS with absolutely no problem whatsoever, with the FPS only dropping slightly at the absolute highest time warp levels.
Oh and there was no such thing as "on rails" or "physics" warp, you could fire your thrusters at any time (even during time warp) and even do things like adjusting what attitude you are in and what thrust level your engines are operating at, all while constantly changing the speed of time passing, and the game didn't so much as bat an eye at it.

Really the only thing that would make the physics reliably mess up in Orbiter was flying too close to the sun, which would cause the physics to mess up because of floating point rollover and/or roll-under effects (apparently those variables weren't clamped to keep them at sane values, so you could "bounce" off the sun and get sent at like 500x the speed of light out of the solar system).

Mind you, that was with a PC that had (I think) like a Core 2 Duo CPU in it, and Orbiter had NO facilities for optimization against multi-core CPUs. Graphics cards also weren't particularly capable either back then, yet like I said, it was managing 600FPS EASILY (I had VSync turned off).

I guess what I'm trying to say is that if Intercept has problems implementing the physics and thrust-on-rails, they have a good example waiting for them in Orbiter.
Heck back when I was playing it it even ran fantastically (maybe not 600fps which was apparently the fastest it could possibly run, but it wasn't bad at all) on a school laptop, which didn't even really have a dedicated GPU in it, and I think my current tablet has a better CPU and more RAM and a better GPU than those old 2005-6-7 era school laptops (Dell brand I think). What I'm trying to say is that these days it would run nicely on a potato computer, heck I don't doubt that it would have no issues running on a Surface Pro "tablet PC".

Oh and I forgot to mention, since this is probably important. Orbiter was made by a college professor, and was released with as open source of a license as possible. It's so old that it even started out as a DX7 game (tho a DX9 rendering pipeline is available for it, which is what I always used).

 

EDIT:
On a totally unrelated note, I do hope that they'll have features available to allow "burn splitting" for things like Hohmann transfer ejection burns and when you want to save propellant doing a plane change by raising your Apoapsis at AN/DN first, basically instead of doing the whole burn right when you need to do it, you split it up into several burns so that only the last burn is the one that sets you on your interplanetary trajectory. This is a good thing because it lets you take more advantage of the Oberth effect, while still having a vessel with a somewhat low TWR (not as low as a craft with an ion engine, this would be best for things using vacuum-rated Hydrolox engines, or nuclear thermal rockets).

The complex part of getting this to work is the math that works things out so that you still arrive at your orbital periapsis right when you had the maneuver scheduled originally (when you initially created the maneuver as a default "single-impulse" maneuver).
I know there is at least one mod for KSP 1 that helps with this, and I did have that installed at one point, but I never really got around to using it so I'm not sure just how well that actually ended up working out. But the presence of that mod means that someone's already worked out the big problems of how to implement this before, so it shouldn't be too hard for Intercept to do that either.

Edited December 3, 2021 by SciMan

[K^2]

15 hours ago, SciMan said:

I have a feeling that a lot of this will be helped immensely by the fact that they're still largely using only patched conics for simulating orbits, and when it's not that, it's the "restricted N-body" problem where you fix the orbits of the planets and let the sole independent variables be linked to just the vessel itself.

Surprisingly, no. Well, a little, but it depends. So if you want to get really technical, there is an entire branch of physics called perturbation theory.  This is how you compute, for example, precessions of orbits. Things like Monlniya orbit are solvable and computable because we have perturbation theory. It usually deals with periodic perturbations that cause periodic motion to drift predictably, again, such as the precession of orbits, but it can also be applied to non-periodic input. Specifically, we'd be talking about Hamilton-Jacobi Equations. Math, loads and loads of math, but the bottom line is that instead of integrating forces applied to a craft in orbit, you can integrate the change to orbital elements directly based on engine thrust only. The advantage is if applied force is small, or at least comparable to the gravitational forces, the error is much less than if you integrated directly.

But the math, Thor Odinson on a pogo stick, the math! In practice, it works out that you are better of using your basic Newtonian mechanics and a fancier integration method on a finer time step to get the same precision with less computation. Unless, of course, you have some special advantage of going with perturbations, like the periodic case mentioned earlier. So in practice, for what we're dealing with in KSP2, the fact that without engine thrust you're just flying a patched conic doesn't really help you get better results when engine thrust is applied. The advantages of going to a fancy method where that matters are outweighed by increased complexity of computations you have to perform for every step. So you just do the math, applying engine thrust and gravity forces to the craft, and in grand scheme of things, whether you have just one source of gravity or a whole bunch doesn't really matter.

The reason why I think Intercept still wants to keep patched conics rather than just go N-body is because while it makes no difference to the craft flying under thrust, majority of objects that the game tracks are going to be passively orbiting, and for these objects, of course, the fact that you're on patched conics means you can just keep them on rails. That is, you still have to do SoI checks, but within a particular SoI, you just update the anomaly and keep all other orbital elements fixed.

22 hours ago, t_v said:

Well, as long as that probe is burning at a constant thrust, it’s trajectory would be set (as in you could see the trajectory spiral that the initial post was proposing, and that spiral is not changing) and the times it would need to slow down warp would be already calculated and stored, so likely the worst interruption to your interstellar mission is a probe that is slowly spiraling from a ringed planet and passes through the rings, slowing the warp, although this interruption probably wouldn’t last more than one pass through said rings.

So while I think caching can, in general, be used to improve the performance a whole lot here, trying to compute the entire trajectory upfront seems impractical. I haven't tried writing an implementation for this, so I might be entirely off base, but going off the fact that KSP absolutely struggles to keep up with updating positions of on-rails craft at 100k time warp as is, simply because of SoI and planetary collision checks, even if we pin a lot of it to bad optimization, the idea that you'll perform the much harder computations of integrating trajectories several minutes ahead effectively instantly seems like a bit too much.

Now, obviously, some sort of trajectory has to be projected forward, but I have a feeling this is another place where corners will get cut, and the future trajectory is going to be a very rough estimate for cases where you have the thrust on. I'm sure it will end up very close if there are no SoI encounters along the way, but it's these exact edge cases that make me worried and the reason I don't think simply storing this loose trajectory is going to cut it. You are going to have to recompute the integration in real time.  Which is exactly where problems with flying multiple missions at the same time are likely to arise.

Of course, I am making certain assumptions here about what is and isn't deemed as acceptable precision. Intercept might view this entire problem in a completely different light, and be perfectly happy with integrating trajectories ahead of time at whatever precision allows it to be feasible and simply storing the results for time warp. It's not how I would solve it, but I'm not the one making this game.

[SciMan]

Perhaps they can improve how they do the SoI checking, at least for vessels not under thrust orbiting around bodies where restricted-N-body is not being used?
My first idea is that when you're orbiting a body that has no natural satellites (ie a moon, or something like Dres which is a planet that just doesn't have any moons) then you can just do SoI checking based solely on orbital eccentricity. If it's below 1.0 (maybe with a tiny fudge factor to handle potential integration errors), your orbital elements are gonna stay where they are forever, so you can cache that result until the player pays attention to that vessel in some way again.
If the body you're orbiting DOES have natural satellites, all you need to do is cross reference the orbital elements of the vessel with the orbital elements of the natural satellites (plus or minus the SoI radius for those natural satellites), and then you can easily rule out any chance of the vessel ever encountering the SoI of those natural satellites, and (yet again) cache that result until the player interacts with that vessel in some way again (be that docking something else to it or just piloting).

Seeing as (at least in my playing of KSP 1) the majority of vessels that I need to have in orbit are simple communication relay satellites that once I place where I want them I never pay attention to them again, it seems to me that this would simplify the math the game has to do by vastly reducing the number of sphere of influence checks the game needs to do (since it can pre-cache results for everything that's never going to be on an intercept trajectory).

This would also allow for a lot more asteroids to be in the asteroid belt, since they have no gravity of their own and are counted by the game as a single-part "vessel", and often don't have a trajectory that intersects anything, while still allowing the player to go out and harvest them for resources and/or scientific results if they so desire.