Announcement

Collapse
No announcement yet.

Virtual Texturing Feedback

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


    Originally posted by Haoris View Post

    Answer here :



    i couldnt find 'Adaptive Virtual Texture method Jeremy mentioned in the live stream'

    Anyone knows how to implement the Adaptive Virtual Texture method?

    Comment


      Originally posted by BulleTime View Post




      i couldnt find 'Adaptive Virtual Texture method Jeremy mentioned in the live stream'

      Anyone knows how to implement the Adaptive Virtual Texture method?
      That, unfortunately, is way beyond of what can be answered in a single forum post.
      You can start here.

      Comment


        Originally posted by Deathrey View Post

        That, unfortunately, is way beyond of what can be answered in a single forum post.
        You can start here.
        So yeah that means its not very possible yet with ue4.23.

        So another question: Is it even possible to 'update' or change a runtime virtual texture at runtime? (like a spline road tool) ?

        E.g. when i spawn a actor at runtime, it wont draw the VT..
        Last edited by BulleTime; 11-15-2019, 08:29 AM.

        Comment


          when use VT for landscape and turn on tessellation in landscape material, it must crash.
          unreal 4.24 preview2

          Comment


            I made all these beautiful user cases and screenshots but got no answer
            All I'd like to know is whether this is indeed a bug, or if I've missed a setting somewhere.
            And if it's a bug, I hope this is fixable for 4.24 as it's pretty essential to the functioning of Streaming Virtual Texturing.

            Comment


              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.

              Comment


                Hi Ben,

                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.../UDIM_Grid.jpg

                I worked for 10 years in Film at MPC and DNEG (https://www.imdb.com/name/nm2501899/).
                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.

                Thanks

                Comment


                  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.

                  Comment


                    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.

                    Thanks for looking into this
                    Attached Files

                    Comment


                      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

                      Comment


                        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.

                        [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.
                        Last edited by beningram; 03-16-2020, 02:21 PM.

                        Comment


                          cool! thanks for the possible fix,

                          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

                          Comment


                            Hi All,

                            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?

                            Thanks very much!

                            -Donald Newlands

                            PS here's our project demo: https://vimeo.com/372546190

                            Comment



                              Originally posted by NC3D View Post
                              Hi All,

                              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?

                              Thanks very much!

                              -Donald Newlands

                              PS here's our project demo: https://vimeo.com/372546190

                              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

                              Comment


                                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.

                                Comment

                                Working...
                                X