Runtime virtual texture sets landscape to lower mip

[Frenetic]

try 12/0 vs 10/2. You want smaller tiles, even though there might be more, each tile is smaller (granularity). Being smaller means you can zero-in on exactly what tiles you want to render with less overhead.

Consider a larger tile where you can only see 1 pixel. You will have to check that entire tile vs the area/overhead of a smaller one; less overhead with more granular data = more performant.

Also, if your RVT covers your entire landscape, you likely can also uncheck clear-before-render since it’s always/only going to render that one thing, one time.

[Pope_Sweet_Jezus]

Does anyone here know why RVT is so much slowing performance during play/simulation?

[Frenetic]

Use smaller tiles, per my above post, and make sure you do not have continuous-updates enabled if you don’t need them (they can be costly).

As well, disable rendering on the source-landscape if you are using a heightmesh; you don’t need to see it. Set it to Never in the VT panel. As well, disable lighting, and anything else you don’t need. Keep it for collision and as a rendering-surface for the RVT.

[Frenetic]

Testing in 5.1.1 shows that the LOD-shuddering on the heightmesh no longer presents. With default settings, one can barely see some slight jiggle on LOD transitions, otherwise with some slight tweaking and/or ground-cover to break up the scene, I cannot see swimming in any appreciable way.

Thank you very much Epic.

The incorrect mipping of the texture, however, is in full-swing.

Will play around with it and update this post with any additional findings.

[Frenetic]

Testing in 5.2.0.Preview1 does NOT show any shuddering on the LOD. Still more testing to totally rebuild things from scratch (I had some holes in the landscape no showing), but the main issue seems to be gone.

I’ll update this post in the next day or two.

[NickKochman]

Thanks for keeping us ol’ landscape users up to date, the mipping is the worst part of problem however.

[Frenetic]

It is, and still present, but it seems that it’s distance based. The tiles up close will be properly mipped, but it’s distant tiles that won’t be.

As you move around, there is also a noticeable delay before the now-close tiles update but it appears once they are, they stay properly-mipped (until you they become distant again).

[sYnapZiX]

RVT’s seem to be just broken at the moment, like most of the engine.
As soon as i use RVT the landscape NEVER switches to the higher res LOD’s quite the opposite happens, the longer i’m in the editor the lower resolution the textures get until i’m left with a multicolored blob that is supposed to be a landscape (looks like in very old PSX games where large scale objects have been colored with vertex coloring).
I can tweak the settings until the engine crashes, move the camera all i want, play in editor, play standalone, package the project, the textures max resolution stays at around 256x256 resolution (guessed by eye).
Generally the virtual texture system is broken as hell. As soon as i enable Virtual Textures the engine is prone to crash every 5mins or so.
I can use 8k non Virtual Textures with no problems but as soon as i enable Virtual Textures it can happen at ANY time that the engine decides to fill up my 10GB of VRAM until i crash.
It even happens when the editor window isn’t focused, i hear my fans ramp up to max and then i can watch Task Manager and see that my VRAM gets just eaten up while not doing anything (also no other windows are open at that point, just Unreal Engine in minimized state). Sometimes the engine even fills up the VRAM when just starting the editor with the default blank template from Epic.

This engine is just so broken that its borderline unuseable in production. Some bugs even reach back to 4.26-4.27.

All documentations from Epic are depracted or never worked in the first place and if we are all honest, all of this will never change because the only thing that they need the engine for is Fortnite because thats their major cash grab and the visuals in this game are from 10-15 years ago so the engine isn’t under any stress at all.
And instead of fixing stability and useability issues they focus their development on the Fortnite Editor that nobody ever needed/wanted. If i count all the crashes and the time lost with broken autosaves (and sometimes broken manual saves as well) Epic could easily pay me 1-2 months worth of salary (not saying they should/have to, just to give a point of reference of how bad the state of the engine is and how much time i lost because of it)

[NickKochman]

There’s been an update in 5.2 for RVT Sample node, I tried it out but the Feedback thing was already checked with no noticeable improvements. Also getting some insane frametime, definitely have to run with these commands: r.VT.MaxUploadsPerFrame 8 r.VT.MaxUploadsPerFrameInEditor 12

Three versions in and still no hope for RVT mipping fix, it may actually be getting worse.

[sebbert3110]

Interesting to read this thread.
I also have constant flickering, but it only occurs when I dynamically spawn actors in the world, that affect the RVT.

