[RELEASED]Terrain Importer

Send you an email and hope you can help.

 

Great, I will be working on your problem exclusively tonight.

 

Hi,
I really appreciate your work. Actually, I have been working on a similar terrain procedure for some time until I found your assets. Here I have a question, it's about the seam between adjacent tiles.

In my solution, I create TerrainData assets with the output heightmaps and textures from WorldMachine, then I load them and create terrain objects at runtime, but it seems to have seam between adjacent tiles. I have set terrain.neighbors and check that the adjacent tiles have the same heights on borders. As long as you have this perfect solution, I wonder if you have occured to such problem and how you deal with it?

Any help will be very appreciated!

 

Is there a full on gap between the terrains? That's how it appears in the screenshot, but obviously it's zoomed out so impossible to know for sure. In that case, the only thing I can think of is to make sure the heightmaps are a power of two + 1 resolution when exported from World Machine.

Note that in some cases when exporting tile maps from World Machine, you may notice a "seam" between the terrain, but not like what's shown in your picture. So once you correct the gap (if that is indeed one), if you still notice a seam, it may or may not be avoidable. Increasing the blending region in World Machine may help. The issue is that Unity does not do texture blending between terrains, so if the neighboring between two alphamap pixels is not exactly the same, you'll likely notice a seam.

For setting terrain neighbors, the only thing I can say is to make sure you call the Flush method after setting each terrain's neighbors, and also make sure the terrain object is fully created and activated before setting the neighbors.

Good luck!

 

First, thank you!

I understand I'm actually having a "gap" rather than a "seam". I set my terrain heightmap resolution to ^2+1 in Unity, but I export heightmap from WM by just ^2. So I fix this and notice the seam between terrain(seam2.png), which I think it's just what you are talking about.

 

@fc2012

When you examine the alphamap textures do they have those yellow lines on the border? If not then it's definitely a terrain neighboring issue. I've offered the only advice I can in that area. If you want to post your neighboring code, maybe something will pop out as being at fault.

Best Regards,
Kyle Gillen

 

For each tile, the output from WM is a single texture in 513x513, but when imported to Unity it turns out to be 512x512, and image_x0_y0.png is an example of my textures. I'm not sure setting the alphamapResolution as 513 or 512, but it seems to have the same result. I'm not sure if my texture code(creating TerrainData) is right, so here it is.

Code (CSharp):

1. private bool LoadTexture(TerrainData td, string tFilePath)
2.     {
3.         Texture2D tex = AssetDatabase.LoadAssetAtPath(tFilePath, typeof(Texture2D)) as Texture2D;
4.         if (!tex)
5.         {
6.             Debug.Log("Fail to load texture file!");
7.             return false;
8.         }
9.        
10.         SplatPrototype splat = new SplatPrototype();
11.         splat.texture = tex;
12.         splat.tileSize = new Vector2(td.size.x, td.size.z);
13.         td.splatPrototypes = new SplatPrototype[] { splat };
14.         td.RefreshPrototypes();
15.         return true;
16.     }

I write the following test script and attach it to Main Camera. It creates 9 adjacent terrains. The index of each tile in the List and corresponding position are shown in terrains.png.

Code (CSharp):

1. using System.Collections;
2. using System.Collections.Generic;
3. using UnityEngine;
4.  
5. public class tryRemoveGap : MonoBehaviour {
6.  
7.     private List<GameObject> terrain;
8.     private string assetPathName;
9.     // Use this for initialization
10.     void Start () {
11.         terrain = new List<GameObject>();
12.         assetPathName="tt/myTD";
13.         TerrainData terrainData = new TerrainData();
14.         for (int i = 0; i < 3; i++)
15.         {
16.             string suf0 = i.ToString();
17.             for (int j = 0; j < 3; j++)
18.             {
19.                 string suf1 = j.ToString();
20.                 string path = assetPathName + suf0 + suf1;
21.                 terrainData = Resources.Load(path) as TerrainData;
22.                
23.                 GameObject newTerrainObject = Terrain.CreateTerrainGameObject(terrainData);
24.                 newTerrainObject.transform.position = new Vector3(i * 500, 0, j * 500);
25.                 terrain.Add(newTerrainObject);
26.             }
27.         }
28.        
29.         //SetNeighbors
30.         terrain[0].GetComponent<Terrain>().SetNeighbors(null,
31.             terrain[1].GetComponent<Terrain>(), terrain[3].GetComponent<Terrain>(), null);
32.         terrain[3].GetComponent<Terrain>().SetNeighbors(terrain[0].GetComponent<Terrain>(),
33.             terrain[4].GetComponent<Terrain>(), terrain[6].GetComponent<Terrain>(), null);
34.         terrain[6].GetComponent<Terrain>().SetNeighbors(terrain[3].GetComponent<Terrain>(),
35.             terrain[7].GetComponent<Terrain>(), null, null);
36.         terrain[1].GetComponent<Terrain>().SetNeighbors(null, terrain[2].GetComponent<Terrain>(),
37.             terrain[4].GetComponent<Terrain>(), terrain[0].GetComponent<Terrain>());
38.         terrain[4].GetComponent<Terrain>().SetNeighbors(terrain[1].GetComponent<Terrain>(),
39.             terrain[5].GetComponent<Terrain>(), terrain[7].GetComponent<Terrain>(), terrain[3].GetComponent<Terrain>());
40.         terrain[7].GetComponent<Terrain>().SetNeighbors(terrain[4].GetComponent<Terrain>(),
41.             terrain[8].GetComponent<Terrain>(), null, terrain[6].GetComponent<Terrain>());
42.         terrain[2].GetComponent<Terrain>().SetNeighbors(null, null,
43.             terrain[5].GetComponent<Terrain>(), terrain[1].GetComponent<Terrain>());
44.         terrain[5].GetComponent<Terrain>().SetNeighbors(terrain[2].GetComponent<Terrain>(),
45.             null, terrain[8].GetComponent<Terrain>(), terrain[4].GetComponent<Terrain>());
46.         terrain[8].GetComponent<Terrain>().SetNeighbors(terrain[5].GetComponent<Terrain>(),
47.             null, null, terrain[7].GetComponent<Terrain>());
48.  
49.         for (int i = 0; i < terrain.Count; i++)
50.         {
51.             Terrain t = terrain[i].GetComponent<Terrain>();
52.             t.Flush();
53.         }
54.     }

Many thanks!

 

So I would try the following, in order, and see if the problem is fixed after each change:
1) Move the Terrain Neighboring code to a different frame. There may be issues when trying to create the terrain and set the neighboring in a single start method, so I would put everything in a coroutine and then throw a "yield return null" in between the terrain creation and neighboring code.

2) Try flushing each terrain immediately after setting its neighbors.

3) Set the neighbors and flush only one terrain per frame. This is how I do it in my own code (if the code is in a coroutine, just put a "yield return null;" in between each terrain neighbor/flush). I can't remember if this was required to get things to work, or if it was just for performance reasons.

None of these options are guaranteed to fix the issue, but it's what I would try if debugging this issue. The only other solution I can suggest is making sure to export the textures from WM at 512 resolution . . . but it sounds like maybe you've done this already? I doubt it's the issue anyway, even if the textures are 513 (but you never know). Are your terrain tile pieces 512 meters x 512 meters (physical size)?

 

Thank you! I'll try these steps.

Each of my terrain tile pieces is 3000m x 3000m in World Machine, but in this code I set the size to 500x500 in Unity. Is that really matters? In WM I use a Bitmap Output device to get a single texture for each terrain and I'm pretty sure it's 513.

 

You're right, I don't think that would matter in this scenario. Hopefully my other suggestions fix the issue.

 

