Announcement

Collapse
No announcement yet.

Virtual Texturing Feedback

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

    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

    Comment


      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.

      Comment


        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 ?

        Comment


          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

          Comment


            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'

            Comment


              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.
              auke huys | artstation
              visual storyteller artist at sooii

              Comment


                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!

                Comment


                  Hi Ben

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

Name:	udimworks.png
Views:	286
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

                  Comment


                    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.

                    Comment


                      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

                      Comment


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

                        Comment


                          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?

                          Comment


                            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?

                            Comment


                              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).

                              Comment


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

                                Comment

                                Working...
                                X