We be burnin'

[cocoscacao]

Since this part of discussion is now officially buried in a locked thread, I'll just continue here. Maybe it would be good if mods shuffled relevant posts here, if it isn't too much of a hassle?

@RocketRockington Well, you've picked my interest, but I think we didn't end on the same page. The question isn't targeted at you specifically, but anyone who might be able to answer it. Maybe @Gotmachine already has, but I'm too dumb to get it.

I've checked the wiki for Tsialovsky's equation, and sure, you can compute dV "analytically", but that isn't what's itching me. When burning, TWR is getting higher and higher, meaning that the trajectory is changing faster and faster towards the end of the burn. TWR still needs to be computed at every step to get correct trajectory. dV doesn't really matter.

Simple example. If you have a rocket, you can:
1) burn continuously, until the fuel is spent, and get some trajectory.
2) do several burns with some pause interval in between them, and get a different trajectory.

Different trajectories can be made with same amount of dV (we all do correction burns after all).

I'm uncertain if I understood @Gotmachine correctly here. Quote:

Quote

what they did is just disable physics when timewarping, and are directly summing the forces resulting from engine thrust to compute the frame displacement.

How is the engine thrust (TWR) computed in the same way for different time-warps, when you have larger elapsed time for each game tick (which sounds suspiciously like the 2nd example given above)?

Alas, I'm unable to fire up KSP 2 atm to check if continuous burn under different time-warps yields the same orbit.

[Gotmachine]

17 minutes ago, cocoscacao said:

How is the engine thrust (TWR) computed in the same way for different time-warps

I haven't looked into it, but I wouldn't be surprised if they are just ignoring the problem. What I can say at least is that I looked into other subsystem having long standing timewarp related issues in KSP 1, and they didn't address any of those in KSP 2.
Indeed, running at variable timesteps will introduce incoherencies.
And, no you can't just substitute numerical integration for an analytical solution.
You can for some limited parts of the problem, but not for the general dependency chain of every involved subsystem, meaning you're adding more complexity, you are solving only part of the coherency problem, and in the end it might not even be much better computationally than running the numerical integration with a lower time step in the first place.

[Observe]

I probably missed something, but I wonder why do we want to time-warp while operating engines? Generally, engines only run for a few minutes or so. High efficiency, low powered engines (ion for example) may run for longer, but not so long that warp makes sense (to me). Sorry if I'm missing something obvious.

Edited May 10, 2023 by Observe

[cocoscacao]

8 minutes ago, Observe said:

High efficiency, low powered engines (ion for example) may run for longer, but not so long that warp makes sense (to me).

First, just having to wait idly for several minutes, is simply a poor gameplay experience. Second, interstellar burns may last significantly longer.

[K^2]

If you have Isp of the engines, you know the mass flow. So a TWR update in vac is a single op per tick. You still have to run sim for all the time ticks, but you're literally just double-integrating thrust + gravity and updating the mass. You can run this at 10k+ warp without breaking a sweat. The hard parts come from SoI changes, stages running of fuel, and other boundary conditions. That's what would make 1M warp hard, for example. I don't know how hard Intercept plans to push this. For interstellar, this can become a hard problem. For in-system, even for things like time-warped ion burns, it really isn't.

[Alexoff]

14 minutes ago, Observe said:

I probably missed something, but I wonder why do we want to time-warp while operating engines? Generally, engines only run for a few minutes or so. High efficiency, low powered engines (ion for example) may run for longer, but not so long that warp makes sense (to me). Sorry if I'm missing something obvious.

It must be to lose control and tip the missile, usually this ends the engines at warp. There are still some sorts of perversions such as one-step on Eve with many hours of burning by ion engines, but this is for especially sophisticated players. Now we have an engine with an impulse of 1400 s, which is enough for the entire system.

[cocoscacao]

3 minutes ago, Alexoff said:

Now we have an engine with an impulse of 1400 s, which is enough for the entire system.

I guess game designers will leave those out of reach, until we spill enough sweat and blood with low-end tech.

[Gotmachine]

"other boundary conditions" are actually not so boundary.
If you have engines involving EC, you also need to tick the whole EC production chain, which might also involve solar panels, which in turn have time step dependent conditions (occlusion, incidence, etc).
You can also potentially have internal resource conversion chains that directly involve the consumed fuel, which you also have to tick.
If you have thermodynamics, either directly for involving engine thermals, or indirectly in the resource/EC production chain (nuclear power for example), you also have to tick that, and also account for varying over time external conditions (radiators).

All that can work relatively consistently at varying time steps up to 100x or even 1000x warp, but start falling apart quickly after that.

And no, you can't "run this at 10K+ warp without breaking a sweat", at least certainly not given the performance characteristics of the KSP 1 or 2 implementations, if what you mean is increasing the tick frequency while keeping a constant tick time step

[K^2]

Just now, Gotmachine said:

If you have engines involving EC, you also need to tick the whole EC production chain, which might also involve solar panels, which in turn have time step dependent conditions (occlusion, incidence, etc).

True. And some liberties will probably be taken. Like, occlusions become boundaries, with inverse r2 everywhere in between.

[Alexoff]

21 minutes ago, cocoscacao said:

I guess game designers will leave those out of reach, until we spill enough sweat and blood with low-end tech.

Well, it's obvious. But I think this will not happen very soon, it should be in 2-3 months, and maybe later. It seems we haven't been shown any scientific parts yet.

[The Aziz]

53 minutes ago, Observe said:

I probably missed something, but I wonder why do we want to time-warp while operating engines? Generally, engines only run for a few minutes or so. High efficiency, low powered engines (ion for example) may run for longer, but not so long that warp makes sense (to me). Sorry if I'm missing something obvious.

Yeah, 40-minutes-long burn of a rapid rescue ion powered mission I did in KSP1 once is totally fine, right? No need for timewarp here.

Still, even if a 3 minutes long burn of a conventional engine can be turned into 30 seconds long burn, that saves me 2.5 minutes of sitting and watching - not actually playing. And it adds up quickly.

[shdwlrd]

4 hours ago, Gotmachine said:

And no, you can't "run this at 10K+ warp without breaking a sweat", at least certainly not given the performance characteristics of the KSP 1 or 2 implementations, if what you mean is increasing the tick frequency while keeping a constant tick time step

Is this due too poor optimization or wrong choice of algorithm? Or is it do to just not time to solve all the outlying conditions and processes with such large time steps?

[K^2]

38 minutes ago, shdwlrd said:

Is this due too poor optimization or wrong choice of algorithm?

It's due to @Gotmachine insisting that the simulation must account for things it absolutely obviously will not. Intercept will have to cut corners to get the interstellar working, and either some of these things will happen over a much larger time step: you don't have to update angle-of-insidence for solar or thermals nearly as frequently as doing the forces integration, for example; or the Intercept will simply ignore the nuance and assume the steady state you've had when the warp started will persist. I'm sure people will find ways to exploit it in the latter case, but you simply cannot run the full sim with both sufficient fidelity for gravity interactions and sufficient time warp for interstellar to be playable. Something somewhere has to give, and the optimal solution is simplifying the model.

We already know the joint physics will be frozen during the time warp. It's natural to assume that more elements of the sim will be dropped, at least, at high warp.

[cocoscacao]

7 hours ago, Alexoff said:

it should be in 2-3 months, and maybe later.

Even so, we probably won't get full tech-tree, until every feature from EA roadmap is complete. I'm curious if we will get all science parts in that update at all. Maybe colonies will introduce "remote lab buildings" or something.

2 hours ago, K^2 said:

We already know the joint physics will be frozen during the time warp

Was that a bug with rocket "slinking" (parts moving up and down) while burning under TW? I forgot if that was resolved with patch 2.

And I totally forgot how many things can fall under this problem.

[K^2]

6 minutes ago, cocoscacao said:

Was that a bug with rocket "slinking" (parts moving up and down) while burning under TW?

No idea. I haven't experimented with it nearly enough, and I don't know how far along the current implementation is. What you're describing could be just from the longer time step at low warp, if it's still handled like it was in KSP1, or it could be due to a position reset from the joint freeze, or there could be a bad joints cache after the warp, or it could be another aspect of the world origin relocation bug....

[Lyneira]

8 hours ago, Observe said:

I probably missed something, but I wonder why do we want to time-warp while operating engines? Generally, engines only run for a few minutes or so. High efficiency, low powered engines (ion for example) may run for longer, but not so long that warp makes sense (to me). Sorry if I'm missing something obvious.

