Will part count still be an issue in 1.1?

[Der Anfang]

I'm not exactly sure what the new unity 5 game engine means for everyone, but  I keep praying it will allow our PCs to handle more parts, or the parts will be handled differently. I'm actually not really sure I understand what the game engine does exactly. Does squad ever plan on fixing the issue with te part count bogging up our systems, or does that ultimatey lie in the quality and strength of our devices?

[Guest]

Right now, the engine is the part count limitation.

With 1.1, you may be able to push your system to its limit without engine interference.

[fireblade274]

Even with strong devices, large part counts still bog down high end systems. Yes, hopefully unity 5 will at the very least take the edge off lag with 200-500 part monstrosity's

Cant wait for multi core support

[Randox]

I would expect it to allow more part in seperate ships that are close to each other, but not so much for single high part count ships. The problem is that multi core physics can only help if your physics problem is one that can be solved in parallel to begin with. Because of how rockets tend to be built, there aren't a lot of branching dependencies that can be easily calculated in that way. You can't solve a calculation in parallel if you need to wait for the previous answer to perform the calculation (serial problem).

Think of it like this. Imagine your computer is trying to simulate you, sitting in your wheeled computer chair, as you push it backwards with your feet. It's a serial problem. Your computer cannot calculate the outcome of your feet acting on the floor at the same time as it calculates your impact on the chair you are sitting in, because your impact on the chair is dependant on the outcome of your feet pushing on the floor. It has to solve the problems in order.

The only way around that limitation I can think of is to have the game combine parts together at run time, into larger custom parts, which would probably work best if we told the computer how to do it (once your rocket was ready, you would have to highlight parts for the computer to combine into one super part, and then wait for your computer to calculate the parameters of the new part). Not that it wouldn't be a complete nightmare to design even that human assisted system in terms of things like resource management. It would be very cool, but realistically, we probably aren't there yet.

 

And maybe someone who knows more about physics engines than I do will be able to point out some flaws in my reasoning. That would be nice, because frankly I think the performance gains are going to be shockingly small compared to what a lot of people here are expecting.

[Fearless Son]

Okay, please understand that I am trying not to sound condescending when I say this, but working in performance testing for games has taught me that there are a lot of misunderstandings people have about performance optimization.  

What @Randox said is true, when it comes to physics calculations there is a problem with serial-versus-parallel processes.  Threading through multiple cores can certainly help with the parallel processes, but multi-core programming is a whole different beast from serial programming.  Splitting an executable process into multiple threads is one thing, but load-balancing those threads is something else entirely, and the program will only run as fast as its slowest process.  Getting something like multiple physics threads to split introduces problems of how do you decide which problems get handled by which threads at which times?  Even then, what are the situations that might strain it more or less?  What about different machines with different numbers of cores, will that affect how this is balanced?  It can be done, sure, but it is not easy and the people who have experience doing it well get paid a lot of money by some very big companies to keep doing it for them.  Wishing no disrespect to Squad's development talents, I do not know if they have the money or the man-hours to invest in taking maximum advantage of a multiple-core solution.

On this topic, Dslyecxi from Shack Tactical has a good twenty minute video on performance and modding.  While this is specifically about Arma III rather than Kerbal Space Program, I think a lot of what he says applies as both games depend a lot on user generated content, either by recombining built-in assets or by extending that content by being extremely mod friendly.  The short version is that in situations like this, the development team can do an extremely good job of performance optimization, and the game will still get bogged down if users do not budget themselves.  I recommend people interested in game performance give it a listen:  

TLDR: Part count will always be an issue, and while it might be better, it will never go completely away.

Edited March 4, 2016 by Fearless Son

[Renegrade]

A lot of people don't seem to understand that the physics problems in KSP are likely something like O(n^2) or O(n^3) or something insane like that.  Even if the operation cost for a single comparison is low, a 200 part ship is doing either 40,000 of those operations per frame or 8 million operations per frame (respectively).

Let's say that you are able to fully leverage an eight core system (fat effing chance, but let's assume our mythical 800% for the sake of argument), and are able to therefore divide that load by eight.   For n^2, that's still 5,000 operations/frame for 200 parts, or a maximum of 320k operations/frame (40,000*8), which is then therefore maximum part count of 565 (assuming 200 was the limit before).  In the case of n^3, that's 64m operations/frame, and therefore only 400 parts max.

(For a 4-core system with an imaginary 400% bonus, the upgrade numbers are 200->400 and 200->317 for n^2 and n^3 respectively).

REAL optimization takes place at the design stage, when you determine that you WON'T have a mesh of parts acting on all other parts in a vessel at once, and instead go with something like Space Engineer's mobile grids or PartWeld's welded parts.  That makes n a small number, like 1 or 5 or such.

7 minutes ago, Fearless Son said:

Splitting an executable process into multiple threads is one thing, but load-balancing those threads is something else entirely, and the program will only run as fast as its slowest process.

I agree with everything you said, but in breezing past the "splitting a process into multiple threads" (this is very non-trivial), you're kinda explaining about why we can't park the car in the garage because of all the junk in there, when there's junk on the driveway in the way too (and first; you gotta drive through the driveway before getting into the garage in this analogy)

 

[numerobis]

@Renegrade: have you profiled KSP, or analyzed the code structure? How do we know much about the asymptotics of the physics simulation?

@Randox: here's a log^2 depth solver for rigid body systems: http://arc.aiaa.org/doi/abs/10.2514/2.4531?journalCode=jgcd. There's been plenty of improvements since 2000 (in fact, I doubt they were the first). Rigid body simulations can be done in parallel just fine. Whether it's worth doing is another question. At the level of the physics engine, maybe; at the level of the game (which updates the rigid body system -- forces and masses etc -- every timestep), maybe not.

[Norcalplanner]

All I know is that I gained greater faith in Squad optimizing the code after certain well-respected modders were brought into the fold.

[Mad Rocket Scientist]

Oh, don't worry.  There'll always be someone who can make KSP lag.

Like @zekes' space shuttle:

 

1300+ parts.

Or my high-roller:

800+ parts

Or @Whackjob's birthday cake!

Almost 1500 parts!

 

Or any @Azimech craft (up to 1000 parts)

 

Or @SaturnianBlue's WWII ships!  (1100+ parts)

 

You'll never have to feel the pain of 60 fps KSP.

 

 

Edited March 4, 2016 by Mad Rocket Scientist

[federicoaa]

Yea, for people like @Whackjob part count will always be an issue XD

[Azimech]

True ... I'll always build for the future. We've got a long way to go. A typical car nowadays has 5000 parts, the Apollo capsule had 2 million.

But we're getting good at optimizing our craft, not a bad thing either. I remember the 1500 part Spruce Goose on KerbalX. When you look inside the fuselage it has an awful web of struts, say 200, while you can make a decent and strong structure with a small fraction of that amount. Personally I strongly dislike the "moar struts" pun, it's how you intelligently place them. On most of my builds, strut count is 1 to 5% of the build.

[StarStreak2109]

Partcount should not be a problem for people playing a sensible game. Of course the "monstrosities" shown above tend to overload the engine as it is now and probably will also overload the Unity 5 engine. Right now the problem is however that even with a "sensible" playstile even normal-ish craft such as space stations become untolerable due to significant lag. IMHO without partwelding, which is a pain, larger, ISS-like spacestations with a certain amount of detail are virtually a nogo due to the lag. Here I hope for significant improvement! It will be a treat having a KSS in orbit around Kerbin, docking a space craft  to it at 20+ FPS.

[Gkirmathal]

What I personally don't get, for as long as I have been playing KSP, is why Squad can't change the part-to-part physics, so that it somewhat work in the following fashion:

'inline connected parts' to be excluded from 'part-to-part physics calculations' and only until a certain threshold is reached, only then the phycics calculations on these inline connected parts is started. For example extreme centrifugal forces, or aerodynamic forces, etc, would trigger physics calculations on those parts.

Thus large constructions could be much smoother as those extreme scenarios are not common, space stations for example.

Edited March 4, 2016 by Gkirmathal

[Azimech]

14 minutes ago, Gkirmathal said:

