Is a robust tool enabling the user to create, manage and manipulate multiple threads on the fly. It also give the user the ability to create “coroutine-like” threads that will loop and wait with given instructions and parameters.
This asset can easily manipulate the scene from data managed on a thread, something that cannot be done with a traditional thread.
If the detailed messaged are to much, they can be disabled.
Key Features:
ThreadPool usages means no overhead from creating new threads.
One line of code to pass a function (or chain of functions) to a thread.
One line of code to start a coroutine.
Thread naming.
Event firing on thread finish.
Ability to call specified functions on the main thread whenever another thread finishes, with full data capturing, useful for manipulating the game scene.
Full function parameter options.
Thread return values.
Coroutine thread return values.
Pause, or unpause, threads.
Pause threads for a certain time frame or until a specified thread has finished.
Mimic Update() or FixedUpdate() on a thread.
Ability to send a signal to a thread, telling it to stop.
Full exception handling with detailed log messages.
The package includes a Quick Start guide, simple offline summary documentation and an example script to reproduce the threads shown in the screenshot above.
Could you please tell me, what the advantage of this solution over using raw .NET Thread and ThreadPool constructions ? Is that, what you have created kind of wrapper for convenient usage inside Unity3D ?
Have you (somehow) managed to operate on objects from UnityEngine in non-main threads ?
As far as I know it is impossible to change GameObjects directly from a thread. This is a thread wrapper that creates the illusion of changing a GameObject from a thread by doing all the calculations you need on a real thread then passing that back to the main thread to directly change the GameObject from the main Unity thread. In the video at the top of the page I show how to do this by moving a cube to random locations generated on a thread. If you need a lot of processing power to directly manipulate the GameObject or you only need one or two threads in your game then this product probably isn’t for you. Powerful Threading was created to allow running many threads concurrently and to have ways to easily signal and manipulate them without having to think to hard about whats happening. You can read what some of the function do here, to get a better idea of what is possible.
Could this be fed to your Thread Manager -
AsyncOperation asyncOp = NavMeshBuilder.UpdateNavMeshDataAsync(data, settings, sources, terrainData.bounds);
The function can be passed into the manager but the asyncOp wont be updated until the operation is finished.
You can update it with a callback function or an EventHandler
Hi, do you think your solution could be used to execute WWW procedures in background, like loading huge textures in a secondary thread, so avoiding the typical hiccups/breaks in the main thread? I mean operations like:
I watched your overview videos and would have a go with your plugin but still can’t figure out how I could mix the threaded approach with the usual coroutine approach needed by the WWW class.
For example, how could I use your plugin to rewrite the following code, so to have a threaded (and hiccup-free) texture loading?
public Material m_material;
public string m_url;
void Start()
{
StartCoroutine(GetTexture(m_url, m_material));
}
IEnumerator GetTexture(string url, Material mat)
{
using (WWW www = new WWW(url))
{
yield return www;
www.LoadImageIntoTexture((Texture2D)mat.mainTexture);
www.Dispose();
}
}
Anythign needing yield wont work inside the current coroutines. Im thinking about implementing it but it will take some time. By the definition of coroutine, yes this package does implement threaded coroutines, however using yield like the above example wont do anything.For now you will have to call them regularly.
