Same here, yet my trenches are shallow enough so I can even them out quite efficiently with the smoothing brush (such tampering may remain visible in grazing light, though). Maybe should I double check the old process because the way I implement it also ends up in boundary glitches. I hope trying my method didn't make you lose too much time. I've just added a red warning in my previous post so future readers take this method with the adequate amount of salt.
Don't worry I´ve spent soooooo much time on preparing lidar data, trying your way was only a very small part.
Lulon, I need to ask you because I work on a very similar project like yours but I get errors and can't merge the xyz files. My project uses LIDAR data from Rhineland-Palatine and Hessen (and actually is not far from the borders of NRW). My CRS is also UTM32 N [ETRS89/UTM32 (EPSG:25832)]. You say your files were in .xyz format and so are the ones for Rhineland-Palatinate. However, I cannot merge these files in QGIS and got errors. What did you do to prepare or make the .xyz files work with QGIS? protonmw said I should convert them into a QGIS friendly xyz-format before using them to merge, but how? I cannot merge them, so using the merge tool falls away. I found the "Translate (Convert)" tool but can't convert all xyz files at once as I need to convert each and every of the 252 xyz files independently (which could take years), plus I'm not even sure whether this is really the correct way to do it. Here is my dedicated thread about the problem. Didn't you had such problems with your .xyz files from NRW, too? It's really a mess here with the xyz files I have from the state of RLP.
I decided to move a bit further with the Hessen part of my Lidar data, just to get to know about the steps after step 3 of your tutorial as all of these RLP and Hessen merging problems for the last 5 days made me sick. Now I came that far to import the Lidar and SRTM data into the Editor, however I have the two problems now. 1. The SRTM data (the two HGT files) doesn't show any height data in the Editor although I imported them into the relative plugin folder and selected "Use Selected Assets" for several times. But not even a single bump on the map. 2. I have the same issue as Zeo2113 mentioned before with the big blocks raising from the ground when you apply the Lidar data to a tile. My Lidar data for Hessen forms to big blocks: I thought about whether is has something with the sea level as well, as I indicated it in my route as well with 129,2 meters. However, you can edit the sea level further on, so I guess this shouldn't be a big problem and rather has something to do with wrong converting and merging the Lidar data in QGIS. I will read through this thread tomorrow when I have more time. I will also focus on using just one tutorial fully at a time, not summarizing tips of different tutorials like mixing Lukas and your tutorial as mentioned by VictoryWorks before
1. Hm that's weird, I'm quite sure I sent you the right files. I just checked again. Your SRTM coordinates should be N50E007 and N50E008. I use this website to get the HGT files but you need a free NASA Earthdata account. If I remember correctly you only need to tell them your full name. But it shouldn't be neccesary as the files I sent you must be right. Oh wait and also I think you cannot apply STRM like LIDAR. You can only create new SRTM tiles. If you want to apply SRTM you need to delete the tile and make a new one while SRTM selected. I think you can do it from the world composition window but it requires a bit of UE4 tile knowledge. 2. It would help if you showed the left panel with the options. But I guess maybe you didn't check Use Pseudo Mercator? Either that or you forgot to reproject.
Thank you for sending me the files, again. No, with the files is everything right. I opened them in QGIS and they cover exactly the area I need and even cover some more area which I maybe planned to extend my route to. So everything well with it and you exactly hit the right location. Thank you also for giving me your source of the SRTM data. I thought you maybe used the SRTM downloader plugin in QGIS to obtain them. But this way also seems nice and maybe even easier. I think there needs to be anywhere the cause of the problem. I mostly went by the way DTG Lukas did in his Route Creation Masterclass on YouTube as he also worked with Lidar data from Hessen, to be exactly Marburg (a city not that far from the location I try to get data and try to rebuild). However, in his tutorial he prepared the SRTM files before the video (which is bad for me and anyone else because we can't follow his exact same way to get them). I created the tiles from KML file before I imported the SRTM and of course Lidar data, as he showed. But anyhow in his video, he already has the SRTM height information in the map short after creating the tiles from the KML file, which is completely mysterious to me. I think I need to look closer at what he did exactly there and most importantly in which order he did what, but on the hand I already did that and I came to a different result. Why do I need to follow his way so exactly? Well, I found only very little information about the actual process of creating and importing the SRTM data into the Editor. I also watched the video of TrainSimGuy how to create terrain but I didn't got it until now. I guess I need to also watch his video more carefully and take care of the order in which is done what. I also would be very thankful if you could add a little bit more information about how you, Lulon, created and imported the SRTM data into the Editor in your tutorial itself. I guess it can help many people as well. BTW, your tutorial is missing point Nr. 4? Did you accidentally deleted this point by editing your post? Or was that just a numeration mistake? Yes, I checked Pseudo Mercator, as I already was aware of that this is causing problems to some people here. However, and this might be my mistake, again the order is important. I think it could be that I imported the Lidar files first and thereafter checked Pseudo Mercator, which probably can be the wrong way. But anyway, sure I can show you the left panel: Also what about the option "Create Landscape(s)" after I imported the SRTM data? I clicked on this as well but nothing happened. I heard and saw noone so far mentioning doing this. Is that even necessary? And if so, when? What I think is interesting and as I heard to be a common bug is that some assets like the both SRTM assets in my case do get unselected once I restart the Editor and reload the project. On the othe side the sea level doesn't change to its new value if you edited and jumps back to the default value with which you created the route. I'm still not quite sure if the sea level has anything to do with causing the issue as Zeo2113 also said he used the sea level information when initiating the route. I think I need to do everything new from scratch and start a new route following one exact tutorial to find out how do it righ and where the problem exactly lies in detail.
On the subject of “create landscapes” I have been creating individual SRTM tiles this way by going to the edge of the existing tiles and placing the red column cursor where the new tile is to be. This is my second attempt at making a route after having problems the first time and I created all of the tiles this way, leaving out the Lukas method of using kml to produce the track tiles, simply so that I could keep control of the tile production and to help me understand what was going on. I do accept that using kml can automate the tile making process and save time over the fully manual method. Where a tile becomes useless due to faulty LiDAR data it can easily be deleted and replaced using this individual create method.
You need to select the srtm data before you create the tiles from KML. As I said, you cannot apply SRTM if the tiles are already there. You must have selected the SRTM when creating a tile. If the tile is already there you have to delete it first. Or just start the route from scratch if you haven't done anything else. Lukas probably had SRTM in his tiles after creating the tiles from KML because he selected the SRTM data beforehand. I suggest starting with a blank route and watching the tutorial from the complete beginning and then follow along. That's how I did it and why I know how to import the SRTM. When I edit the terrain of my route, I don't use the sea level option. I leave it at 0. I don't know what it does. I bet you don't need it, too. I don't know if it matters when you select Use pseudo mercator as long as it's before you apply the Lidar. I would guess the program only checks it when you click Apply lidar. But you settings look fine to me. Did you reproject the data after merging it? You can use "Create landscapes" if you want. When you click in Create lanscapes, it creates a tile directly below you. It's like using the KML but it's the manual way of creating tiles. You can use it to test if your SRTM works.
I didn't notice I left out number 4. I guess it's just a numbering mistake. I might add some information about SRTM later.
So, I set up a new plugin and recreated the route and by looking closer to the terrain tutorials and what you said about the SRTM data, imported the SRTM files before creating the tiles and it worked, Problem 1 solved (Hooray!): Not the best resolution with 30 meters SRTM, but much better than every tile being left flat for sure. Now I only need to solve my Lidar problem. But I also did understand now a bit better how these Lidar data is applied to the tiles, when I got them merged, reprojected, tiled and .asc'ed correctly. Quick question: Do you see the little spark between the tiles on the hile? Should I just smooth the surface there or do I have to do anything else? However with the sea level thing: This time I omitted the sea level. The SRTM problem high probably got solved to importing and click on "Use Selected Assets" for the HGT files before creating the tiles, but I'm still not 100% sure whether this sea level parameter potentially could be a troublemaker. I don't actually understand what the purpose of this parameter is, when setting up your route, because we applying the water for the rivers and seas later on on our tiles in the height we want it to have. A sea level option would then make sense if there is some kind of automatic trigger option which gets a "seaside" to the indicated level, but I'm not sure if the option even has this purpose. Unfortunately, due the lack of information from DTG's side, we still don't know for sure what this option is actually doing. I also didn't heard Lukas or Matt say what it actually does in the streams. It could be a potential bug in this option which affects the height and terrain information of the tiles. So, I would recommend anyone not to use the sea level option, until it's absolutely clear from DTG what it actually does or not does. Don't use it yet, because you want to be your project data be as accurately as possible. This may lead you to problems with it later on.
Yes, just smooth the gap. I guess the sea level option is not used for actual water but for some calculation with the terrain height. I didn't need it for my route and I don't think most people need it. Maybe it's used for negative Lidar data below sea level? I don't know. I think water is just a plane with a water material.
so SRTM is not the same as what we get with KML file from google earth or Lidar? So is the .hgt same as SRTM
KML has nothing to do with SRTM or Lidar. KML is just for markers and paths on the map. It's a helper to automatically generate tiles in the editor. But it's not mandatory to use KML. SRTM and Lidar are both height models of the terrain. SRTM has 90 or 30 meter resolution and Lidar can have any resoution but usually a very detailed resolution like 1 meter. So they are kind of the same. But the editor handles SRTM and Lidar differently in two seperate steps. First create low resolution tiles with SRTM and then optionally apply high resolution Lidar. .hgt is just the file format for SRTM. Lidar often uses .xyz or .tif or .laz.
Yes, this is something I noticed when I've read through your tutorial. You thought that the .kml file has any kind of height data embedded already, but this is not the case. The .kml file only contains the placemark informations and the route you draw in Google Earth Pro. The SRTM (the NASA shuttle data) is the one which has the low resolution DTM/DEM (one point per 30 meters) information in it and it's stored in .hgt files. Lidar data on the other hand, has the high resolution DTM/DEM information embedded. If you're lucky, you find 1 point per 1 meter resolution lidar data for your route for free. I have an issue for my route where the biggest part of it is covered only by somehow broken 25 meter res Lidar data. In the end, it's a lucky wheel, but just saying also the 30 meter SRTM resolution may be fine to create a decent and good looking route, depending upon how much assets and foliage you place to "hide" the inaccuracy of the DTM and how much this inaccuracy actually shows off due to the profile of the landscape on its own (how flat the area is).
So, I've read DonnyDave 's tutorial and watched paintbrushguy 's importing terrain video + DTG Lukas terrain masterclass again and IT WORKED!!! WOHOO!!!! Finally! Lidar data in my project! After all the struggles of more than one week!!! The last two pictures show the sharp edges, but I guess I can just smooth them easily in comparison to the complains I had before. Again thank you to all for the documentations!!!
Oh, another question just came up. I applied Lidar data to the edges of where it is available and I got this massive block. Anyone can give a tip about to deal with it? Recreating the tile with SRTM data? If so, how do I do that? I can't find an option in the right click menu to reload a tile? Or use a dedicated to way to smooth it down again?
I had this once. I don't exactly remember what I did, but you need to delete the tile and create a new one. I think you have to open the world composition then hover over the tile you want to delete: Remember the name, for example LT_x1_y-3. Close the editor. Open Windows Explorer, go to your map's tile folder. Find the file with the same name and delete it: Only the file with LT. Then open the editor. Go to that tile, there should be a hole now. Fly over the hole, and in route building mode select the SRTM as usual and click in Generate Landscape(s). That should recreate the tile underneath you. Backup your tiles if you don't trust it.
The next version of public editor should remove the problem of areas with no data and fixed the rugged edges
will there ever be a time we can use tif files instead of having to convert to asc files for our terrain?
Lukas said in the stream, that this can't be done because the file extension .tif is already used in the Unreal Editor. So, .tif is not always the .tif we refer to, when looking at Unreal. However, and at this point I'm with you, I didn't understand exactly why we can't use it then. Probably Unreal expects a different format of .tif files (hence they seem to have a different purpose in there). I think this shall be the only reason. Otherwise, I didn't tried to import the .tif files just as they are into the Editor. Don't know what happens when you do.
tif is already a format which unreal uses for textures. So it will assume you're trying to import a texture rather than elevation data in GeoTIFF format
What is exactly the difference between elevation and texture in Unreal? As the elevation data becomes a part of texture/terrain it seems?!?
Hi! I keep getting these weird renderings with flat top mountains, mostly where there is water but also on a few random spots. Other than following the guides above I also used Oysteins suggestion to enter -9999 on Nodata value for output bands (Was to remove border spikes since they appeared.) The lidar originates from .laz files downloaded from Lantmäteriet and used SWEREF99 TM + RH2000 height EPSG: 5835. Split the .laz files into smaller sections (To avoid diagonal watermarking) and then converted from .Laz to .tif and then continued from step 2 from the guide above.
Where was I supposed to do that? I followed DonnyDave 's tutorial for route creation at first and there wasn't any mention of putting the sea level value. EDIT: Se level value is 0,0 in the Editor. Note that a few days prior, I didn't have that kind of problem, I had problems with LAStools watermarking the lidar data with diagonals, as well as having border points, wich was totally different problems that I saw some solutions for here at DTG forums and around the internet.
The sea level is optional to set if you create the route project. You might be able to alter it later on in Route Building Mode, but I don't know whether this is effective or only really can be set while creating the route since I experienced it might jump back if you alter the value in the settings. If you read some of my posts before, I raised doubts about this parameter/option. As you stated the problem is mainly related to water areas, one initial thought of mine was whether it has something to do with it, but it does not need to have a relation. Just a thought. I would try to change it or create a new project with the sea level of your reference point of the coordinates, and see if that makes a change. If not, it actually could be caused by the problems you had with your Lidar data before. Just saying also this, I had the same issue with the flat mountain blocks when applying Lidar with black data to my tiles, and the black data causes these. It is possible that anyhow the water data got this same black no data value now, and thus it appears as flat blocks. One option to get rid off the flat mountains which will 100% work is just flatten and smooth them down with the smooth tool in landscape mode. But this can take a bit of time to get it done to level, where you don't notice a change between both levels from the visual view.
Now I have made some experiments and compared several exports within the editor, some I did enter -9999 on Nodata value for output bands, for others I left it empty, but no matter what, I still have these 1km plaetau's just like everyone else. The only difference were that the spiky borders were less present when I applied -9999. Seems like I am going with that for now.
In the guide where you're creating the lidar files I mentioned you add -9999 in a certain part, Not sure where at the moment as i'm still installing software on my computer. But doing this reduces the spikes in your second picture, the raising in the first picture maybe an area that you have no Lidar data for, either because there wasn't any for that area or you never had that area selected when you were gathering your data. The only other thing I can think you could have that happen is if you never imported or never selected the file for that particular area
Normally if you added the value -9999 "fill NoData" in QGIS when you converting your tiles in PseudoMercator likes mentioned by DTG Lukas in the stream. You should have these effects reversed, I mean "peaks or plate mountains" like on your pictures should go down compared to the terrain level in the editor. It is then more easier to correct these effects with the editor terrain brush tool. These effects are coming because you have "pixel holes" on your tiff tile when you converted your LAZ file. This is normal because water or some shiny objects are not been correctly detected by the Lidar beam when they make their point cloud, so considered as no-data. To avoid this there are many ways in QGIS GDAL to fill these holes, but I haven't found a satisfactory solution at the moment. I hope the editor update will fixes these issues?
So im stuck right at the start where i have to reprojct the merged lidar i get 2 error messages ERROR 3: OUTPUT.tif: Free disk space available is 1734349991936 bytes, whereas 703822242515760 are at least necessary. You can disable this check by defining the CHECK_DISK_FREE_SPACE configuration option to FALSE. and The following layers were not correctly generated. • C:/Users/Name/AppData/Local/Temp/processing_PCeTfW/a6a529cf79294d28a968f7685dff1e58/OUTPUT.tif You can check the 'Log Messages Panel' in QGIS main window to find more information about the execution of the algorithm. therre is nothing on this disk besides my OS and a couple steam files, its a 2TB with 90% free space, also the route im trying to do is only about 25miles so i dont know what im doing wrong Maybe im importing the lidar wrong as when i do so and merge the black boxesa it adds are like 3x more than the lidar area itself
I successfully set up a route with Lidar data, then was having trouble with track not snapping to terrain so I reapplied Lidar data to that tile. Big mistake. It's now a huge flat plateau. I couldn't figure out how to fix it, so eventually I started a new map to get a fresh start (using the same source files, I didn't go back through QGIS). I followed DonnyDave's tutorial again and the STRM data works fine, but as soon as I apply Lidar data, I get nothing but a perfectly flat plateau. What am I missing?
My Lidar is not working, it show up perfectly in qgis, but in the editor, its just flat Thats all of what shows up When saving the level, the hole disappears
I am doing the QGIS and using SRTM Downloader and it not downloading file is there any thing I am doing wrong
does anyone know how to fix this. it was working fine yesterday and now i keep getting this when merging. only reason i had to remerge is besuase the reprojection OUTPUT.tif files dont save to the same spot as the .hgt and also dont save as a OUTPUT.tif in general and insted saves as 1 picture not numerous lidar ones
I've been looking for source data for Southeast Scotland but all the data I can find is in a .aux format. I've tried using QGIS to convert it to .tif but to no avail. Any ideas?
Anyone know what can cause the Warp Reproject to take ages, it's moving super slowly. I've follow the tutorial video exactly but yeah something doesn't seem right cause seems for everyone else it's pretty much instant.
For me the source CRS was an issue before, so double check if it's right and if there are any alternatives
What you mean sorry ? I have ended up being able to get it jnto editor but it gives me flat terrain when I apply lidar and there defo is lidar.
I just tried creating the first few tiles of landscape for my route, and something seems to be wrong with my lidar data. After applying it to a few tiles, the result looked like this: No idea what's the problem here. I double-checked the .asc files I imported into the editor in QGIS, and the seem to be fine. Any help would be much appreciated!
Usually this happens when you converted tiles with blacked out edges. It's these black or partwise black tiles which give the flat squares regions in your terrain. Did you deleted all black tiles? Can you show a screenshot of the tiles in QGIS?
Hmm, without the bit of weird cutting at the top (don't know if this already is in original or made by you) but I think the problem is more likely to be a problem with a wrong parameter or so done at the conversion processes, because your applied Lidar in the Editor has these equal placed stripes (almost like a grid) onto it and I can't see anything wrong like that with the tiles in QGIS.
I have the feeling you reprojected it wrong. It looks like when I was trying to find out how the Lidar importing works. It was because I didn't reproject it correctly.
Yes, the reason for the edges being so weird is the fact that this region is just at the borderline between France and Germany. But in this case, this doesn't seem to be the problem. In the editor, the landscape with applied lidar data on it ressembles, as you said, to a grid, with square cells each containing a tile of lidar-covered area. I noticed that, if you "scaled up" the lidar tiles so they fit their "cell" exactly (so there is no space between the cell's edges and the edges of the "lidar area), the landscape would look as intended.
I followed DTG Lukas' masterclass for the whole process (except that the source CRS for the reprojection process was Lambert 93 for me).
Normally, the reprojection should automatically scale it up. I mean if scaling it up works for you, you could just do that. but I would check with the satellite images if everything still lines up.
