I have a component that is in charge of generating a level at runtime, and this is an operation that takes quite some time. As a consequence, I experience a hang when this operation is executed (when the scene is loaded).

This problem can be summarized to the fact that SceneManager.LoadSceneAsync in fact is not async at all in its second phase, when it initializes all the objects.

There are three approaches I have searched for and thought about:

Slicing the operation as explained on this video:

This is non-trivial, I would have to rewrite chunks of code for the sake of avoiding a few seconds hiccup at scene load. Furthermore, the person explaining in the video says that they changed Unity source code which I don't have access to.

Running the operation in a background thread:

This is definitely interesting, it would require minimal changes. The only problem is that at some point I have to create Unity objects (GameObject, Mesh etc) and this is not possible when outside Unity thread.

I was thinking more or less of this code to be run on the background thread:

class Builder
    public void Build()
        // 1. do something long

        // 2. create Unity object with result from #1
        // something like that
        // await RunInUnitySynchronizationContext(() => new GameObject(...))

        // 3. do extra stuff on the result of #2

The thing is I have no idea at all on how that second step should be written, if possible at all.

Use a non-animated Loading screen and wait for it to finish:

This is the simplest and effectively does away with the problem by 'just' hiding it.


What's an effective approach to solve this problem?


3 Answers 3


I don't know your level generation code, but you can just call the necessary things from the main thread again with the below code. Would be the cleanest, if you run all the performance heavy things in the background thread and once that's finished, you go back to the main thread and finish everything up there. But again, I don't know your code and whether that's possible.

You have to add this script to a gameobject in your scene. Put it onto your gameobject that has all the manager scripts attached or put it on your camera.

Copyright 2015 Pim de Witte All Rights Reserved.

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at


Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
See the License for the specific language governing permissions and
limitations under the License.

using UnityEngine;
using System.Collections;
using System.Collections.Generic;
using System;

/// Author: Pim de Witte (pimdewitte.com) and contributors
/// A thread-safe class which holds a queue with actions to execute on the next Update() method. It can be used to make calls to the main thread for
/// things such as UI Manipulation in Unity. It was developed for use in combination with the Firebase Unity plugin, which uses separate threads for event handling
public class UnityMainThreadDispatcher : MonoBehaviour {

    private static readonly Queue _executionQueue = new Queue();

    public void Update() {
        lock(_executionQueue) {
            while (_executionQueue.Count > 0) {

    /// Locks the queue and adds the IEnumerator to the queue
    /// IEnumerator function that will be executed from the main thread.
    public void Enqueue(IEnumerator action) {
        lock (_executionQueue) {
            _executionQueue.Enqueue (() => {
                StartCoroutine (action);

        /// Locks the queue and adds the Action to the queue
    /// function that will be executed from the main thread.
    public void Enqueue(Action action)
    IEnumerator ActionWrapper(Action a)
        yield return null;

    private static UnityMainThreadDispatcher _instance = null;

    public static bool Exists() {
        return _instance != null;

    public static UnityMainThreadDispatcher Instance() {
        if (!Exists ()) {
            throw new Exception ("UnityMainThreadDispatcher could not find the UnityMainThreadDispatcher object. Please ensure you have added the MainThreadExecutor Prefab to your scene.");
        return _instance;

    void Awake() {
        if (_instance == null) {
            _instance = this;

    void OnDestroy() {
            _instance = null;


You call it like this:

UnityMainThreadDispatcher.Instance ().Enqueue (MethodNameWithoutParameters);
UnityMainThreadDispatcher.Instance ().Enqueue (() => MethodNameWithParameters(param1));

Your code will be run in the next update loop.

  • \$\begingroup\$ Looks great, taking a look at it. \$\endgroup\$
    – aybe
    Commented Mar 29, 2019 at 0:08
  • \$\begingroup\$ Thank you, I am going to use this with a background thread. \$\endgroup\$
    – aybe
    Commented Mar 30, 2019 at 5:14

There are 2 simple solutions:

  1. If only #1 in your code example takes a long time and it can be run without any GameObjects, you use the new job system and run it in the background, and then you'll only need to wait for it to complete before executing the presumably shorter #2 and #3. If the logic could be broken into several jobs or built as a parallel job, you'll also get the benefit of parallelization.

  2. A lesser alternative would be moving the logic into a Coroutine, and sprinkle yield return statements throughout your code, so it won't block. This doesn't move the logic into a background thread, but at least it won't block.


A more accessible but less performant alternative to the job system is to use async/await, where you can run code in C#'s thread pool with Task.Run().

I am using a hybrid approach of running multithreaded code by awaiting a function that contains a call to Task.Run(). Since the execution returns to the main Unity thread after the await, I can then call Unity's APIs from there without running into exceptions.

To avoid freezing the game at that point however, I don't see an alternative to using a coroutine. At least until Unity adopts a more asynchronous approach, which I believe it is quite late on!


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .