Unity 5 [Is now available]

[sumghai]

Funny how it was just months since they stated that unity5 was absolutely first priority. It was such high priority that they would halt everything else as soon as they got access to it, so that they could use all resources to get it ported over to unity5. Then suddenly soon after they announced 1.0 instead....

And this is why it to me makes absolutely zero sense to suddenly rush towards 1.0. The more they add to the current version, the more they will have to fix when they finally get to porting it over.

SQUAD never made a legally-binding contract or promise that they would port the game to U5 as soon as it became available. Technical and corporate issues in the background could also have caused a change of plans anyway.

Also, in a software engineering environment, it's not always a good idea to immediately jump to the latests and greatest version as soon as it comes out, because new versions will inevitably come with its own quirks and bugs.

To use a concrete example: I'm a software engineer at a company that makes mass spectrometers, and our instruments are based on a custom-made industrial PC running Linux and Java. Our newest instruments are still using older versions of Java because our software team already knows those versions well enough to keep the software running efficiently and to implement relatively new features in a safe and robust manner. If we switched to using the latest versions of Java, many of our libraries and dependencies will break, and furthermore, many of our customers' instruments would break very badly (these things are worth a quarter of a million dollars per unit). We would end up spending more time trying to fix our own workflow to fit the new update instead of responding to customer issues in a timely manner.

KSP may not be a mission-critical application, but the principle is the same: at a major milestone, one does not simply introduce more unknown variables in the development process by switching to an untested and unfamiliar update to a component software engine/library/module.

[John FX]

Myself, I'm happy waiting for U5 until 1.0 is released, bugfixed (1.1) and new features are added (1.2) and then some more stuff (1.X)

For something as special as native 64 bit, hardware phys-x etc I reckon it would be worth calling it KSP 2.0.

We may even get clouds...

[Eric S]

There are even unity 4 games that properly do 64bit without any stability issues. A perfect example is the new cities: skylines which is only available in 64bit and was made in unity4. It also properly uses all cores of the CPU as well.

Actually, skylines switched over to Unity 5 in late beta. In addition, there were already games using the 64bit client back when there were bugs that would have prevented KSP from running for more than a few minutes at a time. Different games use different feature sets, so unless the games are using the same feature sets, you really can't say that just because game X using engine Y is stable that game Z should be as well. The same goes for how easily the game can be ported from U4 to U5. KSP uses PhysX, which is one of the few parts of U5 that is not backwards compatible with U4.

Funny how it was just months since they stated that unity5 was absolutely first priority.

Source? I've seen comments that they're very excited about Unity 5, one tweet that said that Unity5 would be a high priority after it was released, but nothing stating absolutely first priority.

Also, the release version of Unity 5 didn't land until Squad was well into the 1.0 development cycle. Switching directions at that point probably would have been bad.

[Beduino]

Just out of curiosity this shows what changed in unity5 physics. http://docs.unity3d.com/Manual/UpgradeGuide5-Physics.html

It will probably break these things in KSP:

- joints between parts and related parameters.

- terrain physics material properties.

- raycasting if any.

- kerbal ragdolls.

- wheels

It mentions this: "Unity 5.0 physics could be expected to work up to 2x faster than in previous versions"

Also unity5 is completely written to support 64 bit game releases

Cheers!

Edited April 6, 2015 by Beduino

[boxman]

Actually, skylines switched over to Unity 5 in late beta. In addition, there were already games using the 64bit client back when there were bugs that would have prevented KSP from running for more than a few minutes at a time. Different games use different feature sets, so unless the games are using the same feature sets, you really can't say that just because game X using engine Y is stable that game Z should be as well. The same goes for how easily the game can be ported from U4 to U5. KSP uses PhysX, which is one of the few parts of U5 that is not backwards compatible with U4.

Source? I've seen comments that they're very excited about Unity 5, one tweet that said that Unity5 would be a high priority after it was released, but nothing stating absolutely first priority.

Also, the release version of Unity 5 didn't land until Squad was well into the 1.0 development cycle. Switching directions at that point probably would have been bad.

The source is KSPTV/Squadcast.

[kenbobo]

I've moved my projects from unity 4.6.1f1 or whatever and it has had no problems, and new projects are seamless. The 64 bit edition runs a bit faster with a plane, and some mountain terrain, but other than that i see no difference.

[boxman]

SQUAD never made a legally-binding contract or promise that they would port the game to U5 as soon as it became available. Technical and corporate issues in the background could also have caused a change of plans anyway.

Also, in a software engineering environment, it's not always a good idea to immediately jump to the latests and greatest version as soon as it comes out, because new versions will inevitably come with its own quirks and bugs.

To use a concrete example: I'm a software engineer at a company that makes mass spectrometers, and our instruments are based on a custom-made industrial PC running Linux and Java. Our newest instruments are still using older versions of Java because our software team already knows those versions well enough to keep the software running efficiently and to implement relatively new features in a safe and robust manner. If we switched to using the latest versions of Java, many of our libraries and dependencies will break, and furthermore, many of our customers' instruments would break very badly (these things are worth a quarter of a million dollars per unit). We would end up spending more time trying to fix our own workflow to fit the new update instead of responding to customer issues in a timely manner.

KSP may not be a mission-critical application, but the principle is the same: at a major milestone, one does not simply introduce more unknown variables in the development process by switching to an untested and unfamiliar update to a component software engine/library/module.

I never said they made a legally binding contract. I was just quoting what squad/community manager stated on the Squadcast last year.

And if you are a software developer you should also understand that it is not a wise idea to rush towards 1.0 release until a port has been done, the code has been optimized and everything being bug tested to make sure it is as bugfree as possible. Alot of the features they are planning to put into the game after 1.0 will bring new bugs and quite possible break our save games, ships and mods and same thing will happen when they port it to unity5. It would make sense to get the code more or less frozen by the time it reaches 1.0, so that the chances of that happening is minimal. Instead they are now adding a bunch of features and releasing 1.0 without it even being in beta to make sure it actually does not break the game further.

The current version of KSP is seen as the most unstable version in ages thanks to memory issues. The addition of new features like IVA scenes will make this even worse and yet they are going ahead with 1.0.

[sumghai]

I never said they made a legally binding contract. I was just quoting what squad/community manager stated on the Squadcast last year.

Unless there's a transcript accurately describing word-for-word what was actually said, it is more likely that the alleged statement you're quoting was an off-the-cuff musing rather than an official announcement.

And if you are a software developer you should also understand that it is not a wise idea to rush towards 1.0 release until a port has been done,

Switching to a new engine (or even a newer major version of an engine) late in the 1.0 development cycle is a very bad move.

SQUAD isn't rushing to 1.0 - they steadily and patiently making sure 1.0 works using the existing Unity 4 engine that they're familiar with.

the code has been optimized and everything being bug tested to make sure it is as bugfree as possible.

Given that Unity 5 is still relatively new in the software ecosystem, there will be bugs that the Unity devs will not have caught.

And even if Unity 5 is truly bug-free, those optimizations won't be of immediate help to SQUAD, who will need to spend a long time understanding the new systems (for instance, the new Physx 3 is very different from the Physx 2.x that SQUAD is used to).

Alot of the features they are planning to put into the game after 1.0 will bring new bugs and quite possible break our save games, ships and mods and same thing will happen when they port it to unity5.

Whenever a new version of any software comes out, expect things to break.

It would make sense to get the code more or less frozen by the time it reaches 1.0, so that the chances of that happening is minimal. Instead they are now adding a bunch of features and releasing 1.0 without it even being in beta to make sure it actually does not break the game further.

While I agree that the beta period for KSP isn't as extensive as one would like it to be, your suggestion that SQUAD should port the game over to Unity 5 for 1.0 would compound the development process even more.

The current version of KSP is seen as the most unstable version in ages thanks to memory issues.

Could you provide verifiable statistics and specific bug reports to verify this claim?

The addition of new features like IVA scenes will make this even worse

