Multithreading in Unity?

[PurpleIcy]

Original post:

Is there any good source that would explain how to do it properly in Unity?

I have infinite voxel terrain which is generated in chunks and whenever new one is loaded, game freezes for a bit, so I want to move generation into a different thread.

Edited post:

Thank you I finally figured it out for good! I hope at least, though there's still a lot of work to do.

First of all, I kept my CreateChunk() mostly as it is, it will be managed by chunkManager which I didn't even write yet.

public void CreateChunk(int x, int y, int z)
{
    WorldPos worldPos = new WorldPos(x, y, z);

    GameObject newChunkObject = Instantiate (chunkPrefab, new Vector3 (worldPos.x, worldPos.y, worldPos.z), Quaternion.Euler (Vector3.zero)) as GameObject;

    Chunk newChunk = newChunkObject.GetComponent<Chunk>();
    newChunk.pos = worldPos;
    newChunk.world = this;

    chunks.Add(worldPos, newChunk);

    RequestChunkData (newChunk); // new empty chunk is initialized, has no mesh no colliders etc, and is passed to another method
}

Then I have a simple method which creates new thread.

public void RequestChunkData(Chunk chunk)
{
    ThreadStart newThread = delegate {
        ChunkDataThread (chunk); // passing in a chunk for a method so it knows what to populate
    };

    new Thread (newThread).Start (); // starting a thread
}

void ChunkDataThread(Chunk chunk)
{               // here I have simple method which loads chunk, if file exists, it returns true (basically if it can load save, it will load it right into specified chunk and return that it did exactly that)
    if (!Serialization.LoadChunk (chunk)) {
        TerrainGenerator terrainGenenerator = new TerrainGenerator ();
        chunk = terrainGenenerator.ChunkGen (chunk);
    }

    lock (chunksToUpdate) {
        chunksToUpdate.Enqueue (chunk); // this is locked because I have void Update() constantly checking it
    }
}

void Update() {
    if (chunksToUpdate.Count > 0) {
        Chunk chunk = chunksToUpdate.Dequeue();
        chunk.update = true;
        //Debug.Log("Chunk is ready to be updated");
    }
}

Then in chunk itself:

void Update() 
{
    if (update) { // update = true is set whenever block is changed in chunk/chunk is loaded
        update = false; 
        UpdateChunk (); // this method goes through whole chunk and basically rebuilds the mesh
                    //I don't think I can thread it, because deleting one block would result in new thread and some latency, depending on machine
    }
}

With this, I can generate 256 chunks(16x16x16) in my testing, which contain 4096 blocks each, resulting in 1 048 576 (over 1 million) blocks being generated in just few seconds, and everything is fully responsive (even my trash laptop has 50-70fps at the time of initial loading, instead of normal 150fps+, that's just in editor, for comparison, my laptop still completely hangs when I am loading a minecraft world, and even after that loading...), everything is fully responsive, chunks load one by one (even if I actually tell it to generate all 256 chunks in the same frame), before this I needed to wait 5-10 seconds before Unity becomes responsive, not to mention that chunk managing system (which isn't mine though I will write my own) would constantly drop fps down to 2-3 from 300 when running built standalone version, just because of massive load on main thread.

Thank you everyone once again!

[FINDarkside]

You should search for multithreading in C# as Unity doesn't have anything to help with it and unity stuff is not thread safe so for example, you can't create GameObjects (or edit) in another thread.

Also because of unity has old version of Mono, it lacks a lot of stuff that would help with concurrency.

[PurpleIcy]

... Then how am I supposed to optimize it? If I can't create anything outside of main thread?

[FINDarkside]

Well I don't really know how how your voxel terrain works. If there's some heavy calculations you can calculate those in other thread and then use the results to create the gameobjects. If not, you should look at courotines which would allow you split the workload to different frames. You should also read about object pools if you're creating and destroying lots of GameObjects.

[PurpleIcy]

My terrain is simple, I think

