Ksp need to fix the performance

[Luc1fer]

Seriously,how a game with this low end grapighs can lag a PC that runs  battlefield 1 on medium grapighs?

[klgraham1013]

KSP is CPU dependent.  The graphics aren't what's causing the lag.

[septemberWaves]

The performance is actually very good considering the simulations being done, and being rude about it will do nothing to further improve it.

[Luc1fer]

12 minutes ago, septemberWaves said:

The performance is actually very good considering the simulations being done, and being rude about it will do nothing to further improve it.

I think i wasnt rude,but sorry if i offended you

[The Aziz]

I'd say it wasn't rude. It was more like making assumptions without learning about the topic first

[Guest]

Wel-l-l... KSP's performance is frankly pretty bad. Yes there's a lot of simulation being done, but it really ought to be possible to do them faster. I don't know if it's limited by Unity, by architecture, or by bottlenecks, but I'm pretty certain it's not limited by hardware as such.

[linuxgurugamer]

18 hours ago, Juanlu16 said:

Seriously,how a game with this low end grapighs can lag a PC that runs  battlefield 1 on medium grapighs?

Because battlefield 1 doesn't  have to calculate physics  on dozens if not hundreds of parts, 20 times a second.

I'm curious, if you fire a bullet in the air in battlefield 1, does the game figure out where it is going to land?  Does it calculate the air resistance?  Does the bullet slow down?  Does it get heated from it's passage through the air?

[Starman4308]

The issue with KSP is lego-style construction with rigid body physics.

500 separate objects flying through the air would be trivial to solve. 500 objects linked by rigid body physics requires a self consistent solution that satisfies all linkage constraints without violating basic physics.

I'm still unsure if it's O(n*ln(n)) or O(n^2), but the problem gets harder fast.

Unity's rigid body physics solver is almost certainly not the fastest in the world, but it's being stretched far beyond what most games ask of it.

[KerikBalm]

21 hours ago, klgraham1013 said:

KSP is CPU dependent.  The graphics aren't what's causing the lag.

This

3 hours ago, linuxgurugamer said:

Because battlefield 1 doesn't  have to calculate physics  on dozens if not hundreds of parts, 20 times a second.

I'm curious, if you fire a bullet in the air in battlefield 1, does the game figure out where it is going to land?  Does it calculate the air resistance?  Does the bullet slow down?  Does it get heated from it's passage through the air?

I'd be curious about this too. I think most shooters don't use hitscan anymore.

I know Arma 3 has some pretty complex physics and ballistics calculations. However, Arma 3's graphics aren't phenomenal either, and people complain about low fram rates in that game too.

It calculates trajectories and accounts for air resistance, bullets do slow down with distance... but air resistance is fixed and not velocity dependent. Its an approximation because bullet velocity doesn't change soooo much in the timeframes/distances involved, but it does make bullet drop at extreme sniping ranges (>1 kilometer) for many weapons unrealistically high.

I'm sure BF1 doesn't go into as much depth as Arma3

[Leafbaron]

From what i know battlefield does some kind of bullet simulation rather than hitscan type stuff. Bullets have velocity, and do indeed drop. The game has funtions to even adjust scopes and iron sights for different distances to account for this drop. 

no idea how its calculated in the game though.

[invision]

8 hours ago, linuxgurugamer said:

Because battlefield 1 doesn't  have to calculate physics  on dozens if not hundreds of parts, 20 times a second.

I'm curious, if you fire a bullet in the air in battlefield 1, does the game figure out where it is going to land?  Does it calculate the air resistance?  Does the bullet slow down?  Does it get heated from it's passage through the air?

actually BF1 is brutal on a CPU because of physics. the bullets, rockets, planes, all of that stuff has to be calculated. things can be destroyed,and the game has to track 60 players and a dozen vehicles, and there is bullet drop.

i agree KSP runs like crap, theres no reason my game should run at 20 frames a second with a Ryzen 5 1600 which is overclocked to 3.9ghz and paired with a GTX 1080, but it does happen and it happens a lot especially if the mission is very long.

 

[stibbons]

33 minutes ago, invision said:

theres no reason my game should run at 20 frames a second with a Ryzen 5 1600 which is overclocked to 3.9ghz and paired with a GTX 1080

 

