Ok, thank you for your feedback.
I have now turned on VTS in my project settings, and the textures are now in the correct configuration, but as you can see from my images, I am still not able to get the textures to line up correctly, are there any settings in the import panel of the model that I need to be aware of to get the proper result?
@Limkork Just found a bug with UDIM layout sizes that arenāt a power-of-2, which I suspect is causing your problem. If you add some padding images to make each UDIM dimension a power of 2, that may fix things. UDIM efficiently supports images of different sizes, so you should be able to use empty 128x128 textures to add padding without using a significant amount of memory.
@**beningram **Does reimporting UDIMs work? Instantly crashes the editor for me. Tested multiple meshes/projects.
After some tests, it looks like the quality of the virtual texture is relative to the size of the RuntimeVirtualTextureVolume which make this unusable on landscape for almost every project, even while setting the size of the virtual texture in the RVT asset to 8 (max value), unless you work on a landscape smaller than a RuntimeVirtualTextureVolume with scale of 1000010000 max.
While using it on a 8kmĀ² lanscape it goes from this :
To this :
In fact, to get the same quality than in the first screenshot, I have to set the scale of the RuntimeVirtualTextureVolume to 50005000 which is not really usable
Ok, do you mean that the number of UDIM islands pr object should be power-of-2?
UDIM textures are logically arranged in space by XY coordinates in the file name. Until the bug is fixed, this space needs to have power of 2 dimensions. For example this sequence makes a 2x2 grid, so it should work: 1001, 1002, 1011, 1012. If you add an additional 1003, 1013, then you have a 3x2 grid and it wonāt work correctly for now. If this is the layout you need, adding 1004, 1014 would make a 4x2 grid which will work again.
Hi, I understand that you worked on virtual texture and not runtime virtual texture but can you ask someone in charge of runtime virtual texture to answer the problem I posted just above please?
This feature is really interesting for roads and path and spline decals has been requested for years 
Does anyone else get random crashes in a packaged build with VT?
is the error my team keeps getting seemingly at random. We have a fair bit of virtual textures in use so not sure if itās related to the amount weāre using or if anyone else has come across it?
> Hi, I understand that you worked on virtual texture and not runtime virtual texture but can you ask someone in charge of runtime virtual texture to answer the problem I posted just above please?
The engineer in charge of runtime VT will be on the UE4 live stream tomorrow (9/19) at 2pm EST. Iāll be on as well. That would be a good opportunity to ask questions (or maybe the answer will be proved).
> Does anyone else get random crashes in a packaged build with VT?
Iāve never seen that Assert hit, that suggests thereās something wrong with one of your VT textures (size is 0). Are you getting that as you play through a level, or when switching between levels?
Specifically when playing through a level. Donāt think anyoneās reported it happening when switching between levels but Iāll double check to see if anyoneās had that.
For the texture size as 0, how would that happen? They should all be a power of 2, ranging from 256 to 4096.
Thanks ! 
So from what I understand of the live stream, the texture quality issue is a RVT resolution issue and is actualy locked too low to get usable results for ālargeā (more than 1kmĀ²) landscape?
But even you increase this resolution in next engine versions, getting the same results than 4k (or even 2k) textures on a 8kmĀ² landscape wouldnāt mean insanely high RVT resolution?
And how should I use this with world composition? One RVT volume per proxy bound to proxy level bounds? One RVT volume in the persistant level set to cover the whole landscape component?
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.
Iām also interested on the answer to this. Should I use one RVT volume per landscape tile/streaming level?
Virtual texturing for landscape materials. Right now I have some demo levels that use World Composition (4 x 4 km each, divided in sixteen 1009 x 1009 landscape tiles, if I remember well), and it would be great to simplify the landscape materials, because I ended up having to strip them down of some stuff to make them performant again. As they wonāt change at runtime in the game, it would be great to kind of bake down their layers (snow, grass etc etc). Also that possibility, in the Virtual Texturing Quick Start docs, of also including textures of static meshes in the VT asset used for the landscape opens a lot of possibilities, for richer, less repetitive terrain, integration of paths etc.
Based on answers from the stream, I have a bit of a follow-up.
If layout of RVT is to be hardcoded, It would still be good to have one extra slot. Given the way RVT is likely to be used, many will inevitably run into needing to pass something custom(eg. wetness/puddle maps for landscape). Perhaps 3 more layouts(Usual attributes plus BC4, BC1 or BC3) coupled with extra material pin on RVT output, would be taken into consideration ?
Iām getting UVs showing up in wrong spots when I import a udim
my 1002 is showing up in 1032
is there a way to shuffle the UVs in the import? or am I missing something in the way Iām importing the textures?
are there limitations to filetype?
issues with anything like mixing filetypes? limits to 8bit or 16bit?
@YuuJin Most likely youāre hitting bug with non-power-2 UDIM layouts. The number of textures in both UV directions need to be power of 2, or else UVs will be messed up. This will be fixed in 4.23.1, but for now youāll need to add dummy images to pad your layouts.
Any filetype normally supported by UE4 should work with UDIMs as well. All image files that make up a single UDIM need to have the same file type however.
thx for the input!
Iāve already tried it with dummy files as well, the dummy files are png with 128x128, the bigger ones are 4k (4096px)
in a tile set going from 1001-1034 (square shaped)
they always mess up in the order when looking at the texture in engine for some reason
I tried making big textures with the images as well
but thereās memory complaints in unreal and it just crashes if the images are too big (seems to die with 16k png that are over 1XXmb?)
8k (8192) seems fine, merging all the tiles into one texture
right now Iām testing compressing the png files to something smaller with the 16k (16,384) textures, maybe have to drop to 8bit
it also seems itās more stable working with the big VTs with dx11
so my plan is to prep all the shaders in dx11
and then switch to dx12 to do renders with raytracing
