WebPlayer + Multi-threading?

I'm currently working on a game that generates a terrain in the background procedurally on a separate thread. When data is ready, the main thread picks it up, creates a unity Terrain and fills it with data. It's all working perfectly fine, and I have an endless terrain with one small problem -- it seems to only work in stand-alone builds (and in the editor). Web player just shows a blank screen. Since the game was working prior to my addition of multi-threaded terrain generation, am I to assume that multithreading support is removed in the web player?

Does anyone know?

Edit: It seems threads work, but the "new Mutex()" call fails. Bleh.
Second Edit: Fixed by avoiding mutexes and going with C#'s "lock()".

 

Question : does it generate the terrain in a non-Unity format? As in for example a carrier object with vertex-data just to assign it to the meshes or something like that?
Or does it just generate and populate heightmaps?
I am working on a similar thing but with multi-layered terrain and I wanted to delegate it to another thread and was wondering about how much of the Unity engine can I use in other threads.

Also, can I use MT in Unity Editor for in-scene data generation?

Another question:
Why would You create a mutex for a lock in a MT application?
Isn't it generally used to prevent multiple instances?

 

Multithreading is not available in webplayers, but not due to Unity, from what I recall its a browser plugin security part, that plugins can not run multiple threads / spawn new threads


@sivael: nothing, you are not allowed to touch anything from the UnityEngine namespace in distinct threads at all.
using mutex is useless as unity does not check them, it uses and changes its objects (anything from unityengine namespace) at any time and at its own authority


and mutexes are normally used to prevent 2 threads changing the same object as that leads to a straight application crash, exactly what you will see if you touch UnityEngine namespace from a distinct thread

 

@sivael: In Battle Treads I generate the heightmap data in a worker thread. When the process completes, I let the main thread create the terrain using the generated data. There is more to it, like separating main thread operations into different frames in order to avoid visible stutter, but that's the gist of it. All the player sees is seamless terrain with no borders.

@dreamora: Multi-threading works fine in the web player. The only tricky part was using C#'s lock() instead of Mutexes.

 

I see, good to know

Good to know that such stuff works for webplayers, saves download space too.
How large or better small are your heightmaps as you can do it with no "visible stutter" even on normal human machines

 

Dreamora do you know when 64 bit unity comes available?

 

Terrains in Battle Treads are 256x256, and at any given time there can be up to 7 visible. I've optimized the game so that it reuses previously created terrains that go out of range rather than re-creating them -- this includes not just unity's Terrains but also heightmap arrays generated in the worker threads. I split up processor-heavy operations into multiple frames as follows:

- new TerrainData() (reused if an unused terrain is available)
- TerrainData.SetHeights() + Splat Prototypes (skipped if terrain was reused)
- TerrainData.SetAlphamaps().

Each terrain game object is actually a child of another game object that keeps an eye on how far away the player is and creates/activates/deactivates/releases the terrain depending on distance.

Each game object in game (this includes rocks, tanks, turrets -- everything) has its own listener that activates / deactivates the object depending on distance to the player.

All the distance-based listeners are executed only 2-5 times per second, with a randomized interval so they are spread out evenly among different frames.

These tricks helped me make terrain generation pretty much seamless.

 

Mhm...
Nice.
Useful.

Thanks for the information.

I'll probably have to develop some kind of multiple-heightmap or a kind of portal tech though... or something. Oh well... Problems exist to be solved

Thanks again.