Except there is. As already discussed in this thread, the rigid body calculations required to update a vessel's position are huge, computationally expensive and inherently linear. Your GPU setup is completely irrelevant, it comes down to single core CPU performance. Improving performance won't come from a new engine, but a new branch of mathematics.

[invision]

7 minutes ago, stibbons said:

Except there is. As already discussed in this thread, the rigid body calculations required to update a vessel's position are huge, computationally expensive and inherently linear. Your GPU setup is completely irrelevant, it comes down to single core CPU performance. Improving performance won't come from a new engine, but a new branch of mathematics.

no there is not

simply hanging out on the surface of the moon shouldnt run the game at 20 fps

going to space center and then reloading the same ship now the game runs at 100 fps

there is nothing to calculate except bad coding.

 

[stibbons]

4 minutes ago, invision said:

going to space center and then reloading the same ship now the game runs at 100 fps

If the flight scene is leaking memory, that's a separate issue.

3 minutes ago, invision said:

there is nothing to calculate except bad coding.

Yes, there is.

[Starman4308]

3 hours ago, invision said:

actually BF1 is brutal on a CPU because of physics. the bullets, rockets, planes, all of that stuff has to be calculated. things can be destroyed,and the game has to track 60 players and a dozen vehicles, and there is bullet drop.

i agree KSP runs like crap, theres no reason my game should run at 20 frames a second with a Ryzen 5 1600 which is overclocked to 3.9ghz and paired with a GTX 1080, but it does happen and it happens a lot especially if the mission is very long.

 

All of that is, frankly, a trivial O(N) problem with some glitzy graphics thrown on top. The CPU load, like most FPS games, is trivial: it's all the shiny effects that slow you down because of all the scene rendering the GPU has to do.

On the server side:

Each physics frame, a bullet can ask "in any of the grid cubes I passed through, do any objects have colliders? If so, did I hit them?". This is constant-time per bullet, since it only has to poll nearby objects, and O(N) in the number of bullets. Stuff like bullet drop is almost hilariously simplistic mathematics; unless you're trying for aircraft-simulator levels of aerodynamics, it's a few single-operation multiplies and adds, with nary a single exponential or division to handle.

A player/vehicle object needs to respond to any player or environment inputs, but the number of those is small: maybe a few keystrokes from the player, plus mouse input, plus possibly a bullet or explosion.

On the client side:

The client needs to update the status of nearby objects based on a message packet from the server, respond to player input and send it to the server, and render sounds and graphics.

The client does not even need to be informed of the status of every object, just nearby ones. I can't think of anything that, by necessity, absolutely has to be done in more than O(N) time... and N is pretty small, maybe a couple hundred tops. If you double the number of objects, the workload per frame just doubles.

 

KSP's rigid body physics is not an O(N) problem. I suspect it's an O(N^2) problem, where every single part must act on every other part for consistent rigid-body physics that don't break Newton's laws into a million little pieces. This means that if you double the number of parts, the workload per frame quadruples. This is why KSP can be so slow with large part counts: the amount of CPU effort needed is going up far faster than the number of parts on the vessel.

[MythicalHeFF]

I think the bad performance has to do with the way Unity works, where it collects garbage every few seconds and that results in a stutter. The more parts you have, the more garbage Unity has to collect and the worse the stutter gets. I do think it’s outrageous that my KSP sometimes freezes for a good half second every 5 s or so with a vessel that has <50 parts.

 As for force calculations, there’s really no excuse for the game to perform that badly considering the only forces that have to be accounted for on parts are thrust and torque. 

 

  

[Starman4308]

9 minutes ago, Jack Joseph Kerman said:

As for force calculations, there’s really no excuse for the game to perform that badly considering the only forces that have to be accounted for on parts are thrust and torque. 

 

Please note that there is far more for KSP to handle than "thrust and torque". The ships aren't treated as one big piece: it's often hundreds of parts, each with their own masses, aerodynamics, and temperature, connected together with rigid linkages. An engine fired on one end of the craft winds up transmitting force all the way through the rocket to the capsule at the top, and it winds up being a monstrous O(N^2) problem to solve all that self-consistently.

No comment on the garbage collection, though you might try looking into MemGraph. Admittedly, if you threw a ridiculous amount of programmer time at the problem, you could move KSP to a language with manual memory management...

But not before that manual memory management caused 57,328 bugs to catch.

Edited February 9, 2018 by Starman4308

[Fearless Son]

