Jump to content

  • Log In with Google      Sign In   
  • Create Account


How? - Loading Unity Terrain Async without Pro or Asset Streaming


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
8 replies to this topic

#1 tharealjohn   Members   -  Reputation: 451

Like
0Likes
Like

Posted 12 July 2013 - 01:34 PM

Question: How can I offset some of the load of creating Terrain objects procedurally using a separate thread?

Background: I have been trying to get an "infinite" terrain system going using the Terrain objects in unity. I am procedurally creating the TerrainData objects, and then creating a Terrain object like this:

var t = Terrain.CreateTerrainGameObject(terrainData).GetComponent<Terrain>();

 

 

I need to keep track of my t objects so I know how many and which Terrains have been created. I am following a basic Tile grid, where each Terrain object is thought to be a Tile in the grid, located at coordinates like (0,0), (0,1), etc. The TerrainData object has all of its values and height mapping done using Perlin Noise. As I walk around I "cull" unneeded tiles of the Terrain that are "too far" away from the player. This results in a "rolling" set of 9 tiles surrounding the player, which is always at the center tile.

Here is where the question comes in. Creating the Perlin values for the TerrainData, along with the height map is very CPU intensive. I would like to do this on a separate thread, but because the TerrainData and Terrain objects are so closely linked, and they cannot be accessed on another thread, I am not sure how to architect my situation so I can use a separate thread for the Perlin and Height mapping bits.

An example of what I have (simplified):


List<Terrain> terrain = new List<Terrain>();
...

public Terrain CreateTerrain(int x, int y)
{
    // CPU intensive work
    CreateHeightMapValues(heightMap);

    // Fill in TerrainData values (I dont think this has to be done on the main thread)
    var td = new TerrainData();
    ....

    // Create the actual Terrain (Has to be done on the main thread)
    var t = Terrain.CreateTerrainGameObject(terrainData).GetComponent<Terrain>();

    // set position, etc.
    ... (misc work)

    return t;
}

I would like to wrap that CPU intensive work somehow in another thread, but because I need to return that Terrain object so I can add it to my List terrain, I cant just throw it off on another thread, because Ill need to wait anyway to create the actual Terrain object.

 

Can anyone suggest how to break it apart a little better so that I don't rely on the direct creation being linked to when I can add it to the list of terrain objects?

Note* That list is so I know how to destroy/create them when the player moves. It would also be nice to Destroy the Terrain object on a seperate thread so it doesnt lag the UI, but I dont think that is possible do to Unity's non-threadsafe environment.

 

I originally posted on Unity Answers, but thought this might be a good place too, as it is not 100% Unity specific, since it is mainly a architectural problem. Knowledge of Unity and its limitations is probably helpful though.

 

Also note that creating the threads and being able to invoke back on the main thread in Unity are not my problems, I have that code figured out. I just dont know how to use it effectively given the issues I mentioned above about 1 thing being needed for the other.


Edited by tharealjohn, 12 July 2013 - 01:37 PM.

jmillerdev.com

Follow me @jmillerdev


Sponsor:

#2 tharealjohn   Members   -  Reputation: 451

Like
0Likes
Like

Posted 15 July 2013 - 06:32 AM

Still hoping for some advice about this.


jmillerdev.com

Follow me @jmillerdev


#3 Sandman   Moderators   -  Reputation: 2077

Like
0Likes
Like

Posted 15 July 2013 - 07:36 AM

I have something very similar working, although the architecture is a little complicated, and a bit messier than I'd like. But it works reasonably well - the main cause of lag in the project so far is actually more to do with the dodgy stock water implementation doing a render-to-texture than the speed of the tile generation, although I have a sneaking suspicion that might change once I get tree generation in... :(

 

In my system, I don't actually destroy the terrains. I create a pool of terrains on startup, initially disabled. Processing work is split up into sequential tasks which are then split again into parallelisable tasks which can be offloaded to another thread - you can only start the next sequential task when all parallel tasks are complete.

 

Once everything is complete the terrain is enabled and pops into view. When you've finished with a tile, it just gets disabled and added back to the pool for recycling.



#4 tharealjohn   Members   -  Reputation: 451

Like
0Likes
Like

Posted 15 July 2013 - 11:06 AM