IVA scenes are not new - they were first introduced in KSP 0.17 back in September 2012

and yet they are going ahead with 1.0.

SQUAD has decided that, given their familiarity with Unity 4.x, that they're reasonably confident that the current version of the game engine they have access to would be sufficient to support their original vision for the game, as well as fix most of the problems they are aware of up to this point in time.

[Beduino]

Just out of curiosity this shows what changed in unity5 physics. http://docs.unity3d.com/Manual/UpgradeGuide5-Physics.html

It will probably break these things in KSP:

- joints between parts and related parameters.

- terrain physics material properties.

- raycasting if any.

- kerbal ragdolls.

- wheels

It mentions this: "Unity 5.0 physics could be expected to work up to 2x faster than in previous versions"

Also unity5 is completely written to support 64 bit game releases

Cheers!

I was having fun these days learning Unity 5 so I decided to test the physics performance.

Created the physics equivalent of a ship with 800 parts plus the associated joints of different kinds.

Shadows + Material.

Pretty surprising results while still in the unity editor the fps is around 60 even when madly hitting the physics parts so they are not at rest.

So if this isn't a "silver bullet" it at least is shining like one.

Edited April 6, 2015 by Beduino

[Random Tank]

Voted for the wrong option on the Poll.... *face-desk*

Anyway, Optimization and bug fixing are the most important thing to do in KSP's development; I strongly agree that is should be ported over, and final versions should not be released until it is ported.

The release state of the game should allow people even with not-amazing PC's to at least build decent size ships (500 parts) with serious lag, and for a game that advertises its "Modability" as a feature, it should definitely have 64-bit, and some better texture management and load on demand textures too; plus some features to reduce the physics lag, like part welding and disabling part physics in some situations.

But that's all a bit late now... :\

[cpast]

Anyway, Optimization and bug fixing are the most important thing to do in KSP's development; I strongly agree that is should be ported over, and final versions should not be released until it is ported.

Those two clauses are in direct opposition to each other. Changing engines is the precise opposite of "optimization" and *especially* "bug fixing." The point of doing optimization and bug fixing is that you make minor changes to code. You don't do big things; you only change things if you absolutely have to. Switching engines creates new bugs. It's changing the code from something where the team has a pretty good sense how things work and what to do, and has incorporated all sorts of tweaks to fix issues, into an incompatible physics engine and a new game engine. It's not a simple task. If it were, this would be Unity 4.4 (I think). Likewise, the kind of optimization you do late in the release cycle is as unobtrusive as possible; big changes have heavy bug potential.

It's entirely possible that, had this come out six months ago, Squad would have changed over. Had it come out in December, Squad might have considered investing some dev time into seeing how it works, and trying to hack a port together to see how it runs (and see if it's a bugsplosion, a won't-compile-splosion, or runs decently well). But it came out in March, well into the final push for release. At that point, no matter what Squad had said about U5 a year ago, it'd be *insane* to go all-in on U5. I wouldn't be surprised if they tried compiling against U5, but if there were *any* serious issues, you'd be crazy to put off your 1.0 to change the game engine when you're nearing release (keep in mind, Squad also had and has a much better idea of the status of KSP's development than forumers; I suspect they knew they were nearing experimentals).

Edited April 6, 2015 by cpast

[Fel]

