Search Unity

Terrain does not work well with non-uniformity, question about creating many small terrain

Discussion in 'World Building' started by GiraffeAndAHalf, Sep 5, 2019.

  1. GiraffeAndAHalf

    GiraffeAndAHalf

    Joined:
    Dec 28, 2018
    Posts:
    3
    I want to use the terrain tool in current unity, but have encountered the following issue: I want non-uniform terrain sizes for various reasons, however the neighbor system does not play well with this and it breaks deforming accross terrain boundaries.

    example, each space is 10x10:
    Code (CSharp):
    1.  
    2. 40x10;10x10
    3. 20x10;30x10
    4. --------
    5. |    | |
    6. --------
    7. |  |   |
    8. --------
    What doesn't work:
    1. making neighbor with neighbor tool, then rescaling. Changes carry over to the neighbor, but based on the original scalling. So adding height accross boundary at 50% will change both terrain at relative 50%, not where they are touching.
    2. above, but press reconnect button, no change.
    3. don't use neighbor tool, create terrain at the correct size, then use reconnect button. Will not connect terrain pieces when sides are not the same length.

    My thought is to get around this by making the tiling resolution much smaller. Though if the resolution was significantly small enough (say 1 unit square), there would be a TON of terrain objects. Besides this being a pain to develop, I'm wondering if anyone knows at what point making terrain size smaller really hurts performance? Is its effect on performance linear? Does having better LOD-etc resolution make up for having, say, 10K (100^2) terrain objects loaded if none of the objects have updates?

    Alternatively is there any plan to enable this to work out of the box?

    nonuniformterrain3.jpg
     
  2. crysicle

    crysicle

    Joined:
    Oct 24, 2018
    Posts:
    62
    I've tested partitioning terrains multiple times for various reasons. From my experience, the terrain is optimized to be 1 single large object for rendering and should only be split up scarcely of no more than 16 individual terrain tiles which could be visible to the camera. Etc.: Full terrain of 1025 heightmap res and 2050 vector res would be split into 4x4 257 heightmap res and 512.5 vector res tiles. Most of the performance from partitioning is lost because of rendering individual terrain tiles, not because the data is loaded or physics interactions. However, I don't remember if the performance loss is linear or exponential.

    Also, the smallest terrain resolution is 33x33, which is 1089 heightmaps.

    I don't think that the way you're trying to construct your terrain tiles would be supported any time soon by unity's Terrain unless you'd be willing to build the tools for this integration yourself.
     
    Last edited: Sep 5, 2019