Unity 5 [Is now available]

[NoMrBond]

Or you know they could have moved over to a Bullet based system which you know accelerates on all GPU's...

Unity 4 uses PhysX 2.8.x, nVidia cards however do not get a physics speedup because Unity only implements the CPU part and not the CUDA/GPGPU part (otherwise KSP would already support amazingly huge ships for nVidia owners)

Since the CPU physics on the latest PhysX are just as good as the CPU acceleration on BULLET, there isn't any advantage

If Unity used the OpenCL accelerated branch of BULLET, then nVidia users would be getting the shortish-end of the stick (not as bad, since nVidia at least nominally supports OpenCL), but the migration between Unity based on PhysX to a prospective Unity based on BULLET (or Havok, ODE etc) would be likely be horrendous. A major concern for Unity who probably wants to make the migration as easy as possible to promote upgrading.

I think we have a much better chance of seeing some kind of OpenCL support with PhysX (with the goal of also supporting Phones/WiiU/PS4/XB1), rather than a switch of Unity physics platform

[Payload]

Not sure what that video was advertising but terrible FPS in shooter games that looked like they where made a decade ago. Fancy audio mixer. Too bad that doesn't fix the problem of literally every other PC engine being ten times better in terms of speed and quality.

[Nemrav]

Not sure what that video was advertising but terrible FPS in shooter games that looked like they where made a decade ago. Fancy audio mixer. Too bad that doesn't fix the problem of literally every other PC engine being ten times better in terms of speed and quality.

You simply haven't heard of the open source ones have you ?.......

[marach]

Ubut the migration between Unity based on PhysX to a prospective Unity based on BULLET (or Havok, ODE etc) would be likely be horrendous.

Not really all you'd need is a translation layer moving physx calls to their equivalent bullet calls (not as hard as it sounds infact many indies using Unity have infact done so in) you might experience some slowdown on certain calls but that would be mitigated by the speedups on practically everything else...

As for full OpenCL PhysX? Already done on consoles, has been since around the time of the recent console launches (well technically about a year before that you know lead time on launch games kinda requires that). When will we see it on PC? Maybe in 3-4 years if NV market share drops enough.

By that I mean NV had to convert it for the consoles since if they wanted devs to use it in games it HAD to be cross platform and reliable, on PC however NV has... shut down 2 projects that created CUDA-APP translation wrappers (allowing physx to run on AMD), and added software blocks to stop you being able to use an NV card in an AMD system for Physx acceleration (officially because they can't "guarantee a certain level of performance" which they don't seem to worry about on their own cards...).

[Technical Ben]

Yeah, AFAIK many single programmers have added customer physics to Unity. It's all a risk/reward or time/costs and benefit/costs balance though. For KSP it may or may not be worth it, it's the Devs who know.

[NoMrBond]

OpenCL has not been done for PhysX on consoles, the PhysX SDK runs on the CPU only with limited DirectCompute support for some features on the XBOne

If nVidia don't implement OpenCL support however, the PhysX middleware will get likely get pushed out by OpenCL solutions which apply right across the range of smartphones, consoles and PC (Windows/Apple/Linux). A big selling point is the ease of parallel development now that the major consoles and PC's are basically the same, and this cuts across that

Why pick PhysX and have your console versions hamstrung by tying up multiple CPU cores full-time for limited and sub-par physics while also only catering to PC users with nVidia hardware when you could babelF/havok/naturalmotion and have it even work all the way through the range right down to your smartphone version?

But yes, money talks, so there would have to be more gained for them from implementing the feature, than risked (or lost) by the same

Edited March 19, 2014 by NoMrBond

[Sethnizzle]

Any possibility of getting a dev or two to comment on their opinions of Unity 5, what it could mean for KSP, and what the plans are, if any, for upgrading? I'd be interested in reading about their thoughts.

[marach]

Any possibility of getting a dev or two to comment on their opinions of Unity 5, what it could mean for KSP, and what the plans are, if any, for upgrading? I'd be interested in reading about their thoughts.

There's not much to say atm tbh most of the features listed make certain things easier to do and other things a little slicker.

[Juanfro]

Hopefully GDC gives the KSP team a chance to speak with Unity Team

[guest91111]

Shouldn't be any need, really. It's using PhysX 3.3, which should offload physics calculations largely to the graphics card where possible. It'll speed things up immensely... but... it won't do a thing for AMD users like myself, who don't have a PhysX-capable graphics card. It's a shame.

Does this mean for nVidia users with a reasonable GPU (GeForce GTX 460) can run 1 000 parts objects with more than 5-10 fps?

[LethalDose]

Any possibility of getting a dev or two to comment on their opinions of Unity 5, what it could mean for KSP, and what the plans are, if any, for upgrading? I'd be interested in reading about their thoughts.

I wouldn't hold your breath for a dev comment here in the forum. They rarely post here.

You may want to watch their blogs, though, for their thoughts on the matter. If they do decide to change, I suspect it'll be a major decision that will be announced.

