Question about the 1.1 update

[Algiark]

So, I've read that the 1.1 update will upgrade the KSP to the Unity 5 engine. Many people say that this means a large performance improvement, but I'm wondering what kind of improvements can I expect? Will the graphics be nicer? Less RAM usage? Better physics? Better framerate when building vessels with many parts? Faster loading time? And how much of an improvement could it be?

[peachoftree]

AFAIK, Pretty much every change is under the hood. We are likely to see performance improvements but the game will look pretty much the same

[Hobbes Novakoff]

The scale of the performance improvements is also not really established. Optimistically it might end up like Besiege, which saw a 4-5x improvement in blocks (read: parts) that it could handle.

[problemecium]

Everything listed in OP is likely to appear to some degree:

- Unity 5 ships with a nice "Standard" shader that uses Physics-Based Rendering to appear nearly photorealistic. Parts and ships are unlikely to implement this off the bat, but background objects, buildings, or whatever might benefit. If nothing else, at least the primitives used in Whack-a-Kerbal will look better xD
- Unity 5 includes a lot of optimizations as far as rendering, physics, UI, etc. and KSP is having a lot of code rewritten and thereby optimized for the next update. Total RAM usage is a mystery, but in all likelihood whatever RAM does get used will be used far more judiciously, and with built-in 64-bit support, you'll have access to ALL of your computer's RAM as opposed to only 4 gigabytes of it.
- Physics in Unity 5 has been massively improved under the hood, now supporting multi-threaded calculations, so situations with lots of parts on screen will generally have much better framerates. There is suspicion that this may not apply to large single vessels, but it hasn't been clearly confirmed one way or the other by SQUAD last I heard.
- Faster loading time is probable given the above code optimizations and multithreaded physics. Honestly, though, loading time got so fast in the last patch or two that I hardly care any more.

[Stargate525]

[quote name='parameciumkid']
- Physics in Unity 5 has been massively improved under the hood, now supporting multi-threaded calculations, so situations with lots of parts on screen will generally have much better framerates. There is suspicion that this may not apply to large single vessels, but it hasn't been clearly confirmed one way or the other by SQUAD last I heard.[/QUOTE]
I think the big one here is that rovers will now finally work properly, as Unity 5 is coming with vehicle support physics as well, I think.

[Venusgate]

I was under the impression that they were also planning to implement full 64-bit support as well, so windows users wont be truck with 4gb ram cap.

[Daid]

[quote name='Stargate525']I think the big one here is that rovers will now finally work properly, as Unity 5 is coming with vehicle support physics as well, I think.[/QUOTE]
If you read the devnotes, then you'll have noticed that this "feature" was underwhelming and only worked if your object is a square box with 4 wheels. Not a random shape of shapes with random wheels attached. So there was a lot of work in getting wheels working again.


