Announcement

Collapse
No announcement yet.

Virtual Texturing Feedback

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • replied
    Going to remind, that while not really important for virtual texture, being able to sample runtime virtual texture in domain/vertex shader is very much needed for a whole range of effects.

    Leave a comment:


  • replied
    ahh okay cool thanks, good to know it's not just me doing somethin wrong then

    Leave a comment:


  • replied
    hashu786 I'm not familiar with the alembic code, but some quick searching led me to the function AbcImporterUtilities::ApplyConversion(). Making this work will be a bit more involved since it's doing more, but the basic idea should be similar. Extract the fractional UV part and apply the transform to that, but preserve the integer UV part.

    YuuJin Do you mean reimporting? That's currently broken for VTs, you'll need to delete/import the textures for now. Fix for this should be in 4.25 (possibly 4.24.X).

    Leave a comment:


  • replied
    so I noticed even with 4.24 I can't reload a virtual texture without ue crashing immediately, is there a safe way to reload a virtual texture?

    Leave a comment:


  • replied
    beningram I made the UDIM fix with the fbx static mesh import and it worked like a charm, however I am having the same issue with alembic imports. Could you direct me as to which file I would need to edit to get that to work? Would I use the same code?

    Leave a comment:


  • replied
    You need to reimport any meshes after recompiling the engine with that change. Other than that, not sure why it wouldn't be working.

    Leave a comment:


  • replied
    Originally posted by ElephantFury View Post
    Hi Ben

    We've finally had the time to recompile the code and it works:
    Click image for larger version  Name:	udimworks.png Views:	0 Size:	584.5 KB ID:	1698046
    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

    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?
    Attached Files

    Leave a comment:


  • replied
    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.

    Leave a comment:


  • replied
    Hi Ben

    We've finally had the time to recompile the code and it works:
    Click image for larger version

Name:	udimworks.png
Views:	393
Size:	584.5 KB
ID:	1698046
    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

    Leave a comment:


  • replied
    Originally posted by beningram View Post
    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:

    Code:
    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.

    I'll get this fix into the engine, but it probably won't make it for 4.24. So you'll need to apply fix locally for now.
    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.

    Thanks!

    Leave a comment:


  • replied
    Hi guys,

    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: https://imgur.com/a/Lm0ShIC
    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 -https://imgur.com/a/NyAVnjz
    Here is another example - I get kind of a moire effect and obviously the mips level is totally off in this one - https://imgur.com/a/qZ3LHmn

    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:

    An example use case of these expressions would be to mimic the use of some distance-based shading in the RVT. Because RVT shading is camera-independent, this type of shading cannot be expressed directly. However, something similar is achievable by making the shading mip level-dependent. The Runtime Virtual Texture Replace node can be used to implement a mip level-dependent shading path only for the Runtime Virtual Texture Output 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.

    Leave a comment:


  • replied
    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'

    Leave a comment:


  • replied
    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"

    beningram 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

    Leave a comment:


  • replied
    So just two questions regarding RVT and terrain:

    Is it possible to spawn a actor in level that writes to VT, so it updates at runtime?
    When will unreal support full additive virtual texturing ?

    Leave a comment:


  • replied
    Originally posted by ElephantFury View Post
    Hi beningram
    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.

    Leave a comment:

Working...
X