[DaRocketCat]

Yeah, the devs almost never post on the forums anymore, but they often mention new versions of Unity and their possible effects in dev blogs.

There was a big buzz back when the devs were upgrading ksp to Unity 4.

[frizzank]

It would be easier to optimize the existing game than it would to make it a 64bit application. The results would be better as well since it would then run on both 32 and 64bit machines.

It is entirely possible (But a lot of work) to get KSP to load assets much more efficiently than it currently does. This is just talking about memory and not the other savings of 64bit operations.

The simplest are optimizations of the current assets (I saw a 12mb single texture in the squad folder the other day), loading of compressed textures (dxt), better loading and unloading of planet textures (Your never going to see 2 planets at the same time why are the all loaded in memory?), level of detail meshes for parts. Im sure there are many more that the developers are working on but these alone would provide a substantial boost to performance on 32 bit machines and are currently possible...

[NoMrBond]

Does this mean for nVidia users with a reasonable GPU (GeForce GTX 460) can run 1 000 parts objects with more than 5-10 fps?

Unfortunately not, Unity only seems to implement the CPU acceleration branch (so far)

That said, the CPU implementation of PhysX 3.3 reported for Unity5 is significantly better than the CPU branch of PhysX 2.8.x in the Unity 4 series

So, as far as PhysX is concerned, 3.2 has an issue with memory usage, 2.8.4 has an issue with performance, I guess the conclusion is clear: switch to 3.3. It’s just better. On average,PhysX 3.3 /PCM is 7X faster than PhysX 2.8.4 and 4.7X faster than Bullet here. That’s quite a lot.

Dig through the whole Coder Corner article for more comparisons, but it seems promising

[Nemrav]

I'm sure there will be a unity 5 update WHEN it comes out... But as far as all these things about off-loading to gpu, for me its a big no-no, doesn't anybody here have a bad enough gpu as it is ? sure for some people but what I would like to do is the inverse, unload gpu stuff to the cpu....

[qromodynmc]

it is too early to excite,but still good news. also i have nvidia gpu,good news indeed..

[_Aramchek_]

Does this mean for nVidia users with a reasonable GPU (GeForce GTX 460) can run 1 000 parts objects with more than 5-10 fps?

Meh, just get any i5 cpu and you've achieved this feat very handily.

[coolitic]

Meh, just get any i5 cpu and you've achieved this feat very handily.

I wish it were that easy. I'm running this game on i7 2630qm.

[DragonShadow]

This announcement has given me hope for KSP-64!

...eventually, haha

[Dunbaratu]

Thankfully, they don't have to. No matter how great the CPU algorithm gets, it will never ever come anywhere near the performance of even a lower grade graphics processor. Physics calculations are very much parallel for the most part, which means that the best* thing you can do is throw massive amounts of stupid, low-performing cores at it. CPUs, on the other hand, feature a very small amount of incredibly sophisticated high-end cores. They're built for the complete opposite kind of code.

I think you're missing a very important point of this though, which is other graphics card companies being able to compete with nVidia. By leaving the algorithm working out in the open in the public CPU, "the GPU" doesn't have to mean just "nVidia's GPU". It means a competitor graphics card maker can implement a driver to get PhysX code to work well on their own GPU. That would be a lot harder if PhysX had been implemented as "use nVidia or it will suck". Your response was written as if nVidia has no need to consider how a competitor might perform with PhysX because their only competition they will ever have will come from the CPU makers. But making a good well working implementation that is graphics-card agnostic opens up the chance for a competitor graphics card to make their own GPU layer for PhysX for their own hardware. That would have been a lot harder had it been implemented in such a way that once a game programmer uses PhysX that guarantees that only the nVidia GPU would be able to implement it well.

Giving it a good CPU-only implementation requires designing it in good GPU-agnositc way that allows the GPU-enabled driver for it to be drop-in replaceable. Which helps any potential competitors in the future and avoids artificial market lock-in.

Which is why I'm glad nVidia is doing it this way. They could have decided to behave more like Microsoft typically does, using their current market dominance to try to ensure eternal future market dominance purely through the need for backward compatibility.

[NoMrBond]

Cripes, five months... oh well

Still relevant I guess, actually something about Unity 5

As long as you've got three quarters of an hour

[NoMrBond]

The UNITE keynote

Short version; Unity 5 beta coming up for people who have pre-ordered (4-8 weeks) @ 1h:29m.

[Azunai]

did SQUAD post something about it already?

If they even want to update to unity 5?

[Kasuha]

It's completely up to devs' decision but I think KSP should wait with integration until Unity 5 is out of beta. KSP has enough of its own bugs.

[RockoDyne]

If they do upgrade, I would expect .26 to be a slow update. Chances are it will probably break more things than it fixes.

Bare in mind, I don't expect 5.0 to have the smoothest launch. They have been digging around in the guts of the engine quite a bit, so I wouldn't be surprised if how things get repacked for launch don't end up exploding. They have been taking QA seriously enough though that it could also be pretty stable.