Runtime Virtual Textures and Virtual Heightfield is a mess

Epic, this needs solving immediately.

The system that was created for runtime virtual textures and virtual heightfields needs some serious work. I know the Virtual heightfield is experimental. Tessellation is being deprecated so what are we to do but use the heightfield.

You can successfully generate a virtual heightfield using the landscape material and a runtime virtual texture if you output the World Position blue (Z) value + the materials displacement (ie World Displacement). But because that world position z value was included the World Height value can no longer be used for World Position Offset or World Displacement in a material for a static mesh. If you do the opposite and output the displacment only via the World Height (RVT) the Virtual Heightfield does not sit at the correct height but your static mesh can now use that displacement.

To have the landscapes visibility mask shown on the virtual heightfield I had to output the landscape visibility via the “Mask” pin and change the RVT to the Mask output option which does not use RGB color (Not a big problem).

The opacity pin is included in the output node for some reason but the RVT can’t carry it.

Runtime Virtual Textures have terrible flickering/blurry problems.

The landscape and virtual heightfield are displayed together with terrible mixing of the polygons.

I am tearing my hair out trying to work out how I can have displacement on the landscape and on static meshes while using the RVT system.

It seems there is nothing but silence from Epic.

What is going on, Epic?

Here is a video of the problem:

Have you tried building the VT Streaming Textures? It might help with the flickering. It seems to settle it down a bit from my experience. Also I had a bit more success messing about with the amount of tiles and tile size of the VT itself

Thank you.

Decreasing the size of each tile has helped because the patches that are flickering are not as big anymore.

Yes, building the streaming virtual texture did stabilize it a bit.

A bit more manageable after your help :smile:

Since the VT is somewhat of an indexed structure, smaller, more numerous tiles will tend to lead to better performance anyways (at least in my experience).

Yeah definitely agree with that. I tried a ton of settings, this is what I got atm on a 8k map. Adaptive page table on, and the numbers are currently at 14, 1, 2, res looks good and it’s fairly stable but there’s probably more massaging to do!

So to at least address some of your Qs as I understand them:

Metallic, yeah, we all tend to use maps for metal (I tend to just reuse the R/G/B channels from the BaseColor texture to save on samples). Otherwise the PBR model tends to assume Metal is an integer for a given material. I think it’s just a holdover from olde times when that was the case vs just-plugging-a-texture-in. In that sense 1 would just be a white field, so not worth binning into the VT.

Opacity controls something about how strong the texture blends/renders. I never use it so I can’t comment from experience.

As for the flickering, it looks like Z-fighting? Did you set your source-landscape to Never render in the main pass? You don’t need it as it renders to the RVT…

Otherwise, from my experience, I can say that when I adjust my snow-value (for example) and it would otherwise smoothly fade to white, the RVT has to re-render all the tiles, and I could see over ~1 second all the tiles update 1-by-1. I came to the conclusion real-time adjustments and the like (including depth-fades, etc) aren’t viable for areas where you can see many many tiles…