Where is Nate?

[dprostock]

1 hour ago, Scarecrow71 said:

You know, that's something I never could figure out as to why that happens.  I mean, I get that IRL rockets are rolled slowly from where they are built to the pad, and that in the game they spawn on the pad.  I just never understood why the physics would have the rocket start jumping up and down upon being spawned.  It's as if the game spawns the rocket ABOVE the ground, and then it falls (albeit very slightly) to the ground, causing it to bounce around.

Am I close on that?  Or do I need a new set of eyes?

Simply because they're a bunch of jerks and there's no one in charge! They apply to the entire calculation of gravity (with parameters that vary according to the celestial object) but did not realize that at the same time it causes displacement of the objects that are resting on the surface of the celestial body. Instead of cancelling it for that case, they want to cancel it with an inordinate increase in the values of the friction algorithm. The result is the same as what we saw in the KSP and they never noticed anything. 

To put it simply, the planet keeps spinning and that's why it seems that your rocket is moving, what moves is the planet and it doesn't "drag" whatever it has resting on its surface.

A no-brainer for any self-respecting engineer or developer, but hey....

It was cooler to spend time for the kerbal to behave like an ape in the little window at the bottom right corner of the screen. 

[Scarecrow71]

1 hour ago, dprostock said:

Simply because they're a bunch of jerks and there's no one in charge! They apply to the entire calculation of gravity (with parameters that vary according to the celestial object) but did not realize that at the same time it causes displacement of the objects that are resting on the surface of the celestial body. Instead of cancelling it for that case, they want to cancel it with an inordinate increase in the values of the friction algorithm. The result is the same as what we saw in the KSP and they never noticed anything. 

To put it simply, the planet keeps spinning and that's why it seems that your rocket is moving, what moves is the planet and it doesn't "drag" whatever it has resting on its surface.

A no-brainer for any self-respecting engineer or developer, but hey....

It was cooler to spend time for the kerbal to behave like an ape in the little window at the bottom right corner of the screen. 

I asked a serious question, and I was hoping to get some insight from people here.  Instead, I get this.  Sigh.

If you have nothing to add to the conversation, don't say anything at all.

[RKunze]

3 hours ago, cocoscacao said:

I thought it runs on each engine "tick" and I didn't know it approximates. I assume it at least goes through every part on each iteration...?

It does (both run in each engine tick and handle each part on every tick). And though it does approximate (can't actually do anything else, both because the problem usually does not habe an exact analytical solution and even if there is, floating point math has limited resolution anyway), that is not really the problem.

The problem is that the solver iterates: It starts with something that is (hopefully) already close to a solution and then does a couple of refinement steps until it reaches the solution (actually, an approximation that is close enough to the solution). This works very well if the starting point already is close to the solution - for example, if the starting point is the solution from the previous engine tick, and the solver just needs to catch up some 100 milliseconds or so.

But on a "cold start" of the solver, the starting point is usually very far from a solution, and the solver needs to run quite a bit longer until it finds a solution ("converges on a solution" is the technical term you usually read in papers). Or worst case, the solver does not find a solution at all in this situation - that's called "the solution diverges" or "does not converge" in scientific papers, and "Kraken attack" in KSP.

[K^2]

2 hours ago, steveman0 said:

This doesn't require it to occur immediately after a scene load, though it often does. I assumed this was due to the lack of sensible dampening forces leading to rounding errors becoming blown out by some singularity. I assumed that this would be something applied outside to overlay the physics model, but it is sounding like there might be more reliance on the canned solution that makes it more opaque in understanding what is at fault.

I'm curious to get your thoughts on this. Would the solver have something built-in to suppress spurious noise that could lead to this kind of result, or is that something that would be left to the developer to layer over the physics model to address? Anytime I've built a model for some project from scratch, I would plan some kind of corrective force to ensure a stable state for predictability. Could some of the problems observed be explainable by the absense of something similar here? This seems necessary to ensure stability even if it might not be 100% accurate to life given the constraints imposed by the boundary conditions.

I think there's more than one thing that's going on.

Modern approach is to use velocity constraints with Baumgarte stabilization for drifts. Baumgarte does work a bit like a spring coefficient, but the velocity constraint already has damping built in. So with a sensible choice of coefficients, any perturbations should naturally decay, rather than lead to more oscillation for any single joint. Unfortunately, systems of joints can still misbehave. The worst case is usually a light object sandwiched between two heavy objects. Unfortunately, I just described every single stage separator and decoupler, which immediately becomes a problem in KSP if you don't add additional joints to stabilize it (such as multi-joint connectors, autostruts, etc.)

A very good read on the topic is Erin Catto's GDC presentation from 2009, Modeling and Solving Constraints. Every modern physics engine I've seen goes back to this talk. At a minimum, Havok and Chaos do, as well as Crystal's and Blizzard's internal engine implementations because Erin Catto worked there and was instrumental in making sure these engines worked. Now, not every engine uses impulse exchange as their iteration method, but all iterative solvers are going to behave similarly. I think Erin really likes impulse exchange mostly due to its logical simplicity compared to pure linear algebra methods.

Crucially, the PhysX version that ships with Unity predates the industry's switch to this as the main method. So their constraints handling might be a little different, and I haven't looked at the code for that specifically. Though, it might be interesting to try and dig up the source for a relevant PhysX engine and to make sure. In general, even the older physics engines had to solve the same fundamental problem of enforcing constraints. And even if you start with position constraint (rather than velocity constraint) and work your way from there, you are still building a damped harmonic oscillator, but your coefficients might be less "magical" and require more careful tuning. So we're still dealing with what's ultimately a damped harmonic oscillator for each individual joint, but what can still fall into some sort of a bad feedback loop between multiple joints. And we know that mass ratios are a problem for the PhysX joints as well, so whatever the solver is iterating over, it's not that far different.

So that's one part of it. Even with a good solver, there are bad configurations that you need to learn to avoid, and for something like KSP that means either merging some rigid bodies together (e.g., if you made decoupler and whatever it's permanently attached to into a single rigid body) or doing what KSP1 does and adding additional joints in a way that avoids the unstable configurations.

 

The second part is, I think, what muddled the situation for KSP2. And here we're back to logical connection vs actual joints. I have seen a number of times when a ship spawns in (either at the launch site or from a save) with some parts detached. And it's one thing to just watch some part of your ship drift away, and another is if it's some internal part with collisions that ends up doing a ragdoll-spaz inside the ship. I don't know how many of the KSP2 physics explosions are due to bad joint configurations and how many are due to a part getting loose and spazzing out. I've definitely seen both, but I wouldn't be able to identify each particular case. And I think that might have been why Intercept kept having these issues creep back up, because there are several different bugs they're trying to fix that can be reported as one bug: rapid disassembly without any obvious cause.

All of this is kind of self-inflicted, but I do sympathize. Again, it's a hard problem, and unless you happened to have worked on these exact problems before, it takes time to catch up on all the terminology and required reading.

[dprostock]

1 hour ago, Scarecrow71 said:

I asked a serious question, and I was hoping to get some insight from people here.  Instead, I get this.  Sigh.

If you have nothing to add to the conversation, don't say anything at all.

Does it bother you really? I am sorry. It's the technical answer you should have been hoping for.

If you don't want to know the truth, don't ask.

No one realized that the gravitation algorithm that rotates the celestial body affected the objects perched on it, and there you have the problem. Poorly detected in KSP1 and lines of code copied in KSP2.

Anyway, everything is sterile. It's never going to be solved, that's for sure. 

The truth is out there, I'm sorry if they don't tell you. 

 

[RUD Everyday]

Remember the question, where is Nate and why isnt he anywhere to be found?

[Bej Kerman]

5 minutes ago, gfdgfherytrey said:

Remember the question, where is Nate and why isnt he anywhere to be found?

NDAs, next question

[Tony Tony Chopper]

10 minutes ago, Bej Kerman said:

NDAs, next question

I admire this simplicity, but such a chatty species can't be satisfied with mere answers I'm afraid.

[K^2]

10 minutes ago, Bej Kerman said:

NDAs, next question

To be fair (and pedantic, and as a joke, and just so that we still have a topic,) this doesn't answer the question of where is Nate.

Personally, I'd go on a vacation. Layoffs suck. If you can afford to take a break after one, you should.

And I know a lot of the former Intercept employees had to start applying for other jobs right away, but I hope they'll at least have some time between the interviews to decompress a bit. It's most definitely not the shiny part of the game dev career, but being able to use the quiet times between interviews to relax, despite knowing a limited runway on funds before you need to have a job or face serious problems, is kind of a skill we end up having to acquire. So if you're wondering, why nobody's talking, yeah, NDAs, but also, they were just laid off. Last thing they want to think about is KSP2 or Intercept.

