I’m having an issue with World Composition importing my landscapes at erratic positions on the Z axis, partially above or below the absolute 0 altitude.
I know I can’t unlock and move them, only via relative position. And when I do that, they move again on reload.
EDIT: Has been solved by updating to UE4.25.3
My landscape was exactly 25960 units lower than intended. Previously, I was unable to relocate it via Position in the Details panel, as it would bounce back double the distance I had tried to change it (move up 1 meter, it has moved 1 meter lower than it was on reload, so now it’s 2 meters too low.)
But, on updating to 4.25.3, it “just worked.” I set the “Position” of the Z to 25,960, saved it, then unreal crashed (after initially showing it popping back down with flying static meshes where I intended for it to be) and on loading my project back up, everything is where I wanted it to be, and I was able to save without issue on the second try.
The position of Z is defined in the import script by the value you use as the Z scale × the value of the heightmap value.
You really should not have to do anything special even across multiple imports if you keep the same scale values and the tiles come from the same larger hightmap.
If you need to shift a level up or down you just have to do it correctly so that world composition knows its location.
You can do so within the Level panel. And at least as of 25.1 the changes are kept on reload.
beware. Shifting the level this way makes it so that the heightmap will no longer dovetail to the adjacent one.
One question: So you’re saying I need to change the values in the heightmap itself? (Before importing into Unreal) Essentially, to set the lowest point of the map as a higher value than it is currently?
Probably.
The black on a heightmap is usually underwater.
65533/2 is approx where seal level (or world Z) is supposed to be.
given proper scaling anyway (which the docs were updated to reflect).
its 16bit so use Krita, Gimp or anything that supports 16bit format natively (ei: not photoshop).
You can easily re-map the color range in krita if you have a map that goes from 0 to 1 (0 to 255, also 0 to 65533).
To get the proper “sea level” value that unreal uses (which given 16bit is not an integer value can’t be exactly/ 2).
create an empty tile/map and export to sample the color.
I think it’s above the / rather then below, but sampling is always more exact.
Also, obviously there is nothing wrong with going below 0, but like you I like to keep a somewhat related to “sea level = z 0” approach. It just makes it easier to tell if something should maybe be underwater too
Also, I’d like to point out that maybe I’m doing something wrong. I’m going to attach a sample heightmap and an image where I outline the “0” altitude line to show that mine are almost entirely below sea level, despite the heightmaps showing the black value way further down.
I’m setting Z scale to 80 on import (200x200x80 x/y/z for full reference) due to not being able to afford a better version of World Machine and overall time spent cleaning up seams and LODs around seams as well as having to handpaint the material layers around seams (I have a total of 76 heightmaps for this one island, so it’s a lot of work and I don’t want to quadruple that, especially given this isn’t the only island.)
Edit: Can’t upload r16 heightmaps, so I’ll just use the “preview” output instead. These files are direct from World Machine btw.
The red line on the second image is my “sea level” at 0 on the Z coordinates. The very tip of the mountains is all that is actually above 0. The landscape is importing mostly below 0.
If you don’t immediately know what’s wrong, no sweat, I can work with what I’ve got. But I was curious if you might know off the top of your head what I did wrong.
Lastly, all of that is “above” sea level as I set. I’ll include a third image showing that I built my intended sea level into world machine. “Sea level” is the bottom 17% of the map as I have built it in World Machine. I wanted something very vertical (morrowind inspired of all things.)
Ok. Well the results are only a reflection of the heightmap… i can only postulate.
is world machine already giving you an engine ready file? Is that what “sea level” is for?
The base expectation for me is that World Machine should manage the height.
However , the height is just a value. You have 65533 possible “altitudes” to choose from.
The common assumption is that 0 to 65533 is equivalent to 1 meter with a Z scale of 1.
At a scale of 80 like you state, the terrain would only reach a maximum of 80m divergence. Menaing only 40m high and 40m below 0.
however - changing the value will by design NOT change the result of what portion is above or below sea level.
To do that, you likely have to tell world machine to extrude the land UP starting from the value of the color that unreal tells you in an empty map.
Krita reports said value at 32768
Does this make sense / is there an option that let’s you move the altitude up from seal level in world machine?
1- Didn’t know that until you told me earlier, I had always assumed it was a much smaller value.
2- By scale of 200x200x80, I meant 80% of Heightmap’s “height” value and double the “width” values in the Tiled Landscape import settings in Unreal. My landscapes are actually quite steep (reference video below.) In total the landscape is 7.67x7.67km with a height of 23,460 uu (~234 meters) between sea level and the highest peak (Had to place planes in engine then compare the difference between their position in game to get that value.) I know that isn’t terribly high, but the steepness is used to control movement and isolate areas more than the absolute height.
2a- “Sea level” isn’t being mapped in world machine, except to create splatmaps for material layers such as beaches/underwater zones. The sea level there is just a visual reference, and of course not likely to line up with Unreal on import. It’s more the interesting part is that it somehow imported nearly entirely “below sea level.” I never actually expected my arbitrary marker to line up until you mentioned color sampling an exported map from the engine. However, when making my maps, I had also output some bitmap images with colorization as “previews,” such as the ones previously uploaded. Frankly, I only made them so that I could use them to design important locations and biomes in photoshop to visualize on a broad scale before iterating in engine. Those images with the water aren’t used in the game at any point, just references to keep me organized.
3- I get what you’re getting at. I do think it’s possible though I’m not actually certain (you can change the maximum value, by default World Machine has a range from 0 to 8,000 meters and I know the 8,000 an be changed, not sure if the 0 can be), but after some messing around in Unreal I’m starting to think it’ll be easier to just change how I’m calculating depth offsets to work with the world I already have and then crunch it into a function. Don’t know why I hadn’t considered that. I was worried about having to remember the logic for a million different blueprints, then suddenly it dawned on me that I can just make the logic once, leave an input for anything dynamic, and create a function out of it. Game engines, specifically Unreal, shouldn’t really struggle with an extra 3 switches and tiny bit of math on up to 2 components (at most) per player based on what they are doing, especially if I can switch them off when inactive. May as well take all that time I spend optimizing and spend the leftover resources somewhere lol.
*As for why depth is an issue. In trying to measure my landscape’s height, I took 7,515 (Z coordinate of the tallest natural peak) and subtracted -15 thousand something, the Z coordinate of the sea floor (forget exactly what it was.) Obviously, I got a value that did not represent the actual difference between the two points xD. made me chuckle that in trying to measure my landscape’s actual height, I remembered why I was trying to shift its origin point. But, with gate switches to check if a given pawn or scene capture component are currently negative or positive, I can still get accurate depth readings to make things work. Additionally, for at least two of these actions I want to perform, getting world position OFFSET instead of ABSOLUTE will work, as I never intended for them to function below the landscape level (in caves or underwater) and only intend for them to function above ground in the open world, so I don’t see the switch on those causing any problems.
it wouldn’t, what does cause issues. Though not for you given the size, is floating point precision.
On a 1:1 map with a mountain at 1600m and a sea descending to -1600m you could potentially start to get issues.
I doubt World origin shifting accounts for Z by default, though I could be wrong.
Anyway moving into more realistic sizes of areas like K2 can really become problematic for the engine…
In a custom made world you have no restrictions, so you can pick your own elevations without issues, just remember not to go overboard with the Z scale on import. In fact, anything below z scale 600 has always worked flawlessly for me.
Now, all of that said, if you can shift the maps into the proper position by re-importing you can easily move the actors into position by using the exact same math.
Simply import a tile with the new/correct heightmap and measure the distance between the same area on world Z. Then select all the level actors and move them up by that value.
after that. Dump the new tile. And re-import the heightmap of the old one. done.
Whats more is that all further levels will have the same Z value difference.
So if you do want to change it, its not something that will take lots of time or editing once you figure out the situation of changing the range of the map in world machine.
That’s the part I don’t understand. You said as of 4.25.1 it doesn’t revert positions on reload. Yet that is exactly the issue I’m having. I can freely move landscapes. But on reload, any that were moved snap back by double. So, say I move tile x1_y1 up by 5,000 units because it was 5,000 lower than intended. When I load back in to the project after a save, it is now 10,000 units lower than intended. Easily visible by raising one tile, but not the one next to it. The tile you raised actually becomes lower than the one you did not after reloading.
Is that an editor setting/project preference that I’m missing?
Edit: I have zero issues with horizontal movement. It is only vertical movement that causes this bounce back for me.
Edit 2: I just realized… If it’s going to offset in reverse, I may as well just try lowering them, saving it, and then loading back in. Going to try that after this update finishes.
Edit 3: Going to mark this as solved and update the OP with solution. Updating to 4.25.3 made it work flawlessly. I just changed the Z coord, saved all (UE4 did crash) but on loading back in, they are now in exactly the correct position.
