Multithreading in Unity..... Loom available in asset store. thoughts?

[LordOfTheOrbits]

But doesen't PhysX supporting multi-threading? YES it IS!

However my KSP uses only 1 core for sure, the other three core's potential aren't utilized at all! :

New versions of PhysX support multi-threading, however an older version which doesn't support it yet is used in unity.

[Red Iron Crown]

The older version of PhysX used in Unity is single-threaded only. It uses this version, as I understand, to maintain compatibility across platforms.

If you want a more modern version of PhysX in KSP, go complain on the Unity forums. It's their software that needs the work; Squad is limited by the game engine in this case.

[CsendesMark]

The older version of PhysX used in Unity is single-threaded only. It uses this version, as I understand, to maintain compatibility across platforms.

If you want a more modern version of PhysX in KSP, go complain on the Unity forums. It's their software that needs the work; Squad is limited by the game engine in this case.

I understand that, in this case, I'm not complaining over the need of 64bit unity option either.

But how old is that old, and does unity bother to have a newer version of PhysX implemented?

[manuelasa1999]

I really that an optimization update what supports multi-threaded physics and better frame rate is more important than new solar systems or multiplayer. We need a stable game before adding lots of new features that maybe will slow the FPS rate.

Sorry for my English I´m from Spain

[WarStalkeR]

Unity 5.0 will have PhysX 3.3, which uses multithreading internally.

It seems switching to the Unity 5 will solve this problem: http://feedback.unity3d.com/suggestions/multithreaded-physx

[En_Dotter]

I started playing this game again and i still love it so much. But, there is that ever repeating problem... If you wanna make something in space then you will have a lot of FPS drop problems. Please implement multithreading asap. I dont know how you intend to do a stable multiplayer if you dont make the game use all the available resources current PC-s have (yes im a PC user, but this applies to any other stuff).

[Red Iron Crown]

Squad doesn't control how well the Unity engine multithreads, that's on the Unity developers. Telling Squad to fix it is like telling a cab driver to fix the potholes in the road: It's not their job, and they're just as frustrated by it as you.

[Rakaydos]

I'm given to understand the problem with multithreading KSP is that physics doesnt multithread well.

However, does anyone know what the problems would be to run the active vessel on one core, and any inactive vessels in load range on another core, physwarping to keep up with the active vessel?

It wouldnt help with large vessels, but it might make rendevous with large space stations easier.

[phoenix_ca]

Physics can be multithreaded just fine. PhysX 3 has done that for a looooong time now.

[Northstar1989]

It seems switching to the Unity 5 will solve this problem: http://feedback.unity3d.com/suggestions/multithreaded-physx

So, does anybody know if there are any plans for KSP to switch to Unity 5?

Also... it would be nice if the devs could directly respond to this issue. Performance is one of the biggest problems for KSP- I shouldn't get the kind of lag I do with a 3 year old dual-core laptop... KSP's not even using one of the cores just annoys me, considering how many much older games do...

Regards,

Northstar

[Rowsdower]

So, does anybody know if there are any plans for KSP to switch to Unity 5?

Also... it would be nice if the devs could directly respond to this issue. Performance is one of the biggest problems for KSP- I shouldn't get the kind of lag I do with a 3 year old dual-core laptop... KSP's not even using one of the cores just annoys me, considering how many much older games do...

Regards,

Northstar

There are no plans to switch to Unity 5 at this time, but the devs are very excited for what it brings.

[Xhotono]

I hope they somehow fix the issues on performance. I love this game and can't stop playing.

It's a real bummer to me though, to play high end graphics games without Problems on a gaming rig. Then you put Kerbal on, a game with lower end graphics in my oppinion, and you get performance issues?! Most Computers you buy today probably don't even break a sweat with kerbal, even if they aren't ment for gaming. A game in development should utilize the complete performance of actual Hardware/Software and not only use a small portion of it. Well it's still Alpha, so plenty of time to fix this issue, by god i just hope they will.

[WarStalkeR]

I hope they somehow fix the issues on performance. I love this game and can't stop playing.

Main issue in KSP's case is non-multithreaded physics, because even Unity v4 uses very old version of PhysX. I can feel it even on my beast of PC, which has Core i7 3930K, two GTX 780 and 32GB ram. While Unity 5 actually updates a lot of stuff they've been using till now, including latest PhysX, which supports now multiple processors, multiple cores and multiple threads by default.

There are no plans to switch to Unity 5 at this time, but the devs are very excited for what it brings.

And Unity 5 brings a lots of stuff. PhysX and IL2CPP is just two things out of everything planned by Unity Team for Unity 5. I believe Unity 5 has required capability to greatly reduce time developers need to optimize game, since lots of applications will be up-to-date by default.

[WarStalkeR]

Unity 5 beta is here, go for it devs, start playing with it! And fall in love with it to switch KSP's engine from Unity 4 to Unity 5

P.S. I won't bother playing KSP when just 3000+ parts station lags horribly, while my PC (Core i7 3930 + 32 GB RAM + 2x GTX 780) has enough processing power, to work with millions of objects.

[Xaiier]

Unity 5 beta is here, go for it devs, start playing with it! And fall in love with it to switch KSP's engine from Unity 4 to Unity 5

P.S. I won't bother playing KSP when just 3000+ parts station lags horribly, while my PC (Core i7 3930 + 32 GB RAM + 2x GTX 780) has enough processing power, to work with millions of objects.

They have already said that they would adopt U5 once it comes out.

Also, do not overestimate the benefits it will provide. Processing power & multithreading will not be a magical solution to lag problems.

[Bilfr3d]

They have already said that they would adopt U5 once it comes out.

Also, do not overestimate the benefits it will provide. Processing power & multithreading will not be a magical solution to lag problems.

Depending on how they code to work with multithreading, the performance and physics lag may even become worse. I imagine if they do run into that problem they won't actually release it until they are able to remove said multithreading bottle-neck, although a bottle-neck on multithreading is not that usual. It all lies down to how the devs code the multithreading physics.

[xtoro]

Why is thread back?....

Just read the Loom disclaimer on the link from the first post : "Loom does not 'magically' enhance performance. Implementing multithreading takes time and efford. Unity's tools like physics, AI, networking, audio, etc will not directly benefit from this toolkit. Unity engine does remain thread-unsafe, therefore using Loom to speed up loading times of scenes and resources will not result in beter performance."

And yes, they spelled "effort" like "efford" (I just copied and pasted).

And no, multithreading will not help. It has been discussed for several pages now... Why hasn't this thread been locked yet?

[p1t1o]

Unity 5 beta is here, go for it devs, start playing with it! And fall in love with it to switch KSP's engine from Unity 4 to Unity 5

P.S. I won't bother playing KSP when just 3000+ parts station lags horribly, while my PC (Core i7 3930 + 32 GB RAM + 2x GTX 780) has enough processing power, to work with millions of objects.

3000 parts! Dude, that is pretty huge...do you have the texture settings way down?

Anyhoo, does it not work something like this: Every part interacts with every other part on the ship, so the 100th part you add increases the stress on the system by 100x (or more, or less, depending on the exact nature of the software?) the stress of part #1. So processing millions of parts would take an extreme amount of system power?

Im only saying that because my system is comparable to yours but my part limit is more like 300 than 3000. I do have like 150 mods installed and all the settings on max however.

This is all just guesswork, the intricacies of software design are not my strongpoint.

Edited November 5, 2014 by p1t1o

[Red Iron Crown]

Also, do not overestimate the benefits it will provide. Processing power & multithreading will not be a magical solution to lag problems.

This++. It's not clear that physics on a single tree of constrained rigid bodies is a threadable problem. At best I think we'll get one thread per vessel in the physics bubble.

[Padishar]