Once everything is complete the terrain is enabled and pops into view. When you've finished with a tile, it just gets disabled and added back to the pool for recycling.

 

Thanks Sandman for your reply.

 

Are you using Unity and its Terrain feature? 


jmillerdev.com

Follow me @jmillerdev


#5 dAND3h   Members   -  Reputation: 214

Like
0Likes
Like

Posted 15 July 2013 - 11:25 AM

hmm, do you really need every new piece of "Terrain" to be completely random? 

 

If not, you can create a set of pre computed heightmaps in a image program which you can then load a random set from.

 

In regards to your question, have you thought about generating a heightmap texture via shader code? If you are doing alot of floating point calculations this would greatly increase performance.  It would increase performace even more if you decided to only generate a new random heightmap after you have used one a certain number of times, and just apply rotations to bits of terrain to keep it looking like it is more random than it really is.

 

Regards



#6 tharealjohn   Members   -  Reputation: 451

Like
0Likes
Like

Posted 15 July 2013 - 11:40 AM

dAND3h, 

 

Thanks for the input.

 

 

 


hmm, do you really need every new piece of "Terrain" to be completely random? 

 

Because the terrain object is just a small tile in a much larger ("infinite") terrain system, yes. Each terrain piece should line up with the next to create a "seamless" environment. 

 

 

 


If not, you can create a set of pre computed heightmaps in a image program which you can then load a random set from.

 

This is a different scope than the project, but not a bad solution for a different game. However, for me, this will not work. 

 

 

 


In regards to your question, have you thought about generating a heightmap texture via shader code?

 

No, I have little experience with shader code, and might be something I can investigate later. I am not sure this even would work with my solution ( I dont know how to do that with shaders). The performance is only an issue because currently everything is on the main thread. I need some architecture level solutions related to Unity on how to address this. Something technical would be great, but a high level overview might push me in the right direction. 


Edited by tharealjohn, 15 July 2013 - 11:40 AM.

jmillerdev.com

Follow me @jmillerdev


#7 dAND3h   Members   -  Reputation: 214

Like
0Likes
Like

Posted 15 July 2013 - 11:57 AM

I assume you have already found this? http://docs.unity3d.com/Documentation/ScriptReference/Mathf.PerlinNoise.html or are you using a custom solution?


Edited by dAND3h, 15 July 2013 - 11:57 AM.


#8 tharealjohn   Members   -  Reputation: 451

Like
0Likes
Like

Posted 15 July 2013 - 12:46 PM

I am using the Perlin.cs file included in one of the Unity procedural examples.

 

I would still need to call that function above on a separate thread, which by itself is not hard, but bundled with creating Terrain, I am struggling. This is mainly because the Terrain objects have to be created on the main thread, and I have to keep track of them "synchronously". I say synchronously because as I create them, they need to go in a list to update all the neighbors for LODs to match up, which is part of how the Unity terrain works. 


Edited by tharealjohn, 15 July 2013 - 12:46 PM.

jmillerdev.com

Follow me @jmillerdev


#9 Sandman   Moderators   -  Reputation: 2077

Like
0Likes
Like

Posted 15 July 2013 - 04:02 PM

 


Once everything is complete the terrain is enabled and pops into view. When you've finished with a tile, it just gets disabled and added back to the pool for recycling.

 

Thanks Sandman for your reply.

 

Are you using Unity and its Terrain feature? 

 

 

Sorry, I wasn't clear... yes. Unity + Regular Unity Terrains as tiles. The noise generator is my own though.

 

I don't think you can create the terrains ready made - I think the best you'll be able to do is create them disabled, generate them, and then enable them when ready. The generation process might take a reasonable amount of time, so you have to give yourself enough time to generate them.

 

My system basically sets up tasks to generate a heightmap, then a series of splat maps, and then detail maps, and (when I get around to implementing it), tree instance lists, plus a few tasks to do things like copy stuff back to the terraindata object. When that's all done, it just sets up neighbours, refreshes prototypes etc. and enables the terrain.

 

One thing to be aware of, is that I don't believe you can dynamically set up base texture maps. This means that the base texture map for your terrains will always come out as their default black (IIRC this is particularly noticeable in release builds). As far as I know, the only workaround is to effectively disable the base map by setting the basemap distance to something implausibly huge so they are never used.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS