v1.1 and/or Unity 5 Speculations

[Gampersnaz]

Just wondering everyone's thoughts about how Unity 5 will improve ksp. Will it maybe be ported for the 1.1 update? Do you think the visuals will be a little better in terms of shaders and lighting, or will it be the same? Will the physics be more efficient since it will use a newer version of PhysX? Any other thoughts or comments?

[Eric S]

I can't answer on the subject of shaders and lighting. There are visual improvements in U5, but I'm pretty sure Squad would have to do some work to implement the improvements.

Squad is reimplementing the UI with the intent of being identical to the user, but consolidating three UI subsystems into a single subsystem to improve efficiency.

Since U5 uses a more recent version of PhysX, we should see some improvements there. Most likely, we'll be able to handle craft with more parts, though how much of an increase isn't certain. This breaks down into two factors. First, the PhysX code is more optimized. Microbenchmarks indicate that the connected rigid body simulation code can run up to 50% faster. I doubt we'll see that translate into 50% more parts for the same FPS, but we'll see.

Second, PhysX 3.3 allows multiple concurrent threads to run the physics simulation, so multi-core machines will have some performance gains under certain circumstances. This isn't as big a win as you might think at first as PhysX 3.3 doesn't allow for more than one thread to process a given set of connected rigid parts at the same time, which is to say that the physics of a single craft can't get split up between multiple CPU cores.

This isn't just a limitation of PhysX, despite claims otherwise, there's not a general purpose physics engine that does this. Most modern physics engines can use multiple CPU cores to simulate unconnected bodies, even if those bodies are bouncing off of each other, but actual connected rigid bodies have only been split across multiple CPU cores in research work more constrained than what currently happens in general purpose physics engines.

So there should be some improvements in framerate with the switch, but we probably won't know how noticeable the improvements will be until someone that has gotten their hands on 1.1 is allowed to report their impression.

[SessoSaidSo]

Ah yea! I hope they fix the stutter issue!

[Kuansenhama]

I certainly hope there is some increase in the amount of parts we can get away with before lag becomes a problem. I know on my machine I begin to notice lag at around 250 parts, and at about 500 parts, things become basically unplayable. The problem of course being that a space station, where each module needs radial RCS ports and multiple docking ports, solar panels, probe cores, etc, the part count gets high fast. I know I have a friend who can manage 800-1000 parts in the physics bubble. Granted, he has a powerful computer and I'm stuck playing on a laptop.

In other words I want/would like to think that they will better optimize the game. Even if that comes at the expense of graphical quality.

Edited July 21, 2015 by Kuansenhama

[KrazyKrl]

Here's hoping that unconnected rigidbody chains are at least multithreadable for physics calculations (And any craft packed for non-physical time warp.) You might even be able to multithread docked craft together if you take docking ports as a special case; control authority then becomes an issue.

[TheTom]

I would give up on PhysX making a difference. Investigations ni another thread showed clearly that the current performance is not a PhysX problem but seems to be located in 2 subsystems: Heat distribution and - extremely - resssource allocation. It seems that the way for example fuel and electricity consumption is handled is extremely suboptimal, exploding in needed processing power the more resorce containers one has.

Try putting 50 batteries on a rocket and watch the slideshow style of bad.

If that is the case, then the PhysX performance benefits may result in some small improovements - but one can hope that the code in question that is the real culprit is optimized at one point.

The thread in question is http://forum.kerbalspaceprogram.com/threads/128021-Just-why-is-KSP-Physics-so-slow-%28NOT-a-Rant%29 - I suggest reading the whole list. Anyone remembering flying multi hundred part rockets? PhysX did not change, but it is not really possible these days

[Eric S]

Here's hoping that unconnected rigidbody chains are at least multithreadable for physics calculations (And any craft packed for non-physical time warp.) You might even be able to multithread docked craft together if you take docking ports as a special case; control authority then becomes an issue.

They are. It's not quite linear scaling (it takes three cores to double the work that one core can do), but it can be done without much extra development work, as I understand it.

I would give up on PhysX making a difference. Investigations ni another thread showed clearly that the current performance is not a PhysX problem but seems to be located in 2 subsystems: Heat distribution and - extremely - resssource allocation. It seems that the way for example fuel and electricity consumption is handled is extremely suboptimal, exploding in needed processing power the more resorce containers one has.

This is one of the reasons that I almost always spend some time lowering expectations when discussing U5 performance. Yes, the rigid-body microbenchmarks run 50% faster, but I don't expect us to see that much of a performance boost since that's only part of what's happening. I'd love to see this particular issue optimized in 1.1. Between the faster PhysX and this optimization, we'd get to more accurately see what the next bottleneck will be.

Worse, even a 50% improvement across the board doesn't mean 50% more parts would have the same performance as now. Since the resource issue mentioned in that thread describes an O(n^2) algorithm, performance dropoff from additional parts isn't linear. Even with optimization, I don't think that issue will reach O(n), but really O(n*log(n)) would still be better than O(n^2).

[waterlubber]

It better fix the random Linux crashing whenever you change a scene. I think Kraken drives work more often than KSP doesn't crash.

[Majorjim!]

I am sad that games still use the CPU for physics calculations. They are terrible at it!! Why oh why can't Unity/KSP use the massively parallel performance of modern GPUs?

Oh and Squad really need to fix the bug fest that is the heat system. It's slowed the game down so much and for what?? Some pretty colours..

[Eric S]

I am sad that games still use the CPU for physics calculations. They are terrible at it!! Why oh why can't Unity/KSP use the massively parallel performance of modern GPUs?

Because Unity doesn't allow for rigid body simulation to run on the GPU yet? Nor did any of the other major physics engines, last I checked. Unity 5.1 allows hair to be done on the GPU, but that's it so far.