Virtual Texture Streaming causing low res failures in first frames of Screenshot Tests

Hello,

We are in the process of adding character screenshot tests (subclassing AScreenshotFunctionalTest) for catching visual regressions. We started using UDIMs/VTs and hit a problem w/ mips being too low res in the first few frames. Once the test level has loaded, e.g. running the tests locally a second time, the high res mips are resident, and the test passes. But the first test after load always fails, which is an issue because we would like to run these tests on our build farm with Gauntlet at some point.

I are aware of these relevant threads:

1. [Content removed]

2. [Content removed]

3. [Content removed] (with the help of digital translation)

We are currently on 5.7.4 with some minor custom engine changes and have yet to get the latest Cinematic Prestreaming plugin. Ideally we would like to run these tests without needing to record streaming just to know when a static, unmoving character is fully visible at its desired mip level. I’ve tried many things so I’ll omit most for brevity. The most promising ones were these, called in Event Prepare Test on our ScreenshotFunctionalTest BP:

- Called “Set Force Mip Levels to be Resident”

- Called “PrestreamTextures” after setting Virtual Texture Prefetch Mips to the max # mips in the texture as suggested by Jeremy Moore in link (2).

- Added the following to a BPFL node and called it, based on success that Tom Goodwin had at the end of link (1) :

```

ENQUEUE_RENDER_COMMAND(VirtualTextureSystemRefresh)(

[FeatureLevel, ScreenSpaceSize, Material](FRHICommandListImmediate& RHICmdList)

{

GetRendererModule().RequestVirtualTextureTiles(Material->GetRenderProxy(), ScreenSpaceSize, FeatureLevel);

GetRendererModule().LoadPendingVirtualTextureTiles(RHICmdList, FeatureLevel);

});

// Run all render commands and wait till they’re done.

FlushRenderingCommands();

```

But every time, the mips in use at the time the screenshot was taken, even with a 5 frame delay, were not the desired mips that the scene eventually landed on. I thought for sure the last one would work given the fence `FFrameEndSync::Sync` in FlushRenderingCommands, but perhaps the actual dispatch of the command lists to the GPU is further delayed. I’m unsure and would love to know more.

Is there no deterministic guarantee of when a VT is fully streamed in, and no way to poll for it? This seems to be corroborated by https://dev.epicgames.com/community/learning/tutorials/dB5a/unreal-engine-cinematic-prestreaming-virtual-textures ? Is the only option for testing to hardcode a fixed delay and hope for the best? Or cinematic prerecord VT requests, even if the scene is not changing?

For polling, I tried calling `HasPendingInitOrStreaming` (from link 3), but this always returned false, even at the start of Event Prepare Test. I considered using IsFullyStreamedIn(), but this comment gave me pause:

``` // IsFullyStreamedIn() might be used incorrectly if any logic waits on it to be true.

// there could be optional mips which are not available to be loaded, so waiting on IsFullyStreamedIn would never finish```

Aside: What are “optional mips” and how does one create an example asset with them?

Any assistance would be appreciated!

[Attachment Removed]

Hi,

There is no API for detecting that virtual texture streaming has settled. Instead we would recommend setting _both_ Delay and FrameDelay on your AScreenshotFunctionalTest to give the streaming time to settle.

In addition it could be worth setting the virtual texture update speed higher just for your test runs. That can be controlled with something like: “r.VT.MaxUploadsPerFrameInEditor=500”. Note that in 5.8 the relevant cvar changed to “r.VT.MaxUploadsPerFrameInEditor.Streaming” and is 500 by default.

In the context of the comment you highlight, “Optional mips” are the high detail mips that are only optionally downloaded/available for streaming. For example, in a setup where users can select to have optional high-res textures.

Best regards

[Attachment Removed]

Thanks Jeremy, that’s good to know we just weren’t looking in the right place. And thanks for the cvar suggestion!

[Attachment Removed]