Unity 5 [Is now available]

[Renegrade]

By the way, as a note to this Squad comment:

"Yes, we are running internal tests on Unity 5. It's looking promising, but also... it kinda looks like every time... how to put it...like, there's a lot that CAN happen with Unity 5, but the work we have shown [internally] so far, is that it can... just about IGNITE the computer it is running on."

7 Days to Die internal testing revealed situations in which their Unity 5 version would cause massive overheating, and they did some sort of workaround. May be related to that Maxmaps quote.

Mind you, if code is causing your machine to overheat to dangerous levels, you have serious hardware problems, not software problems. Or you're using a laptop (which qualifies as a hardware problem anyways~)

[NoMrBond]

I imagine the problem causing that sort of behaviour would show up very clearly in the Unity Profiler

There have been enough conversion diaries detailing projects being upgraded to Unity 5 that I'm not worried about feasibility any more.

Top that off with Unity 5 games which are out (like Cities:Skylines), and games still in development/early-access like The Forest or 7 Days to Die which showing lots of nice stuff (like a working win-x64 client), yeah, this is looking peachy.

I'm also wondering, that since this will be such a big change, it presents an opportunity for, not quite sure how to describe it, but 'deep' fixes, changes to underlying systems which may be needed but making the fixes or updating those systems risks (or guarantees) braking a lot of downstream stuff/dependencies so they can't be made presently because of how much time it would take.

[Edit] Plus stuff like

Gives me hope for enhanced rover fun in the future

Edited April 17, 2015 by NoMrBond

[waterlubber]

So, Unity 5 pushes GPU's and such to the level of coil whine? Is that what I'm getting?

Such a shame no PhsX for AMD. I seriously, seriously, seriously, doubt that AMD will ever make a driver, for linux, compatible with PhsX.

And the chance of me being able to install it? 0.

Anyway, maybe you could have a U4/5 version after 1.0 comes out and then see how it goes from there.

[NoMrBond]

Anyway, maybe you could have a U4/5 version after 1.0 comes out and then see how it goes from there.

If you convert a Unity 4 project then run the resulting Unity 5 project without checking anything then yes, very odd things can happen, including with performance

Most APEX modules sound like they come with OpenCL support, but unfortunately it's unlikely that this would happen with the main PhysX functionality (still, GPGPU accelerated APEX Destruction would be cool as all hell)

Upgrading KSP's engine to Unity 5 has been stated as a priority after 1.0 is released so that part at least is going to happen, although exactly how much of a performance benefit there will be is a matter of conjecture

[slumpie]

Such a shame no PhsX for AMD. I seriously, seriously, seriously, doubt that AMD will ever make a driver, for linux, compatible with PhsX.

And the chance of me being able to install it? 0.

It runs just fine on computers with AMD hardware and additionally there's no need to install anything (apart from the game, of course...).

[Fel]

Such a shame no PhsX for AMD. I seriously, seriously, seriously, doubt that AMD will ever make a driver, for linux, compatible with PhsX.

And the chance of me being able to install it? 0.

PhysX is a proprietary acquisition by nVidia and has always (well, before it was a separate unit) been hardware acceleration for nVidia cards with software for ATI.

If Unity is releasing with GPU accelerated physics, then they rewrote parts of it so it works using opencl instead of nVidia's proprietary interface.

[sarbian]

Most of PhysX is pure CPU even on Nvidia hardware. The GPU part is restricted to some part like particles.

[NoMrBond]

If Unity is releasing with GPU accelerated physics, then they rewrote parts of it so it works using opencl instead of nVidia's proprietary interface.

A lot of the APEX bolt ons have OpenCL support

[Fel]

Most of PhysX is pure CPU even on Nvidia hardware. The GPU part is restricted to some part like particles.

PhysX was designed, purely, to be a hardware implementation of physics. Of course, getting developers to actually USE something that only a portion of their clientèle actually have is different but, if you're trying to say "developers don't use PhysX to the full potential because it creates incompatibilities between customers with different hardware, and Unity 4 removed the nVidia acceleration component of PhysX because of this" you'd be right.

A lot of the APEX bolt ons have OpenCL support

This probably is true enough, I was just trying to point out that PhysX is bloody proprietary and if ATI "implemented PhysX" nVidia would swamp them with lawsuits. OpenCL writing an abstraction layer to deal with this is a bit different... it'd be akin to suing Microsoft for creating DirectX.

[marach]

This probably is true enough, I was just trying to point out that PhysX is bloody proprietary and if ATI "implemented PhysX" nVidia would swamp them with lawsuits. OpenCL writing an abstraction layer to deal with this is a bit different... it'd be akin to suing Microsoft for creating DirectX.

