Processing a large UE map by regions and unable to eliminate seams

Using Gaea Ask for Help
,
1

I have been working on our round robin between UE and Gaea, and since we are working with a rather large map, we are using world partition in UE and we would need to perform the Gaea pass on individual UE regions for iteration.

We are exporting equal Regions to be imported in Gaea as individual HF’s, not tiles.

Obviously having the edges match up is a concern when you are processing a region at a time, so I am exporting an oversized region from UE to process, so that Gaea has the data from surrounding regions.
I have pushed it so far as 50% oversized, so rather than the 4081 that UE outputs for a given region, I’m writing out the surrounding tiles for a total of 6121.

In Gaea I am transforming those heightfields to the appropriate areas of the landscape (in case we do need to load more than 1 region at some point and to insure a consistent scale for Gaea simulations) and then I am creating Gaea regions that should match up 1:1 with the original UE regions and rendering those Gaea regions, as a way to crop the HF to the desired resolution.

Regardless, I continue to get seems along the border that do not match up between the 2 regions.

If there is a different recommended workflow here can you please point me in that direction.

2

Often the answer you’re looking for even when using regions.
/Unreal node is your global normaliser, so scrubbing back or testing very small scale to confirm with just a simple height field, that node and the region workflow, should clarify whether it work or you needed to

3

I’m not using the /unreal node to export. I dont believe that I have any nodes doing a normalization or auto level.
Its a file read/erosion/sediments/transform and then exporting from an adjust node
Is there some place within those nodes that is normalizing my data?

4

Anything that remaps, auto-levels, matches, or normalises height data changes the values based on a minimum and maximum range.

The problem happens when we split one big heightfield into tiles.

When it is one big terrain, the whole thing uses one shared range.

For example:

  • lowest height: 2
  • middle height: 5
  • highest height: 17

So every part of the terrain is judged against that same global range.

But when we cut the terrain into separate tiles, each tile now has its own local lowest and highest point.

So Tile A might have:

  • min: 2
  • max: 10

Tile B might have:

  • min: 7
  • max: 17

If each tile is normalised separately, the software stretches each tile to fill the full height range on its own.

That means the same original height can become a different value depending on which tile it is in.

So at the border between two tiles, the heights no longer match perfectly.

That mismatch creates visible seams.

The simple rule is:

If you normalise each tile separately, each tile gets its own scale.
If you normalise globally before cutting, every tile keeps the same scale.

5

is there any normalization that happens with the default nodes that I have listed?
I dont believe that Unreal is doing it when it writes out the map, but I will test it

6

/Adjust if you’re using most of it’s modes except invert and multiply I believe.

But it looks like you’re using it as an extra end point?

7

yeah it is just an end point. it shouldnt be performing any operations.

1 Like
8

The issue is the Sediments node. A small change on one far corner of the map will affect the result everywhere

Screenshot 2026-05-13 105918
Screenshot 2026-05-13 1059181917×1005 160 KB

Screenshot 2026-05-13 105819
Screenshot 2026-05-13 1058191919×1003 161 KB

9

This would definitely mean that processing neighboring tiles would leave seems, even if you process them both oversized so that you are grabbing overlapping pixels