Isn't SQUAD under notice saying they will not ever use PhysX's gpu feature? The rationale being that they end up having more issues with having two codebases to maintain (those who have a physx enabled gpu... and those who don't).

PhysX, no matter how you spin it, is just an interface for hardware. Saying using "the latest version" will automatically make your code uber fast is like saying using DX11 on a DX9 card will make it run faster. I "guess" later versions did interface with more recent CPU architecture... Nvida seriously thought they could get away with not maintaining their codebase?

*A new note on this.

Unity Devs state that they "improved" upon raw PhysX which makes it hard to understand how much of the code was still legacy x87. If all of it was, then yeah, you would see a significant speed increase, if only some of it was the difference would be significantly less.

Edited April 6, 2015 by Fel

[Alshain]

Isn't SQUAD under notice saying they will not ever use PhysX's gpu feature? The rationale being that they end up having more issues with having two codebases to maintain (those who have a physx enabled gpu... and those who don't)

That doesn't really make sense. For one thing, there wouldn't be two code bases, even if they needed to do something special for PhysX hardware acceleration. There are programming techniques to do this sort of thing (see Subtype Polymorphism).

For a second, PhysX hardware acceleration is just that, hardware acceleration. The PhysX processing is shipped off to the GPU so the CPU doesn't have to do the work. It's kind of like having extra CPU power. I don't think the program running the PhysX engine has do anything special except turn it on, it is built into the engine, however Unity 4 uses a version of the PhysX engine that doesn't support it. You DirectX analogy is flawed, a more accurate one would be like saying a multi-core processor running supported code will run faster than a single core processor... which is true.

Edited April 6, 2015 by Alshain

[Climberfx]

Don't mistake Physics (KSP have in code on CPU), with PhysX (Nvidia proprietary code to direct access the video board, but not AMD, just Nvidia)

And KSP does NOT have PhysX. Never had and possibly will never have but here i'm just speculating!

AMD users must be included, everyone must be included.

And you are wrong Alshain, you must write code directly to PhysX. Is a proprietary from Nvidia and run only on Nvidia and is not equal other codes. Is not just turn on and off in Unity compiler thing.

Just because majority games have a button to turn it on and off, don't think there is equal in game programing.

Edited April 6, 2015 by Climberfx

[Fel]

That doesn't really make sense. For one thing, there wouldn't be two code bases, even if they needed to do something special for PhysX hardware acceleration. There are programming techniques to do this sort of thing (see Subtype Polymorphism).

For a second, PhysX hardware acceleration is just that, hardware acceleration. The PhysX processing is shipped off to the GPU so the CPU doesn't have to do the work. I don't think the program running the PhysX engine has do anything special except turn it on, it is built into the engine, however Unity 4 uses a version of the PhysX engine that doesn't support it.

It's just bad jargon, the issue is that problems with non-gpu accelerated users WOULD be different from problems with GPU accelerated users, call it what you want, you'll still end up maintaining two different sections of code. (Err, I was wrong here... problems in Linux / Mac / Windows versions are different... so 6 different sections ;p)

PhysX is 100% about hardware acceleration, initially a poorly sold sub-unit (Physics Processing Unit) and later Nvidia's lovechild...

In more research it seems Unity also had the same notion; they had a FULLY CAPABLE of using GPU PhysX... but they did not use the GPU because that would create problems between platforms... unity 5 looks to be the same.

http://blogs.unity3d.com/2014/07/08/high-performance-physics-in-unity-5/

Yeah... it really sounds like the whole GPU offloading is "if we feel like it" rather than "doing it now" (and more so, this would be THEIR bland of offloading; likely using something like opencl)

Edited April 6, 2015 by Fel

[rkman]

Don't mistake Physics (KSP have in code on CPU), with PhysX (Nvidia proprietary code to direct access the video board, but not AMD, just Nvidia)

And KSP does NOT have PhysX.

PhysX is automagically executed on the cpu on systems that don't have an nvidia graphics card. http://en.wikipedia.org/wiki/PhysX

Unity has physx, and KSP uses it for at least some parts of the physics simulation. http://wiki.kerbalspaceprogram.com/wiki/PhysX

[Climberfx]

KSP use only CPU to calculate all the physics. If it use "Physx" that are in Unity3D (and that wiki link don't prove anything), is the CPU type only. Even if you have an Nvidia GPU, it won't use it at all.

The best way to advance that on KSP would be by Open CL, that run in all type of video cards, not Nvidia only. And have practically the same type of acceleration/optimization.

Edited April 6, 2015 by Climberfx

[rkman]

KSP use only CPU to calculate all the physics. If it use "Physx" that are in Unity3D (and that wiki link don't prove anything),

is the CPU type only.

The cpu type of Physx. In other words it is physx, as opposed to "ksp does not have physx".

[Red Iron Crown]

PhysX is the physics engine used by Unity and thus KSP. It exists in several forms, and GPU-acceleration is only a small subset of that, which KSP doesn't use it. Nor should it.

GPU acceleration only helps when simulating many independent rigidbodies, like in the second video ClimberFX linked above. Such a simulation can effectively use one thread per body, and a GPU has a lot of parallel processors for highly threaded operations. KSP's physics are a bit different, the parts of a vessel aren't independent but are instead chained and constrained. It is not clear that that sort of calculation is easily threadable like independent bodies are, there are scholarly papers about attempts to make them so but no real-life implementations as far as I know.

Whether GPU-accelerated PhysX or OpenCL doesn't really matter if the task isn't threadable in the first place; in such a case it's better to keep it on the CPU where a single thread executes more quickly. I think at best we'll see one physics thread per active vessel inside the physics bubble.

[Beduino]

Whether GPU-accelerated PhysX or OpenCL doesn't really matter if the task isn't threadable in the first place; in such a case it's better to keep it on the CPU where a single thread executes more quickly. I think at best we'll see one physics thread per active vessel inside the physics bubble.

Actually PhysX can use multiple threads on CPU too.

Here's a simulation of KSP like physics in Unity 5. It's somewhat the equivalent of 5 KSP Ships with 265 parts each.

"5 contraptions containing each 265 mesh colliders cylinders (approximately) and associated breakable joints with collisions between bodies enabled. Total of 1325 cylinders.

30 FPS while recording

60 FPS when not recording"

Edited April 6, 2015 by Beduino

[Red Iron Crown]

Never said it couldn't. Just that a single KSP vessel is not easily threadable. (That demo is pretty impressive all the same!)

[Climberfx]

I think that is not the same level of interaction. This just colide and fall. like the ones i show too.

The KSP have a massive trust on bottom of the pieces, and must stay together, and function accordingly.

This small diference that requires today one core to "rule than all". In an organized manner.

The moment multiple ones try to do the interaction, the results start to break a part.

But is not impossible do solve this in near future...

[Beduino]

I think that is not the same level of interaction. This just colide and fall. like the ones i show too.

The KSP have a massive trust on bottom of the pieces, and must stay together, and function accordingly.

This small diference that requires today one core to "rule than all". In an organized manner.

The moment multiple ones try to do the interaction, the results start to break a part.

But is not impossible do solve this in near future...

Maybe (ill try to do more tests on that) but that doesn't explain why simple stationary orbital stations with 250-500 parts are already lagging hell in KSP.

But anyway what you see as a rocket is just a bunch of cylinders attached together with joints with a force applied, much like in the test video.

Edited April 6, 2015 by Beduino

[Climberfx]

Well, i do not know how KSP is programed...

Can't tell.

But even an orbital station, have it's wobbling effect occurring in between all the parts...

Some times in the past, when i oversized some stations and docked a lot of other vessels on it, i try to aim the station (rotate) at a specific direction, with RCS and RW, it start to wobble and then explode.

Man...

The quicksave saved me.

Imagine in this little demos you are using a plane, in game, you have planets, and orbits. Is a different calcule. Not only a one axis gravity...

[pincushionman]

…Here's a simulation of KSP like physics in Unity 5…

Not to be that guy, but I've seen several attempts to show U5 handling the physics much better than we know KSP currently does, which is great. Could you please run the exact same simulation in U4 and post the results similarly, so we can compare the two side-by-side?

If the U5 sim runs great, that's great…but if the U4 sim runs great too, then it's meaningless, and the performance bottleneck is something besides just a U4/U5 thing.

Now, I say that as someone who would love for U5 to be the big performance breakthrough, simple as that. But the devil is in the details, and it depends on exactly what KSP is doing and how it goes about doing it. And even then, as others have said, it may not be as simple a task as just switching. The'yve admitted to kludging some stuff to get U4 to work…well, at least partly like they want. All of that will have to be evaluated as to whether it ports smoothly, ports at all, needs re-written, or even needs to be used at all.