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

[ratchet freak]

in a stepped physics model if you apply a force F for T seconds to an object with mass M then you should get accelerated by F*T/M, this is a perfectly normal approximation

you need to constantly apply the force across multiple frames to get the smooth acceleration

[Red Iron Crown]

in a stepped physics model if you apply a force F for T seconds to an object with mass M then you should get accelerated by F*T/M, this is a perfectly normal approximation

you need to constantly apply the force across multiple frames to get the smooth acceleration

If you think about it, there's no other way it could work. Computers by nature are discrete and stepwise, they can only approximate continuity by taking finer and finer steps (i.e. make T as small as possible).

[Padishar]

Err, I'm not sure you understand the physical principles involved, acceleration is exactly proportional to the force/mass ratio and the amount the velocity changes depends on how long the acceleration is applied. Surely, when you apply a force to an object in Unity, it is only applied for a single physics time-step (frame) so for a force F (a vector) applied to an object with mass m you get:

a = (1/m) * F (a is a vector)

vnew = vold + a * timestep

So, you are trying to claim that your description implies something bad about Unity physics but it does not.

Edit: double ninja'd due to taking too long trying not to sound patronising...

[p1t1o]

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

Not for nothing, but my EVA Kerbs accelerate nice and smooth just fine...

And whether Unity applies a speed or an acceleration is merely a case of semantics.

[Ricardo79]

I know not this is the actual likings from the author of this thread...

Altough I very very much like the idea of multithreading phisics. I Understand that is not possible right now.

But if functions (mods actualy) can make changes on ships not active like kill kerbals because of hunger, or EVEN BLOW up ships because of the overheating by the sun...

So Maybe and maybe there is a way for "adhoc" style multithreaded maneuer node execution possibility. with reduced (or no phisics involved at all).

How? Think about hyperedit. so If I set up a maneuver node to do an orbit. and switch vessel. the "old"/"set up" one will know how much delta-v Needed even at node creation it should check for "thing in the way and such", so if it could make the burn. just "hyperedit" it into the given orbit with the amount of consumed resources gone. That's it.

Okey this is not a problemsolving for docking autopiloting it. but for every hours task it should be ok. Even holding heading and spead... with a known starting point and time, speed and heading There is no need for phisics to know where that something is right now.

Before accusing me of lack of phisics therefore maybe "teleporting" inside things... Yes that is a possibility. but think about asteroids/mün returning ships timewarping through kerbin... not so realistic... but works fine And it is basicaly a game right?

I do like the idea on the modding side Too. generators/collectors/minning machinery/orbitalconstruction with timeneeded to finish the craft can do their job when not active the ship itself. Altough these features should be stock also...

Even at least a minimal life support with achievable self sustainability.

I don't know what am I talking right now on the programming side, but I use a good game with many of the "must be stock kind" of mod so this is a superb game. and all of the above mentioned feature including "false multithreading" can be achieved/already achieved in a mod or in the stock game.

So it is not a unity limitation stuff... and I think more gamer of this game could say this is true and a must have feature

[NoMrBond]

Unity 5 (which is thread safe, has a multi-threaded job scheduler and PhysX 3.3 (also multi-threaded)) is already in release candidates, development effort would probably be better spent porting KSP up to 5 rather than spend time LOOM'ing or otherwise working threading optimisation into the current Unity 4 project

Maxmaps described adopting Unity5 as a high priority, so this decision about what to allocate development resources to (and when) has likely been made already

[Ricardo79]

unity 5 (which is thread safe, has a multi-threaded job scheduler and physx 3.3 (also multi-threaded)) is already in release candidates, development effort would probably be better spent porting ksp up to 5 rather than spend time loom'ing or otherwise working threading optimisation into the current unity 4 project

maxmaps described adopting unity5 as a high priority, so this decision about what to allocate development resources to (and when) has likely been made already

sweet

[sal_vager]

Don't get your hopes up guys...

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

And Loom doesn't look so great either.

Disclaimer: 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.