I am getting the same kind of issues with RVT on a 16km2 terrain, I’ve attempted to use a single RVT volume but split up my materials across 4 tiles covering the landscape.
Initially I saw inconsistent behaviour in editor comparing between individual Landscape streaming proxy tiles:
Then I noticed moving the material plane used for RVT I could temporarily restore resolution when moving around the editor:
But the problem I’m more concerned about is whilst running in standalone mode the resolution looks like this:
Try increasing “Size of the virtual texture in tiles” ( mine is 65536 |16] ) and decreasing “size of each virtual texture tile” ( mine is 64 [0] )
Final resolution will still be 4MiTexels but will be divided in many smaller tiles.
It doesn’t solve the issue but it’s less noticable as, while tile updates are still as slow, more tiles are updated and fewer are not so the over visual is less bad.
Also I add to tick “enable adaptive page table”, both in the RVT texture settings and the “RVT sample” node settings in the material, to reduce time needed to update tiles.
Yes, like I said almost every “modern” (less than 10 years old) open world use virtual texture for landscape material (like almost every Ubisoft open worlds) because it’s the only way to get a get landscape with decent amount of layers and complexity not eating half of the framerate.
Assassin’s creed Origins is now 5 years old and have “adaptive virtual textures” and nice tesselation (which as now been removed because Epic implementation was a performance killer… lol) for the landscape, running at really good framerate, while the same landscape quality would run 20 time worse in Unreal Engine 5.
Documentation is way too basic, it’s more a general presentation about what you can do with it than an in depth documentation about to use it, how to trade quality/performance, how to resolve most common issues, etc.
“I can only assume, nobody is using RVT’s and Virtual Heightfield Mesh commercially with a released product that works?”
Unless a big studio plan to use UE5 for his new AAA open world, I’m afraid it will stay an experimental feature forever.
Thanks Haoris, those were some interesting settings to test out, and it’s clear to see the increase in tiles in regards to how the RVT is split up in memory.
Here’s a video of me in the editor after switching to your settings, selecting the plane that feeds this RVT, and then deselecting it and the speed at which the RVT tiles load up. this seems to be the only way I can make the material show at it’s original resolution (in editor), as soon as I move to another part of the map which uses a different plane, then come back the resolution has dropped and won’t change no matter how long a wait looking at it?
But more my concern is how do you get this working in standalone mode, as my entire terrain looks like this when I load standalone, it never get’s better than that! I must be missing a setting somewhere -
Can you confirm what size resolution your source textures are? what size is your terrain? are you only using a single RVT volume, and are you using World Partition?
My textures are 16384x16384 pixels and I’m trying to load 4 of them across the terrain, so perhaps a little too big for an RVT setup to handle?
I’m going to try and test multiple RVT volumes, and breaking my source textures up into smaller tiles.
This slow update issue happened since RVT was introduced in early 2021, it’s not related to textures (except the RVT itself of course), landscape size, etc. but to how the engine is streaming this virtual texture, even more when the virtual texture resolution is high (like 4MiTexels we both use).
Is your project stored on a HDD, a SSD, a M.2 drive? Because as it’s a streaming feature, the faster your drive is, the faster the virtual texture will be updated (same for RAM/VRAM bandwith I guess), even it shouldn’t be as slow.
This issue doesn’t happen on games (other engines than UE), using adaptive virtual textures, installed on HDDs.
I’m running off an M.2 drive for OS, and remaining drives are all SSD’s.
So in Standalone or packaged build do you achieve the correct resolutions, even if you have to wait for streaming at times? as I’m not able to get this at all.
We have been running into the same issue on our project. We have been able to mitigate the issue somewhat by changing the feedback factor to a much higher number, which seems a bit counter intuitive when reading the tooltip (Lower factor will increase virtual texture feedback resolution which increases CPU/GPU overhead, but may decrease streaming latency, especially if materials use many virtual textures.).
The number we settled on for now is 512, which seems to give us the sharpest results ingame, with the least amount of waiting for the system to load the higher resolution mips. However we still need to do a deeper dive into why this number works better than the default value, and how it actually works under the hood. Hope this helps some of you for now.
It can help to tweak [/Script/Engine.VirtualTexturePoolConfig] Values in BaseEngine.ini
my values, stoped flickering still has slow update from time to time:
Very interesting to find this thread. I’m been losing so many days combating this. The feature is utterly broken and it will be very difficult (or impossible) to go back to render targets for me. I have all of the same, mip flickering, not updating, weird unpredictable behaviour and settings that don’t seem to affect anything.
I reworked my 4.26.2 project in the latest preview build. It all works with landscapes/rvts/heightmesh, but I get this odd LOD flickering on the whole thing, even when standing still. It ‘shudders’ between different mips/lods and just looks ugly.
I gather that is what we’re all talking about?
Fer sure not seeing this in 4.26.2, which is a real shame… The new LOD-transition for the heightmesh is much improved in terms of swimming-ness/swimmy-ness. In 4.26.2 it was a series of overlayed LOD’s that attempted to ‘blindly’ blend on top of/into one another and was very swimmy. In the latest 5preview it seems to fill in each lower-LOD poly one at a time/directly vs ‘will it blend?’. I can’t really see swimming and I’m using a lot of detail in the mesh.
NOTE TO EPIC: that one-thing above, with the new fill on the heightmesh is ‘the-thing’ that lets me feel I can actually use it as a landscape; I cannot really see it swim. To paraphrase Doc Brown: “Meshes? Where I’m going I don’t need meshes…”
Performance is still good, getting the same FPS as in 4.26.2, whereas in other v5-releases I was NOT, even w/o lumen, etc. Lumen still eats my FPS but not nearly so much as before; definitely still needs to improve IMHO. Also, build-times on the RVT volumes is much faster/performant.
Issues with the heightmesh aside, performance seems up-up for me, at the very least.
Small update. We have found to get much better results when we use traditionally mipped textures in our landscape material (specifically the part that writes into the Runtime Virtual Texture), as opposed to using Virtual Textures (that have “Virtual Texture Streaming” ticked in the texture’s details panel).
It looks like Virtual Textures are not currently supported when writing to the Runtime Virtual Textures. They “work”, as in it won’t crash, but the behavior is erratic
I want to say that I read (somewhere) that the order with which a VT-tile is rendered is not guaranteed so having one VT into another can cause race-track conditions, etc.
Enabling ContinuousUpdates causes all the visible tiles to be prioritized, so it can help, but on something like a 2k by 2k landscape, you can still see tiles flicker-through updates if you can see enough of the thing.
Insofar as v5.1p3, I still just-get the odd LOD toggle where it switches back and forth between a nice high-res version and some really low LOD, back and forth, back and forth…
Having similar issues as well where it “swims” back and forth to the camera, RVT still seems fairly busted in 5.1, I tried using SVT in combination but it consistently crashes nor did it seem to help the mipping issue. I’ve got marketplace products that solely rely on RVT so it’s been upsetting to say the least after spending days on trying to figure out a solution.
Indeed, for me, it was working perfectly fine in 4.26. Despite what issues I did see in 5.p1,2 or 3, the snapping-LOD/mipping is new-new for me as of 5.1. Until that release I’d never experienced them.
In fact, except for the swimmy-ness of the heightmesh at the LOD-transitions, everything else was working to expectations. I was very hopeful, in seeing the new tessellation that swim go away, that the heightmesh/rvt might be close-to production ready. It’s fast, it captures a lot of detail a low cost, that detail can be SHARED across materials/meshes, etc; lot’s to like, then…this… :-/
NOTE to Epic if you are reading but I’m not whining, just ‘argagaghaghag’ b/c it’s new-stuff instead of the old-stuff. I get that this is all free (as in beer) but also, I do see this particular tech as a viable solution to material-driven worldscapes where materials, grass-systems, and the rest can all come together to ‘just make that world’ by dropping in some textures/settings.
The only missing piece is the ‘firmament’ that is a landscape. To my experience, fix these issues with the RVT/heightmesh and you/we will have something decently-nifty to work with.
Hi, I’m glad I found this topic even if nothing came out of it to fix those issues. At least I can tell I’m not alone.
I’ve been working with RVTs since one and a half years on UE 4.26 and it was pretty nice. I achieved to fix weird flickering and mips loading.
But we recently migrate our project on the 5.1 and, like most of you, my RVT and landscape are quite buggy. Tiles are almost never shown with Mips 0 and as soon as you move the camera to go elswhere you find your landscape complety blurred out for 1 or 2 second.
I’ve tried everything from, forcing no Mips on the textures that my RVT use or playing with the RVT settings but nothing seems to work.
I really hope that Epic will adresse those issues in next updates
So whether this helps others or not I can’t be sure but hopefully it goes some way. I was having issues and seem to have finally fixed them, though it seems like there’s a bounty of different issues amongst everyone so this may not work for all cases.
For the textures in your landscape make sure they have the ‘VT’ label in the bottom corner, if not right click in browser and check ‘convert to virtual texture’
In your landscape material if you have any camera culling / distance fade effects they seem to mess with it, try bypassing them (this was the big one for me, a mipmap thing?)
