Is Unity multi-threaded?

Unity asset import is already fully multithreaded using all available cores if the workload can be spread.


As for average user and 32bit: With OSX 10.6 Apple has stopped even offering a 32bit OS.
And if Microsoft hadn't chickened out, AGAIN, Win7 would not have a 32bit version either, as Vista was planned to be the last 32bit OS, the large parts of Windows users either wouldn't be worth supporting (XP and earlier total future refusers) or on 64bit ...

 

Its just that I hate it when I import an fbx with 20+ animations, I have to wait for at least 10 minutes doing nothing.

 

Multithreading won't help there.
It can't be parallelized.

A model taking 10 mins to import on a normal pc is beyond reasonably structured normally, if its about animation then I would highly recommend to go with the @ naming scheme so you can restrict the loading time in the player then too as objects with hundreds of animation frames don't load exactly fast either

 

I have an fbx where generic human animations are stored (stand, walk, run, crouch, jump, attack with one hand weapon, attack two-hand weapon, etc.). The problem is when I edit just one of those animations, Unity has to reimport all of it.

What's this @ naming scheme?

 

The @ naming is Unity's way of letting you break up the animations into individual files while having an automated way of assigning them to the character. You would have one file that's the rigged mesh and bones in a bind/t-pose named say "myChar", then you can have files with just the bones for the animation (or if exporting to FBX just select only the bones not the mesh) for each animation like "myChar@idle", "myChar@walk", "myChar@picknose", etc. When you drop them all into Unity it sees the naming prefix and auto-assigns all the @animationname items to your "myChar" mesh.

I would really recommend going with this method as you won't have the long re-import times when you have to change just one animation, and from my experience having strung together animations that you break apart in Unity through the import settings can have 'issues' with granularity where you have to pad each animations start and end if the poses are too dissimilar otherwise you'll get a frame of halfway between them when you play even though you told Unity the exact frame cut-off/stop or start point.

 

I'd like to return to that. Either I'm confused, or the engine has changed since dreamora wrote that back in 2010, or it's simply not true. I did a small test, similar to the one Eric5h5 did where he called transform.Translate. Mine looks like this:

Code (csharp):

1.     void Start () {
2.         System.Threading.Thread testThread = new System.Threading.Thread(new System.Threading.ThreadStart(test));
3.         testThread.Start();
4.     }
5.  
6.     void test()
7.     {
8.         Vector3 letsRotate = new Vector3(1, 1, 1);
9.         letsRotate = Quaternion.AngleAxis(30, Vector3.up) * letsRotate;
10.         Debug.Log(letsRotate);
11.     }

All the test does is rotate a vector and print it, but it's using Vector3 and Quaternion to do it, and those both reside in UnityEngine. That test runs just fine (on Windows 7 32bit), even the threaded call to Debug.Log actually prints (1.4, 1.0, 0.4) to the console in the editor. Multithreaded code in other parts of my project make pretty extensive use of these, and I've never had a problem with that. Multithreading problems with Unity only seem to appear when you attempt to call functions that manipulate UnityEngine variables and objects that are instantiated on the mainthread, like translating an object or changing a material; those are no-no. But it appears you can instantiate your own UnityEngine objects and use UnityEngine's static functions just fine, as long as you're not touching the mainthread's variables. Similarly, Eric5h5's multithreaded BilinearScale uses Mathf.Floor inside of it and works with instances of the class Color, both of which are also in UnityEngine.

 

I think what he said is generally true, but you're right, generally any basic, independent class is thread safe. This would include the Vector classes, Quaternion, Color, probably Matrix4x4, etc and libraries like Mathf. I've used almost all of these safely in multiple threads.

I've made a couple of examples in this thread and should probably add some more that I've made since. If you feel like it, check out the bottom one called MeshRipples which has a multithreaded mesh manipulation.

http://forum.unity3d.com/threads/90676-Multithreading-Solutions

 

Actually I should have been more specific back then, cause the limitation is simpler (but for beginners its easier to shy them away from doing stupid things and blaming it on Unity unhappily if its written like that)

The limitation is: Anything that extends from UnityEngine.Object is not to be touched in threads.
These objects are managed actively by the UnityEngine at runtime which is among the reasons on why its impossible to "shield" them in any form and why you need a communcation queue from thread <-> static manager <-> unityengine.object objects


Mathf is a namespace that does not use the UnityEngine at all it just resides within it for example but actually its a wrapper either around true .NET stuff (System.Math) or around elemental core classes of .NET (numerics) which are all thread safe.

Matrix, Vector etc while residing inside the UnityEngine namespace, are no unity objects either, actually they are not even objects, they are structs.

 

Ah, that clarifies things for me at least. Thanks for explaining further.

 

(removed my pointless question)

 

This is a very interesting topic, but the last post was over two years ago. Rather than revive a dead thread, I've started a new one with updated information for Unity 4 and coming releases:

http://forum.unity3d.com/threads/214138-Is-Unity-Multithreaded