Making large dV burns in KSP1 with the ion engines could already easily result in burns of 30 minutes or more. On top of that, the KSP1 maneuver nodes do not account for the length of time it takes to complete the burn. For short, high-TWR burns the difference is usually low enough that it's easy to correct afterwards but for longer burns this becomes a huge problem. That's why they added the new maneuver system in KSP2 that can work with low-TWR engines in timewarp and account for the burn length in the prediction.

You may have missed this but with one of the patches, the thrust of the Ion engine in KSP2 was slashed from 2 kN (its original value from KSP1) to 0.2 kN while keeping EC consumption roughly the same. They did this to do justice to the ion engine's unique place in the engine lineup as a huge efficiency, low TWR engine that must be used for very long burns and eats a ton of power. Still far above the thrust of real ion engines, but already it means a burn of 30 minutes in KSP1 would now take 300 minutes (5 hours) in KSP2.

In return, KSP2 has much better wet:dry mass ratios on the Xenon tanks than in KSP1, making it much more feasible to reach high dV numbers with the ion engine... If your planned trip allows for enough time to make good use of it and you have enough power generation. Battery storage as a primary EC source for Ion vehicles was sort of viable in KSP1, but not so in KSP2 because it takes nearly 10 times the EC for the same dV.

The near future interstellar engines they want to add will also similarly work as very high efficiency, low TWR engines that need this system.

Edited May 11, 2023 by Lyneira

[RocketRockington]

2 hours ago, cocoscacao said:

Was that a bug with rocket "slinking" (parts moving up and down) while burning under TW? I forgot if that was resolved with patch 2.

And I totally forgot how many things can fall under this problem.

That's going to be an issue even if they fix their joint settings and implement something like KJR to increase rigidity - it's just the way the PhysX relaxation solver works.  It does a number of constraint relation substeps for each tick of the physics system to resolve the joints and other forces to a good state.  Think  of it kind of like how when you shake a string, it takes some time to stop wiggling and relax back to whatever position its going to settle in - basically all the joints are taking their current state, and iteratively moving toward a more 'relaxed' state where the forces are in balance.  Even when those joints are supposedly to be simulating rigid metal or w/e, under the hood PhysX still considers them to be springs.  However, the less steps you give it to relax, and the more forces you're applying to the system in the meanwhile (thrust, collisions, aerodynamic forces) etc, the more wiggly things get because the vibrations between the joints don't ever have a chance to settle. 

This is something that KSP2 CAN'T get around because of the design choices they've made. ( mostly in sticking to exactly how KSP1 did it, but with worse tuning).  They decided 'nope, we didn't learn anything from KSP1, and we're not going to bother trying another solution, we accept all the issues'.  So they have to turn physics off at high timewarp, just like KSP1 did.

[GGG-GoodGuyGreg]

This thread is like on a speed run to get locked. 

[cocoscacao]

1 hour ago, RocketRockington said:

This is something that KSP2 CAN'T get around because of the design choices they've made.

Unity related... or?

[RocketRockington]

24 minutes ago, cocoscacao said:

Unity related... or?

PhysX related, which is Unity's default physics engine.  (tbf, many real time physics engines share these issues)  You can swap out physics engines, but that's a bit more work, and means you can't copy KSP1 as closely.   The primary issue is deciding to use spring-system joints to connect parts.

Edited May 11, 2023 by RocketRockington

[Gotmachine]

2 hours ago, RocketRockington said:

So they have to turn physics off at high timewarp, just like KSP1 did

Note that there is no algorithmic solution that allow to simulate physical integrity (be it using RB joints, soft body / beam physics, or any other kind of simulation) at arbitrarily large time steps, it's not just a limitation of Unity/PhysX.
In general, not only for physics, time warp at such extreme levels as in KSP is a quite unique requirement, and one that is a massive challenge.
Everything in games (and actually, in non-games software as well) is based on the premise that logic is running in an iteration whose frequency is lower enough than real time to handle everything with a good enough degree of precision.
This make everything orders of magnitude easier than trying to solve the same logic with analytical algorithms, which in most cases is simply out of reach given the overall complexity of the logic.