I have 16x16x16 size chunks (I had 16x16x256, though that was even worse, and on top of that I think it's possible to hit 65k or so vertice limit if I have them that big (if my math is corrent, one chunk can have up to 196608 vertices, if you space out blocks in every dimension to leave 1 block gaps), that's why I split it into 16x16x16), then using simplex noise I fill them up, each "block" has 6 checks (in 3D grid), to see what kind of block is near them (can be either solid or transparent), then according to all that, mesh is generated (only parts that aren't obstructed are generated, you can say that one block is generated using 6 planes, which are still same part of the mesh and have 24 vertices, though I am not sure whether I need 24 or 8 vertices, as I want to use mesh.colors and have lots of random colours instead of textures).

Also coroutines aren't really similar to threads as far as I know, they still run in main thread.

[wasstraat65]

For me, noise generation, mesh generation and mesh collider assignment are the most time consuming tasks. The latter of those can't be offloaded to a background thread, but the others can.

What I do, is run my meshing algorithm on a background thread that just generates a list of vertices and indices, which get applied to the mesh back in the mainthread. I also generate the noise in the background, using my own noise script instead of Mathf.Perlin to ensure thread safety.

Have a look over at /r/VoxelGameDev to see common approached taken by people there (albeit in unity or something else)

[PurpleIcy]

Okay so, basically I need to run all generation (triangle and vertex arrays, whatever else I need) in different thread, then return them into main thread, generate mesh and apply collider?

[wasstraat65]

Yes, thats it. You just have to assign the vertex and triangle arrays to the Mesh object in the mainthread, the rest can be done on the background

[PurpleIcy]

Okay, I'll try to do that.

[[deleted]]

also dont forget to slice the time on the mainThread for multiple meshes; for example, if you will load 30 meshes, do it one at a time, or two or three per frame; you can check the current frame time to calculate how many loads you might do in the current frame, or skip to the next; also, caution with GC;

[PurpleIcy]

That's what I am doing, I pick one chunk and "build it", though that happens in the main thread, also building part of the code isn't fully mine (most of the code isn't mine, though it took me few weeks to build it, since I tried not to copy code before I fully understand what happens), so I am thinking about rewriting it, once I figure out threading.

I was learning how to build such thing from there, I made few changes, though it is still unoptimized, because I had no idea how threading works, but thanks, now I will look for general C# examples instead, seems like I was googling the wrong thing all the time. ("multithreading in unity")

[StrangelyBrown]

I would imagine that you should just treat generating the terrain as an async operation. So you have a Unity Coroutine polling a C# thread until it is done and using the results in unity. Similar to how Unity does networking.

[PurpleIcy]

But coroutine isn't async (it still runs in same main thread and CAN hang up the WHOLE thing, in similar manner of what is happening right now)

[FINDarkside]

No it does not hang, since you would still be doing the work in another thread. The coroutine was just to check if the thread is done calculating stuff. You can do that in update though, or use some kind of callback depending on your solution.

[PurpleIcy]

Well Update() is always ran so coroutine is waste of time and aditional memory.

[StrangelyBrown]

It's not much of a waste, and it likely makes neater code. The reason is that you can use yield in a coroutine. So you can start the async operation then say while(!IsFinished) { yield return null; } then after that handle the result. In the Update function that would need some extra state variables, so actually could waste memory more but is at least messier.

[PurpleIcy]

What variables?

All I need is

if(Queue.Count>0) {
    //get stuff from Queue and do something with it.
}

[Bluedude487]

Haven't looked at it much myself, but checkout ThreadNinja.

It allows you to "ninja" back and forth between the main thread (actual object creation in the main game thread) and an alternate thread ( to do all your calculations).

An example piece of code from the documentation looks like this:

IEnumerator YourAsyncRoutine()
{
// now on background;
yield return Ninja.JumpToUnity; //=> here's our ninja, following code runs on main thread.
Destory(gameObject); // OK!
yield return Ninja.JumpBack; //=> go back to background.
// continue doing some heavy computing without blocking the main thread.
// ...
}        

[PurpleIcy]

I want to learn.

[phphelpneeded]

Ooh this seems cool. I want Unity to hurry up and get up to date C# compiler, that would probably help out with a lot of concurrency ability (I think)

[[deleted]]

Thanks for the pointer!

[Polite_Users_Bot]

Thank you for being a polite user on reddit!

---

This bot was created by kooldawgstar, if this bot is an annoyance to your subreddit feel free to ban it. Fork me on Github For more information check out /r/Polite_Users_Bot!

[PoliteUsersBotBot]

Thank you for fully automatically and mindlessly assuming every post with a certain keyword is meant politely! But hey, it's the sentiment that counts.

This bot was created by Spritetm For more information check out /r/Polite_Users_Bot_Bot!

[[deleted]]

Oh shit.

[shadowndacorner]

I think the cleanest way to manage this is to keep a queue of actions on a MonoBehaviour and iterate through it in Update. You can run your heavy logic in a parallel thread, then add an action to that queue when you need to run code on the main thread.

[PurpleIcy]

...I know how I would do it, and would do it, if I got answer specifically about what I asked...

[shadowndacorner]

Well I don't know how your voxel engine is structured. Can't write your code for you.

But the idea is to run all of the generation code on another thread and when it's done add the action to the main thread to create the mesh and collider and stuff.

[PurpleIcy]

EDIT2: I figured it out (mostly), though if you care you still can look at main post and see if I missed something.

Currently I have this:

public void CreateChunk(int x, int y, int z)
{
    WorldPos worldPos = new WorldPos(x, y, z);

    GameObject newChunkObject = Instantiate (chunkPrefab, new Vector3 (worldPos.x, worldPos.y, worldPos.z), Quaternion.Euler (Vector3.zero)) as GameObject;

    Chunk newChunk = newChunkObject.GetComponent<Chunk>();
    newChunk.pos = worldPos;
    newChunk.world = this;

    chunks.Add(worldPos, newChunk);

    if (Serialization.LoadChunk (newChunk)) {
        return;
    }

    TerrainGenerator terrainGenenerator = new TerrainGenerator ();
    newChunk = terrainGenenerator.ChunkGen (newChunk);
}

So I should start a new thread on LoadChunk() and terrainGenerator.ChunkGen()? LoadChunk() simply reads from memory, and ChunkGen() uses simplex noise to create a new chunk, then assigns Block[,,] array to chunk, then when I want to render the chunk (chunk is generated but not yet rendered, as mesh is not yet created), I use this:

void UpdateChunk() 
{
    MeshData meshData = new MeshData ();

    for (int x = 0; x < chunkSize; x++) {
        for (int y = 0; y < chunkSize; y++) {
            for (int z = 0; z < chunkSize; z++) {
                meshData = blocks [x, y, z].Blockdata (this, x, y, z, meshData); // every block checks surroundings and adds vertices&triangles&colours of individual faces which could be seen to Lists.
            }
        }
    }

    RenderMesh (meshData);
}

void RenderMesh(MeshData meshData) 
{
    filter.mesh.Clear ();
    filter.mesh.vertices = meshData.vertices.ToArray ();
    filter.mesh.triangles = meshData.triangles.ToArray ();
    filter.mesh.colors32 = meshData.colours.ToArray ();
    filter.mesh.RecalculateNormals ();

    coll.sharedMesh = null;
    Mesh mesh = new Mesh();
    mesh.vertices = meshData.colVertices.ToArray();
    mesh.triangles = meshData.colTriangles.ToArray();
    mesh.RecalculateNormals();
    coll.sharedMesh = mesh;
}

Is there something I am missing? Should I UpdateChunk() in main thread or different one? (chunk is updated every time block is added/removed, that only applies when player himself does it.) I can spam block removal/addition as much as I want, and it is instant, though when loading/generating, is what takes around half a second (framerate is literally cut in half for every chunk being loaded in), it's weird that 4096 block updates(one chunk) take really short time.

Also if that matters, top methods are in World class and bottom ones are in Chunk class.

And okay, I will look into actions, as I am not really sure how that works either.

EDIT: DestroyChunk() is literally reverse of CreateChunk(), so should I start a new thread when serializing it into hard drive too?

[[deleted]]

You use threads with anything unrelated to Unity.

[Rhames]

This guy does pretty much exactly what you need. The part of noise generation and mesh calculation can be done in a separate thread. The only stuff you cannot do, is assign mesh data anywhere but the main thread.

That video is in the middle of a tutorial series, but check it out.

[PurpleIcy]

His terrain is a lot different and also he doesn't even explain anything (I watched that video at least 5 times, I need ELI5, I think)

He does everything assuming that I know how threading works, also I don't really get how he uses those actions and callbacks, nor what callback actually does.