Absolute World Position no working in 5.4?

The below imaged code seems to work just fine in 5.3.2. The idea is that the snow material appears on the top of my mountains automatically and allows me the ability to blend it into the rock material with falloff, etc. In 5.4, however, it does… nothing. There is no height division at all.

I really don’t want to roll this project back to 5.3… does anyone have a solution?

Cheers

Also, why is the engine demanding I rebuild the world after every tiny change? Example, I changed nothing in the above code since taking this snapshot. Just saved it, and I get this:

image

0_o Not a major issue, but annoying. Almost as annoying as when after I rebuild adn save, my camera directions seem reversed and instead of scrolling forward, I go backwards…

1 Like

Try a more basic thing/item to see if WPO works at all or not.
It’s very possible they broke it like they break everything else…

Seems like it. I added a separate object to my landscape, a cube, and set it on my landscape floor. AWP should grab the total height of said map but when I set my landscape to 0,0,0 and placed the cube on my floor, AWP did NOT grab that data. Instead I had to move my entire landscape to the position AHP considered to be 0. 47000 for the Z location of my landscape.

As you can see by the image, although the the cube rests on my landscape, in order for me to find the centre of the cube via AWH, the value is -1290.

This is just wrong. Worse, when I try to use the bug reporting tool they’ve provided, it just hangs and goes nowhere!

Thats because Epic definitely cares :wink:

I’d just say change engine, but at this point I know i must sound like a broken disk :stuck_out_tongue:

If you have the know-how you can probably pull source from the last patch and find it fixed after building (assuming someone got to it). And if not, with the source you can track down what the shift is due to.

Generally speaking WPO returns the object’s pixel location.

Landscape has bothing to do with it.
The object does.

With an object placed At 0,0,0 - if you hook a debug node for float 3 into the texture output filtered by the pivot, you should get a print out of the exact object location (so 0,0,0) into the UV.
You may need to scale the uv up or down to get it readable, depends on the model in use a bit.

Anyway, its a quick and dirty way to verify.

If at 0,0,0 an unparented actor returns anything other than 0,0,0… well then the value provided is incorrect (or the hook isnt refined by the pivot, since WPO returns the pixel on scrren value and a UV covers more than 1 pixel?).
Regardless, a 1m cube should give you a z value between 100 and 0 even if you just stretched the debug texture randomly to display it.

Of note, the scale value of WPO is always Uu.
This should match the direct location output in engine - 1m being 100uu.

An easier way to test would be to divide the WPO by 100, and output the result of the B channel to the output.

You should see a UV that goes from 0 to 100 - so covers a 1m cube, the start of which is a value of 0 at 0, and 1 at 100.

A 2x2 cube would have a tiling of 2 white to back rows.

Because it tiles, you don’t know for sure the value is correct - you only know that the division is creating somewhat accurate Tiled results.
But its something…

But you can easily do an IF statement and when WPO B is > 0 lerp the value btween 2 different colors.
When its bot, output as is.

Then theoretically, any part of the mesh below Z 0 will look grayscale.
Any part above it will look as whatevrr colors you lerped.

Needless to say that if an object with a face that goes across the 0,0,0 point and extends over 2m doesnt show you both variations - the output of WPO is incorrect.