Now when I select and click on any texture and convert it to virtual texture, UE starts to look for all the textures available in the project and then crash at 50%, instead of converting that one texture.
I can repeat this bug n number of times.
I am doing something wrong or is there a way to clear the cache in some way? because I am kind of stuck as my texture pool of 6GB is getting filled and without using virtual texture, I may not be able to add more objects.
I would also like to know whether virtual textures use RAM memory or VRAM?
If I open the texture and enable the virtual texture, that works, but right-clicking on the texture in the work space and selecting virtual texture crashes ue5. So I cannot do batch virtual textures.
Myself here using the latest ue5 version from the launcher i have no such issues.
No problem right clicking and converting 20-30 images to virtual textures.
Might be worth to click on the dropdown on the engine version on the launcher and verify.
Perhaps some files are missing or corrupt and verifying may solve some problems.
And for your other question, Streaming virtual textures( so the non runtime variant)
are cooked and loaded from disk, then the gpu determines which tiles are visible on screen.
And loads the required tiles into the GPU memory cache!
I suggest looking at the virtual texturing documentation, its very helpfull.
So basically still GPU is used? SO what is the difference when it gives the texture pool limit reached and virtual texture? Both uses GPU VRAM?
I was getting that error, it has reached 6GB of my VRAM. So I tried converting the textures to virtual in case, I go out of VRAM. Once some of the textures were converted that pool error was gone.
A copy paste from the documentation: Streaming Virtual Texturing (SVT) is an alternative way to stream textures in your project from disk. SVT has several advantages—along with some disadvantages—when compared to existing mip-based in Unreal Engine.
Traditional mip-based texture streaming performs offline analysis of material UV usage and then at runtime decides which mip levels of a texture to load based on object visibility and distance. This process can be limiting because streaming data considered is the full texture mip levels.
When using high-resolution textures, loading a higher mip level of a texture can potentially have significant performance and memory overhead. Also, the CPU makes mip-based texture streaming decisions using CPU-based object visibility and culling.
Visibility is more conservative—meaning your system is more likely than not to load something—to avoid objects popping into view. So, if even a small part of the object is visible, the entire object is considered visible. The object loaded including any associated textures that may be required to stream in.
In contrast, the virtual texturing system only streams in parts of the textures that UE requires for it be visible. It does this by splitting all mip levels into tiles of a small, fixed size. The GPU determines which of the visible tiles are accessed by all visible pixels on the screen. This means that when UE considers an object to be visible, it’s communicated to the GPU which loads the required tiles into a GPU memory cache. No matter the size of the texture, the fixed tile size of the SVTs only considers the ones that are visible. Tile GPU computes visibility using standard depth buffers causing SVT requests to only happen for visible parts that affect pixels.
//
So when using virtual texturing you are requesting differing amounts of texture sizes depending on visibility and distance.
I would suggest you to look at some of the optimization talks on youtube.
Certain things dont always need 4k texture maps. depending on size of the object you can lower the texture size without losing much detail. Allot of the larger objects i personally use do use a 4k albedo map but the other textures like normal roughness i tend to lower to 2048-1024. Try lowering them and see if you could even tell the difference. Also texture packing is great, instead of having 5 different textures try packing them into 2-3! all of these things help greatly with performance and pool usage.
Hey Di3on this is great. I posted a few days ago trying to get more information on SVT. Have you done any performance testing on packing textures into a virtual texture? I am a little lost on when to use SVT because there is a performance cost for texture lookups. It seems useful for larger meshes that are easily occluded, where you want only a portion of the texture loaded into memory, but at full res, not mipped. Is there any other use case that would benefit? I was thinking you could pack together props into one large SVT to help nanite render passes?
Also, am I right in thinking that SVT only really works if you have a contiguous UV layout? If your UV texture sheet layout is randomly packed then SVT will just be loading in all the tiles anyway? and will defeat the purpose?
Wouldn’t tiling textures be kind of useless for SVT?
Have you tried the UDIM workflow in the docs, where you can assign individual textures to SVT tiles without having to pack anything?
Sorry if its a lot I have so many questions
Hi Maasj,
I have not done any specific performance testing comparing svt vs the old method.
But packing textures in general is a good idea whether you use svt or not.
In my case i have for example a large amount of forest debris(branches twigs pinecones etc)
that all share the same material packed into 2 textures. And these meshes are not large at all, so i would consider that like you would want your props in one texture. Svt uses the gpu to consider what is visible compared to normal mip based uses cpu. And svt only uses the parts of the texture that are visible tiles. So i would think you would get some performance benefit because not all props are on screen at the same time, and our modern gpu’s are very fast.
But i am not a 100% sure in my case what parts of the texture layout it is actually grabbing and my layout on these props is very randomly packed.
Tiling textures… hmm, you would think that it would be more likely that it would be getting the full res since it is more likely to have the texture fully on screen but im not sure.
There are some performance differences when it comes to sampling and texture fetches.
But when the objects use the same uv’s and sampler source they combine into virtual texture stacks. I would say if you are really worried about performance maybe do some testing on a scene with both methods and see if it really makes a difference.
Have not tried the udim workflow yet but it looks usefull, with characters for example having one shared texture for different parts is allot better than having seperate ones for each.
No problem on the question amount.
Found helpfull answers on the forums myself over the years.
So i thought why not try and help others like they helped me
edit: try the command r.VT.Borders 1 for a visualiser on svt tiles
Hmm FameKrafts,
That is some very strange behaviour indeed.
Do the textures share the same master material?
Just to test, could you remove the textures from one of your parts that use the same master material. And create one new material with these textures applied to it. So that the one object that uses those 3 textures is not sharing any material with anything else, save, then try to convert those 3 textures again.
I will try creating new material, right now I have only created a new material instance so that I can change the tint of different instances of the object in the scene.