I need some advice:
I need to build a 20x20 km, I'm trying to create a grid 10x10 with a 2000x2000 terrain in Unity.
I didn't have a World Machine pro, so I use gimp to slice the picture in small pieces.
20480 x 2048 is a correct format?
Also, sometime terrain Importer refuse to create a 2000x2000 terrain, but instead it set the terrain in smaller tile, like 800x800 or 1000x1000 any idea why it happen?

 

It depends on what the resolution of your pre-sliced heightmap is. It should be a power of two + 1 value, something like 2049 or 4097 (or probably higher).

Dividing the pre sliced heightmap into a 10x10 grid will not work, you have to use a power of two value, such 2x2, 4x4, or 8x8. Obviously 8 is the closest value to 10 so I'd advise using that. To find the resolution of the sliced images, use this formula:
sliced_image_resolution = ((non_sliced_image_resolution - 1) / grid size) + 1

where grid size is likely 8.

When creating the slices, introduce overlap so that the right most column of pixels in each slice is exactly the same as the left most column of pixels in the slice to the right of it (and top most row of pixels in each slice is the same as the bottom most row of pixels in the slice above it). This will ensure that the heightmap values are the same along the borders of slices.

I assume this is happening when you are importing a tile set. If that is the case, there is an option called "Use These Settings For Individual Tile Pieces", found in the "Dimensions/Resolutions" subsection of the "Base Terrain Settings" foldout.

If you leave this option unchecked (which I think must be the case for you currently), then the tool will divide the width, length and all resolution settings by the value of the "Tiles Per Side" field in the "Tiled Import Settings" foldout.

So, try checking the "Use These Settings For Individual Tile Pieces" option and see if the problem goes away. If it does not, or you didn't have this option unchecked to begin with, let me know and I will try to think of another reason this may be happening.

Thanks!

 

Hey I have a question regarding heightmap tileset import. I created a 16x16 tileset in WM, each with a resolution of 2049x2049 in r16. Before, I managed to import a tileset correctly from TIF images. When choosing raw16 I additionally need to specify "File Width" and "File Height". I am not sure which resolution I should set: a) the 2049 with which each tile was rendered or the whole resolution of the complete (non-tiled) heigthmap? I just want to clarify this before I hit the initialize button because of obvious heavy workload incoming

Fact: total build time of the terrain in WM was: Total Build Time elapsed: 18386.48s
This is just a proof of concept test. The WM terrain is 56km x 56km. Looking forward to it.

Update:
While importing the monster I got a Unity out of memory error. This happened at terrain tile 15_12.


My system has 8gb RAM which I know is not that much nowadays.
Could I bypass this issue by importing only sets of the tileset? Say 1_1 -> 5_16; 6_1 -> 10_16; 11_1 -> 16_16? Or would the sequentially imported tiles ram up the RAM (pun intended)?
How would I do this.
Using the "Region to import" function?
Or with "Tiles to import"? Therefore I would need to know the order of how Terrain Importer is importing the tiles.
Does it first import a complete row or a complete column? Also the naming convention WM creates the tiles is _%x_%y incontrast to _%y_%x as the txt in the asset is telling me to do. This way I managed to import the TIFs correctly. _%y_%x did not work for me.

Example:
Assumptions: Rows are imported first.
Tiles to import: First Row = 1; Last Row = 5 ; First Colum = 1 ; Last Column = 16
Rinse and repeat for all 16 rows respectively columns (need to know which imports first..).
Depending on what is imported first this could be subject to change. I guess if columns are imported first this would need to be like this: First Row = 1 ; Last Row = 16 ; First Column = 1; Last Column = 5.
I will update this post once I check on this.

Update 1:

The problem here seems to be the naming convention. As seen in this screenshot I used this exact naming convention when I created TIFs with WM and imported them using Terrain Import. It worked as intended with this naming convention. But with RAW16 (*.r16) I get these misalignings.
As for Tiles to Import you can see the settings on the screenshot aswell.

 