Nvidia once offered AMD physx working on AMD cards... their requirement for this? Complete technical specs (including the wafer fab masks!) of AMD chips! For some reason AMD declined...

[sarbian]

PhysX was designed, purely, to be a hardware implementation of physics. Of course, getting developers to actually USE something that only a portion of their clientèle actually have is different but, if you're trying to say "developers don't use PhysX to the full potential because it creates incompatibilities between customers with different hardware, and Unity 4 removed the nVidia acceleration component of PhysX because of this" you'd be right.

It was pure software from the start, then got accelerated for the ageia cards but most stayed pure CPU. Then Nvidia bought it and redid some of the code to run on their GPU but it always could work on pure CPU since it was the physic engine in many game WAY before Unity4 existed. Each time you saw the whole phyxis on nivida stuff you only had some particle done on GPU while the rest of the engine was still on CPU.

You may want to read up on the history of Physx from its creator : http://www.codercorner.com/blog/?p=1129

[Francois424]

Now that 1.0 is due out really soon, I hope they focus efforts into making KSP in U5 a thing.

Even if there is ZERO improvement over the current version (and as long as it doesn't make it WORSE), That is totally worth it for the mods you'll be able to run. I'm dying for that as the next, major update

[NoMrBond]

Now that 1.0 is due out really soon, I hope they focus efforts into making KSP in U5 a thing.

Even if there is ZERO improvement over the current version (and as long as it doesn't make it WORSE), That is totally worth it for the mods you'll be able to run. I'm dying for that as the next, major update

Updating to Unity 5 is likely to be the first thing on the agenda post 1.0. Well, after everyone at Squad sleeps for ~72 hours straight then has a few days off after the launch crunch anyway.

[Eric S]

Even if there is ZERO improvement over the current version (and as long as it doesn't make it WORSE), That is totally worth it for the mods you'll be able to run. I'm dying for that as the next, major update

While I'll agree that I want to see a U5 version of KSP, i'm not sure I understand your point. I think you're assuming that U5 has fixed win64 sufficiently that Squad can offer a Win64 version of KSP again. I suspect that you're right, but it isn't a given, and probably won't be as necessary given the fixes coming in KSP 1.0.

[Instresu]

Sorry for bumbing an old thread, but as we all know, KSP is still running using Unity 4. Will Squad port KSP to Unity now when the stable version is out in a near future? As you all know, a stable 64 version for Windows users is the ultimate wish of KSP players. Single-threading and a RAM limit is a pain in the a-s-s for modders. As much as I love KSP, I also hate it because of this reason.

[NoMrBond]

Sorry for bumbing an old thread, but as we all know, KSP is still running using Unity 4. Will Squad port KSP to Unity now when the stable version is out in a near future? As you all know, a stable 64 version for Windows users is the ultimate wish of KSP players. Single-threading and a RAM limit is a pain in the a-s-s for modders. As much as I love KSP, I also hate it because of this reason.

As above ^ Updating to Unity 5 is given as a high priority.

We'll likely see a 1.0.1 hotfix patch for any immediate issues first, followed by a 1.1 update for features which were intended for 1.0 but were not be ready before Squad moves on to the Unity 5 update though.

[Instresu]

As above ^ Updating to Unity 5 is given as a high priority.

We'll likely see a 1.0.1 hotfix patch for any immediate issues first, followed by a 1.1 update for features which were intended for 1.0 but were not be ready before Squad moves on to the Unity 5 update though.

You think we'll see a few updates before Squad seriously begins to look at Unity 5?

[NoMrBond]

You think we'll see a few updates before Squad seriously begins to look at Unity 5?

Yeah, there is already a post about a 1.0.1 hotfix patch which we can expect soon, and before 1.0 came out Maxmaps said that features which they wanted to put in 1.0 but didn't have time for would arrive in a subsequent patch (like the delta-v readout for the VAB/SPH and engineers being able to supply the same for craft in flight).

I imagine they'll want issues addressed to their satisfaction and the game will be in good shape before they start working on the Unity 5 update as that may take quite a while

[Eric S]

You think we'll see a few updates before Squad seriously begins to look at Unity 5?

Depends on your definition. The devs have announced that they're working on 1.0.1, which as a patch update number means that they're not looking at adding features, just fixing a few things that need hotfixes and maybe a few tweaks.

After that, I'm not sure if Squad would want to do a 1.1 that is just U5, that is just a regular update (features intended for 1.0 plus anything else they decide to fit in), or if they'd do both in one update. The last time we had a major Unity update, it was practically an update dedicated to just the Unity update but not entirely so, so I think the likelyhood of the third option would depend on just how many features the devs intended for 1.0 that got pushed back. The more that got pushed back, the less likely they are to combine both those features and U5 into a single update.

This is all assuming that by seriously looking at Unity 5, you mean an actual intended-for-customers dev cycle. They've already done an in-house Unity 5 test. They're quite serious about Unity 5, there was just no way to work it into the 1.0 development cycle.

Long story short, I don't know if they're going to give U5 or the missed 1.0 features priority. We're definitely getting a hotfix patch. I'd be surprised if they did much more than these two things before diving into U5.

Edit: So what I'm saying is that if you don't count the hotfixes as an update, then I don't think we'll see "a few updates" before we see an update with U5, unless they hit a roadblock with U5, which is possible. The Beseige devs tried to get U5 working for Beseige and they weren't able to get it working smoothly enough yet from what I've heard, and Beseige is probably the closest game to KSP in the kinds of Unity features it uses.

Edited April 28, 2015 by Eric S

[Wolfox]

"NavMesh data for non-carved regions takes ~2x less memory now.

HeightMeshes bake faster, work faster at runtime, and use ~35% less memory."

I believe that features mentioned above means that we will get significant RAM usage boost even if 64-bit won´t be a thing. However, if combined with 64-bit, it looks like virtually unlimited modability avaits us! (Okay, except mods conflicting between themselves)

Right?

[NoMrBond]

There are multiple Unity 5 games with working x64-win implementations now, so hopefully that bodes well for x64 KSP in the future (under Windows anyway).

As for other advantages from migrating from Unity-4 to 5, we don't know, savings in one area might be countered by additional requirements in another (i.e. the physics area might become more efficient but the PBR/shaders in the graphics system might end up taking up more memory). Even if they (Unity Technologies) just fixed their DX9 CPU texture mirroring bug the savings would be significant.

Going by Maxmaps tweets we can expect at least one more 1.0.x hotfix/patch so the game will be in a (by their own judgement) satisfactory state while they confront the possibly long haul task of migrating KSP over. Later on the Squadcast he said that Unity 5 tests are looking promising although they will have to remake the entire UI (without any elaboration), hopefully the now built in UI tools which were not previously available will make reimplementing this less of a chore.

Hopefully we'll start getting news about this with this weeks DevNotes now that everyone is back home and on the case

[Friedrich Nietzsche]

Unity 5 paired with KSP would force me to spill tears of joy and to buy a second copy of the game, just to reward Squad

[NoMrBond]

Unity 5 paired with KSP would force me to spill tears of joy and to buy a second copy of the game, just to reward Squad

Judging by today's DevNotes, you should prepare your wallet then

[Climberfx]

I will prepare mine too. Buy a second copy for the same reason as NoMrBond that i will gift some friend of mine.

Unity 5 64 bits on OSX running 100%. Today even the ps3 joystick won't work anymore on 1.0.2.

[Beduino]

"NavMesh data for non-carved regions takes ~2x less memory now.

HeightMeshes bake faster, work faster at runtime, and use ~35% less memory."

I believe that features mentioned above means that we will get significant RAM usage boost even if 64-bit won´t be a thing. However, if combined with 64-bit, it looks like virtually unlimited modability avaits us! (Okay, except mods conflicting between themselves)

Right?

NavMesh is used in AI, not used in KSP.

HeightMeshes probably is unity stock terrain system, also not used in KSP.

So yeah you got it wrong.

- - - Updated - - -

There are multiple Unity 5 games with working x64-win implementations now, so hopefully that bodes well for x64 KSP in the future (under Windows anyway).

As for other advantages from migrating from Unity-4 to 5, we don't know, savings in one area might be countered by additional requirements in another (i.e. the physics area might become more efficient but the PBR/shaders in the graphics system might end up taking up more memory). Even if they (Unity Technologies) just fixed their DX9 CPU texture mirroring bug the savings would be significant.

Going by Maxmaps tweets we can expect at least one more 1.0.x hotfix/patch so the game will be in a (by their own judgement) satisfactory state while they confront the possibly long haul task of migrating KSP over. Later on the Squadcast he said that Unity 5 tests are looking promising although they will have to remake the entire UI (without any elaboration), hopefully the now built in UI tools which were not previously available will make reimplementing this less of a chore.

Hopefully we'll start getting news about this with this weeks DevNotes now that everyone is back home and on the case

Dude i think they should totally ditch the old shaders (which were reported broken anyway in the last devnote) for the new unity PBR standard shader, it looks awesome and it's easier to use.