That's why virtually every game having a "time acceleration" feature are only doing it at low factors like 4x or 10x. You only have two options to accelerate time :
- Increase the iteration frequency, in which case the computational cost is directly proportional to the warp factor (ie, if your PC was able to handle 100 ups at 1x, it will only be able to handle 50 ups at 2x, 10 ups at 10x, and so on). Obviously this is very rarely used, and not applicable for KSP.
- Increase the time step of each iteration, in which case you inherently get a less precise result, and past some point, you will start to hit boundary effects and get garbage, broken results out of the game logic. Some of those boundary effects can be dealt with, but this has to be done on a case by case basis, and usually require more complex specialized implementations that always have precision, performance and capabilities tradeoff. They can be either in the realm of analytical methods (rarely), or iterative methods (basically, sub-stepping some critical parts to avoid hitting the boundary effects, or using those boundaries as an iterative condition, instead of the arbitrary time step).

In KSP 1, the issues of high warp speeds were relatively rare in practice, mostly because they avoided to implement features that would be subject to such issues. So while those issues exist, they aren't too much of an annoyance. But you can definitely experience them. Everything related to resource consumption/production/conversion is utterly broken past the 1000x warp barrier, and so are thermodynamics (vessels overheating out of nowhere when getting out of timewarp is a pretty common sight in KSP 1). But at least in stock KSP, those are relatively minor feature, that only affect the currently active/loaded vessel, as indeed, everything resource related is dealt with in a comically simplified analytical way for all non-active vessels. There are many other examples of things that are utterly broken at large timewarp speeds, like the comms network or solar power evaluation. But there is barely any player interaction or effect while timewarping, so this has no visible effect.

In KSP 2, however, they made the (ambitious) choice of expanding the active vessel game logic to all vessels, essentially reducing the loaded/unloaded distinction to just "affected/unaffected by rigidbody physics". The primary motivation was very likely to provide the "thrust under warp / in the background" feature, but I'm not sure they realized how huge a can of worms they opened... This mean that all those timewarp issues will now have a much more impactful and visible effect (not to mention the performance implications). Personally, this has been my main concern about KSP 2 since they first announced that it would have an interstellar scope (meaning there will need to allow a huge timewarp max speed) and the "thrust under warp" feature (meaning they need to simulate everything coherently at any timewarp speed).

[Alexoff]

5 hours ago, GGG-GoodGuyGreg said:

This thread is like on a speed run to get locked. 

There has long been a topic on the forum where the main fans of KSP2 are looking for what they love the game for. Moderators just need to sanction a topic where one could openly criticize the game and developers, and not swear at other players. And hang an ad at the beginning so that the faint of heart do not come.

[cocoscacao]

4 hours ago, Gotmachine said:

they made the (ambitious) choice of expanding the active vessel game logic to all vessels, essentially reducing the loaded/unloaded distinction to just "affected/unaffected by rigidbody physics". The primary motivation was very likely to provide the "thrust under warp / in the background"

It would be a more sane choice to only mark a vessel as active if it's burning (unfocused) or if it is focused.  

[K^2]

4 hours ago, Gotmachine said:

Note that there is no algorithmic solution that allow to simulate physical integrity (be it using RB joints, soft body / beam physics, or any other kind of simulation) at arbitrarily large time steps, it's not just a limitation of Unity/PhysX.

So long as you're prepared to give up on bendy rockets for the duration of the warp, it is absolutely solvable. All you have to do is solve for stress in a rigid body, which is a known problem. You'd normally only have to do this once, but the solution does change as the fuel is spent and the stress gets redistributed as some parts get lighter. An iterative method will need to run a single iteration to update for mass changes, and can then spit out the new stresses for all the joints, which can be checked against limits. And because you no longer have oscillations, which is the thing that krakens your ship if your time steps get too large, you can actually increase the time step and only check for stress every few minutes or even hours of simulated time if you're running, for example, at 1M warp.

Not only is this solvable, the solutions exist. We don't have to invent anything. But it would be completely custom implementation for KSP2.

[shdwlrd]

53 minutes ago, cocoscacao said:

It would be a more sane choice to only mark a vessel as active if it's burning (unfocused) or if it is focused.  

Makes sense. It would be really daft on Intercept's part if they didn't expand the rules for active and inactive crafts when applying the physics simulation.