Height Remap option with the Unreal node

Using Gaea Ask for Help
1

Hello,

I have a question about using the Height Remap option with the Unreal node.

I am currently creating terrains using Unreal Engine and Gaea 2. My workflow is to create a simple terrain in Unreal, export it to Gaea for further editing, and then export it back to Unreal.

However, when I connect the Unreal node at the end of my node graph, the terrain height starts to change compared to the original. In the viewport, adjusting the Height Remap values in the Unreal node seems to visually match the original terrain height, but after building and importing back into Unreal, the height and overall elevation no longer match the original terrain. This causes significant issues in my workflow.

Am I using the Height Remap option incorrectly? Or does modifying Height Remap in the Unreal node not actually preserve the original height values?

What would be the correct workflow to ensure that a terrain exported from Unreal, edited in Gaea, and then re-imported, maintains exactly the same height and elevation?

It seems that simply connecting the Unreal node is not enough to achieve an accurate round-trip back into Unreal.

Any guidance would be greatly appreciated. Thank you.

Gaea professional and unreal node problems
2

The /Unreal node will auto level the output to ready it for Unreal Engine.

The bigger issue here however is that round tripping with UE isn’t really that practical for this workflow.

You can attempt it

Just be aware of Unreal’s remapping requirements every time you go in and out again

You can see here the manual method to see how unreal will remap -256 > 256 range, you must essentially do this process backward.

The other is that unreal resolution is lower than the typical power of two.

You would be reducing the quality of the resolution every roundtrip.

You can build a Gaea workflow that reintroduces quality every time, just be aware of these things

For remapping the auto level you could potentially use /match node as well

1 Like
3

Yeah, just echoing Ty’s points. The Unreal node will auto level your data no matter the modifiers. This is what you want so your data is using the full bit depth. How that data is then represented/scaled in Unreal all comes down to the scaling of the Landscape actor.

When you are sculpting your “block out” terrain in UE, first scale your landscape actor to your desired size according to the guide Ty linked. That way when you re-import an autoleveled heightmap, it will be scaled correctly.

4

Dear Quadspinner Team,
Thank you sincerely for your detailed response. You addressed the exact core issues I have been struggling with, and I deeply appreciate your guidance.
Allow me to summarize my specific situation before asking my questions:
My Setup:

Unreal Engine Landscape Z-Scale is fixed at 100 (team requirement, cannot be changed)
Normal working range at Z-Scale 100 would be [-256 to +256]
However, to achieve sufficient mountain height, I moved the Landscape actor’s Z-location upward, shifting my effective range to [-128 to +384]
Negative values are required because my terrain includes sea level and underwater areas
I have been searching for a way to handle this offset adjustment within Gaea before exporting

What I Have Already Tried:
I tested both methods you mentioned:

Manual Import (Manually Importing Gaea Heightmaps into Unreal Engine)
Gaea2Unreal plugin

Both methods technically work for exporting to Unreal. However, the critical problem with both approaches is that the Landscape Z-Scale gets changed to a value other than 100 upon import. In our team environment, other departments require the Z-Scale to remain strictly at 100 for technical consistency. This makes both solutions currently unusable for our pipeline.
This is why I have been trying to finalize all height calculations and remapping entirely within Gaea, so that the exported heightmap imports correctly into Unreal with Z-Scale remaining at 100.

My Core Questions:
Following your suggestion, I would like to try the Match node, but I am facing difficulty with its correct implementation.
My concern is this: even if I successfully align the height values using the Match node, adding the Unreal node at the end of the chain appears to apply Auto Level again, potentially overriding the corrections I made.
Could you please provide guidance on the following:

  1. How should the Match node and Unreal node be used together in this scenario without the Unreal node’s Auto Level interfering with the intended output?
  2. Is my hypothesized workflow on the right track?
  • Connect a Constant node to the Reference input of the Match node
  • Manually define the Min/Max range (e.g., -128 to 384) within the Constant node
  • Place this before the Unreal node in the graph
  1. Is there a recommended workflow or best practice for remapping the Auto Level behavior of the Unreal node while keeping the final output fully compliant with a fixed Z-Scale of 100 and a custom height offset in Unreal?

Any guidance, example node graphs, or workflow recommendations would be incredibly helpful. Thank you again for your time and expertise.
Best regards.

1 Like
5

This is the right approach to keep each stage as clean as possible.

Instead of match because the unreal node will auto level anyway.

It seems because you have a strict 100z you’d likely want to set the Terrain Definition in Gaea’s build settings to 512.

Following Unreal’s tech docs and manual formula

Z scale = max height in meters * 100 * 0.001953125, which makes 512 m map to 100

When the unreal node auto levels your data should read 512m.

You can check this in Data view - Stats tab in Gaea

[!note]
Changing you’re terrain Def main visually change your terrain look you can offset this(I’ll need to get to a PC to show case how if that’s a problem for you)

Try this one and report back

1 Like
6

Thank you for the detailed breakdown! The formula makes perfect sense.

Regarding my current setup:

  • I am actually already using 512m for the Height in the Terrain tab under Build Settings. My current dimensions are set to [Width: 2017m / Height: 512m].

  • I also verified that the Data view - Stats tab indeed shows exactly 512m.

  • For the export file format, I am using UshortRaw16.

Given these settings, are there any other parameters in the build or terrain menus that I should double-check?

To summarize the intended workflow based on your advice:
Would the most appropriate approach be to keep the Unreal node at the very end of the graph, and handle all offset adjustments just before connecting to it?

Since you mentioned being able to showcase how to handle the offset settings when you get to a PC, I would be incredibly grateful if you could share that guide or advice! I believe properly managing the offset is the exact missing piece I need to solve this issue.

Thank you again for all your amazing guidance so far. I look forward to your reply!

7

The Unreal node should always be the last node for your heightfield. Even though your Terrain Definition is set in Gaea, there’s still that head room, so when it gets normalized it doesn’t match that shape you see in Gaea.

Because the UE node will always export normalized data, and because you have to keep the Z-scale at 100, you have to ensure your heightfield data already takes up a normalized range for it to match between the two programs.

You need to take the extra headroom/negative space of your landscape and “hide” it underwater, so your seafloor is at 0 and your highest peak is at 1.

I’ll just mention, while I haven’t practiced this workflow, and I’m sure you can get it working with good results with a little tinkering, Landscape actors are meant to be rescaled as needed.

1 Like
8

Hi TyXanders,

I hope you’re doing well.

I’m following up on my previous reply regarding the Offset adjustments. As we discussed, I’ve confirmed that my Terrain Definition is set to 512m and the stats tab reflects this correctly. However, I am still struggling with the visual changes and the height synchronization ($[-128m \text{ to } 384m]$ range) when the Unreal node performs its auto-leveling.

You mentioned earlier that you could showcase how to handle these offsets once you were at your PC. Since maintaining a fixed Z-Scale of 100 is critical for our team’s pipeline, your guidance on this specific offset setup would be the “missing piece” to complete my workflow.

Could you please share the node setup or advice on how to compensate for the visual changes while keeping the precise offset before the Unreal node?

Thank you again for your time and for all the help you’ve provided so far!

9

Hi @HK_JUN,
Thanks for confirming those settings.

I had a chance to test this more directly, and I think the main issue is a conceptual one rather than a different Terrain Definition value.

For Unreal, a Landscape Scale Z of 100 represents a total vertical height range of about 512m.

So this part is correct:

512m Terrain Definition Height > Unreal Scale Z 100

Your desired range:

-128m to +384m

is also a 512m range. It is simply shifted upward by 128m.

So the Unreal-side setup should be:

Landscape Scale Z    = 100
Landscape Location Z = 12800 cm

assuming sea level is intended to sit at world Z = 0.

The important part is that sea level must sit at 25% of the final normalised height range:

0.00 = -128m
0.25 = sea level / 0m
1.00 = +384m

So I would keep the Unreal node at the end of the Gaea graph, keep the Terrain Definition height at 512m, and make sure the final heightfield going into the Unreal node is shaped/remapped so that sea level lands at roughly 25% height.

In other words, the missing piece is probably not finding a new Terrain Definition height. 512m is already the correct value for Scale Z = 100. The key is treating Scale Z = 100 as the fixed 512m vertical container, then using the Landscape Actor Z location for the offset in its properties.

I have a simple terrain file you can test different heights and set ups to confirm this is the right direction for you and your team
Gaea2UE_Import.terrain (16.5 KB)

As well as just a rough video of me using it.

I hope this brings some resolution to your continued efforts.

1 Like