[Skorj]

If you've ever noticed the "ease in physics" setting in KSP1, this is why it's needed.  It's not just on load, I think, but any time you switch to a new craft, it risks kraken attack due to only partial state being cached.  Squad solved this rather elegantly IMO by simply ignoring some physics effects until the physics model has time to settle down.  Now that I understand K^2's explanation, I have to admire this approach.

[GigFiz]

On 5/20/2024 at 12:42 PM, K^2 said:

Every modern physics engine I've seen

Out of curiosity, especially since you clearly have, likely, the most (and most relevant) experience in game physics programming out of everyone who frequents this forum: if this were your project and you were in the position were you got to make the decisions, what game/physics engine would you use (for sake of relevance, say, both if it was started now and for if it was started in the 2017-2020 range, like ksp2 was)? Since all we can really do now is talk about what ifs, and I (and others, I think) always value your insight, it would be quite interesting/educational to read.

Also, If you want to go into what your overall approach would be if you were engineering and/or game lead, too, please be my guest (it would be quite interesting, I imagine). I know, though, that you've given aspects of that already (though putting it all together would still be of value), and it would easily be mass wall of text that you may or may not feel like like writing, so do what you feel like. (for a given value of force). But, if you genuinely WANT to, please do.

[K^2]

8 hours ago, GigFiz said:

Out of curiosity, especially since you clearly have, likely, the most (and most relevant) experience in game physics programming out of everyone who frequents this forum: if this were your project and you were in the position were you got to make the decisions, what game/physics engine would you use (for sake of relevance, say, both if it was started now and for if it was started in the 2017-2020 range, like ksp2 was)? Since all we can really do now is talk about what ifs, and I (and others, I think) always value your insight, it would be quite interesting/educational to read.

Also, If you want to go into what your overall approach would be if you were engineering and/or game lead, too, please be my guest (it would be quite interesting, I imagine). I know, though, that you've given aspects of that already (though putting it all together would still be of value), and it would easily be mass wall of text that you may or may not feel like like writing, so do what you feel like. (for a given value of force). But, if you genuinely WANT to, please do.

It's a little bit hard to be certain in retrospective. I said a few things about that already, but some expectations we've all had about where the engines are going in 2020 have came to be, and others not so much. The landscape change quite a bit, and it's hard to now talk about it without the benefit if hindsight.

In a similar vein, what we know about the project has changed. Even just talking about what is believed to be the scope of the KSP2 plan in 2017, 2020, and 2023 are likely to have been quite different. So there are quite a few blanks to fill in with any number of plausible options.

Lets start with a slightly different hypothetical, one that's almost plausible, albeit very unlikely given the ownership chains and realities of the game market. Say the game goes on ice. About a year from now, my boss tells me, "Hey, Kat, <our company> is in talks with T2 to rebuild KSP2 under license. Want to take this one?" In this hypothetical I have a pretty good picture of what sort of resources and budgets we'd be operating with, as well as have specific people in mind for some of the work. And unless I have to be very scrappy with this, like I get only a skeleton team and just need to make the best of it, I would scrap the code and rebuild everything in Unreal. This is despite the fact that I have access to some amazing Unity engineers in our organization. The mid-2024 reality of Unity vs Unreal is that this is a better route. In part, I'm taking into the account the disaster areas of the KSP2 and that a lot of the code would have to be scrapped anyways, but it's a little bit bigger than that. The advantages of Unreal for KSP2 are quite enormous.

I'm not usually this generous towards Epic Games, but they have made several bets and investments in tech that have payed out. Crucially to KSP2, the three areas that are important are the physics engine, procedural placement, and large worlds. Chaos physics is good right now. It is better than Havok and quite a bit easier to use in your flows in Unreal than importing Havok as a middleware. That last part's just the advantage of it being already integrated, of course, and not a dig at Havok. Going with Chaos in 5.4 would eliminate a lot (not all!) of the problems with simulation stability and networking. If you were to start building KSP2 code base from scratch today in 5.4, there is zero reason not to have multiplayer enabled from the go and do all of your testing in server-client configuration. In a similar vein, basically all of the work that Intercept did for planet tiles, painted procedural biomes, and origin relocation for interstellar scaling comes out of the box with Unreal 5.4. We are talking probably the past four years of Intercept's work, about half of their team, possibly more, were building stuff that just comes packaged with 5.4. And it's better. The performance is better, the stability is better, there are more features and options...

Note that this all hinges on some assumptions I'm making about the content, and that we'd be able to port over the art and tech art work that was done on planets and rocket parts over. I'm prepared to scrap the code, because in about a year of development we can be fully caught up, and have almost all of the problems fixed "for free" because they are already fixed in the engine. But I'm not prepared to scrap the art in general, and there's a lot of fiddly planet-building work that's gone in, much of which we haven't even seen yet, and throwing that away is a much more expensive proposition. So if we were just starting KSP2 clean today, no contest - Unreal, if we're trying to salvage parts of KSP2 (which is more realistic) I still want to say Unreal, but I'm making some assumptions which might change under closer examination of what's there in the dev folders.

 

Alright, sorry about the long preamble, but that is to set up the question of what would be the correct choice for Intercept in 2020. With hindsight in mind, still Unreal - no competition. Without, there's a lot we didn't know back then. Unreal 4 was well established, and we have seen a lot of 5.0 previews to know what Epic is promising us, but there were a lot of undelivered promises in 4, so grain of salt. I started evaluating Chaos in late 2020, and it was raw then. I think in early 2020 when KSP2 dev work started, my realistic options would have been Havok or Havok. I sort of understand why "Lets use Havok in Unity," wasn't the go-to for Intercept, but I think I would have been prepared to take the risk on ECS and DOTS even if decision was made to go with Unity. PhysX just comes with way too much baggage, and Intercept has rather predictably struggled with it. The only choice besides Havok was building custom, and as fun as that would be, I don't think I'd get a sign-off on the extra budget. So Havok it would be. Now the actual choice of Unreal vs Unity would have been a little tougher back then. The team had experience with Unity and the advantages of taking parts of KSP1 that do work fine or work well enough as temps to bootstrap some parts of development are pretty clear. So it looked like a decent enough choice on the surface but.

The big tipping point is what we didn't know about the scope of KSP2, but that was clearly in Nate's mind back then. I'm pretty sure that one meeting with Nate about the art/design direction of the game would have made it clear that scalable, procedural environments for the planets with modern visuals was a big part of the 2020 pitch. And with that in mind I would have pivoted hard towards Unreal. The reason is that the proc gen stuff was already in 4. In a somewhat early form, but we've seen it in shipped games by that point. Unreal 4 also supports tiling and virtual texturing out of the box, which I know are major boons to large world development. One thing I absolutely had in my bag in February 2020 is a year of working on building these features for an in-house engine and I would feel like shaking anyone who says, "We're going to build all of that in Unity." To Intercept's credit, and part of why I'm probably less critical of them than most people here, they made that part work, and it's a monumental amount of effort. Just that alone would have probably freed up2-3 engineers and a tech artist to work on other things in KSP2 for 3 years until EA release. And even Unreal 4's implementation of these things is a bit better peformance-wise. So you'd have better framerate, Havok out of the box, and all the things that would get fixed/built with the extra technical people freed up from that work. That would already put KSP2 in a much better place, and this is just from things that would have been known to me in 2020.

Looking back, it's clear that going with Unreal 4 in 2020 would have led to a switch to Unreal 5 in late '21, early '22 and make things even better. There are still a lot of things that needed to be done differently in KSP2 in terms of architecture to make it stable and performant as a game overall, but the engine choice would have been a leg up. If you look at the speculation we've had around early 2020, you might even find some posts from me unsure on whether Unity or Unreal is a better option, but a lot of it was coming from our best guesses on the art/design directions back then, and a lot of that came from by-then outdated articles and previews.

tl;dr, a well informed and competent TD in 2020 should have chosen to go with Unreal. Going with Unity was a big mistake, and likely caused by the narrow experience of the technical leadership at the time, who knew Unity almost exclusively. Do keep in mind that I am saying that with the advantage of hindsight, as much as I try to compensate for it.

 

