Unity 5 [Is now available]

[sumghai]

Harv already talked about Unity5. I can't find the post, but the transition to Unity5 would be an extremely long, complex, and hard process, which is not even guaranteed to work correctly. If they try to fit this in 1.0, bad stuff is bound to happen.

I think this is the post you are referring to:

I think it's important to make it clear that Unity 5 is very unlikely to be the magical silver bullet people are making it out to be.

When we moved from unity 3 to 4, we had to deal with a LOT (and I do mean a LOT) of upgrade-related bugs which we didn't expect. Furthermore, the earlier versions of Unity 4 had quite a few bugs of their own which we had to work around (or hang tight) until fixes came along.

My point is, moving to Unity 5 is very unlikely to be a straightforward transition, and by no means I expect KSP to be stable or even playable (let alone improved) after simply upgrading the project over. I would be very happy to be wrong in that one, I must add, but historically, every time we upgraded to a new major version of unity, we came across new issues we had to contend with, so please don't get overexcited about Unity 5 just yet.

This late in a project, most games tend to freeze engine versions when they find something stable that fits their needs. Regression issues is in fact the main reason why Unity stuck with PhysX 2.8 until now. If breaking mods and saves is an issue for us, imagine their case, where instead of mods and saves, they risk breaking hundreds of commercial projects. We have it easy by comparison really...

Anyhow, we don't plan to freeze engines, but I just wanted to clarify that moving to Unity 5 may not be as simple and so immediately beneficial as it may seem. At the very least, we don't plan to upgrade until A: The 1.0 release is out, and B: Until U5 is out of beta and confirmed stable.

Cheers

Personally, I think that the biggest optimization needed for KSP isn't so much U5's native Win x64 and multithreaded Physx 3.3 support, but on-demand loading/unloading of game assets (especially textures).

I also agree that, at this relatively late (and critical) stage in 1.0's development, the devs should focus on getting a stable release based on the U4 engine, instead of treading unfamiliar waters by jumping into directly into U5.

[basic.syntax]

If one takes Max's tweet literally, (the way I read it) they will sweep the table after 1.0 ships, and dig into the new toys.

I'll be happy enough, if I can go back and forth from the VAB to the pad with a 200+ part craft, 15 times in a row, (preferably more times, lol) without a crash.

