Virtual Texturing Feedback

[RyuMaster]

Something is certainly wrong with VT and landscape, but I can not figure out, what exactly. Here is the comparison image. On the left, I use large 16384x16384 texture; On the right, same texture, bus stream from 2048x2048 chunks (using fix supplied above to fix Y rotation); Now, on the left, single 16384 texture is applied normaly. On the right, one stream as chunks, is applied with some odd offset.

[raianlp]

Thanks for the answers here! Any chance you could briefly describe how cache eviction policy works? Does VT unload tiles after some time? For example, when we don’t need specific texture mips anymore? Is it implemented at all?

UPD: After some investigation I ended up thinking that cache eviction is implicit i.e. we just reusing parts of textures (allocated in FVirtualTexturePhysicalSpace).How true is that?

[schiho]

I skimmed through the Issues and I would like to get some more info on couple of things I’ve selected. To understand my usage case, we are doing in engine cinematics, using tons of high-res textures (mostly 8K) and we don’t care too much about running on high fps, as we are focused on the final render.

1. First a broader question, looking at our use case, is VT something we should definitely consider or are we fine not switching to it?

2. I’ve heard that UDIM’s were fixed for FBX, what about Alembics?

3. Ben Said
   "Virtual textures are not currently supported in ray-traced shaders "

So we cannot use raytracing, if we use VT Textures?

4. Ben Mentioned:
   "In general switching textures to VT will save memory, but increase the cost of materials. However since VT enables much higher texture resolutions to be used, materials can often be… "

Is this about being able to import higher resolution textures or did I miss something?

5. Ben said:
   “Larger than 8k textures should import correctly, but UE4 texture import code currently keeps everything in working memory, so large textures will eat a ton of ram. I’m not sure if this will be addressed for the initial release, but we’ll see.”

Is this still an issue, we have ton’s of large textures (90%are 8K)

Thanks a lot for helping out here!

[YuuJin]

I’m using virtual texturing (VT texture streaming objects, not udim or the landscape VT one)
with ray tracing, sometimes i have to turn off raytracing with switching to DX11 in order to work without crashing, then just turn on dx12 when i want to light with raytracing

[jkinz3]

I’m using 4.25.1 and my landscape textures are super blurry when using RVT. I even shrunk the volume down to 200x200x200 and it still is really blurry. What can I do to fix this?

[anonymous_user_8b31b095]

Hi, there is an issue with tiles not streamed for a material on a mesh that is occluded by a mesh that has a translucent material with VT textures. It seems like a translucent material with VT is effectively occluding any VT that is behind. This issue does not occur when using regular textures on a translucent material.

[SophiesChoice]

@jkinz3

I’m using 4.25.1 and my landscape textures are super blurry when using RVT. I even shrunk the volume down to 200x200x200 and it still is really blurry. What can I do to fix this?

Your textures are probably set as Virtual Textures. Right click and convert them to normal textures.

[Actuss]

I am using tiled landscape (with World Composition), and I am trying to use VT. It worked great with one, “solid” landscape, but 8129x8129 landscape is never a good idea, so I switched to tiled landscape. The problem is that when my terrain tiles are not loaded in the editor, landscape in game is just black. When I load them - the textures are correct in game, but when I unload them again, terrain in game is black again. What’s going on with it? Thanks!

Edit: I have noticed that when I build my game while all tiles are loaded, it actually works. But only for landscape, and not for landscape LOD meshes (my LOD meshes are using the same material and virtual texture as landscape). Those LOD’s are just black. At least it is a progress…

[MostHost_LA]

@Actuss Read my work around a few posts above. each tile needs it’s own material with it’s own VT reference.

[krz9000]

i can confirm that the “runtime virtual texture sample parameter” does not take the instance linked RVT. it always renders the RVT that is set inside the “virtual texture sample parameter”-node. this is a pretty big dealbreaker for my project since i use a quite complex landscape shader and many, many worldcomposition sublevels.

is epic aware of this issue?

[MostHost_LA]

@krz9000

i can confirm that the “runtime virtual texture sample parameter” does not take the instance linked RVT. it always renders the RVT that is set inside the “virtual texture sample parameter”-node. this is a pretty big dealbreaker for my project since i use a quite complex landscape shader and many, many worldcomposition sublevels.

is epic aware of this issue?

I reported it, but due to the pandemic I have yet to hear anything about it.

[Maximum-Dev]

@beningram

Lightmaps don’t use UDIM (also udim bug has always been there), so this is likely something different. First I’ve heard of it, I will try to investigate soon.

Hello,

WorldHeight is said to be storing data in 16Bit but it doesn’t.

I’m using world position B channel to create a gradient on the landscape along Z axis and storing that into WorldHeight, when I sample from it, it’s 8Bit. Step like artifacts are quite obvious.

Have you been aware of this?

[Bashinerox]

To everyone having a problem with runtime virtual textures on tiled landscapes in PIE:

I discovered that the Runtime Virtual Texture Component (which is the component attached to a Runtime Virtual Texture Volume) has an incorrect decorator on the RuntimeVirtualTexture property. It is set to DuplicateTransient, instead of NonPIEDuplicateTransient.

When you press play in the editor, all scenes currently open are copied to a PIE version, so that moving things around in the scene isn’t permanent. Unfortunately, due to the DuplicateTransient decorator on the aforementioned property, this will reset that field in the PIE version of all scenes that were open when you pressed play, and all scenes that are streamed in during PIE will have no bounds to assign from.

Changing the above decorator will fix this issue, and I have submitted a pull request for it.

A couple of workarounds that I can think of now:
(Note: i have not tested any of these workarounds, as i simply fixed the decorator in my own custom version of 4.25 )

1. Have your perisistent level be an empty level that loads a sublevel via blueprint which contains the Runtime Virtual Texture Volume in it, and that sublevel contains all of your world composition tiles as sublevels, and make sure that this sublevel is not open in the editor when you press play.

2. Reassign the runtime virtual texture component’s VirtualTexture property after the level containing it loads. This looks like it will need manually calling some code present in the RuntimeVirtualTexture’s PostEditChangeProperty, in the actor whose job it is to reassign the property on load:

#if WITH_EDITOR //the notify functions are only available in the editor, which is ensured if you are in PIE anyway, where the bug happens.
runtimeVirtualTextureComponent->VirtualTexture = runtimeVirtualTexture;
RuntimeVirtualTexture::NotifyComponents(runtimeVirtualTexture);
RuntimeVirtualTexture::NotifyPrimitives(runtimeVirtualTexture);
#endif

I hope this helps

[anonymous_user_2681644d]

> Does VT unload tiles after some time? For example, when we don’t need specific texture mips anymore? Is it implemented at all?
VT tiles are stored in a fixed size cache. Once the cache fills up, tiles are evicted using a simple LRU scheme to make room for new tiles.

> I’ve heard that UDIM’s were fixed for FBX, what about Alembics?
The latest UDIM fix should work for all mesh import formats.

> So we cannot use raytracing, if we use VT Textures?
Raytracing shaders won’t update the VT feedback buffer. So I think it’s possible for ray-tracing passes to sample from VT, but they won’t cause higher resolution tiles to stream in. This might be OK if you’re using RT reflections combined with normal rasterization for other rendering (since the raster passes will trigger VT feedback). You may end up with low-res VT for reflected objects that are not present in the base pass though.

> Is this about being able to import higher resolution textures or did I miss something?
Right, I was making the point that if you have higher resolution textures, you may not need as many texture layers inside your material. Separate tiling detail textures may not be needed for example, since you can just bake the detail into the main (virtual) texture if resolution is high enough.

> Is this still an issue, we have ton’s of large textures
Texture import code should all be properly using 64bit sizes now, but everything is still kept in memory. So large VTs are possible if you have lots of ram. 8k textures should not be a problem.

> Hi, there is an issue with tiles not streamed for a material on a mesh that is occluded by a mesh that has a translucent material with VT textures
Yeah there have been a few bugs related to this. I think I’ve fixed them all, but I’m not sure if all the fixes have made it into the 4.25.x stream yet.

[raianlp]

Thank you for all the answers!

[Actuss]

I have another problem with RVT. When I open my project, some of the texture’s mip maps are black. When I move my runtime virtual texture volume actor, or change it in some way, it usually goes back to normal, but not allways or not everywhere. Interesting thing is that the my roads that are also baked onto the same RVT works fine. When I move my camera around, it seems to finally bake. Also. I have noticed that when I have this RVT on, it causes hitches during the game.

[Haoris]

I see some people telling they’re using RVT with tiled landscapes, can someone explain their setup please?

[MostHost_LA]

@Haoris

I see some people telling they’re using RVT with tiled landscapes, can someone explain their setup please?

You might loose your mind currently. Each tile needs its own material. Each material needs to specify the rtvt. Each tile needs to render to the correct rtv.
It works, but on anything large enough to require world composition it is a massive amount of work and needless files.
if/when they patch the instances to accept interchangeable rtvs, then the process would be a little easier. Create an instance for each tile and set it up on the tile itself.

[Haoris]

@MostHost_LA

You might loose your mind currently. Each tile needs its own material. Each material needs to specify the rtvt. Each tile needs to render to the correct rtv.
It works, but on anything large enough to require world composition it is a massive amount of work and needless files.
if/when they patch the instances to accept interchangeable rtvs, then the process would be a little easier. Create an instance for each tile and set it up on the tile itself.

Ok, that’s what I thought, each tile would need its own RVT. Yes, that would be a lot of work for 1000+ tiles (I’m just reminding that Novigrad map of The Witcher 3 is made of 2116 tiles :rolleyes: )

We should be able to use only one RVT on the main landscape actor but then we go back to this point and there’s no more news about this :

@beningram

The resolution of a given virtual texture ultimately is limited by the page table size. VT is typically divided into tiles of 128x128 pixels. Each VT gets a page table allocated, where each pixel in the page table corresponds to 1 tile in the physical texture. So an 8k x 8k VT would require a 64x64 page table texture. This isn’t generally an issue for more “normal” sized VTs, but it becomes a problem when you want to create huge VTs to cover terrain. The page table size is limited by GPU texture limits, and it’s also an uncompressed texture, so once it gets too large it actually starts to consume a large amount of memory.

So for terrains, I think the current state of the art is to dynamically adjust the page table as the player moves through the world, so only pages “close enough” to the camera origin are kept in memory. There are various ways to do this, one of them being the Adaptive Virtual Texture method Jeremy mentioned in the live stream. I believe there are slides online somewhere that describe how this works in the context of one of the recent Far Cry games. The plan is for us to implement something like this for future version of UE4, but I don’t have any specifics to offer yet. For now RVT will be limited to the current size limits, so it won’t work for huge terrains.

[MostHost_LA]

2116 tiles equals 2116 impostor/lod drawcalls. Thats a lot of wasted calls.
performance would be better with something closer to 8km tiles. Less tiles, less draw calls.