We have been experiencing an issue in both UE5.5 and UE5.6 regarding Runtime Virtual Texturing on a Landscape.
We are using a material graph which is writing and sampling an RVT for our layered material setup in our project.
We are using a layered material and sometimes when we change one of the parameters on the material not all tiles are properly updated. It is possible to see the issue in the attached before and after screenshots.
Before modifying material param
[Image Removed]
After modifying material param (RVT tiles visible)
[Image Removed]
Some things I’ve noticed:
It’s not all levels of the RVT that are incorrect, only some. Flying in and out will reveal the expected output at some, but not all mips.
Doing a r.vt.flush will fix the tiles that are visible on screen, but not tiles that are off screen
The issue is very difficult to nail down a dependable reproducing. Sometimes it happens frequently, other times very rarely and it’s not seen for 10’s of material property updates.
There is nothing in the log related to VT pools or similar happening
In addition if I enable `r.VT.ForceContinuousUpdate` the tiles seems to flicker between correct and incorrect. It’s very confusing. I have attached a video highlighting the issue.
As it currently stands I don’t know of many ways to further debug what we are seeing here and I can’t currently provide a great reproduction case as it’s not cutting down to a smaller project well.
Are there any cvars we should be trying?
Are there any settings we should try changing on the RVT volume?
Are there any ways we can debug this to get more information?
Any assistance would be greatly appreciated. Thank you.
the flickering tiles issue may be somewhat related to these ones:
[Content removed]
[Content removed]
[Content removed]
The first issue was fixed by enabling a new CVar introduced with 5.6, r.VT.RVT.PageCorruptionFix. Can you please try setting that to 1 and check if that helps? If that helps, there is a similar, but improved fix in ue5-main which doesn’t require an additional pass, which you can cherry pick here: https://github.com/EpicGames/UnrealEngine/commit/e55c8794bcb13be3d12ab17712e6d6c180309a07
Please let me know if that solves your issue. If not, we can diagnose it further.
One of out technical artists has managed to make a small reproduction project that runs on vanilla 5.6 I’ve attached it here with some of her information:
-----
Version: 5.6.0-43139311+++UE5+Release-5.6
Steps:
Open the project
Select the landscape actor, double click to open the Landscape Material
On Layer Parameters tab, tweak the parameter values on different layers (this is important). I had most success tweaking the testblend parameters on the layers.
In 5.6 you will need to release your mouse to see the changes so unlike 5.5 you see the flickering while you drag the values. Eventually the artefacts will stay. The repro project is created with the default open world project, and I simply imported the landscape materials and RVT asset, enabled RVT checkbox in project settings and that’s it. I didn’t copy over other settings. The landscape materials are minimal.
* Main landscape material - just pass the BaseColor into RVT and output BaseColor from RVT.
* Layer material - just a plain color parameter.
* Blend material - just lerp BaseColor of top and bottom layer with a scalar parameter.
* Background material - just give the noise pattern with world position + noise node, to make the issue look more obvious. The artefacts still happen with this material being pure plain color.
-----
Some observations from me:
* It is possible to make the issue happen when still well under the VT memory pool size.
* If you hit the pool maximum size and the pool resizes the issue goes away
Here is a screenshot with the issue present where we are still under the pool size with our project.
[Image Removed]
Here is another one (from the attached project) here I set the pool manually to 1000mb, the usage is at ~800mb. The r.VT.RVT.PageCorruptionFix cvar is set to 1. [Image Removed]
Note: I just noticed that the landscape material is not optimally configured in the uploaded version (not using the RT VT switch) that it should be. I’ve changed this locally and the issue still happens so is not related to the badly configured material. The image is the change I made to the material to make it conform to be representative of how we are doing our full landscape material.
thank you very much for the reproduction project, that’s really helpful. I investigated the issue and tried out a number of settings and CVars, and noticed that the tiles eventually seem to settle after a while when r.VT.ForceContinuousUpdate is enabled and moving the camera a bit (although in some situations it can take a relatively long time before the landscape tiles reach a correct stable state and stop flickering). One thing I noticed when using fixed pools (instead of transient) in the virtual texture pool config is that the “Size in Megabyte” fields needs to be set high enough to allow for all tiles that are in view to be loaded. When using transient pools, this size will increase dynamically and trigger the “Resizing virtual texture pools” pop-up whenever it can’t fit all the tiles in view. A common practice here is to first use a transient pool to find out the peak memory required by quickly moving the camera over the scene and force the editor to pool as much as it needs to quickly, and then copying over that dynamically obtained size to a fixed pool.
I hope this make sense. As I’m not very familiar with how the RVT streaming system works at a low level, would you like me to escalate this issue to Epic so a subject matter expert can have a look?
>>. One thing I noticed when using fixed pools (instead of transient) in the virtual texture pool config is that the “Size in Megabyte” fields needs to be set high enough to allow for all tiles that are in view to be loaded. When using transient pools, this size will increase dynamically and trigger the “Resizing virtual texture pools” pop-up whenever it can’t fit all the tiles in view.
Yep, if you look at the screenshots we have configured a fixed size for the pool that is more space than the current utilization. The repro project is using the transient grow only pool but even if you change this the issue still happens.
In our ‘real project’ screenshot you can also see we are not using transient pools and the usage is less than the pool size and the issue is still present.
>>I hope this make sense. As I’m not very familiar with how the RVT streaming system works at a low level, would you like me to escalate this issue to Epic so a subject matter expert can have a look?
thanks for the additional info. I have re-assigned this case to Epic. Please note that Epic’s offices will be closed for summer break for the next two weeks, but they will get back as soon as possible once the office re-opens.
One last question: are you planning to change the layered landscape material parameters in-game (with a runtime dynamic material) or only in the editor?
Thanks for reporting the issue and sharing a project. I took a quick look at the project in 5.6 but couldn’t immediately repro the issue. From the description it does sound like the issue is intermittent, so I will keep looking on my side.
One thing I tried when debugging was to turn on the “Viewport/Virtual Texture/Pending Mips” debug view to understand whether pages were being flushed (into a mips pending state) when changing material instance parameters. I then noticed that sometimes pages get stuck showing pending mips (green in the debug view). This shouldn’t happen, and I can imagine that if it does, then possibly pages might then appear with old stale data. I don’t know if this is related to your issue, but I will investigate.
Further to this I noticed that you are using adaptive page tables on your RVT. I tried disabling that on the RVT asset and in the material RVT sample node. After I did that the pending mips issue went away. Again this is something to investigate on my side, but also could you please test whether turning off adaptive page tables also fixes the bug you are seeing? If it does it would indicate there is a single issue with adaptive page tables that needs fixing.
I have now had a look at this with the pending mips view enabled and it seems like the mips are being flushed but the results are wrong
In addition the issue is still occurring with adaptive page tables turned off.
For us in the reproduction project we have managed to reproduce this pretty consistently with vanilla Unreal 5.6 on multiple computers in our office without too much effort.
I’ve attached 2 videos to this post, the first contains a video showing specifically how we get the issue to happen (basically rapidly changing the values using the hover and drag rather than inputting the values directly), the second shows the current stat of mip streaming and that we have adaptive page tables off. Second one isn’t so exciting but you can see the configuration to validate we have it set up like you suggested.
Thanks for testing and sharing the videos. I have still not been able to reproduce locally. But I’ve found out that one of our internal content teams has seen something similar previously. In their case the issue only happened when using layered materials. Is that true for you too?
If it is layered materials only then a hypothesis is that a race condition in the layered material parameter update causes us to render some RVT pages before the material uniforms have fully updated. One argument against that is that you mentioned that r.VT.ForceContinuousUpdate can cause flickering rather than fixing the issue over time.
The next two weeks are the Epic company vacation, so I won’t be replying to this thread. But let me know whether the issue is layered material only, and any thing else you find. I’ll return to this issue after the break.
Thanks for the extra context. In particular it is useful to see the “r.VT.ForceContinuousUpdate 1” behavior.
Since continuous update does clear the issue over time and you only see this on layered materials, I think that the theory of a race condition in the layered material parameter update is quite possible. I’ll take a look at the code here.
Internally we have found an issue with the behavior in live updating layered material parameters. For some materials the updates are not always propagating correctly to to the material uniform buffer. This could possibly cause an issue if invalid data gets cached in the RVT for one or two frames.
I’ll reply to this thread when a fix has been made for that issue, so that you can take it to see if it solves the problem you are seeing.
I’ve attached it here with some of her information: