werner.poetzelberger Posted October 27, 2022 Share Posted October 27, 2022 (edited) I create a Terrain using height map and an Image layer, both are overlapping. For some reason I get 2 layer maps. One is twice as big and black. The other lies above and holds the albedo color. My question: Why are there 2 layers and y is the one twice as big? Why then is the layer culled by the camera and is revealed in a certain distance? thx. werner I am observing that in a single layer as well: Somehow the Heightmap is visible as Albedo and is blended with the real 'Albedo' in a certain distance. Nevermind, its a classical missleading issue. Can I turn off SSS for the Terrain itself? Edited October 27, 2022 by werner.poetzelberger Link to comment
bmyagkov Posted October 28, 2022 Share Posted October 28, 2022 Hello, Werner! 18 hours ago, werner.poetzelberger said: Why are there 2 layers and y is the one twice as big? The thing is that the Sandworm tool will merge data between each other only if used sources have the same density. In the other case, each source will have its own ".lmap" asset. As you can see in World Hierarchy after generation you've got two LandscapeLayerMap assets where both of their names ends on "_41.97mpx" and "_11.33mpx" which is literally means their original density. I guess it's quite hard technically to blend data like this with such a big gap in their original resolution. So, there is nothing to worry about and everything went out as expected here. As I can see from screenshots the big one are contains height data and smallest one is used for imagery here. 18 hours ago, werner.poetzelberger said: Why then is the layer culled by the camera and is revealed in a certain distance? I can't tell for sure at the moment but most likely bunch of the issues comes because of choosing unsuitable projection for used source data. At least that one where is one lmap is bigger than the other and this culling artifacts too. This is may happens because some of projection might be completely unsuitable for a given region and can completely break the data on the output. So, please try to use another projection such as suggested EPSG:32107 and follow the messages in the console since they may helps us to debug what is actually happens. Thanks! Link to comment
werner.poetzelberger Posted October 28, 2022 Author Share Posted October 28, 2022 Hey. Thanks for that explanation. I wil try the different projection for sure. Basically we dont care too much about the correct projection and location in the world as we do our artworks, Its just way more convinient and accurate in creation process. I could manage a fairly good result just by using EPSG 3395. I will try EPSG 32107 as well lets see. The Layers/blending thing was explained in the other thread, thanks for that. This issue above was the Screen Space Shadow! Would be convinient to turn that off for the landscape objects seoparately if we want to use it in the project. Cheers. Werner Link to comment
bmyagkov Posted October 28, 2022 Share Posted October 28, 2022 7 minutes ago, werner.poetzelberger said: This issue above was the Screen Space Shadow! Would be convinient to turn that off for the landscape objects seoparately if we want to use it in the project. As for me this behavior with Screen Space Shadows and ObjectLandscapeTerrain looks like a bug at the moment, but we need some time to investigate it on our side to say exactly. Moreover, there is no way to turn off Screen Space Shadows for ObjectLandscapeTerrain individually but I guess it would not be a problem if this feature will behave correctly, right? There is one more thing that I want to add on your output results - used sources for height data (output_USGS10m.tif) have such resolution which is could not be divided by two correctly while ObjectLandscapeTerrain designed to work with round values only. So, that's why part of your terrain are bigger than it's real data. OjbectLandscapeTerrain just internally made an upscale of the ".lmap" asset to the nearest round value and fulfilled it with "no data" values. So, basically you should not worry about it. I also may suggest you to try another projection EPSG 26711 which is may suits that data pretty well. We was able to find it used following instructions in our documentation. Thanks! Link to comment
werner.poetzelberger Posted October 28, 2022 Author Share Posted October 28, 2022 2 hours ago, bmyagkov said: There is one more thing that I want to add on your output results - used sources for height data (output_USGS10m.tif) have such resolution which is could not be divided by two correctly while ObjectLandscapeTerrain designed to work with round values only. So, that's why part of your terrain are bigger than it's real data. OjbectLandscapeTerrain just internally made an upscale of the ".lmap" asset to the nearest round value and fulfilled it with "no data" values. So, basically you should not worry about it. That make sense. 2 hours ago, bmyagkov said: I also may suggest you to try another projection EPSG 26711 which is may suits that data pretty well. We was able to find it used following instructions in our documentation. okay. Actually I have no idea what the EPSG geo pepository does ;)) But I try the 26711 2 hours ago, bmyagkov said: As for me this behavior with Screen Space Shadows and ObjectLandscapeTerrain looks like a bug at the moment, but we need some time to investigate it on our side to say exactly. Moreover, there is no way to turn off Screen Space Shadows for ObjectLandscapeTerrain individually but I guess it would not be a problem if this feature will behave correctly, right? Exactly. Shouldnt be an issue if that s a bug. Cheers! Werner Link to comment
bmyagkov Posted November 1, 2022 Share Posted November 1, 2022 Hello! On 10/28/2022 at 4:29 PM, werner.poetzelberger said: Exactly. Shouldnt be an issue if that s a bug. This issue was a bug for sure and fix has been already implemented in our internal version, it will also be included in following update next month. Thanks! 1 Link to comment
Recommended Posts