8 hours ago, KerikBalm said:

This

I'd be curious about this too. I think most shooters don't use hitscan anymore.

I know Arma 3 has some pretty complex physics and ballistics calculations. However, Arma 3's graphics aren't phenomenal either, and people complain about low fram rates in that game too.

It calculates trajectories and accounts for air resistance, bullets do slow down with distance... but air resistance is fixed and not velocity dependent. Its an approximation because bullet velocity doesn't change soooo much in the timeframes/distances involved, but it does make bullet drop at extreme sniping ranges (>1 kilometer) for many weapons unrealistically high.

I'm sure BF1 doesn't go into as much depth as Arma3

Okay, this is where I get to put on my Professional™ hat as someone who has done performance testing for a big-budget first-person shooter.  

Yes, most first-person shooters these days do projectile calculations for bullets rather than the hitscan calculations common to shooters in the 90s and early oughts.  However, these calculations tend to take a lot of mathematical shortcuts to simplify their effect on performance.  What they tend to do is more "emulation" than "simulation", because in most games a lot of the real world ballistic considerations are simply irrelevant to the gameplay and would bog down the perf for no reason that the player would notice.  So for example, a bullet might simply have a "damage" value that gets decremented every time it passes through the collision mesh of a penetrable object.  Arma 3 is an exception to this usual method since it calculates how the penetration changes the ballistic qualities of the projectile, but that is a game that tends more toward simulation. 

The big thing though is the interaction.  Calculating the physics qualities of a single object in motion is easy, calculating how several objects in contact have reciprocating forces on one another makes the calculation more complicated, and it gets exponentially more complicated the more parts you add.  So for example when a player fires a gun in a shooter, the bullet did not exist in the weapon, it was simply spawned at the end of the barrel at the time of firing with a velocity already applied to it.  When that bullet impacts a target, it simply applies a discrete physics force and damage to the target without the target necessarily applying one back on the bullet other than that simple "cheat" I mentioned above.  If the bullet is decremented of all its damage, it disappears from the world and ceases to be part of the simulation.

[HebaruSan]

5 minutes ago, Fearless Son said:

However, these calculations tend to take a lot of mathematical shortcuts to simplify their effect on performance.

Do they account for the effects of differently shaped bullets?

[Starman4308]

2 minutes ago, HebaruSan said:

Do they account for the effects of differently shaped bullets?

You could probably do that just by storing a precomputed ballistic coefficient for the bullet, which saves on the cost of ever having to actually worry about the bullet's shape.

Sure, it would change a bit as speed decreased, and if a smoothbore round began to tumble, that would have a huge effect on ballistic coefficient, but you could either have a precomputed lookup table/curve for ballistic coefficient vs. speed, or, more likely, ask yourself exactly how important this is to gameplay and just store a single ballistic coefficient.

[HebaruSan]

5 minutes ago, Starman4308 said:

ask yourself exactly how important this is to gameplay and just store a single ballistic coefficient.

That's what I was thinking. Either you have a single coefficient for all bullets, or one per type. As compared to a parachute-pod-shield-decoupler-tank-engine monstrosity hurtling down out of the vacuum.

[KerikBalm]

Different ballistic coefficients is what Arma3 uses, I know that much.

Does BF1 model ricochets and penetration? 

Arma's damage calculations are quite complex, varying depending on bullet velocity, if the projectile comes to rest in the target or completely penetrates, etc. Depending on the projectile and objects in the way (walls, sandbags, trees, fences, etc), projectiles may pass through, have their direction altered, large velocity changes, etc. The penetration system is also used for determining vehicle damage (not sure about player damage).

Spoiler

Case B: The projectile does not penetrate through the entire FG. In this case the Hitpoint will receive 100% of the directDamage (directDamage = (Hit - indirectHit)*speedmodifier ) of the projectile

Case A: In contrary to Case B, the projectile completely penetrates the FG. Only a portion of the directDamage of the projectile will be dealt to the Hitpoint. The portion of damage depends on the amount of speed the projectile lost during penetration. The formula for this is unknown and also seems to be nonlinear. This means that very thin firegeometry will cause low amount of damage in most cases (as many projectiles will fully penetrate).

...

Recall from the "Damage vs. Penetration section that an attack must simultaneously affect both fire geometry and a hitpoint to produce damage.

