8k heightmap gives me very weird landscape

Hi guys, this is an image of my landscape after impirting an 8k heightmap. I used the exact same steps as when i imported a 1k heightmap, which worked fine. I also have imported an 8k heightmap that was photoshopped - 4 heightmaps into an 8k for testing purposes. That worked fine.

This heightmap is from Gaea, like the 1k one that worked. Does anybody know why the landscape would turn out like this? Both the bizarre checkers that im sute represent the components, and also the fact that it’s perfectly flat.

I would greatly appreciate some help hete because I’m completely stuck.

Thanks in advance.


OK I want to delete this and create a new one but I’m not sure how. I got the landscape to look normal, but it’s way flatter than it should be. I have a mountain in the heightmap but I barely get a hill in the landscape.


When you altered the heightmaps’ when editing in photoshop, did any changes occur? For example, did the aspect ratio change causing anything blur or did the image possibly lighten?

Any additional info or specifics you provide may go a long way in solving your problem!

Hi, yeah well the heightmap with the mountain was much lower in space than the other three heightmaps i had in that combined one I did in photoshop. It was black while the other 3 were gray. But it at least imported fine. My problem is the 8k map directly from Gaea. But I noticed that in the level that has the 8k landscape made, the auto landscape material I’ve been using is flashing all kinds of colors in the details panel. It looks fine in the other levels and on the other landscapes, but when I apply it to this landscape I get the colored checkers.

Now when I apply the later data, my landscape is a lime green/yellow color. I have no idea what I did wrong as I followed the same steps as always.

OK now I’m looking in other levels and suddenly my other landscapes are rainbows too. So it must be in the auto material. It was working perfectly last night. Have you ever seen anything like this in a landscape auto material?

I really hope all my hard work isn’t lost. Do you need any more info?

Thanks so much for replying

Please stop even suggesting for people to use photoshop at all.

Heightmaps are 16bit.
Photoshop does not work in 16 bit.

Whatever you get out of photoshop will never work correctly. Period.

You used photoshop.

Aside from that, the engine doesn’t really like to handle 8k files / and you may be hitting RAM/vram limitaions during the import process as well.

Find a program that works natively in 16bit.
Then cut up your map in 4 parts so as to have 4 tiles.
Import the 4 tiles.

The overall height of the terrain is driven by the terrain scale settings - the Z particularly.
Look up the documention to find the right ratio to calculate your required value.

Note that your map may be “under water” if it contains any values below 65535/2, so when you go and do the math, you need to consider the proper starting point if the idea is to match the height to some real world location (the docs should explain this if they haven’t been gutted again)

If you did not keep the original file before you used photoshop, then it likely is.


Ah I see, I was thinking the main issue was going to be those altered files. I do agree and suggest that you should not alter files whenever possible if you are trying to achieve the most accurate look. I don’t use photoshop unfortunately, so I can’t give any advice, though I would instead suggest importing them separately in their original format if possible and restitching them together. However, if someone else in the community has had success with somehow managing to get the correct settings hopefully they see this thread.

As far as your materials go are the colors constantly shifting? Do you have RVTs set up? If something goes wrong there, like it’s been turned off for example, it can and will cause the materials to go haywire.

Would you mind sharing some screens of your new coloring issue?

We can definitely figure this thing out!

Hi, no nothing changed that I could see. The 8k heightmap from photoshop worked perfectly except the “tile” with the mountain being way lower.

I realized that it’s the runtime virtual texture that’s causing the disco effect. If I turn it off it looks fine. I really need it on though because I need every fps I can get.

Do you know why a RVT would do this? It worked fine before, but now every map it’s applied to is going disco.


I’ve tried to turn on nanite on this 8k landscape. My pc goes to 100% ram usage (64gb) then the engine crashes every time.

Is there a better way to built nanite for huge landscapes? It’s really not even that big compared to some games out there.

Are you talking to me? I didn’t tell anybody to “use” anything. I was explaining what I did, albeit with false information I got elsewhere.