This++. It's not clear that physics on a single tree of constrained rigid bodies is a threadable problem. At best I think we'll get one thread per vessel in the physics bubble.

Actually, it is (at least partially) a threadable problem as should be obvious by the fact that it can be run very fast on GPUs with their highly parallel architecture, however I would still advise not expecting too much, especially from a first release. That way, if it does provide a really significant boost, then you will have something to be really happy about (i.e. pessimists are not usually disappointed).

[Red Iron Crown]

Actually, it is (at least partially) a threadable problem as should be obvious by the fact that it can be run very fast on GPUs with their highly parallel architecture, however I would still advise not expecting too much, especially from a first release. That way, if it does provide a really significant boost, then you will have something to be really happy about (i.e. pessimists are not usually disappointed).

My reading on this topic indicates that a single tree is not easily threadable. The higher performing GPU-accelerated physics are different types of problems.

I'd love to be wrong about this, though. (Entirely possible, I'm neither a computer scientist nor a mathematician.)

[Tuareg]

the problem with multithreading physics is not that squad couldnt write a multithreading api but that the physics is fully INSIDE the engine. its not something they have any control over it. they could multithread their own code, their own calculations (even that would be good but thats tiny little compared to the calculations done by the engine).

if you try to imagine a black box you are pouring data into and it will do something with it, the physics engine is the black box and your code is the one pouring the data into. you can optimize/multithread your code, but you cant change what is inside the box...

the biggest problem is that this actual black box is made to simulate physics ON THE SCREEN and it isn't up to simulate real physics or to make realistic physics calculations. It's just to make it "looks like". building a physics simulation on something like this is silly.

There would be 2 ways

a: write their own physics (it sounds horrible but it actually isn't) but knowing squads drunken garage developer style it will never happen

b: integrate a modelling engine used in engineering, we all know it will also not happen

So whats left is cheating wherever they will need, and they will need a lot...

One of the biggest crap in KSP physics (both unity's and squad's fault):

unity physics engine, when you apply a force to an object, in reality apply a SPEED to the object calculated from the weight and the force but missing the time value. there is no acceleration over time just momentary speed, however we all know in reality it doesnt work like this.

now if you launch a rocket with solidboosters around it has x force, they calculate its speed of it but when the solidbooster gets empty, your SPEED drops because they calculate the new speed from the new force / weight, however it shouldnt. only the acceleration should decrease, not the speed (if the speed decrease it would mean that your rocket cant lift off without the solidboosters).

Edited November 5, 2014 by Tuareg

[Xaiier]

As insightful the rest of your post is...

One of the biggest crap in KSP physics (both unity's and squad's fault):

unity physics engine, when you apply a force to an object, in reality apply a SPEED to the object calculated from the weight and the force but missing the time value. there is no acceleration over time just momentary speed, however we all know in reality it doesnt work like this.

now if you launch a rocket with solidboosters around it has x force, they calculate its speed of it but when the solidbooster gets empty, your SPEED drops because they calculate the new speed from the new force / weight, however it shouldnt. only the acceleration should decrease, not the speed (if the speed decrease it would mean that your rocket cant lift off without the solidboosters).

...this just doesn't seem right. I've never seen reference to anything like this within Unity. Do you have a source?

[xtoro]

Multithreading could be used for physics calculations in KSP, but not using Unity. At least not now, and likely not in the near future.

[Tuareg]

As insightful the rest of your post is...

...this just doesn't seem right. I've never seen reference to anything like this within Unity. Do you have a source?

no need of any reference. if you have unitiy engine, place a model into the scene, apply a force. it will not accelerate but get a constant speed and start moving with that speed until there is an other force applied to it...

best to see it in KSP is the crappy eva. did u ever wonder how is that pressing any movement button will launch poor kerbal into the deepspace instead of slowly accelerating against its mass? thats why. they apply a force and it doesnt cause acceleration but apply a speed based on the force/mass ratio