Hi, A while ago I had some questions regarding the texture 2d array structure [Content removed]
And on this topic was established that the texture array combines textures inside. It was also established that they will not be virtual, even if the textures selected are. Is there a reason for this? I feel like it would be a great benefit to be able to use virtual textures this way as well, and have the benefits for memory saving and not having to craft the atlas ourselves.
Hi Pedro,
The Texture2D and Texture2DArray assets map directly to structures provided by graphics APIs and are hardware accelerated in nearly all platforms, which allows them to take full advantage of hardware samplers, hardware caching and other low-level optimizations.
Virtual Textures, on the other hand, are very complex software abstractions implemented by Unreal Engine on top of graphics APIs. They require a custom sampling strategy to handle efficient indirect access of texture tiles that can be streamed in and out on demand. A single Virtual Texture uses several Texture2Ds (and maybe even several Texture2DArrays) under the hood.
Implementing some form of Virtual Texture Arrays would probably be a great undertaking for the engine, and so far it seems that the devs have not considered that it would be worth the required development time. Note that, in most cases, Virtual Textures should probably not be used where a simple Texture2D would suffice.
Now, from your older question, I see you are attempting to use large UDIM textures, combined with the ability to select a different appearance on a material based on a mask texture (which can be done more conveniently and efficiently by using Texture2DArrays rather than multiple Texture2Ds). Unfortunately, Unreal added support for UDIM using Virtual Textures as the underlying technology, and Arrays of Virtual Textures are not supported in the same manner as Texture2DArrays, which means that even today you must choose between using Texture2DArrays without UDIM support, or multiple individual Virtual Textures with UDIM support.
Currently, you will likely have to choose one of these approaches:
A) Use multiple independent Texture2DArrays, one for each region that would correspond to a UDIM tile, and work without UDIM. Select which array to sample from based on the tile of the current coordinates, and which array index to sample from based on the mask.
B) Use UDIM with multiple Virtual Textures, one for each area identified by the mask. Select which virtual texture to sample from based on the mask, and let it handle UDIM.
At a first glance, I’d guess that using Texture2DArrays should perform better, although it probably requires more work and more GPU memory usage. On the other hand, I’m not sure of how relevant would the performance difference actually be, because when using the Virtual Textures approach, only one of them will probably be accessed on each fragment on the material.
If you’d like, I can try to ask Epic staff if there are any plans to support Virtual Texture Arrays in the future. As I said, a completely general implementation to support openworld landscapes and other huge-area use-cases seems like a big undertaking, but an implementation restricted to UDIM support, where all textures of the array from each tile are always accessed in exactly the same way over a not-so-big model, might be a manageable idea.
Best regards,
Vitor
The specific case I`m trying to handle now is different. Indeed, the array will perform better, but the case now is having many masks for different architectural pieces in a big city, which is the reason why the question has become relevant again. Given that now there will be many more masks that can show or not on multiple pieces, the memory savings benefit of the virtual textures has started to become more attractive. That’s why the idea of an array of virtual textures was appealing to me, combining the ease of use of the arrays with the virtual textures.
It would be a good feature to have, I would say. At least I think it would be nice thinking in a scenario for example, now we can use bindless resources, which is also an array based structure, very similar in how you use for sampling, and since bindless resources is a feature now all hardware have, virtual arrays would be a perfect fallback for older hardware. Even without that, just not having to keep patching a bunch of textures in an atlas and being more flexible would be nice.
I see. Note that regular textures should also be streamed in and out as needed based on the visible objects that require them. But I do see value in the concept of Virtual Texture Arrays. I’ll let you know if I find any official information about their feasibility, but note that there is no mention of such a feature on the public roadmap.
Best regards,
Vitor
Hi Pedro,
I have some information for you directly from Epic.
First, they noted that Virtual Texture Arrays are not on the backlog, according to [this recent [Content removed]
On the other hand, [mention removed] told me the following:
[quote]
We are considering something related called “Virtual Texture Collections” which are like bindless “Texture Collections” but populated with virtual textures only and may operate in a similar way to what the licensee is calling virtual texture arrays. They have a constraint that each texture in the collection must share the same pixel format.
UDIM can have different resolution per tile, and stream only visible tiles. TextureArrays need same resolution per slice and mip streaming is limited. So potentially UDIM uses less memory. But then again that presupposes the use of virtual textures for other things, meaning that you are already paying to have virtual texture pools. UDIM require two texture fetches per sample. So usually less performant than texture arrays. The hit depends on what else is going on in the shaders, so would require a bit of profiling with real content.
[endquote]
From the linked post and from the first paragraph above, I understand that the engine devs are aware of the need for a feature that addresses such use cases. But since this is still under consideration, we cannot give estimates on the availability of the feature or what specific use cases it will be best suited for.
Best regards,
Vitor