Ah OK this is what I’ve been looking for. So you say make 4 smaller heightmaps and combine then in UE? If I read you right. How do you combine 4 heightmaps or landscapes into one “piece of land” that is connected and that can be sculpted/painted across? I’ve been looking for how to do this and haven’t found anything… hence why I went with an 8k landscape.

And i did not use the photoshopped heightmap in the landscape I’m having problems with. It’s the runtime virtual texture that seems to trigger the disco effect.


Hey, OK yes. I was told that you could not “stitch together” landscapes inside ue. That’s why I went with an 8k heightmap. I’m glad to hear that you can. Could you explain how you do that, or share any instructions on it?

Here is my map with RTV turned on. When its off, it looks fine. I’m looking forward to hearing back from you.


Photoshop works in 8,16 or 32bit. the Export tools are 8bit afaik but if you “Save As” it will use the bit depth you’ve created in photoshop. I’ve just tested it and it works:

I’m not suggesting using it to stitch landscape tiles together as there is potential to loose quality, and get seams along the edges - but it can be a very useful tool for creating 16 and 32bit maps for other things.

It doesnt “work” in 16 bit. Nor save in 16 bit.

If you even open up the file you compromise your data as all the values get changed to their nearest 256 color counterpart.
You lost 65535-256 data just for opening the file.

It is absolutely not a good tool to use for heightmaps.
Heightmaps are data, not graphics.
Stop even thinking of them as graphics.

World composition or world partition both do this.

But how isn’t really important. Start by making sure you have the correct files at the correct scale importing and working correctly.

Once you know they do, you can then work on figuring out which version of the world tools to use for your project / or you can do the math to place the levels at their correct place.

Sorry, but it’s important for my workflow that it does in fact work - here’s some proof:

shows the 16bit version is different from the source data.

landscapes made from heightmaps made in photoshop.

It does default to using BC1 compression after importing which is 5:6:5 bit format - but you can change that in the texture editor to any of the 16bit formats without loosing data.

It does not work.
Study what 16bit is and how the color values work - you’ll understand why photoshop doesn’t work after editing with it and comparing sampled values.

Also, No one in their right mind would leverage an image editor to deal with data. Particularly at a pipeline level.

And when you do “tests” at the very least you should take a scientific approach. Otherwise what’s the purpose?
As such:
What on earth is the purpose of testing a uniform file? At a minimum try a gradient from 0 to 1 across a file range which is larger than 65535 pixels…

I give up - those images I’ve posted should at least convince anyone else reading this that photoshop is ok to use :slight_smile:

1 Like

Photoshop is not ok to use.

Stop even suggesting it since you have no idea what you are even testing.

And before you attempt to even go any further, look up what 15bit+1 means.

ok, here’s another different test. (the other test was a gradient btw).

This time, just using a material blueprint - do you agree that no matter if it’s an 8bit or 16bit channel, the output is between 0.0 and 1.0 for a basecolor? Here is a test for that here:

So, this example below - subtracting the 8bit texture from the same 8bit texture results in a black texture:

and now, subtracting the 8bit version of the texture from the 16bit version:

Surely you have to agree that if photoshop wasn’t keeping that extra resolution the result of the last test would be a black output?

Also, I have some tutorials on textures, and some information about the formats used here (there are some new ones in UE5.1 and up):

No I do not agree that the output is the same.
Particularly not if you use photoshop.

Again. Look up what 15bit+1 vs 16bit means.

Also, heightmaps and textures are more different than oranges and apples, so why would you even go there?
Is it a lack of understanding, just wanting to be right, or what exactly?

I am aware of Adobe’s 15bit+1 - that’s a very small amount, if you’re worried about that amount - it’s time to go 32bit :slight_smile:

But quoting what I said in my first post:

I’m not suggesting using it to stitch landscape tiles together as there is potential to loose quality, and get seams along the edges - but it can be a very useful tool for creating 16 and 32bit maps for other things.

Quoting you, and the part that I was disagreeing with:

It doesnt “work” in 16 bit. Nor save in 16 bit.

If you even open up the file you compromise your data as all the values get changed to their nearest 256 color counterpart.
You lost 65535-256 data just for opening the file.