POM stretchings


Started using POM tonight, performance seems to have improved. But I think I’m setting it up the wrong way?

This is a simple road material applied to a cube. When viewed from above, this is the look I get:

But when viewed from the side, everything looks skewed or stretched.

And the material:

Btw I set the number of steps to anything, but as soon as I slightly start to look at the surface from the side and not fully perpendicular, the material starts to look stretching.

This is most likely due to the way POM works. At more and more glancing angles, you can see the steps for each ray. It’s just a limitation of the technique. The way to get around this is to increase the number of steps, but there will always be an upper limit.

Ryan talks about it in this stream starting at 13:02:

You can try to increase the number of steps POM uses as the camera is at a more glancing angle (Camera Vector Dot Normal), so you don’t pay that cost when looking down from the top. For something as large as a road, you probably also want the steps to fade off to nothing after a certain distance from the camera.

I believe the issue I’m experiencing has a cause other than number of steps.

Here’s a simple texture with 64 steps for min/max. The form looks pretty good at extreme angle.

And the road material with 64 steps for min/max.

Quite curious why this is happening.

Does it still happen when you do it like this?:

Because of the reference plane setting most likely.

Okay first, apparently putting displacement map in normal map blue channel and setting heightmap channel to 0,0,1,0 doesn’t give good results (lots of noise close up). Looked butter smooth with a separate heightmap texture sampler though, but having a separate heightmap texture sampler per material is quite a waste of memory and nerve.
Second, the stretching issue seems to happen when the mesh is scaled non-uniformly, in this case, road material is 4096x2048, road mesh was also scaled from 1x1x1 to 2x1x1 which caused the UV to be stretched along the X and the height going in all the wrong directions when viewed from the sides. This issue makes it quite difficult to get perfect results with landscape splines even if the mesh is modeled 2x1x1 and UVed properly, because landscape spline by itself makes the spline mesh shorter, longer, depending on the distance pf control points from each other.
Third, I find the results quite unacceptable with 32 and 8 steps, and going much higher than that isn’t a very good move in UE4 so I give up using it. I’m going to setup distance based tessellation for roads. A little deformation helps them blend better to the ground anyway.

Thanks all for the tips. :slight_smile:

Oooooh, that explains it.

Normal Maps in UE4 use BC5 compression, which means that Blue channel is for all intents and purposes useless and nuked out. You can’t use it for anything really. Using a separate Heightmap is the way to go. You’re not really saving any memory because BC5 just uses extra bits for the R and G channels anyway.

For best results, TC_Grayscale or TC_DisplacementMap is best for Heightmaps since they’re purpose built for Heightmaps. Texture Compression really matters in UE4. It’s very commonly overlooked.


your grass looks great can you post material setup!

Hmmm not quite, I use Masks compression when I store heightmaps in normal map blue channel. The blue channel for normal map is reconstructed through shader and the heightmap is used for landscape tessellation, but for POM looks too noisy for some reason even though I blur the heightmap a lot.

TC_Masks has a lot of compression artefacts and is noisy. It’s not really suitable for Normals or Height Maps because you lose so much data.

Probably not with BC3. Good enough for heightblend but, pom or tess does look blocky. Might be worth trying BC7.

You are not restricted to that in any way.

Hmm strange. I don’t recall seeing POM issues of that severity caused UV stretching. Well, atleast not within reasonable margins. Haven’t ran it on splinemeshes before though.
I still kinda think that the issue on your first screenshot is caused by excessive view angle coupled with reference plane setting.

32 steps seems more than enough for the use case you are up to. 8 shadow steps might be a bit low.
One particular issue with Tess for roads is the fact that you will be paying base cost for all verices of the road, not just the ones needeing tess, the same like landscape.

With Mask compression blue channel isn’t independent so normal map r and g will cause cross talk errors to blue channel. So noisy normals is cause of noisy height map. For performance it’s better to use single channel format for textures that are sampled multiple times per pixel.(POM). For similar or better quality with better performance you can use lower size texture but higher quality compression.(alpha aka BC4)

Just test it out.