[Administrator]

George, I added some new members in v1.0.3 which I just submitted that should help with this. When it goes live, check out:

• ConcurrentBehaviour.SharedInstance
• UnityFiberScheduler.SharedInstance
• UnityTaskScheduler
• UnityTaskFactory

Thanks for the feedback!

[Administrator]

Hi George, I think this ought to work even in the editor, just be careful to manage your instances.

static MonoBehaviour CreateBehaviour()
{
  GameObject go = new GameObject("EditorBehaviour");
  GameObject.DontDestroyOnLoad(go);
  go.hideFlags = HideFlags.HideAndDontSave;
  return go.AddComponent<MonoBehaviour>();
}

[Administrator]

Indeed, there are networking and AI scenarios where this approach adds value compared to the built-in coroutine support in Unity. It’s also really useful for portable libraries that expose an async interface. We have some other projects in the works that use the framework and will demonstrate this, but I agree with you it would be good to have more online content showing this in the interim. Thanks again for the feedback.

[Administrator]

Thanks for the feedback!

If you haven’t used the Task Parallel Library before from .NET, I recommend this series here on CodeProject which has great examples of what you can do with the library:

http://www.codeproject.com/Articles/152765/Task-Parallel-Library-1-of-n

Beyond that foundation, the Concurrency Kit adds micro-threading support, a Unity coroutine task scheduler, and MonoBehaviour extensions which you can read a little more about here:

http://spicypixel.com/static/developer/concurrency-kit/api-reference/?topic=html/ecb518db-2bfe-4374-a299-a309c51973c4.htm

http://spicypixel.com/static/developer/concurrency-kit/api-reference/?topic=html/ecb518db-2bfe-4374-a299-a309c51973c5.htm

http://spicypixel.com/static/developer/concurrency-kit/api-reference/?topic=html/2a81f423-ee99-4745-a514-3db4a67dbb00.htm

Let me know if there is a specific scenario you have in mind that you would like to see more examples for and I’ll see if we can add some content on that in the future.

[Administrator]

You are correct, access to most Unity methods must be on the main Unity thread. This is typical of many UI frameworks as well. However, just like standard UI frameworks, it’s entirely possible to run logic off thread and at a different frequency, then callback to the main thread when the results are ready. There are different ways to set this up and it really depends on what type of logic you would like to offload or wait for (pathfinding, physics, etc.).

Ultimately it boils down to picking which scheduler you want the calls to run on. So you could do something like this:

void Start()
{
    // Grab a snapshot of the current transform and state
    var physicsState = ReadFromRigidbody();
    Task.Factory.StartNew(() => ProcessOnAnotherCore(physicsState)) // thread pool
	.ContinueWith((t) => ApplyOnUnityThread(physicsState), taskScheduler); // Unity thread
}

When you’re interacting with the Unity thread like this you will need to manage marshaling data back and forth and there are various patterns for that such as in the above example. You could have Unity push the data to another thread in Update() or you could pull the latest from another thread at whatever frequency you need it:

void ThreadPoolThread()
{
    PhysicsState physicsState;
    taskFactory.StartNew(() => CopyFromUnity(physicsState)).Wait();
    DoSomethingWithCurrentState(physicsState);
    taskFactory.StartNew(() => CopyToUnity(physicsState));
}

Longer running operations or those that run more infrequently than Unity’s Update() lend themselves better to offloading to another thread. If you’re interacting with Unity’s physics system you’ll want to take into account that the main thread can update transform data while you’re working with the copy.

I hope that explanation helps some, and please let me know if I can provide any more info.

[Author]

Posts