Yes, it is the heightmap size of each individual file you are importing, so 2049 is the correct size.

The tool has been designed to free memory after each tile is imported, allowing for importing of large tile sets. If you're seeing this error it means there is a bug somewhere. I will figure out what is going on ASAP. Can you email me your invoice number (to kgillen@deepspacelabs.net)? That way I can email you an updated package once the fix has been implemented.

You should absolutely be able to bypass this error by doing multiple partial imports (great idea!). You'll want to use the Tiles to Import functionality.

I am not quite sure I understand why you need to know the order that the tiles import, but yes, every column is imported from one row before moving on to the row above. Import Tile row 1 column 1, Import Tile row 1 column 2 . . . etc., Import Tile row 2 column 1, Import Tile row 2 column 2 . . . etc.

As for the naming convention, use whatever convention was used to export the tiles from World Machine.

Your naming convention looks okay. I believe World Machine just flips the y axis for some reason. You should be able to fix this by checking the "Flip Vertical" option under Heightmap Import Settings.

 

@ianmcmillian

I think I know what is happening. I should have instantly picked up on this. Sorry! The brain must not be working right today.

The issue is that Unity simply cannot handle all those high resolution terrains in the scene at once.

When importing a large high resolution tile set, you need to create prefabs rather than creating terrain in the scene (or more accurately, create prefabs and then delete the terrain in the scene).

Under the "Terrain Output Settings" section, you should see an option called "Create Prefabs". Check this option and specify the folder where you want the prefabs to be saved. Then check the "Remove Terrains From Scene" option.

I am 99% sure this will resolve your issue. If not, please let me know! Hopefully you are utilizing some kind of dynamic loading solution to load only the terrain around your player in game. Otherwise, like I said, Unity cannot utilize so many high resolution terrains at once.

If you're using the 32 bit editor you can try downloading the 64 bit one. That will (I believe) double the amount of memory that can be used by the editor. No guarantees though, and perhaps you are already using the 64 bit editor, in which case this tip will not help.

Best Regards,
Kyle Gillen

 

Does this tool handle 16bit single channel TIFF files with non-(power of two plus one) dimensions?

 

It should be able to, assuming the tiff file follows standard protocol. If the tiff file is using custom tags they'll just be ignored, though if it is a GeoTiff file, most of the meta data can be utilized. What program was used to generate the file? You can send the tiff file to me and I can test importing it to make sure it works (kgillen@deepspacelabs.net), assuming the file is small enough (alternatively you can find somewhere to host it and send me a download link).

Also, note that you will not be able to import the full non power of two file, as Unity does not support terrain with a non power of two heightmap. Instead, you will import a sub region of the tiff file. You do this by specifying the heightmap of the terrain you are creating (or that already exist) and x and y pixel that is used as the bottom left pixel of the import region. You will most likely need to figure out the correct pixel to use in a third party image editing program, or possibly in the program you used to generate the tiff file. Of course, you can also just guess and and readjust the value by re importing the file over and over again.

Best Regards,
Kyle Gillen

 

Hey @gilley033 - Got a few questions about this tool.

1. Does this work with Unity 2017.1?
2. Can I export multi tile terrain using this tool?

 

There is no reason it shouldn't work with Unity 2017.1. I don't believe they've changed anything regarding the terrain system, though if anyone has information to the contrary please let me know. I have done some limited testing and everything appears to be working.

As for exporting multi tile terrain, if you mean exporting terrain from Unity to an external heightmap, then no, the tool does not do any exporting.

If you mean importing multi tile terrain heightmap/splatmaps from outside of Unity into Unity, then yes, it can do that!

Best Regards,
Kyle Gillen

 

Hi all,

Does this asset detect the terrain height automatically for each tile?
Also how does it deal with heights that are below 0 for example sea bed?

Regards

 

