terrain file split

[demostenes]

Is there any reason, why height map and masks are in one .lmap file? It means in case of any small change I have to commit several GB change into VCS in dev stage and prepare several GB patch for players in production stage. It would help to seperate it as much as possible into more files, even split into some chunks like it was in Unigine 1.0 many years ago. Of course if it is possible....

[silent]

Hi Jirka,

The only option that you may use is to split terrain to multiple landscape layer maps. In that case your base terrain will only consist of a heights and other layers will make a final picture.

New .lmap file structure was designed that way to be more artists friendly and it's contains all the information that would need to be displayed after a simply copy between the projects. Filesize will be smaller when some texture compression algorithm will be implemented in the future SDK versions. Also it contains acceleration structures for fast intersection / collision tests.

Thanks!

[demostenes]

10 hours ago, silent said:

Hi Jirka,

The only option that you may use is to split terrain to multiple landscape layer maps. In that case your base terrain will only consist of a heights and other layers will make a final picture.

New .lmap file structure was designed that way to be more artists friendly and it's contains all the information that would need to be displayed after a simply copy between the projects. Filesize will be smaller when some texture compression algorithm will be implemented in the future SDK versions. Also it contains acceleration structures for fast intersection / collision tests.

Thanks!

Ok, thanks for explanation. Is there any real performance overhead for this suggested approach (several landscape layer maps insted of one)? I ve tried to do some and it seems impact is small to none. Does it mean, that engine builds final terrain from all layers at once, so it shouldnt be big difference if I have 1 or 10?

Edited July 13, 2020 by demostenes

[silent]

It highly depends on the overall terrain size and data density (as well as the amount of lmap files). However, there is no strict limitation for the lmap files count.

Please don't forget to check the performance while streaming is active (camera movement) when you finish splitting your landscape into the multiple lmaps and you won't get into the sudden trouble when adding a new layer will somehow affects the framerate.

Merging all the lmaps into the final build is not yet implemented, but planned. That will also give a boost in performance in the final release build.

Thanks!

[demostenes]

15 hours ago, silent said:

Merging all the lmaps into the final build is not yet implemented, but planned. That will also give a boost in performance in the final release build.

Thanks!

Thanks. Great, this is exacly what I was missing.

[demostenes]

When I split terrain into several lmaps, it has one drawback. Sooner or later I will need to edit heightmap on the border between two lmaps (in the worst case 4) and this will became problem. Any solution to this?

 

Edited March 7, 2021 by demostenes

[silent]

Hi Jirka,

We wish there was some silver bullet that would help us to achieve a smaller lmap size and as well an ability to split the lmaps to even smaller chunks to handle the overlapping areas.

Right now we can't really see any options to handle this in more convenient way. lmap file was intentionally designed to be 'all-in-one' container that will store all the necessary information about runtime object (as well as the convenient way for the Editor built-in asset system).

Redesigning how lmap files generated and used is not possible without redesigning the runtime part and we don't really want to do it, because the amount of work will quickly become enormous (basically, another full-time research for several months). 

We will continue gathering feedback about current LandscapeTerrain object implementation and sooner or later will understand how to develop and improve it further.

Thanks!

[demostenes]

8 hours ago, silent said:

Hi Jirka,

We wish there was some silver bullet that would help us to achieve a smaller lmap size and as well an ability to split the lmaps to even smaller chunks to handle the overlapping areas.

Right now we can't really see any options to handle this in more convenient way. lmap file was intentionally designed to be 'all-in-one' container that will store all the necessary information about runtime object (as well as the convenient way for the Editor built-in asset system).

Redesigning how lmap files generated and used is not possible without redesigning the runtime part and we don't really want to do it, because the amount of work will quickly become enormous (basically, another full-time research for several months). 

We will continue gathering feedback about current LandscapeTerrain object implementation and sooner or later will understand how to develop and improve it further.

Thanks!

Thanks. It is not that big issue, we can live with that. It just means, that splitting terrain into more lmaps is not an option in case you plan manual editing. Currently I just want to decide, if/how much terrain insets we will use. In such case it makes sense to have option to bake all into one for production release, but you said it is planned, so all OK.