What I personally don't get, for as long as I have been playing KSP, is why Squad can't change the part-to-part physics, so that it somewhat work in the following fashion:

'inline connected parts' to be excluded from 'part-to-part physics calculations' and only until a certain threshold is reached, only then the phycics calculations on these inline connected parts is started. For example extreme centrifugal forces, or aerodynamic forces, etc, would trigger physics calculations on those parts.

Thus large constructions could be much smoother as those extreme scenarios are not common, space stations for example.

What a smart idea! I wonder what @NathanKell thinks of this.

[Geschosskopf]

Thanks @Randox, @Fearless Son, and @Renegrade for your explanations.  My days of being required to know anything about how computers work inside date back to the time of punch cards so I've never really bothered to learn anything about how multi-threading works.  Thanks to you all, now think I have a nutshell picture of it.

OK, so KSP's basic design doesn't allow for taking much advantage of multi-threading for physics calculations.  Still, I suppose having more RAM to play with should slightly raise the part count at which things become intolerable, right?  Also, what about going from 32-bit to 64-bit?

Now, about what @Gkirmathal said....    KSP parts can have a flag called "PhysicsSignificance".  Counter-intuitively, if this is set to 1, the that part is excluded from the physics calculations.  It used to be that PhysicsSignificance = 1 also meant the part was massless but that changed a few upgrades ago.  The part itself is still massless but its mass is added to whatever it's attached to.  I always wondered why, because the parts that had this flag set were mostly tiny things of insignificant mass, not enough to impact a rocket's dV or TWR.  Sure, you could exploit their masslessness to build silly little ships to goof around with, but their impact on mainstream gameplay was nil, so that never struck me as the real reason for this change.

It now occurs to me, however, that adding mass to physicsless parts could have been an optimization thing.  What if, somewhere under the hood, KSP now dynamically sets and unsets this flag for major structural parts?  That would reduce the effective number of parts, and thus operations, that the physics engine has to deal with, but the mass is still there for the calculations.  IOW, dynamic, virtual "welding"  Is there any way to do that without hosing everything else up?  Does KSP do this already? 

[paul23]

4 hours ago, Azimech said:

What a smart idea! I wonder what @NathanKell thinks of this.

I'm resisting the urge to facepalm here. Structural (and aerodynamic) forces, in essence, are differential equations, where you solve a large matrix (mesh) with each row being a "part" and columns the variables (this is overly simplified). You have to do it this way, because the way a part behaves -under standard behaviour- changes how other parts react. So you can't just ignore a part in the physics calculations you have to take that part into account to calculate how the other part works.

This is utterly obvious in practice, you can see it easily: sometimes your craft deteriorates after a seemingly uncontrolled increase in spin (without any work being done), this is exactly due to above reason (combined with rounding errors). 

[KerbonautInTraining]

16 minutes ago, paul23 said:

[Lots of very informed computer stuff]

Each ship in the physics bubble gets 1 thread to play with in 1.1, according to the devs.

What happens when 2 large ships touch each other but don't dock? Do the threads merge and slow your game to a crawl? Do they stay as separate threads and do black magic to figure out what the other is doing?

[Azimech]

31 minutes ago, paul23 said:

I'm resisting the urge to facepalm here. Structural (and aerodynamic) forces, in essence, are differential equations, where you solve a large matrix (mesh) with each row being a "part" and columns the variables (this is overly simplified). You have to do it this way, because the way a part behaves -under standard behaviour- changes how other parts react. So you can't just ignore a part in the physics calculations you have to take that part into account to calculate how the other part works.

This is utterly obvious in practice, you can see it easily: sometimes your craft deteriorates after a seemingly uncontrolled increase in spin (without any work being done), this is exactly due to above reason (combined with rounding errors). 

Not every situation involves aerodynamic forces, in space they can be left out, also on Kerbin while driving at low speeds. I think it depends on which part is placed on which branch of the tree.

[paul23]

25 minutes ago, KerbonautInTraining said:

Each ship in the physics bubble gets 1 thread to play with in 1.1, according to the devs.

What happens when 2 large ships touch each other but don't dock? Do the threads merge and slow your game to a crawl? Do they stay as separate threads and do black magic to figure out what the other is doing?

Well I have no idea how ksp works - but I think when two ships are close they are part of the same physics bubble (since they also don't disappear). Thus they occur on a single thread. Btw because of the way those calculations work they don't have to be single threaded (forever). Once you build the matrix solving a matrix can be done using many threads (heck this is a perfect task for a GPU through something like CUDA allowing very fast simultanous calculations.

Edited March 4, 2016 by paul23

[p1t1o]

5 hours ago, Gkirmathal said:

What I personally don't get, for as long as I have been playing KSP, is why Squad can't change the part-to-part physics, so that it somewhat work in the following fashion:

'inline connected parts' to be excluded from 'part-to-part physics calculations' and only until a certain threshold is reached, only then the phycics calculations on these inline connected parts is started. For example extreme centrifugal forces, or aerodynamic forces, etc, would trigger physics calculations on those parts.

Thus large constructions could be much smoother as those extreme scenarios are not common, space stations for example.

I'm not too familiar with the ins-and-outs of how software works, but I do know that there is no free lunch. Your own idea contains its own downfall - 

"...only until a certain threshold is reached, only then the phycics calculations on these inline connected parts is started. For example extreme centrifugal forces, or aerodynamic forces, etc, would trigger physics calculations on those parts."

Bang, you've just introduced a new process that has to continuously run that watches for this "threshold" being crossed - you've replaced a bunch of physics calculations, with...another bunch of physics calculations.

And whilst I am sure there is always room for clever optimisations, and perhaps an incremental benefit could be gotten from your idea, there is a reason why it is difficult.

[Gkirmathal]

@p1t1o thinking theoretically of course: the calculation would only address the vessel as a whole. Not on a part-to-part basis like it is the case now, so the number of calculations being done on a 100 parts ship, would be less. Thus performance would theoretically be increased, even for a single threaded process.

Unless thresholds are reached, as Paul mentions them being differential equations, than of course performance still goes out of the window on high part count ships.

Whether this can be actually be done within the constraint of Unity, that is a whole different discussion

Edited March 4, 2016 by Gkirmathal

[Fearless Son]

52 minutes ago, KerbonautInTraining said:

Each ship in the physics bubble gets 1 thread to play with in 1.1, according to the devs.

What happens when 2 large ships touch each other but don't dock? Do the threads merge and slow your game to a crawl? Do they stay as separate threads and do black magic to figure out what the other is doing?

My best guess would be that each ship processes independently, registering the "bump" of the other ship as just one more physics force to calculate.  

This does introduce the issue that you could have two high part count vessels that can rendezvous and be running at a smooth framerate, only to find your framerate takes a sharp nosedive as soon as they dock together and become one ship.  On the other hand, such a situation would be better than in previous versions, where that framerate drop would occur simply by the two ships simply getting near one another.  

[Red Iron Crown]

Moved over to Development Discussions.

[Kerbart]

1 hour ago, Azimech said:

Not every situation involves aerodynamic forces, in space they can be left out, also on Kerbin while driving at low speeds. I think it depends on which part is placed on which branch of the tree.

For starters you could apply a simple heuristic along the lines of "if a part has no subnodes and a mass of less than x% of its parent than merge it with the parent for physics calculations" or something along those lines. With some refinements you could come up with a good reduction of the parts involved in Physics calculations without significantly altering the accuracy.

[pellinor]

1 hour ago, KerbonautInTraining said:

Each ship in the physics bubble gets 1 thread to play with in 1.1, according to the devs.

Not sure if this is confirmed yet. I remember a dev statement from several weeks ago (either devnotes or squadcast) that in principle unity can split physics into several threads but nothing is done (so far) from the KSP side. So it all depends on how the engine decides to handle things, and they did not want to promise that it actually happens with multiple vessels in physics range.

The possibility is a unity feature, so this is public knowledge. It actually happening is a definite observation/promise about game behavior/performance, and they have been quite secretive about that kind of information. I have the impression that those two tings are often confounded in the discussions.

Edited March 4, 2016 by pellinor