Hi veddycent, and thanks for your interest!

What kind of files are you importing? If you are importing GeoTiff or Terragen files, then the tool should be able to automatically detect the height of each tile, but otherwise you will have to manually enter a terrain height (I know of no other file format that stores this data). The manual settings are applied the same for each tile, so if you need tiles with different heights, there will be a problem (also, if the height cannot be retrieved from the file, the manual value will be used).

In regards to your other question, absolute heights are not stored in the Unity. A heightmap simply consist of a set of floating point values between 0 and 1. Within Unity, these values are multiplied by the terrain height to find the World space height of each point above the current Y position of the terrain. If you want negative heights, then you just need to lower the Y position of the terrain, most likely to whatever the lowest height you want (otherwise, if left at 0, 0 will be the lowest height possible).

For file formats that contain absolute heights, the tool will find the lowest height and highest height and then normalize each height in the file to within that range so that a value between 0 and 1 can be fed to Unity.

I hope that answers your questions, but if not please feel free to clarify or restate your questions.

Thanks!

 

Thanks for the reply.

I'll hopefully be using GeoTiffs. I'm going to try and load the whole of New York County and alot of the sea bed (used for offshore wind farm)

I see what you mean about the heights being interpolated from 0 to 1 so any elevation below 0 will require the terrain gameobject being adjusted in the y axis accordingly. I might have to create a txt with the maximum and minimum heights for all the terrain segments then write a script in unity to set these values for each individual terrain gameobject.

I'll have to do some testing first...

Regards

 

To be honest, I never envisioned needing this functionality because usually when importing a tile set, all the files utilize the same range of elevation data. Perhaps this assumption was flawed, however. There is already an option to try and preserve the absolute elevation data when importing Terragen or GeoTiff files, but it assumes that the tiles are all utilizing the same elevation range and you are simply trying to map the values to a new elevation range.

Really what the tool needs to know is the minimum elevation and maximum elevation (taking into account all tiles in the tile set). We could then set the height of every tile to the same value (max elevation - min elevation), and map each raw elevation data point to this range.

I could also add an option when getting the terrain height from the file to set the y position of the terrain to the lowest elevation data in the tile.

Both of these possibilities rely on the GeoTiff storing its elevation data as floats, since this is only format in which the raw elevation data is stored, so the easiest option may be what you say, just write a little script to set the y position from a text file.

If you want to email me or get to me one of your GeoTiff files once you create it, I can inspect it and determine if its in the correct format. There's no point to add this extra functionality if not (unless someone else request it).

Regards,
Kyle Gillen

 

Hey,

I've got another quick question...
Can your asset load 32-bit GeoTiffs? I have been using a GIS program called GlobalMapper to process all the DEM data and I get the best results with 32-bit GeoTiffs. Unfortunately converting them to 16-bit GeoTiffs converts the elevation values to integers giving a stepped result which is not ideal for real world terrains.

Regards
Ved

 

Yes, the tool should be able to handle 32 bit uint, int, or float values, though only float values have been actually tested (but that is probably what your program is using). If you can send me a sample file I can test it out for you to make sure it does indeed import correctly. Just to be safe!

 

Hello everyone,

I just wanted to mention that the latest update to the package is available in the Unity Asset Store. This is version 2.1.0. This version incorporates some additional features requested by a user:

1. When importing GeoTiff or Terragen files, you can now set the y position of the created or existing terrain to the minimum (lowest) height in the heightmap file. This is primarily intended to be used in importing tile sets from GIS data in which the min and max heights vary across tiles and the tiles do not line up correctly when each has the same y position.
   
   
2. When importing tile sets, you can now import or modify sets with missing tiles (previously an error would be thrown when a heightmap or alphamap file was missing, or an existing tile set was missing a tile).

Also, the package will be included in the upcoming Asset Store sale at a 20% discount!

 

And the package is now on sale at 20% off ($12 - $3 savings). Enjoy!

 

When checked "Individual Tile Pieces" flag and pressed Initialize Import Button, import stops on a first tile with error:

'FormatException: Index (zero based) must be greater than or equal to zero and less than the size of the argument list.
System.String.FormatHelper (System.Text.StringBuilder result, IFormatProvider provider, System.String format, System.Object[] args) (at /Users/builduser/buildslave/mono/build/mcs/class/corlib/System/String.cs:1925)
System.String.Format (IFormatProvider provider, System.String format, System.Object[] args) (at /Users/builduser/buildslave/mono/build/mcs/class/corlib/System/String.cs:1873)
System.String.Format (System.String format, System.Object arg0, System.Object arg1) (at /Users/builduser/buildslave/mono/build/mcs/class/corlib/System/String.cs:1858)
TerrainImporter.RawHeightmapFileImporter.ImportHeightmap (TerrainImporter.HeightmapFileImportEnumerator enumerator)
TerrainImporter.HeightmapImporter.ImportHeightmap (Int32 horizontalOutputResolution, Int32 verticalOutputResolution, Int32 horizontalOriginOfRegionToImport, Int32 verticalOriginOfRegionToImport, System.Action IncrementProgress)
TerrainImporter.TerrainImporter.ImportAndSetupTerrain (System.String heightmapImportName, System.String terrainExportName, System.String terrainDataExportName, System.String[] splatImportNames, Vector3 terrainPosition)
TerrainImporter.TileSetImporter.Import ()
TerrainImporter.Importer.InitializeImport (Double importStartTime, Double expectedTimeNeededToImport)
UnityEditor.DockArea:OnGUI()"

If uncheck flag, resolution of every tile is divided "Tile per side" times. How to obtain a source resolution of a tile?

P.S. For example, I have a 3x3 tile set. Every source .r16 image has 1025 heightmap resolution. I need total square by size of 12000x12000.
If flag "Individual Tile Pieces" is not checked, I got in result:
- every tile with size 4000x4000,
- heightmap resolution 513,
- detail resolution 680 etc.

But I thought every tile should have heightmap resolution 1025, am I right?

 

You are seeing that exception due to a bug in my code when an error message is suppose to be printed due to incorrect file size. Luckily the bug only appears in one spot so I know what the actual issue you are experiencing is.

Basically, the file size of your heightmap is not large enough to support the terrain heightmap you are trying to create.

However, this error may pop up if you forget to set the file size under "Heightmap Import Settings," which is required when importing raw files (as the file size cannot be read automatically from the file as is the case with other formats). So first make sure you enter 1025 for the File Width and File Height.

As for the "Individual Tile Pieces" flag, for a 3 x 3 grid you will need to have this flag enabled (explanation below). Then just set the size/resolutions for each individual tile piece, so:

- 4000 x 4000
- heightmap resolution 1025 (since that is what you said each .r16 file is)
- detail resolution: Whatever you want (I am guessing 2048 if that 680 is any indication).

Basically when the "Individual Tile Pieces" flag is enabled, the sizes/resolution specified are for each individual tile in the tile set. If the flag is disabled, then the sizes/resolution specified are for the entire tile set, and in order to get the sizes/resolutions for the individual tile pieces, each size/resolution is divided by the tiles per side.

However, this will not work for a 3 x 3 grid because drop down options for Heightmap, Control Texture, and Base Texture Resolution have predefined values which can only be properly divided by a power of two number (2, 4, 8, 16, etc.). That is, they can be divided by 3, but the resulting resolution will not be valid, and so the tool will convert the number to a value that is valid (but this will result in an incorrect import).

Let me know if the above suggestions do not fix your problem, and thanks for purchasing the tool!

Best Regards,
Kyle Gillen

 

Thanks for a quick response!

I enter 1025 for File Width and Height, and there no error but only a pop-up message like a "The number of height point values (1048576) in the file does not match the expected number of values (1050625) given the manually set file resolution (1025 x 1025).

Just in case, my WM Tiled Build Options are set by default:
- Tile Resolution 1024x1024
- Tile per side 3x3

Cheers,
Ivan

 

The tile resolution when exporting a heightmap from World Machine should be a power of two + 1 value, so change that to 1025. Note that if you need to export an alphamap or other non heightmap file you will need to switch it back to a power of two value. This is annoying, I know. I wish World Machine had a dual resolution export feature.

 

I thought about 1025 in tile resolution, but can't believe it. Finally, it works: got a tiled terrain in a seconds!

I must say it was my personal hell on previous scene with remastering a tiles by hand. But such a solid and comfort workflow now!

Thank you for a tool.

 

I am glad you got it importing correctly. I wish it was not necessary to create separate exports from World Machine for the different resolutions. I am looking into this!

Note that for raw files coming from World Machine, I often find that the "Flip Vertical" option needs to be checked under Heightmap Import Settings in order for the terrain to line up as they do in World Machine.

 

Improvements Incoming (submitted to store, should be available in a week or so).

1. You can now scale your imported heightmaps either up or down (depending on if the heightmap you are generating within Unity is larger or smaller than the imported heightmap). This can be useful if you want to preserve all of the features of your heightmap but can't import the heightmap at its native resolution (either because it is too large or because it is not a power of 2 + 1 value). When scaling heightmaps that are a part of a tile set, edges can be preserved so they line up after scaling using the "Preserve Edges" option. Currently only Nearest Neighbor and Bilinear Filtering are available as scaling methods, but more may be added in the future.
   
   
2. Added limited support for multi threading. This is used in the scaling operation (which is a new feature) and in processing GeoTiff files in some situations, so you will probably not see a performance improvement unless you are using GeoTiff files.
   
   
3. When importing GeoTiff and Terragen files, it is now possible to choose how non normalized elevation data (if it is in that format) is normalized (to a value between 0 and 1 which Unity can utilize). This is especially useful when importing tile sets, as it will allow you to normalize every tile in the set within the same range (which should full encompass the range of elevation across the set), ensuring that edges line up properly. See Terrain Importer Guide for more information!
   
   
4. You can now import tile sets whose rows, columns, or both rows and columns are in reverse order. These are tile sets with their first row starting at the top rather than the bottom, and/or their first column starting at the right side rather than left side. Simply specify a first row/column value that is larger than the last row/column value to import in reverse order (note, the tile set generated within Unity will always be in non reverse order!).
   
   
5. Added Gizmos folder with an icon for the Terrain Importer Scriptable Object, to help you better identify it in the Project Hierarchy.

 

I just wanted to let you know that with the next update (see post above this one) scaling has been added. While it's always best to just export from world machine at 1025 or some other power of 2 + 1 resolution, the new scaling option will give you the option to import 1024 (or really any resolution) heightmaps!

 

The latest update (2.2) is now live on the Asset Store!! Here are the changes once again:

1. You can now scale your imported heightmaps either up or down (depending on if the heightmap you are generating within Unity is larger or smaller than the imported heightmap). This can be useful if you want to preserve all of the features of your heightmap but can't import the heightmap at its native resolution (either because it is too large or because it is not a power of 2 + 1 value). When scaling heightmaps that are a part of a tile set, edges can be preserved so they line up after scaling using the "Preserve Edges" option. Currently only Nearest Neighbor and Bilinear Filtering are available as scaling methods, but more may be added in the future.
   
   
2. Added limited support for multi threading. This is used in the scaling operation (which is a new feature) and in processing GeoTiff files in some situations, so you will probably not see a performance improvement unless you are using GeoTiff files.
   
   
3. When importing GeoTiff and Terragen files, it is now possible to choose how non normalized elevation data (if it is in that format) is normalized (to a value between 0 and 1 which Unity can utilize). This is especially useful when importing tile sets, as it will allow you to normalize every tile in the set within the same range (which should full encompass the range of elevation across the set), ensuring that edges line up properly. See Terrain Importer Guide for more information!
   
   
4. You can now import tile sets whose rows, columns, or both rows and columns are in reverse order. These are tile sets with their first row starting at the top rather than the bottom, and/or their first column starting at the right side rather than left side. Simply specify a first row/column value that is larger than the last row/column value to import in reverse order (note, the tile set generated within Unity will always be in non reverse order!).
   
   
5. Added Gizmos folder with an icon for the Terrain Importer Scriptable Object, to help you better identify it in the Project Hierarchy.

 