EDIT: Turns out that RVT and ISMs doesnt like each other too much.
I’m using ISMs to spawn footsteps and those footsteps draw to the RVT.
If I’m just spawning the footsteps as actors, no flickering occurs anymore…

Although I’d really like to know how to use ISMs for that purpose…

[Frenetic]

I’m using a landscape, rvt, heightmesh, skysphere and associated directional-light, in a minimal test-case.

Play in editor, fall-in, watch flicker

[Frenetic]

I use a render-target with a camera pointing up per the (used to be Ray Wenderlich) article here series here: Creating Interactive Grass in Unreal Engine 4 | Kodeco

RVTs can’t really do anything dynamic in terms of time/distance, but since this is just-a-texture, the RVT doesn’t know it’s been updated since the last frame… ¬_¬

Paint your decals, depth-checks, whatever into that thing and then sample that as a texture in your landscape material. More advanced usage would then be tracking additional RVT-targets per landscape-section, and it can also be used for capturing other information like normals, etc.

If you want realtime deformation be sure to enable ‘realtime updates’ inside the RVT volume settings (it costs you though). It’s surely not so expensive as updates on the PBR portion, but it costs you… RVTs are rendered in tiles, as they are marked. Continuous page updates ensures they are updated every frame, so you claw-back some of the performance gain on the height part (it’s on the VT properties)…

[sebbert3110]

I don’t see enable realtime update in the RVT volumes. Where can you find that setting?

[Frenetic]

My mistake, correct dialog, wrong-context; it’s a property of the VT itself:

[sebbert3110]

Ah thanks, I already have this enabled

[cannasoftware]

On 5.2.1 and still no joy. Landscape is blurry.

I’ve tried everything and I just cannot find anything that doesn’t make my landscape into a blurry mess.

If anyone knows of a solution to this, I’d really appreciate it. But right now my grass looks like green lumpy blob.

As opposed to what it is supposed to look like:

This is very frustrating.

[cannasoftware]

Okay, found a post on Reddit that may have a hint:

https://www.reddit.com/r/unrealengine/comments/p5k3pl/use_rvt_on_landscape_makes_a_low_resolution/

Basically, the RVT was oversubscribed (not sure what that means, but sure, I’ll go with it).

Note: the person referenced Unreal’s documentation (SHOCK):

Virtual Texture Memory Pools

Okay, so I used the following:

r.VT.Residency.Show 1

And I get this screen. And what is it telling me? According to Epic’s doc I don’t have enough memory allocated to the DXT5 pool, so it is REDUCING my mip and making my lumpy lime jello.

So, I pulled out VSCode and basically copied this into Engine.ini:

[/Script/Engine.VirtualTexturePoolConfig]
+Pools=(Formats=(PF_DXT5,PF_DXT5), SizeInMegabyte=2048)

(BTW, this worked for a bit then froze up the editor SHOCK)

Now when I show residency, I get the following:

Okay, the graphs look lovely, but… wait a minute, the grass is still blurry!

I’ve played with bigger and smaller tiles to no avail — it still looks like I have the wrong prescription for my glasses.

However, if I use

r.VT.Residency.Notify 1

It no longer tells me I’m over subscribed. Sooo, long story short, it looks like RVT is totally borked (well, unless you really like that lime jello and then you are set to go!).

So, bottom line, no joy and a wasted afternoon.

[NahorCA]

I was just working on this myself. I did not have a problem with over-subscription as far I could tell. For me, it was because I was using virtual textures to build the landscape material. Once I switched to regular textures, my RVT was not blurry anymore.

[cannasoftware]

Ah, that’s very interesting. Seems counterintuitive, but I’ll give it a go.

EDIT: Well… it does seem to work. Going back and reading the documentation at no point does it even hint that the textures must be virtual textures (in fact, it is now painfully obvious that it is not even mentioned once.

That said, I’m a little puzzled why it doesn’t work… Virtual textures are supposed to be a thing and this seems like… well… a throwback.

This really helps my rendering a LOT. Thanks for the pointer!

(Me looking at a the ground covered in spinach leaves)

I guess I will ge spending the time reworking all my materials back to regular textures.

EDIT: Several days later and I find a nice 15-20 FPS bump. This is basically my understanding of how it should look (per Epic’s documentation). If it looks weird, it’s because I use named nodes to reduce the spaghetti and make my shaders more readable.

[Frenetic]

I can say that residency was my issue. As soon as I adjusted poolsizing in the .ini, my issue resolved itself.

Thank you VERY much, it makes 5.2 at least usable (viable) for me.