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

[griffman99h]

I was just doing a little research on the multithreading problem with the Unity engine and I came across this item in the Unity asset store:

LOOM

https://www.assetstore.unity3d.com/#/content/7285

youtube demo:

API doc:

http://www.frankfortsoftware.com/LOOM/Documentation/

has anyone on the Squad looked at this? not sure if its helpful or not. but might be worth a look.

[kustus]

bump!

I've been reading about this stuff and it seems that multithreading will not be a simple walk in the park patch. I'm guessing they have to rewrite big parts of the core KSP to adapt it into LOOM.

but it could be worth it and I hope they do. :D

[Brabbit1987]

I think it would be nice to give it a shot at some point, most certainly would be worth it in my opinion.

[Winter Man]

Considering the price, that'd make a pretty awesome .22 or .23 update.

[Rocketeer Hopeful]

Awesome, awesome, awesome. It may be a while from now, but having this would help so much.

[DaRocketCat]

Really cheap too.

[griffman99h]

Really cheap too.

I have to wonder about that. I'm not familiar with how the asset store works. is it a one time fee or is there licensing involved in including it in the game code....

for the price I'm tempted to get it myself and seeing about getting the KSP sdk or earlier version of the source, improve my coding skills a bit more.

[MSD]

Darn.. 30 bucks ?

[stupid_chris]

Can we get the devs attention on this. Really, we need to know if this could work with KSP. Man that would be insane. 64bit support would be the last thing we need by then.

[eRe4s3r]

Just adding my "wow this is amazing" here. Any opinion from devs? The big question would be if this would actually work correctly with a (considerably larger than normal) project like KSP. Because if it does.. KSP needs this. Asap. I would even pay extra money to get multi-threading in my KSP!

[MalfunctionM1Ke]

I know a little too less about the Unity Engine and how KSP is coded/written to push the devs to make any steps into this direction.

Nevertheless, finding a solution for stuttering spacestations or low FPS Rocket Ascents have to be made sooner or later.

Anyways, I know this game is an Alpha-Version and right know I am pretty satisfied with the firstlooks on V0.21.

[skyace65]

Considering the price, that'd make a pretty awesome .22 or .23 update.

with some of the optimizations in .21 that are coming I think multi-treading could wait a little longer. but yeah it would be great to have.

[allmappedout]

If it works as promised, it seems to be a no-brainer, but my cynic says that if it's as simple as writing an API for it, why haven't Unity done it yet?

[bowdlerize]

Multi-threading and 64-bit would be a nice 1.1 update. It's still way to early in development to worry about this kind on thing. The code hasn't even been optimized yet.

[NeilC]

If it works as promised, it seems to be a no-brainer, but my cynic says that if it's as simple as writing an API for it, why haven't Unity done it yet?

Probably because writing a good API is hard. Especially ones that are multithreaded, stable, easy to use, easy to debug, extensible, and offer full support for PC, Mac, Webplayer, iOS and Android. Unity's got a big community, they leverage their asset store for lots of functionality that isn't baked-in.

Multi-threading and 64-bit would be a nice 1.1 update. It's still way to early in development to worry about this kind on thing. The code hasn't even been optimized yet.

I disagree. The rigid-body physics solver is very CPU bound at the moment, even for reasonably-sized (~100 part) craft on reasonable hardware (3-year old Core2 laptops). 1.0 games should be feature-complete, and multithreading is a significant feature that requires many changes to how the code works. Removing a bottleneck as large as KSP's current physics solver should be handled early as it's an architectural change to a core component of the game, not merely an optimization pass on some functions.

I haven't looked over LOOM extensively, or watched the video (at work, not lunchtime yet). Does anyone know if it can multi-thread physX code? The physics solver code causing KSPs slowdowns isn't written by the devs so unless LOOM can get around the single-threaded physX restriction, it's not going to benefit KSP much.

[The-Bean]

Bump so hopefully a dev' can see. Multithreading would be very welcome.

[Neomatt]

I haven't looked over LOOM extensively, or watched the video (at work, not lunchtime yet). Does anyone know if it can multi-thread physX code? The physics solver code causing KSPs slowdowns isn't written by the devs so unless LOOM can get around the single-threaded physX restriction, it's not going to benefit KSP much.

Yeah, same question here. Multi-threading is often seen as a fix-all-issues thing, but if physics calculations cannot be multi-threaded due to PhysX or other factors, the advantages would be pretty low.

edit: checking the API quickly, it does look like a very good but basic implementation of multi-threading, for example computing multiple paths for enemies at the same time.

But now, that got me thinking: can physics calculations be "splitted" into sub-computations? If yes, LOOM helps a lot (set packs of 10-50 parts in each thread, get the results). If not...

Edited July 25, 2013 by Neomatt

[DannySwish]

It would be great if I could put some of those three extra cores I have sitting around to work.

[thermobaric]

im curious what the devs think of this

[NeilC]

<...>But now, that got me thinking: can physics calculations be "splitted" into sub-computations? If yes, LOOM helps a lot (set packs of 10-50 parts in each thread, get the results). If not...

Yes that's the issue, and unfortunately I think the answer is no.

Now that I've seen the video and given a brief look at the API, I'm pretty sure all LOOM does is allow threadsafe read/write of Unity objects. This is very useful if you're writing your own CPU-intensive worker threads, as he is doing with the flocking demo. He is writing all the crunch-heavy stuff and just needs to interact with Unity to get it drawn.

As I understand it, KSP uses the RigidBody solver internal to Unity, which uses PhysX under the hood. The crunch-heavy code is written, maintained, and controlled by Unity, and due to limitations in their PhysX version they cannot multithread it. Totally out of KSP's hands, and LOOM would not change that.

I would love to hear a Dev confirm/deny/elaborate on this.

[DaRocketCat]

bump so a dev could comment.

[Scoundrel]

Dev's currently won't comment on future possibilities except through PR channels, though NeilC is quite correct on PhysX and Squad's position on the subject. If you desire confirmation, watch

. Feel free to fill the thread full of bump posts though. I'm curious as to how many can be posted before a mod locks the thread.

[Technical Ben]

Then we need to bug the makers of PhysX to make an API for multithreading in unity.

[carde]

Then we need to bug the makers of PhysX to make an API for multithreading in unity.

PhysX is fully multithreaded, and even works on GPU:s (for about a 10-100x performance increase using low-level cards, more with high-end (eg, titan class) cards).

However, unity has choosen to remain with a very old version. And they modified it so it only uses one thread (even that version of the original PhysX SDK was actually multi-threaded, and also uses the GPU if possible)

[oggylt]

this thread gave me some hope, and yet I am realist so 'll not give too much for it.