Rolling back to 2017, we're in a completely different world. Not only is the tech different, with a lot of the features that would make Unreal a clear winner still very early in development or even entirely as unannounced plans on the roadmap, but also the scope of the game was different, as far as we know. I'm not going to spend too much time going over this. Assuming that I understand correctly that the pitch for KSP2 was, "Take KSP1, make it look shinier, add a star system, and do some cool colony-building gameplay," Unity was the right call. You'd be able to reuse much of the work that KSP1 team did, both under HarvesteR and later with new tech team at Squad. And while at the time it would have meant steaking with PhysX, we're also talking about a smaller game where a lot of KSP1 patches on top of that would have been adequate. Especially if multiplayer wasn't planned at the time. So I think Star Theory's plan for KSP2 was fine and probably would have panned out if the scope didn't expand so much. We'd probably get KSP2 in 2020, and it'd probably look like KSP1 with some visual and interstellar mods and colony gameplay. Hopefully, with some loading issues addressed, since ST would need to improve on them for interstellar. It'd be fine, and most KSP1 players would probably jump over to it.

 

In terms of general changes I would make compared to how KSP2 seems to have been developed across both iterations, I'm just going to run through bullet points.

• Introduce compound rigid bodies. It'd be exposed to Chaos/Havok/PhysX as a single rigid body, but we'd be able to compute the stress on implied joints between the actual component parts of it. So if any limits are exceeded, it can still break, and if it crashes into the terrain, parts of it could be destroyed rather than all of it at once. I've mentioned advantage for colonies, but you can also use it for physics LoDs and crucially for things like a tank with a decoupler or docking port on it. The latter parts are very light compared to the tank, making the joints flimsy. Turning this into a single rigid body would make all the joints so much more stable even if we're talking about KSP2 2017 and we're doing this in PhysX. So many physics problems would just not.
• Don't rely on game physics for any part of orbital motion simulation. The CoM of every ship should be on its orbital element rails, with any external forces (sum total of all engines or a binary planet situation) added together and applied to the ships in this bespoke simulation. So even if you're focused on a ship, yeah, it should be simulated for any rotation, part flexing, joint stress, etc. But the net force applied to it should go to the external, bespoke orbital mechanics sim that just moves the ship's CoM. And in your local view, the ship's CoM should be reset to that position on every frame to nulify drift from any Kraken forces. Energy and momentum should be conserved, full stop.
• Build the data representation incrementally, testing along the way. Playtesting, QA testing, and unit tests everywhere. The KSP2 data mess looks like the team that worked on saved games, editor, and actual simulation never talked to each other. I don't know how that happened, I wasn't there, but I'd like to think I can avoid that kind of a disaster. It's just bad.

There are also performance considerations that are graphics related. I'm not a graphics engineer, though. And I don't know how much of what we've seen in KSP2 is really a tech problem, and how much is just tech art not having had an optimization pass. It's very easy to make a quick and dirty shader that does the job but is awful on rendering performance, and you see a lot of that in early alphas. Given that EA is pre-alpha, I'm not sure how harsh I should even be on this. But the bottom line is if there were tech issues, I don't know if I'd know how to fix them. But I also don't really need to. The most important bit is knowing how to find people who can do these tasks. I think a lot of bad calls in that regard were budget restrictions, but it also seems like tech leadership at Intercept hasn't done an ideal job of it. So that's sort of the final part of it.

And as a final note, a lot of what I wrote here is criticism, but I know where some rakes are hidden, and I don't know how many rakes Intercept avoided that they knew about that I don't. I think I could have made a much better KSP2 from the purely technical perspective whether I was given the TD on it in 2017 or 2020. Would KSP2 be a better game overall? I don't know. It'd be less broken, but would less broken KSP2 that looks like garbage and has almost unusable UI and editor be better? (Not saying as a necessary cost, but purely as a hypothetical, knowing that these are areas where my own expertise wouldn't be enough.) I don't know. So don't levy all of that against ST or Intercept. This is purely a list of ways that would have been available to make things better if somebody with the right talents was on the team, but everything's an opportunity cost.

[Superfluous J]

1 hour ago, K^2 said:

<snip a lot of very informative and thoughtful commentary>

I couldn't give this post 10 likes so I went back and gave a like to the last 10 posts of yours that I hadn't already given a like to

1 hour ago, K^2 said:

Don't rely on game physics for any part of orbital motion simulation.

That this isn't already a thing blows my mind. I understand why it wasn't that way in KSP1 because by the time it was obvious it was needed it would have probably taken a whole game rewrite... but the whole point of KSP2 was a whole game rewrite!

[Stevie_D]

Whenever I see the title of this thread, my mind goes back to The Dark Knight and, instead of Harvey Dent, the cop saying : "If Nate's got any sense, he's halfway to Mexico by now." 

[K^2]

49 minutes ago, Superfluous J said:

That this isn't already a thing blows my mind. I understand why it wasn't that way in KSP1 because by the time it was obvious it was needed it would have probably taken a whole game rewrite... but the whole point of KSP2 was a whole game rewrite!

It's really easy to fall into the hole of, "Orbits will be fine, so long as the integrator is good," because gravity just doesn't like that happening. If you are coming into it from perspective of a game developer, velocity Verlet solves basically all your problems, and RK4 is there for the few cases it doesn't. Gravity is a rare exception to that. Likewise, if you're coming in from physics, the understanding of the physics can actually be a little disarming. All of the actual physics that's relevant to a game like KSP I have learned in undergraduate courses, mostly in Classical Mechanics. I've picked up more context, some methods, and just experience using this in the later years studying physics, but if anything, it made me feel like gravity is a simple problem compared to other things I knew. And that can do more harm than good when you start trying to solve a practical problem.

The only reason I really know better is because I have tried to write simulations, realized I'm crap at it, and started looking at other ways to do this. And I've done so incrementally over the years, often prompted by something that came up in KSP or on this forum. This is an atypical experience for any given team you'll put together to make a game.

I can only guess at the logic that went into the KSP2 sim, but the requirement to warp under thrust was probably what kicked off the chain of bad decisions there. KSP1 didn't need to do simulation. The moment you go into warp, simulation's frozen and everything's on rail. The only part of it that's sim-like is SoI boundary crossings, and as far as I can tell, it would just check if you are in a different SoI after doing a time step. So there was some randomness based on where the true SoI crossing is compared to the step size, but it's nothing that's going to impact the gameplay. I'm sure that even with the on-rails update there were places where drifts could occur, but it's nothing like KSP2's.

In KSP2, you had to be able to leave the engine running and go to max warp, because you're not crossing an interstellar void otherwise. So you have to simulate physics somehow. And it turns out, applying a simulated force to an object in orbit is actually really, really hard. We're talking old books, from the pre-computer era hard, because while there are numerical methods for dealing with this, they're absurdly expensive computationally. If you want a good simulation that gives you stable orbits, is fast to compute, and can work across time warp ranges, you have to work with orbital elements, and not simply use them as a convenient geometrical representation, but understanding how they arise from the constants of motion, understand Hamilton-Jacobi equations, have a strong sense for a classical perturbation theory... This used to be fairly common part of physics curriculum in, like, 70s and 80s, back when things like orbit precession had to be computed by hand, but basically as soon as that was replaced by computers, it started becoming a lost art. And it's not that it's so hard to learn for anyone who has been doing other areas of physics. It's just knowing that you need to learn it so that you can do the numerical simulation that KSP2 requires is a very non-trivial bit of domain knowledge.

And yeah, it's not like it hasn't come up before. There have been numerous discussions on physics under warp and n-body gravity on this very Forum, plus a number of members of KSP1 modding community have become acutely aware of the problem trying to implement these features as mods. So it's not like KSP2 team wasn't able to discover both the problem and some potential paths of solving it in advance. But they evidently didn't, so that was another rake in the tall grass.

[FreeThinker]

7 hours ago, K^2 said:

 And it turns out, applying a simulated force to an object in orbit is actually really, really hard.

I don't recall it beeing that nessisary computional hard, basicly what you need to do is adjust the orbit every time Delta  with generated engine Force. As long as your positional orbit isn't too curved, or crossing SOI it seems to work fine when you prevent the edge cases.

Edited May 23 by FreeThinker

[DA299]

I bet the Principia devs could have helped out KSP2 devs when it comes to orbital simulations. Their handling of orbital mechanics is far better than stock KSP1, with the exception of thrust under warp. but like K^2 says, that's a very hard problem, likely even harder in true n-body simulations.

[K^2]

3 hours ago, FreeThinker said:

I don't recall it beeing that nessisary computional hard, basicly what you need to do is adjust the orbit every time Delta  with generated engine Force.

The question comes down to how you update the orbit. KSP1 ran this for ships under player control in Cartesian coordinates. Fast and dirty, and also results in an absurd amount of error. It looks like KSP2 team was doing something very similar. And in Cartesian, just integrating the main body's gravity goes awful immediately.

If you are integrating forces in orbital elements coordinates, you're back to doing very heavy math for changes in argument of periapsis and anomaly at epoch.

Fortunately, KSP simulation doesn't need to be predicting with high degree of accuracy if a given real world asteroid is a danger to Earth 30 years from now. So a mixed coordinate system can be used as I've mentioned earlier in the thread. So long as you integrate energy and angular momentum change directly, your orbital shape will be correct, and then you can use the Cartesian update to figure out periapsis precession and the true anomaly update. And if these latter two end up a little off, nobody playing the game will notice.

3 hours ago, FreeThinker said:

As long as your positional orbit isn't too curved

That part there are at least standard methods for. You basically have to run a variable time step, with different step sizes for every craft, depending on their local gravity strength and the engine thrust. In most of these cases, the craft is either engines-off and on rails, or it won't be in high curvature area for long, so it's ok to spend more computation there. At worst, you'll have very occasional slowdowns in your simulation.

The only special case is low orbit, low thrust. Here you'll have to pull out some formulae from dusty books on satellites orbiting the Earth to see some approximate analytical solutions which will let you apply coarser steps to such craft.

[GigFiz]

15 hours ago, K^2 said:

Lets start with a slightly different hypothetical

That one really falls in with the things I was wondering, so that was great. And thank you very much for the detailed answer!

I've seen so much talk about how Unity was the wrong choice, that it makes you wonder why they used it in the first place, but the change in scope after starting in a place where it had advantages, does make sense, and seems like it certainly led to problems when they ended up at place where they were making something with an engine that no longer made sense for the project, but were likely in too deep, and probably couldn't get the time/budget/manpower approval for an engine change, even if that was on their minds as something they wished they could do.

By the by, what do you think of their solution for precision at the scales of distance being dealt with? There was a dev diary about the problems with necessary floating point precision being impossible at the distance scales being dealt with, without resorting to methods that increase computation cost impossibly high, so essentially they had a little bubble of higher precision simulation around the craft being controlled, in order to get the precision necessary for things like docking. Judging from the explanation, and the overall logic of the problem, it seems like this would be necessary, and your answers would lead me to think you would go in a similar direction, but curious about if you think that's one they got right, or if there was a better alternative.

Edited May 23 by GigFiz
spelling

[K^2]

1 hour ago, GigFiz said:

By the by, what do you think of their solution for precision at the scales of distance being dealt with? There was a dev diary about the problems with necessary floating point precision being impossible at the distance scales being dealt with, without resorting to methods that increase computation cost impossibly high, so essentially they had a little bubble of higher precision simulation around the craft being controlled, in order to get the precision necessary for things like docking. Judging from the explanation, and the overall logic of the problem, it seems like this would be necessary, and your answers would lead me to think you would go in a similar direction, but curious about if you think that's one they got right, or if there was a better alternative.

It's a standard solution. When you're doing floating point math, your sensible options are single precision (32 bit) or double precision (64 bit). And while most modern CPUs do basic operations with double precision floats at an ok speed, a lot of the vector operations aren't built for it, and consumer GPUs are absolutely horrible with it. Your realistic performance penalty from going from 32 bit to 64 bit floats could easily be in 5x-10x range. As a consequence, none of the tools are even built for it as an option, so you'd be stuck with dirty workarounds to have an awful performance in the end anyways.

And 32 bit floats are precise to roughly one part in 10 million relative to their magnitude. So if you're dealing in distances of a few km, your precision is sub-mm, and that's fine. Once your distance scale is more like an astronomic unit, the smallest increment you can do in your position is in tens of km, so all your craft parts and geometry are at the same exact coordinate to that floating point precision. Realistically, though, your ship will get krakened to bits long before you make it that far.

So instead, you do all your physics and rendering in some sort of a local coordinate system, relative to an origin that you relocate as needed. There is a little bit of a leeway in how you store that origin's position, and I haven't looked at how KSP2 handled it. A lot of open world games that start running up against this simply store origin as a float as well, and eat the complexities of dealing with the fact that the location isn't perfectly fixed, but even that starts getting wonky at interstellar distances. Using a double precision float is a lot more viable for the origin position, since you don't use it in simulation - it's just an offset. So that's pretty common. I would make a case for using a 64 bit integer, though. You could then place an origin anywhere within 1km of where you want to do the simulation, which is close enough, and that'd still let you place objects nearly a million real world light years away from Kerbin without loss of precision.

The way Intercept talked about it makes it sound like they were having more trouble with it than I'd expect, which might be just the devs never having to have had to deal with this before, but otherwise the approach is fine. It does look like they had some bugs in the relocation code, and I don't know if they were all fixed, but that in itself isn't really uncommon either. This is just part of a development experience for a game where distances are that huge.

[PDCWolf]

13 hours ago, Superfluous J said:

 but the whole point of KSP2 was a whole game rewrite!

From our position. For IG/PD/T2 it was, I'm pretty sure they thought, a golden egg goose with a very quick turn around and minimum budget for the numbers T2 oversees.

[R-T-B]

I'm just going to drop this here:

With Kopernicus's distant collider fix (it disables colliders too far out to be relevant in gameplay, or in our case, past stock eeloo distance), you can actually move pretty reliably between systems literal lightyears away.  Actually, the only real bugs with moving to systems that far out appeared in 1.8+...   This is all In KSP1.  So they certainly had some knowledge of floating origin working, it just needed some tuning.

Edited May 23 by R-T-B

[AVaughan]

14 hours ago, K^2 said:

In KSP2, you had to be able to leave the engine running and go to max warp, because you're not crossing an interstellar void otherwise.

I actually think they made a mistake in going for interstellar travel that way.  Even their new manoeuvre node editor seems to only generate burns in a constant cartesian co-ordinate frame.  Whereas if you really want to do long durations burns efficiently, (eg ion engines) you want to be able to do burns that are always parallel to your prograde vector, so I'm not sure their new manoeuvre node code would result in efficient multi-year burns for an interstellar voyage.  (It would probably generate a burn that would work, but with significate penalties for much of the burn not being prograde, when compared to a more optimised burn). 

I'm only part way through the exploration mode campaign, but given the way that sems to be focused on monuments presumably left behind by some predecessors, they might have been better off with the Kerbals finding some sort of a gateway on a planetoid in an asteroid field at one of Jool's Lagrange points.  Land on a surface portal there, then trigger a transfer to another system.  Still wants ships with high dV, to rendezvous with a planetoid at Jool's lagrange points, then need more dV to get anywhere from another Lagrange point, and more dV, if you want to return science/samples/Kerbals.  So still want more advanced engines than KSP 1.  Whilst it isn't hard physics, what we would have got from generations ships would have probably skipped much of the hard physics/engineering problems of interstellar ships.  (eg Life support over generations, shielding against debris when traveling at significant fractions of light speed).

That sort of approach wouldn't have needed much beyond what KSP 1 could do as far as orbital mechanics (mainly the need to simulate multiple solar systems, rather than just one), and wouldn't have required players to warp through tens/hundreds or even thousand of years of interstellar travel. 

 

Edited May 24 by AVaughan

[Superfluous J]

1 hour ago, AVaughan said:

it isn't hard physics

Wherein the problem lies. They wanted to keep KSP "realistic-ish" in that way.

As a simulator, I agree that realism is important. As a game, I would much prefer to be able to just "jump" to other systems using some interesting but totally unrealistic method, like your Joolian Trojan (Troojan?) asteroid idea. Or just make it so you have to reach a specific point in the system and then initiate the "Jump," or even better have to build an interplanetary station (Hello!? Colony!) that served as a huge jumpgate or something.

Yes 90% of the forum would lose their... uh anyway they'd freak out but 90% of the forum is freaking out at any given time so whatever.

[LameLefty]

13 hours ago, AVaughan said:

I'm only part way through the exploration mode campaign, but given the way that sems to be focused on monuments presumably left behind by some predecessors, they might have been better off with the Kerbals finding some sort of a gateway

Not gonna lie, when I discovered the fancy Mun Arch with the glowy bits, and the monuments on Minmus and Duna, I was sure that's what they were going for. 

But even setting the whole mess of math involved with integrating interstellar burns and the resultant trajectory over the scale of lightyears, the fumbling of basic part physics (exhaustively detailed in this thread and others) is just mind-boggling. I still have a save from my first landing at the Duna monument that just falls apart on scene loading, even with the patches.

Edited May 24 by LameLefty