General rule of optimization, do not expect magic. 5% to 30% is a rule of thumb (I'm an software engineer, 10 years of experience)
64bit would be a welcome addition for the windows users, if it's really stable. And might yield some performance improvements as well (software I develop runs about 15% faster in 64bit mode, but I expect way less improvement for KSP)

[selfish_meme]

[quote name='Daid']If you read the devnotes, then you'll have noticed that this "feature" was underwhelming and only worked if your object is a square box with 4 wheels. Not a random shape of shapes with random wheels attached. So there was a lot of work in getting wheels working again.


General rule of optimization, do not expect magic. 5% to 30% is a rule of thumb (I'm an software engineer, 10 years of experience)
64bit would be a welcome addition for the windows users, if it's really stable. And might yield some performance improvements as well (software I develop runs about 15% faster in 64bit mode, but I expect way less improvement for KSP)[/QUOTE]

They purchased a new wheel module because of the underwhelmingness of stock Unity 5, one that has provisions for a lot better wheel simulation than currently exists

[Francois424]

In between the lines, I am expecting a 20% performance increase overall

@Hobbes Novakoff : if we ever get 4x-5x more parts improvement and say 64-bits support, then U5 will have exceeded my expectations. I was hoping for at most 50% more parts increase, which unfortunately would mean I am getting back to parts performance I was getting in 0.24.2 (lost a lot of multiple part performances with recent updates, even with me getting a brand new rig).

[Warzouz]

There was a reduction in part number support between beta and official release. I hope we'll get back there.

Best hope is for memory management in 64 bits so we can have some improved existing planets and additional planets.

And get a proper sound design !


Don't forget that 1.1 will improve wheels and add a basic communication gameplay

[TheTom]

[quote name='Daid']General rule of optimization, do not expect magic. 5% to 30% is a rule of thumb (I'm an software engineer, 10 years of experience)[/QUOTE]

Thanks for demonstrating the sad state of software engineers.

Given the demonstrated and proven ridiculous bad code, anything below a 100% to 200% improvement would be a shame or something waiting for a lot more optimizations. The later would be quite acceptable given the brutal amount of rework that has to go into 1.1 due to the UI rework.

Now, befor you guys come out and scream that this is ridiculous - it is NOT physics. Physics as it is can handle a LOT more than we can do today. Anyone with not 10 years software experience but 2 years KSP experience will remember how we could run multiple times the current part count in the past. Physics has not changed a lot during these times.

What makes KSP slow are:

* The non-physics simulations (heat mostly)
* The user interface code (which is reworked) which supposedly was doing a lot of stuff in every frame, while the new UI creates / manipulates game objects and is drawn in the unity engine.
* The resource allocation code. This means came resources (fuel, electricity) which is demonstrated to be extremely badly coded and gets significantly slower the more consumers/producers exist. THe main culprit here is the permanent allocation of new memory resulting in ridiculous amount of garbage collection.

If all that is fixed to some degree, and multiple cores are used (for example it is not that hard to move the heat calculations to a separate processor) we should see a lot more than a 30% increase in performance in anything except trivial craft. Once you get into the 100+ part count the current code is a demonstration of wasted CPU cycles. Especially the resource allocation code really is slowing things down a lot. Well, heat too.

[RocketPropelledGiraffe]

[quote name='TheTom']
...What makes KSP slow are:

* The non-physics simulations (heat mostly)...
[/QUOTE]

How heat calculations can be considered "non-physics" is incomprehensible to me... Software development really IS a world of its own. :)

[KerbMav]

[quote name='RocketPropelledGiraffe']How heat calculations can be considered "non-physics" is incomprehensible to me... Software development really IS a world of its own. :)[/QUOTE]

Heat is calculated by itself and not as part of the physics engine, physics meaning the interaction of individual parts in the simulated environment and with each other.

[OrtwinS]

[quote name='TheTom']... [B]demonstrated and proven[/B] ridiculous bad code ...
... the current code is a demonstration of wasted CPU cycles...[/QUOTE]

That is quite a choice of wording.
Can you link to the research?
Sounds like an interesting read.

[RocketPropelledGiraffe]

Jep, I know that physics in software terms basically is reduced to "mechanical interactions" and most other spects of physics are done separately.
I was merely commenting on the weird wording you get as a result from time to time...

[Hannu]

[quote name='TheTom']
What makes KSP slow are:

* The non-physics simulations (heat mostly)
[/quote]

Do you know how they have done it? I can not understand why it can be slow. Heat generation in parts is very simple. They take just few parameters into account, speed, air density, internal heating, which all are simple functions. Heat exchange is simple and number of joints between parts are on the same magnitude as the number of parts. I could understand the problem, if there were 100000 parts, but couple on hundreds of generations and same amount of interactions between parts should not be significant load to any modern processor core.

If they can really waste so much processor power in this kind of calculations, I do not expect they can get significant improvements, if they do not hire someone expert in physical modeling. And I think that it is not realistic hope. Unfortunately bad coding is very common nowadays, even in so called physics engines (like Unity). There are even stupid errors, like using floats instead of doubles (I know that floats may be better in some very extreme applications, but certainly not in computer games and animations). But all we (at least I) hope that I am wrong.

[selfish_meme]

All the armchair generals are out today I see.

[*Aqua*]

[quote name='Hannu']There are even stupid errors, like using floats instead of doubles (I know that floats may be better in some very extreme applications, but certainly not in computer games and animations). But all we (at least I) hope that I am wrong.[/QUOTE]
KSP calculates stuff (position, rotation, velocity, etc.) using doubles. When rendering images these numbers get casted to floats so Unity can work with them.
This is known as Krakensbane and was introduced in 0.17 (I think).

Also a float is usually the best data type for games. CPUs and GPUs are faster at calculating floats than doubles and the range of values is greater than the one of integers.


KSP is a very special game as it needs both huge numbers and high precision. 99% of the games only require high precision for which floats are good enough. Edited November 24, 2015 by *Aqua*

[Red Iron Crown]

[quote name='*Aqua*']KSP calculates stuff (position, rotation, velocity, etc.) using doubles. When rendering images these numbers get casted to floats so Unity can work with them.[/quote]
Not quite. PhysX uses floats for its physics variables, so when off timewarp (or in physical timewarp) everything is single precision. When on rails (normal timewarp), orbital calcs are done with double precision using Squad's own code.

[quote]This is known as Krakensbane and was introduced in 0.17 (I think).[/quote]
Krakensbane was the recentering of the coordinate system on the vessel instead of on the parent celestial body. Floating point error magnitude increases with the magnitude of the value, so this gives excellent precision in the vicinity of the ship where it is needed most (at the cost of coordinate conversions for many calculations).

[*Aqua*]

I got the impression Krakensbane introduced the orbit calculation using doubles.

[Red Iron Crown]

[quote name='*Aqua*']I got the impression Krakensbane introduced the orbit calculation using doubles.[/QUOTE]
Looks like we're both right: [url]http://forum.kerbalspaceprogram.com/entries/12-Krakensbane[/url]

[Hannu]

[quote name='*Aqua*']Also a float is usually the best data type for games. CPUs and GPUs are faster at calculating floats than doubles and the range of values is greater than the one of integers.[/Quote]

I disagree, except maybe when calculated vertex and normal coordinates are thrown to GPU. Floating point instructions of CPUs works with 64 bit numbers (or even 80 bit). Only exception are AVX-instructions which can calculate 8 float or 4 double operations simultaneously. However, such instructions are typically not suitable or practical to physics needed in KSP (or other games). 4-vectors and 4x4 matrices needed in games can be calculated with doubles and there is not need to 8 simultaneous operations.

I do not know if KSP or Unity even uses them because they are not compatible to old CPUs (and laborious to program). Does any game use GPUs to calculate physics? I also think that new GPUs can handle doubles.

It is true, that doubles do not benefit practically all games, but they do not also take anything. There is no good reason to keep old practices (but of course I know that it takes decades to change even in hectic software industry). Especially, if someone programs a space simulator, there should not be any reason to use 32 bit floats or use toy physics engines which use such numbers. More probably they need some specific 128 bit libraries.

[Red Iron Crown]

32-bit CPUs can handle doubles, they're the reason they're called doubles in the first place. They just don't perform as well as on a 64-bit CPU.

[TheTom]

[quote name='KerbMav']Heat is calculated by itself and not as part of the physics engine, physics meaning the interaction of individual parts in the simulated environment and with each other.[/QUOTE]

More exact: Phsyics - moving, movement powers between parts - is calculated by a Physics engine (PhysX) which is part of Unity. This is what decides the wobble, for example.

Heat calculations (as well as the whole aerodynamics calculation) is done in separate code written in C# and part of the KSP codebase.

[*Aqua*]

[quote name='Hannu']Does any game use GPUs to calculate physics? I also think that new GPUs can handle doubles.[/QUOTE]All games with PhysX with enabled GPU acceleration calculate their physics using the GPU. The first game which allows that is Mirror's Edge.
KSP uses PhysX too but GPU acceleration for it isn't enabled.

The current Tomb Raider allows hair 'physics' to be calculated on AMD GPUs.

[quote name='Hannu']It is true, that doubles do not benefit practically all games, but they do not also take anything. There is no good reason to keep old practices (but of course I know that it takes decades to change even in hectic software industry). Especially, if someone programs a space simulator, there should not be any reason to use 32 bit floats or use toy physics engines which use such numbers. More probably they need some specific 128 bit libraries.[/QUOTE]GPUs and CPUs are optimized for fast 32 bit floating point operations because that's the current state of the art. Games like KSP which may profit from 64 bit floats are a seldom. Your average shooter or driving game doesn't need 64 bit floats. And those use cases are what the game engines are optimized for. As you said you can calculate either 8 floats per cycle or 4 doubles. Changing everything to double will [I]half[/I] the speed of floating point calculation.

You don't implement everything which is possible, instead you implement what's reasonable.

The only reason why software slowly changes from 32 bit integers to 64 bit integers in the last decade is because there's a need for more addressable memory. Edited November 24, 2015 by *Aqua*