(all stock parts. I'm only using UI helper mods like KAC, KER)

[RocketPilot573]

Here you go:

http://forum.kerbalspaceprogram.com/threads/112265-Unity-5-to-release-today

[Master Tao]

Duplicate threads merged.

Also, it looks like the developers read the discussion of last week's DevNotes:

Felipe (HarvesteR): Oh, and in response to a discussion that flared out from the last notes: procedural means a mesh that is created by code, as opposed to one that is imported from file.

There's a difference between ignoring and not actively responding.

[Starwaster]

Also, it looks like the developers read the discussion of last week's DevNotes:

There's a difference between ignoring and not actively responding.

Especially since that same answer had been adequately given by others, even if they weren't Squad

[Thnd3r]

On a not particularly similar topic, we are thrilled to see the release of Unity 5, and look forward to digging into it once we’ve released 1.0, as development on the next update is far too advanced now to throw something as complex as an engine update on top of it.

From Max in Today's Dev notes

[W1ntermute]

I think this is the post you are referring to:

Personally, I think that the biggest optimization needed for KSP isn't so much U5's native Win x64 and multithreaded Physx 3.3 support, but on-demand loading/unloading of game assets (especially textures).

I also agree that, at this relatively late (and critical) stage in 1.0's development, the devs should focus on getting a stable release based on the U4 engine, instead of treading unfamiliar waters by jumping into directly into U5.

The differences between coding for U4 and U5 are not significant, it still uses the same programming language. It's the allocation of assets that has been streamlined and the focus on multithreading for internal processes. Saying that U5 isn't the magic silver bullet is a bit of a cop out. It has features that game devs have been screaming out for from Unity since v4 came out and didn't get.

Personally, Squad would've been better off scripting their own proprietary engine or utilizing one like space engine but scaling it down to solar system size, so it did exactly what they needed rather than work around Unity's limitations and use the latest version of Physx as a plugin. It would've been a lot more stable too

[bullettMAGNETT]

Squad please move KSP into Unity 5 *drools*

[NoMrBond]

Squad please move KSP into Unity 5 *drools*

Already said they're going to (well, strongly want to), just not for 1.0

[sumghai]

The differences between coding for U4 and U5 are not significant, it still uses the same programming language.

The official Unity blog entry on how U5's Physx 3.3 implementation states otherwise:

We’ve been using PhysX 2.8.3 for a while now. We’ve not just used the plain stock PhysX, but extended it with numerous patches made by Unity engineers over the years. It’s been so long, and we say thanks to PhysX 2 for all the fish. As announced at GDC’14, Unity 5.0 features an upgrade to PhysX 3.3. Let’s give it a closer look.

PhysX SDK 3 is a radical redesign of the good old PhysX SDK 2.x. Basically, the PhysX team have taken the best ideas and best approaches from 2.x and rewritten the whole SDK from scratch. That means the entire codebase is different, all the interfaces are different and most of the functionality is different.

[AbhChallenger]

A few things I would like to clarify for this opinion.

#1 I am NOT talking about hotfix, bugfixes, or balance issues that would require SQUAD to push an urgent update prior to their plans. (Such as 1.0.1 etc…) I am speaking about a version that gets its own name.

#2 This opinion is IF and I mean IF the KSP development team has determined that Unity 5 after KSP 1.0 is in a state that would allow them to implement such a plan. I am NOT trying to say they should push KSP to Unity 5 just to say “We are Unity 5 now! YAY!!11â€Â

---

Now again IF this is the case. My opinion on thinking about the subject that indeed a jump to Unity 5 warrants a version focus soon after 1.0 launches. My opinion is based on three potential benefits and the multiplayer path.

#1 The upgraded software PhysX and the possibility that it will allow a massive improvement in CPU use allowing players on lower end machines to build rockets with additional parts. And for those who have higher end machines to have less of a CPU wall of performance.

#2 Unity 5 treating 64 bit as more than afterthought. (Again I have NO repeat NO evidence that Unity has actually fixed the problems preventing a proper KSP 64 bit. Only squad can determine if this is a possible benefit worthy of focus) And removing this plague of the 32 bit barrier.

#3 The benefits Unity 5 can bring for modders.

#4 The need to get used to Unity 5 as soon as reasonable to get back on the path towards multiplayer KSP.

---

As has been said by others many times. The jump to Unity 5 will not be an easy path. And that is assuming that after 1.0 Unity 5 is in a stable condition to make it possible. However, I think it is more important than many other potential focus paths KSP can take for 1.1 or 1.2.

To close I do not claim that Unity 5 is a cureall for the issues KSP currently suffers from. Just that it should be prioritized as soon as it is reasonable to do so.

[Dodgey]

I'm sure that's the plan of the developers. They have mentioned many times in the past that once Unity is updated it will become their priority, in the dev notes they said they are not doing it this update because they have already progressed too far into this update to throw an engine change in there as well.

[problemecium]

I'm in favor, and I agree with the above response that they're probably already planning for it.

[AbhChallenger]

I'm sure that's the plan of the developers. They have mentioned many times in the past that once Unity is updated it will become their priority, in the dev notes they said they are not doing it this update because they have already progressed too far into this update to throw an engine change in there as well.

TBH I figure that is their plan as well. It is just that I understand that it is going to be difficult for them to market 1.1 being focused on Unity 5 rather than something flashy like resources, aerodyamics, or asteroids. And it is going to suck to wait for it as it will likely take quite a long time to make the switch proper. It is that I encourage them to endure that to make the switch to Unity 5 as soon as it is reasonable to do so.

[tsotha]

Soo I think squad is like "when unity 5 releases then we will update to it and then people can stop Complaining!*"

* may or may not be true!

People will never stop complaining. They just change the target of their complaints occasionally.

[Renegrade]

From Max in Today's Dev notes

Unity 5 in 1.1 releasing tomorrow confirmed!

Here's to hoping for better performance, and an actual working 64-bit release.

(Dammit, the Unity guys are slower than Squad~ )

[Joshwoo70]

to all the devs (or mods!)

I found out that unity 5 was made stable not long ago (a few days)

do you plan on porting ksp to unity 5?

if so do we get a better ksp?

[Bill Phil]

No, not now of all times.

In the FUTURE, sure. But it's Squad's call.

[Mipe]

If they want to remain competitive, they will upgrade. Nobody wants a game that can't run all its mods due to memory constraints.

[sal_vager]

You didn't read the devnotes did you?

On a not particularly similar topic, we are thrilled to see the release of Unity 5, and look forward to digging into it once we’ve released 1.0, as development on the next update is far too advanced now to throw something as complex as an engine update on top of it.

[magnemoe]

First they will want to finish 1.0, that will make the game feature complete.

It will also let others find bugs in unity, probably also to make an knowledge base on 4 to 5 conversion issues.

[Joshwoo70]

You didn't read the devnotes did you?

yup i did not read the page ....

[RAINCRAFTER]

KSP already looks ok, stock is good enough in my opinion, mods don't make the game insta-crash, and 64 bit is also pretty stable in my opinion. So WHY do you think Unity 5 should be our game engine?

(This is my opinion so don't hit me.)

Edited March 4, 2015 by RAINCRAFTER

[Capt Snuggler]

KSP already looks ok, stock is good enough in my opinion, mods don't make the game insta-crash, and 64 bit is also pretty stable in my opinion. So WHY do you think Unity 5 should be our game engine?

(This is my opinion so don't hit me.)

the massive physics improvement for one. I think under unity 5, physics could be processed by the graphics card rather than CPU.

Anthony from unity3d.com July 8, 2014here

We’d like to highlight some of the 3D physics changes you can look forward to in Unity 5.0....

From what we’ve seen so far, it’s reasonable to expect a doubling in performance generally just as a result of having a better code base and improved multithreading. In some instances, the improvement is dramatic, with up to tenfold improvements.

and 64bit is not stable. squad have said KSP v1.0 will not be 64bit. Unity 5 should fix this

also some improvements to lighting too I think.

Edited March 4, 2015 by Capt Snuggler

[Whirligig Girl]

KSP already looks ok, stock is good enough in my opinion, mods don't make the game insta-crash, and 64 bit is also pretty stable in my opinion. So WHY do you think Unity 5 should be our game engine?

(This is my opinion so don't hit me.)

KSP already looks ok, stock is good enough in my opinion, mods don't make the game insta-crash, and 64 bit is also pretty stable in my opinion.

Mods don't make the game insta-crash, and 64 bit is also pretty stable in my opinion.

64 bit is also pretty stable in my opinion.

64 bit

Stable

*Laughs continuously*