I’m only mildly Maya-literate, so not sure how to read the UV diagram you posted.
The UV origin in UE4 is at the top left of the image. So for UDIM the 1001 square should have UV (0,0) at the top-left, and (1,1) at the lower-right. This should match how you would fit a non-UDIM texture to a plane.
The 1002 square increases the U coordinate by 1. So it should have UVs (1,0) at the top-left, and (2,1) at the lower-right.
The 1011 square increases the V coordinate by 1. So it should have UVs (0, 1) at the top-left, and (1,2) at the lower-right.
Etc.
None of the UVs values should be negative.
It seems we’ve got to the source of the confusion
As opposed to what you describe, UDIMs are conventionally read from bottom to top.
The UDIM order presented in my Maya screenshots are not specific to Maya - I could have taken a similar screenshot in Mari, Katana, Clarisse, Modo, Substance or any other software: each would have presented the UDIMs order loading from bottom to top.
This is even the order described in the UE documentation: https://docs.unrealengine.com/Images/Engine/Rendering/VirtualTexturing/Streaming/UDIM_Grid.jpg
I worked for 10 years in Film at MPC and DNEG (Patrick Harboun - IMDb).
This UDIM workflow is cemented in every step of the pipeline of Film and Animation studios, and the hope is that, thanks to SVT, we can load in assets and textures build with the conventional UDIM workflow into Unreal without having to modify thousands of models and textures.
The UDIM image you link matches what I describe, at least as far as UV regions mapping to UDIM tiles.
1001 has UVs from 0-1.
1002 has U from 1-2, V from 0-1
1011 has U from 0-1, V from 1-2
etc.
There’s some confusion on whether the UV origin is shown in the lower-left (typical for OpenGL) or upper-left (typical for DirectX and most game engines, UE4 included). But even if this is ‘wrong’, that will only make your images upside-down. It shouldn’t affect the layout of individual UDIM tiles.
Right, I understand that UV origin is different for DirectX and OpenGL however the UDIM standard has been around for almost 10 years now and users expect their textures to read from bottom to top. Even softwares that support both APIs like Substance Painter and Designer have adapted to this unified standard.
I’ve attached my example files here for you to test.
These are just a few plane meshes (2x2, 10x10, etc) and 100 labeled udim textures.
If you load the textures on the 10x10 plane mesh, you’ll see that the images unfortunately don’t load upside-down and compensate for the different UV origin, as you describe.
my current work around idea for characters is to export the in-game mesh with a different UV tile set than one used for painting in substance painter.
so yeah it would be pretty cool if you could maybe tickbox specify if the V tile order goes up or down,
then I wouldn’t have to make any weird changes from other art authoring programs
even if I use unreal with DX12 on for ray tracing, the the udim tiles still need shuffling around to sit in the correct spots.
other than that the udims work pretty nicely if the shaders are kept simple
@ElephantFury@YuuJin OK I think I found the problem. UE4 fbx import has code to automatically flip the V-coordinate to account for different UV origin. But this is breaking UDIM coordinates which contain UVs outside the 0-1 range.
In Engine\Source\Editor\UnrealEd\Private\Fbx\FbxStaticMeshImport.cpp, search for the comment “//UVs attributes”, around line 716. Replace the following block of code with this:
for (int32 UVLayerIndex = 0; UVLayerIndex < FBXUVs.UniqueUVCount; UVLayerIndex++)
{
FVector2D FinalUVVector(0.0f, 0.0f);
if (FBXUVs.LayerElementUV[UVLayerIndex] != NULL)
{
int UVMapIndex = (FBXUVs.UVMappingMode[UVLayerIndex] == FbxLayerElement::eByControlPoint) ? ControlPointIndex : RealFbxVertexIndex;
int32 UVIndex = (FBXUVs.UVReferenceMode[UVLayerIndex] == FbxLayerElement::eDirect) ?
UVMapIndex : FBXUVs.LayerElementUV[UVLayerIndex]->GetIndexArray().GetAt(UVMapIndex);
FbxVector2 UVVector = FBXUVs.LayerElementUV[UVLayerIndex]->GetDirectArray().GetAt(UVIndex);
const float U = static_cast<float>(UVVector[0]);
const float V = static_cast<float>(UVVector[1]);
const float VTile = FMath::FloorToFloat(V);
const float VOffset = V - VTile;
FinalUVVector.X = U;
FinalUVVector.Y = VTile + (1.f - VOffset); //flip the Y of UVs for DirectX
}
VertexInstanceUVs.Set(AddedVertexInstanceId, UVLayerIndex, FinalUVVector);
}
This will flip the V-coordinate within each UDIM page, but will preserve the layout of each page. A similar change needs to be made in FbxSkeletalMeshImport.cpp as well.
[EDIT]
It turns out this fix will break wrapped UVs (for meshes that aren’t using UDIM). So it’s fine to apply the change locally (and be aware of potential problems with wrapped UVs), but it’s not appropriate to add to the default engine. My current plan is to fix the UV layout when importing UDIM tiles, but this won’t make it into 4.25.
I’ll maybe get the engine guy on my team to apply that when we move to 4.24 later on maybe, not sure if I’m confident enough to try to mod this myself just yet, so I won’t be able to report it here as a possible solution till then
As I understand it, the VT size limit for all tiles in 4.23 is 16K x 16K, correct?
Has anyone imported larger textures?
Would it help if we tried on a machine with more RAM?
Also, does 4.24 improve the size limits?
And can anyone suggest utilities for tiling very large images?
haven’t tested bigger files
but i did notice i didn’t need filler tiles (extra tiles to satisfy the 4 x 4 texture files) in 4.24 to load up a udim set like in 4.23
Size limit isn’t exactly 16k x 16k, but there is a practical limit of around that size due to UE4 using 32bit size/offsets at various places in image import code. More RAM in your machine won’t help with this unfortunately. I don’t think this will be fixed in initial 4.24 release, but it’s possible it could make it in for one of the 4.24 point releases.
Hi
Thanks for the suggested fix. Unfortunately editing FbxStaticMeshImport.cpp didn’t have any effect for me.
I even tried deleting the entire Fbx folder from C:\Program Files\Epic Games\UE_4.23\Engine\Source and UE still loaded up normally, allowing me to import Fbx meshes as if nothing happened.
Could you please let me know if there is any other file I would need to edit?
Thanks
You need to download source version of the engine from GitHub, modify it and build in Visual Studio. Launcher version can not have sources modified or rebuild.
Chiming in here, but I’ve been playing around with things VT related on 4.24 preview 4 and while I can get some pretty good results on large large texture sizes, but once my texture size is greater than ~1,000,000 I just get a constant spit out in my log of
“LogConsoleResponse: Display: Failed to allocate VT page from pool 0
LogConsoleResponse: Display: PF_DXT5
LogConsoleResponse: Display: PF_DXT5”
I’m curious if this is a result of 4.24 bug or just my having eyes to big for my VT stomach. That being said I seem to be able to still use the VT in editor despite that warning
If you hit that message, it means the physical VT atlas (the big texture that holds all the visible pages) is full. You can control the sizes of these texture atlases in your BaseEngine.ini file, under the [/Script/Engine.VirtualTexturePoolConfig] section. This has a default size, as well as a list of entries that control the size of pages for different texture formats. Increase either the DXT5 pool, or the default pool size and that warning should go away. There will be a practical limit to the size of each pool, as GPU is limited to 16k x 16k texture. So the pool size will be clamped to (16k * 16k * FormatSizeInBytes). For DXT5 textures (1 byte per pixel), this will be a max size of 256MB.
When the engine is running, you can print out the status of these physical pools using the console command ‘r.VT.ListPhysicalPools’
I already posted this questions into the Unreal Engine Subreddit, but no one had a clue of what is causing my problems so they redirected me to this thred here - hopefully you are able to get around this problem
I am building a landscape shader and I thought it would be nice to use the ‘new’ Virtual Texture functionality in Unreal.
There is actually very few tutorials and documentation out there, but I thought I’ll give it a try. So I watched the Unreal live stream about virtual texturing and did everything like they did - as far as possible. Anyway.
For testing it the most simple way, I build this graph here: Imgur: The magic of the Internet
My first problem with this is, that the tiling is very hard to control. When I use the LandscapeCoords node with a value of 8, it kind of works … but whenever I want to parametrize it with a divide/multiply node the results are very strange.
For example I choose a value of 8129 in the LandscapeCoords node and divide it with 1000, the result is a completely different than using a straight 8 as said above. The tiling is so high, that it’s just grey … is there something I don’t get?
The result with a value of ~8 is still not satisfying at all. The chosen mip level is way to high -Imgur: The magic of the Internet
Here is another example - I get kind of a moire effect and obviously the mips level is totally off in this one - Moire - Album on Imgur
So the question here is, how can I manipulate it to get the correct mip maps? The documentation tells me, that this is possible by using the View Property node:
So the two main questions here - how do I manipulate the used Mip Maps and how do I modify these using the View Property.
Currently having issues with the UDIMs stacking in the wrong direction and just need to know if this only works with the source version of the engine and if I need to re-import my mesh for this to take effect or if this will just automatically fix the UV orientation on meshes already imported into my project.
Many thanks for the fix
Do you think it would be possible to include it in a 4.24.1 release?
Since it’s such a fundamental fix to the basic functioning of UDIMs, it would be unfortunate to have to wait until 4.25.
Thanks
It’s too late to add anything to 4.24.1, so it won’t be in there for sure. I may be able to get it into the next 4.24 point release, but it’s not entirely up to me.
on first attempt to add this feature, my engine guy added the script adjustment beningram posted and compiled it, and the virtual textures were inverted,
then, he added it to the skeletal fbx file thing, recompiled the change
and the result is the images i added below
the mesh is a basic 4 x 4 tile and the udims are separate tiles imported as virtual textures
what’s the missing steps to get the mesh to load the VT set correctly?
