Two Physics Questions

[Darknote]

Dear Forumites,

I'm posting this question as I did not find any references to these topics. Basically:

1. Any idea if the Devs plan to allow multiple simultaneous vessels with active physics in different parts of the solar system?

2. What method would be used to simulate physics on ship parts? Will each be simulated independently (As in KSP1 which causes lag after a certain number is reached). Or after the ship is build, the physics will be rendered for just that ship, and all other attached parts will be graphically rendered but with different graphical destruction reactions and still be a part of just one unit.

If these questions have not been asked/answered in the past or can't be answered yet, no stress, I understand! 

Thank you for any information.

[Guest]

I think (1) would only happen in multiplayer games, with each player in their own physics bubble (unless the bubbles overlap, of course). I don't recall the devs saying anything specific about it, however.

From what they've shown with (2) – although that was a quite a while ago, before the reset and switch from Star Theory to Intercept – it looks like the physics simulation is really similar to the one in KSP1, noodle rockets and all.

They have said that they've found a way to support ships that are kilometres long and composed of thousands of parts, without compromising performance. We're assuming that they have some kind of physics LOD/auto-weld type system, which programmatically keeps the physics part count to a manageable level regardless of the vessel part count. They haven't said anything specific about the solution they're using, however, and it's really been a long time since they showed the noodly gameplay clip, so it could be they've ditched the noodle rockets altogether and gone with something else.

[Kerminator K-100]

1 hour ago, Darknote said:

2. What method would be used to simulate physics on ship parts? Will each be simulated independently (As in KSP1 which causes lag after a certain number is reached). Or after the ship is build, the physics will be rendered for just that ship, and all other attached parts will be graphically rendered but with different graphical destruction reactions and still be a part of just one unit.

 

It could be that they compute physics in the VAB, drag, etc... and then just simulate the ship as a whole. It would probably be more CPU efficient.

[OHara]

5 hours ago, Darknote said:

1. Any idea if the Devs plan to allow multiple simultaneous vessels with active physics in different parts of the solar system?

They do play to simulate acceleration due to long burns of the engines, for far away craft not in the player's focus. 

If I remember correctly, this was discussed in the long and interesting podcast (link) six months ago -- as well as the idea of simulating to different 'levels of detail' (LOD) relevant to your second question.

5 hours ago, Darknote said:

2. What method would be used to simulate physics on ship parts?

[K^2]

7 hours ago, Brikoleur said:

From what they've shown with (2) – although that was a quite a while ago, before the reset and switch from Star Theory to Intercept – it looks like the physics simulation is really similar to the one in KSP1, noodle rockets and all.

So I've been looking at LinkedIn profiles, and the person they've hired to do physics has great background in FEM. I'm actually cautiously optimistic about KSP2 physics for once. It sounds like they are still going for "flexible" joints to keep the KSP style of rockets, but if they write a custom solver, we might see much better performance and far fewer Kraken appearances. (Or none!)

If Intercept also manages to optimize fuel and trajectory solvers, this could give us the kind of performance KSP should have had from the start. Smooth frame rates with thousands of parts? It's more likely than you think!

This could all be wishful thinking, of course, but getting people with right background working on a feature is half the battle.

[mattinoz]

There was a brief and tantellising write up about the new "spacial graph" system that was part of allowing 3+ Body Physics for the twins.

Not a lot of details but it seemed like a central system keeps track of everything in the games on rails. Then spawns sub-processes with just the information needed for the physics bubble. I guess it has further refinement as to what engages with physiscs calculations. Would seem like that would make it easy to have multiple of the sub-processes within a game for things like constant acceleration out of current player scope and I assume multi-player when not directly interacting.

 

[mcwaffles2003]

10 hours ago, K^2 said:

So I've been looking at LinkedIn profiles, and the person they've hired to do physics has great background in FEM. I'm actually cautiously optimistic about KSP2 physics for once. It sounds like they are still going for "flexible" joints to keep the KSP style of rockets, but if they write a custom solver, we might see much better performance and far fewer Kraken appearances. (Or none!)

If Intercept also manages to optimize fuel and trajectory solvers, this could give us the kind of performance KSP should have had from the start. Smooth frame rates with thousands of parts? It's more likely than you think!

This could all be wishful thinking, of course, but getting people with right background working on a feature is half the battle.

So I google  "FEM" and assume you are talking about "finite element method" and I am seeing a lot of images of simulation software simulating deformation.

In your opinion do you think that KSP 2 might even have flexible parts instead of flexible joints? I know with high mesh count parts in simulation software it takes a while to model physical deformation. I figure even with low mesh counts something like this would take far long than game time to simulate. Possibly though this could all be conditionally dependent and prerendered somehow or maybe low enough mesh counts could be simulated in real time?

Hoping you could offer your professional opinion.

[Darknote]

Thanks guys for the answers! And the interesting links/references @OHara and @K^2!!

[Incarnation of Chaos]

12 hours ago, mcwaffles2003 said:

So I google  "FEM" and assume you are talking about "finite element method" and I am seeing a lot of images of simulation software simulating deformation.

In your opinion do you think that KSP 2 might even have flexible parts instead of flexible joints? I know with high mesh count parts in simulation software it takes a while to model physical deformation. I figure even with low mesh counts something like this would take far long than game time to simulate. Possibly though this could all be conditionally dependent and prerendered somehow or maybe low enough mesh counts could be simulated in real time?

Hoping you could offer your professional opinion.

K^2 is probably more thinking that it would mean they have the mathmatical background to make KSP2s rigid body implementation far superior to KSP1. 

Deformable meshes per part would absolutely crush performance without very special handling ah la Doom Eternal. And they didn't have to worry about the dismembered parts being in orbit lel

[K^2]

13 hours ago, mcwaffles2003 said:

So I google  "FEM" and assume you are talking about "finite element method" and I am seeing a lot of images of simulation software simulating deformation.

In your opinion do you think that KSP 2 might even have flexible parts instead of flexible joints? I know with high mesh count parts in simulation software it takes a while to model physical deformation. I figure even with low mesh counts something like this would take far long than game time to simulate. Possibly though this could all be conditionally dependent and prerendered somehow or maybe low enough mesh counts could be simulated in real time?

Hoping you could offer your professional opinion.

Sorry, I usually link abbreviations, but forgot this time. But yes, that's the one.

No, like @Incarnation of Chaos says, it's more about relevant background. I don't think there is any benefit in trying to make parts flexible. But a person with FEM background should know how to optimize the joint solver. For a special case of a KSP rocket, where (almost) every joint is a weld, you don't have to start iterations from scratch. There is a way to get an approximate exact solution in a single matrix multiplication, at which point a single iteration over the joints can give you excellent precision to account for flex. Properly optimized, you can have stable rockets with thousands of parts at absolutely minimal computational cost. It won't help you during rapid disassembly, which will still tank your framerates, but I think that's something we can all live with.

[mattinoz]

8 hours ago, K^2 said:

Sorry, I usually link abbreviations, but forgot this time. But yes, that's the one.

No, like @Incarnation of Chaos says, it's more about relevant background. I don't think there is any benefit in trying to make parts flexible. But a person with FEM background should know how to optimize the joint solver. For a special case of a KSP rocket, where (almost) every joint is a weld, you don't have to start iterations from scratch. There is a way to get an approximate exact solution in a single matrix multiplication, at which point a single iteration over the joints can give you excellent precision to account for flex. Properly optimized, you can have stable rockets with thousands of parts at absolutely minimal computational cost. It won't help you during rapid disassembly, which will still tank your framerates, but I think that's something we can all live with.

Exploding in slowmo doesn't seem like a bad idea to me.

DAMN!

OOOooohhhhh.....   Pretty

[Guest]

1 hour ago, mattinoz said:

Exploding in slowmo doesn't seem like a bad idea to me.

Intentional slow-mo! To cover the drop in frames.

[K^2]

15 hours ago, Master39 said:

Intentional slow-mo! To cover the drop in frames.

Yeah, I don't think that's going away, sadly. I think, Havok physics would do a lot better, but it doesn't sound like we're getting that with KSP2. So the three options are either to re-compute all of the stress matrices on the fly as joints break and parts get destroyed, which is slow; to just give up and let PhysX do its thing, which is slow; or to re-write the physics solver completely from scratch, which is... I mean, it's actually not that difficult if you have experience with constraints solvers, but it's not something you just throw together in a month or two. You can build a prototype on this time scale, but then debugging, polishing, fixing some special cases... It's a lot of work. So I can't imagine us seeing completely custom generic solver in KSP2, and that means that bad performance during RUD on ships with excessive part count is unavoidable. But I'll take it if it's only during RUD and we can get good performance during flight. And a custom solver for this special case is very much doable with the time Intercept has and, hopefully, with this particular hire leading the work. Fingers crossed.

[mcwaffles2003]

9 hours ago, K^2 said:

Yeah, I don't think that's going away, sadly. I think, Havok physics would do a lot better, but it doesn't sound like we're getting that with KSP2. So the three options are either to re-compute all of the stress matrices on the fly as joints break and parts get destroyed, which is slow; to just give up and let PhysX do its thing, which is slow; or to re-write the physics solver completely from scratch, which is... I mean, it's actually not that difficult if you have experience with constraints solvers, but it's not something you just throw together in a month or two. You can build a prototype on this time scale, but then debugging, polishing, fixing some special cases... It's a lot of work. So I can't imagine us seeing completely custom generic solver in KSP2, and that means that bad performance during RUD on ships with excessive part count is unavoidable. But I'll take it if it's only during RUD and we can get good performance during flight. And a custom solver for this special case is very much doable with the time Intercept has and, hopefully, with this particular hire leading the work. Fingers crossed.

Seeing as explosions were seemingly a focus from the start of development and they've hired specialists in the field, do you think that they may have already re-written the physics solver?

[K^2]

6 minutes ago, mcwaffles2003 said:

Seeing as explosions were seemingly a focus from the start of development and they've hired specialists in the field, do you think that they may have already re-written the physics solver?

I mean, it's not like they hired Erin Catto. The guy Intercept hired has the background, but unless he's been writing his own game physics engine in his free time, I don't think he has the experience. Given the background, I have very little doubt he can learn all of it, but that takes time. And part of the issue here is that you can't really fall back on PhysX for anything, as it has very poor performance in the thing that really matters here - collision detection. So to get high performance out of RUD on large, complex craft, you'd have to implement the whole physics engine. As in the sort of thing Havok does exclusively as their business model. Yeah, they have a lot of bells and whistles you don't need here, but to handle general carnage, you need collision tests between various primitives, preferably something you can farm out to multiple threads; a dynamic BVH to keep the test count reasonable, which also means a system that can update said BVH; to generate contact constraints for intersections in addition to any constraints that come from the structure; some way of splitting collision groups into islands; and finally, generic constraints solver, one that respects limits.

This is a lot even if you know exactly what you're doing. But each of these also has a bunch of little gotchas that you wouldn't think about until you trip over them. I think I can write something like this at ship quality and fully optimized in about a year. But a) that's literally been part of my job for years and b) this isn't the only thing a physics programmer at Intercept is going to be doing. There is aerodynamics, orbital mechanics, various components that might interact with physics, and all the bugs in all the even remotely adjacent systems that are going to shake out. And this is Intercept physics programmer's first game job. Someone out of postdoc is no novice by any measure, but work at academia is very different from game studios, and it does take some adjusting. So yeah, it might sound like he has 2+ years to implement good physics for rockets in KSP2, but realistically, he has a few months of work he can dedicate specifically to that. Maybe a year total if we're being generous. I'm not going to say this is flat out impossible, but I would bet heavily against it.

On the other hand, if we treat the rocket as a single body, things get a lot easier. You can either ignore all self-collisions or drastically reduce the number of tests you need to run. That way, you can rely on PhysX to handle collisions and any contacts generated. All you have to do, then, is reconcile any forces applied to the rocket. And again, if you start with assumption that the rocket is rigid, you can very cheaply compute approximate stress, use that to seed the undetermined multipliers, and then run one round of constraint solver specialized to weld constraints, which is a lot easier to handle. That's still a lot, but if you're experienced writing FEM code, there are a lot of similarities here. So I think they hired a person with the right background, and we'll see how much he manages to implement in the game. I think good framerate for high part count ships (~1,000 parts) in flight is a reasonable expectation and good frame rate when these ships blow up isn't. But we'll see. And we're still likely to get much, much better performance than in KSP in all situations. Both from general improvements to Unity engine and from work that Intercept's going to do to make KSP2 better. At least, there's no excuse for not making it better based on what I'm seeing.

[mcwaffles2003]

@K^2 Thank you very much for your explanations, they are very helpful to understanding what may be going on and what to possibly expect

[modus]

Yeah really interesting to get more insight in this kind of stuff. Being a total layman I understood (most of) it, so good job!

Edited May 16, 2021 by modus

[mattinoz]

On 5/14/2021 at 5:21 PM, Master39 said:

Intentional slow-mo! To cover the drop in frames.

I was thinking more more physics "unwrap" so the engine has time to keep up as it then have 4 or 8 seconds to render every detail of the explosion. 

That is assuming that slowing it down would allow to avoid dropping frames. 

[K^2]

3 hours ago, mattinoz said:

I was thinking more more physics "unwrap" so the engine has time to keep up as it then have 4 or 8 seconds to render every detail of the explosion. 

That is assuming that slowing it down would allow to avoid dropping frames. 

I'm not sure that's possible with Unity, tbh. I mean, suppose, it took you 1s to compute one frame of physics, but there were not graphics stalls and you render on a separate thread. Common enough. You can probably keep rendering at 30 FPS on that thread and get 30 frames of graphics into that 1s of simulation. But until the simulation is finished, no positions are updated, so you have 30 frames of all the parts being in exact same place. At best, it looks exactly like if you simply ran at 1FPS. At worst, it looks a lot worse, because maybe the camera angles and FX are still updating, and now it looks like the rocket is just strobing from position to position in an otherwise normal framerate world.

It is possible to interpolate, of course, but that has to be supported at engine level and would involve special kind of update path for physics objects. That seems like a lot of work for an edge case that shouldn't happen in most games. Of course, KSP isn't like most games, but I doubt Unity would implement this feature just for the few exceptions. And maybe I'm completely wrong about this, but I don't think there's a simple way to get around it without engine support.

What's usually done is that physics runs at some multiple of graphics framerate. So if you are rendering at 30Hz, physics might update at 30Hz or 60Hz. Maybe even higher for a racing sim or something. But if either rendering or physics starts to lag, the framerate will drop for both. And then you get a choice of whether the time step in simulation gets very large and you get all sorts of instabilities, or you stop running sim at 1:1 with real time, and things slow down. But you are still getting choppy framerate, because your limiting factor is literally how often you can update where everything is.