The guide has also been updated and should be your go to source if you are having any trouble understanding anything. The copy on the website has not been updated yet though so make sure to use the one included with the package.

 

@gilley033 Hey, just pulled down your tool to utilize some jpgs as raw input's. Thank you! I am having one problem. My maps are coming in VERY blocky. Any ideas?

 

Can you email me the heightmap file and Importer asset that contains the import settings? kgillen@deepspacelabs.net

I'm surprised you are able to import anything. JPG is not a supported format for heighmap importing . . . but perhaps I am confused about what you are doing?

 

My apologies, I did convert it to a PNG. I'll get that email out to you.

 

Thanks, I received the file. I tested to make sure there wasn't an issue with the .png import code, by exporting a heighmap from World Machine as both a .r16 file and .png. Both imported without the blocky look and pretty much were identical. So I am left to conclude that this is an issue with the file you are using. Do you have access to any other files to test? Where did you generate these files from?

The png import is fairly straight forward. The png file is loaded into a Texture2D via the Texture2D.LoadImage method, and then for each heightmap point Texture2D.GetPixel is called and the grayscale value of the Color that is returned is used as the heightmap point value. I make this point just to say that there is very little that could go wrong during this process.

If you have reason to believe, after further testing, that the file is not at fault, please let me know!

 

I pulled a jpg from a Gaia stamp, imported it into GIMP and simply exported it as a PNG.

 

Thanks for looking at it. Never heard of World Machine, looks pretty cool.

 

Hmm, if that's the case than perhaps it isn't the png file. I will look into the issue more to see if there is something else going on.

 

@jnbbender

I converted a different file from Gaia (I own it as well) and tried to import it into World Machine and saw the same blocky look there, so I am even more confident that it is an issue with the file. It doesn't seem blocky when you are looking at it in an image editing program so I'm not sure what is going on. But I don't think it's any issue with my PNG import code. I'm not sure what else to tell you besides try and get a hold of a different heightmap file. Or perhaps the creator of Gaia will have a better idea of what is going on.

Good luck! I will let you know if I discover anything else.

 

Thanks soooo much for all your work. I've just been trying to lay some sort of foundation with a heightmap, it doesn't have to be from Gaia. I'll try and pull something from the internet.

 

@gilley033 The reason I purchased your tool was to utilize .png files as heightmaps instead of .r16 files. I do notice that you use World Machine a lot but I was wondering if you have an example of just a straight up .png heightmap that would work (or tiff).

 

I've got to investigate this further. I exported a png from World Machine and it definitely looks blockier than the same file in .r16 format from World Machine once imported using my tool. I am not sure if this is a png issue or an issue with how I am using the grayscale value of the colors from the png file. I'll let you know what I find.

 

@gilley033 I performed these exact steps https://unity3d.college/2017/07/17/importing-real-world-terrain-unity-free-terrain-party/ and it produced exactly the same results as your tool.

 

Just to be clear, are you saying that the resulting terrain was blocky or not?

Edit: I downloaded a png file from terrain.party and it was not blocky. So I think there must be an issue with certain png files. My best guess is that some png files are 16 bit and during the import process the png file is converted to 8 bits which causes data loss and many values which were previously different to get converted to the same value, causing the areas of flatness. The investigation continues!