Consider the following two approaches to hitpoint placement for the same vehicle--the front view of a simplified AFV. The polygons represent FG and the purple circles represent the virtual spheres created by hitpoint vertices and their radii.

...

 In the second approach, the hitpoints are constrained to be inside the armor layer (blue polygons). The second vehicle will take only trivial damage from non-penetrating hits.

Obviously, if you have non-armored parts of a vehicle that should be damaged by non-penetrating hits (tires, glass windscreens, unarmored vehicle parts, etc.), then their hitpoint spheres should "poke through" the FG in the "old" manner.

 

I'm sure that's more complicated than what BF1 does, people complain about arma3 being a bit slow. Its also much simpler than what KSP does - vehicles seem to act as only 1 piece for most physics calculations, so except when multiple vehicles are colliding with each other, you don't have "reciprocating forces " as Fearless Son calls them.

So who cares what BF1's framerate is with its graphics. It effectively has a very low partcount within the physics bubble, with the "parts" undergoing less calculations - they probably ignore air resistance (even if they don't, I'd bet that air density is constant and they don't care about mach number), no temperature simulation, gravity is constant, there are no "connections" between objects, bullets are probably just vectors/trajectories rather than "physical" objects...etc.

Running that game with good graphics should just mean that your computer could run Scatterer and high res texture packs for KSP without slowing it down, since the bottleneck is the CPU and not the GPU.

 

[peteletroll]

If 24 fps was good enough for Stanley Kubrick, it's good enough for me :-)

[Fearless Son]

5 hours ago, HebaruSan said:

Do they account for the effects of differently shaped bullets?

 

5 hours ago, Starman4308 said:

You could probably do that just by storing a precomputed ballistic coefficient for the bullet, which saves on the cost of ever having to actually worry about the bullet's shape.

Sure, it would change a bit as speed decreased, and if a smoothbore round began to tumble, that would have a huge effect on ballistic coefficient, but you could either have a precomputed lookup table/curve for ballistic coefficient vs. speed, or, more likely, ask yourself exactly how important this is to gameplay and just store a single ballistic coefficient.

That is almost exactly how they do it.  Most of the time, these things are simply defined on a per-bullet basis.  A designer inputs the coefficients in the constants of the projectile, and when the player fires it simply instantiates the projectile into existence at the barrel of the gun with an input velocity vector defined by where the gun is pointed.  Air resistance is almost never modeled, since with very rare exceptions differences in air pressure or wind are almost never an issue in the environments and ranges at which the gunplay takes place.  Usually they just substitute the damage dropping off as a function of range, with the longer the projectile travels the less damage it does.  Often this is actually dialed down to drop off far faster than it would in real-life as a function of enforcing close-range shootouts as a gameplay feature (getting sniped in one shot from across the map by an enemy you were not close enough to see is rarely "fun".)  Different guns will spawn different bullets, as defined in the game's files.  Sometimes even the same gun will shoot "different" bullets, even if they are the same caliber, just by switching the weapon's parts (the game uses a different dataset reference for bullets in that case.)

Compare that to KSP, where each "projectile" is made of multiple objects and they have to calculate aerodynamic forces on each of them, at different kinds of velocities and air pressures, and the forces on those can then impact the forces on other parts of the craft (dragging surfaces triggering leveraging forces which affect the orientation of the craft for example.)  KSP cannot do the kind of simplified, fixed calculation that a shooter's bullets might without losing a substantial amount of the core of the gameplay experience. 

[Mako]

Hold up. Let me get this straight. If we ignore the details about the physics for a second, are people actually saying they expect an indie game made by a small, relatively inexperienced team with a small budget working on a somewhat closed-source third-party engine should perform as good as a game made by a large studio of experienced industry professionals with a Triple A budget working on their own completely customizable engine?

I'm not going to ever say that is impossible. I've seen small teams do amazing things on a tight budget. That being said, I would think it's highly unlikely that Squad could deliver Triple A performance levels on their indie project that was likely never expected to go as far as it did.

We don't know how many employees Squad has, but let's say it's less than 30 people. The folks who made Battlefield 1 work in a studio of over 600 people (as of 2016 according to wikipedia, grain of salt sold seperately) who have the benefit of full control over their engine. Battlefield 1 appears to have been made by a team well over 20 times the size of Squad.

The comparison being argued here seems beyond absurd before you even get into the discussion of how extremely different the games are.