Announcement

Collapse
No announcement yet.

Virtual Texturing Feedback

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

    #16
    Hi everyone, I'm the main owner of the core virtual texture system (not any of the runtime VT stuff). Thanks for all the feedback so far, I'm glad to hear people are excited about this. Everything posted look mostly accurate, I have a few additional notes.

    Larger than 8k textures *should* import correctly, but UE4 texture import code currently keeps everything in working memory, so large textures will eat a ton of ram. I'm not sure if this will be addressed for the initial release, but we'll see.

    Basic UDIM support should already be there. If you import a texture named like this: "whatever_1001.tga", the current directory will be scanned for additional UDIM pages, and they'll all be imported together. UDIM textures used in material should automatically apply the proper UV scale, so UVs from source mesh should work as-is. This feature is still very early and hasn't been tested very much...if someone tries it out, let me know how it works.

    The cost of a VT sample in material is 2 texture samples plus a bit of ALU in the base case. There is an optimization, where if multiple VTs are sampled with the same UV expression, they will be combined into a "VT stack". So really, each VT stack costs 1 texture sample, plus 1 additional texture sample for each VT in the stack. You can see the number of generated VT stacks in the material statistics window. So for example if a material samples 4 VT all with the same UVs, the total cost will be 5 texture samples (plus some ALU).

    Comment


      #17
      Hello, Could you elaborate more on the UDIM support i havent seen any info on virtual texturing but i have been trying to get UDIMs in for the longest tile and while granite is good it still limits what can be done where as directly manipulating the textures in engine

      Comment


        #18
        When importing an image into UE4, it will automatically detect if the image is part of a set of UDIM images, and if so, all the images will be imported into a single virtual texture asset. When sampling from this texture in a material, UVs are automatically scaled such that UDIM UVs imported into UE4 should just work.

        Comment


          #19
          Originally posted by beningram View Post
          Hi everyone, I'm the main owner of the core virtual texture system (not any of the runtime VT stuff). Thanks for all the feedback so far, I'm glad to hear people are excited about this. Everything posted look mostly accurate, I have a few additional notes.

          Larger than 8k textures *should* import correctly, but UE4 texture import code currently keeps everything in working memory, so large textures will eat a ton of ram. I'm not sure if this will be addressed for the initial release, but we'll see.

          Basic UDIM support should already be there. If you import a texture named like this: "whatever_1001.tga", the current directory will be scanned for additional UDIM pages, and they'll all be imported together. UDIM textures used in material should automatically apply the proper UV scale, so UVs from source mesh should work as-is. This feature is still very early and hasn't been tested very much...if someone tries it out, let me know how it works.

          The cost of a VT sample in material is 2 texture samples plus a bit of ALU in the base case. There is an optimization, where if multiple VTs are sampled with the same UV expression, they will be combined into a "VT stack". So really, each VT stack costs 1 texture sample, plus 1 additional texture sample for each VT in the stack. You can see the number of generated VT stacks in the material statistics window. So for example if a material samples 4 VT all with the same UVs, the total cost will be 5 texture samples (plus some ALU).
          So when is the initial release for VT? Really looking forward to this.

          Comment


            #20
            Originally posted by Mellnik View Post

            So when is the initial release for VT? Really looking forward to this.
            It's available right now in the 4.23 branch from git hub

            Comment


              #21
              Originally posted by beningram View Post
              Hi everyone, I'm the main owner of the core virtual texture system (not any of the runtime VT stuff). Thanks for all the feedback so far, I'm glad to hear people are excited about this. Everything posted look mostly accurate, I have a few additional notes.

              Larger than 8k textures *should* import correctly, but UE4 texture import code currently keeps everything in working memory, so large textures will eat a ton of ram. I'm not sure if this will be addressed for the initial release, but we'll see.

              Basic UDIM support should already be there. If you import a texture named like this: "whatever_1001.tga", the current directory will be scanned for additional UDIM pages, and they'll all be imported together. UDIM textures used in material should automatically apply the proper UV scale, so UVs from source mesh should work as-is. This feature is still very early and hasn't been tested very much...if someone tries it out, let me know how it works.

              The cost of a VT sample in material is 2 texture samples plus a bit of ALU in the base case. There is an optimization, where if multiple VTs are sampled with the same UV expression, they will be combined into a "VT stack". So really, each VT stack costs 1 texture sample, plus 1 additional texture sample for each VT in the stack. You can see the number of generated VT stacks in the material statistics window. So for example if a material samples 4 VT all with the same UVs, the total cost will be 5 texture samples (plus some ALU).
              Hey Ben... currently it is impossible to even import a 16k x 8k texture, it will hard crash with a failure to allocate memory. The amount of memory it is trying to allocate is huge (in the GBs), so there seems to another issue not related to just the size in memory for the textures. This is from the 4.23 branch on github. But generally marking texture as "Stream Virtual Texture" works.

              Tommy.

              EDIT: UDIM based import works, both in terms of single (initial file import) and as part of an import of a model... Cool!!!!!
              Last edited by TommyBear; 06-22-2019, 02:53 PM.

              Comment


                #22
                What determines what VT asset a given texture is stored in? This is important when breaking up assets for streaming.
                George Rolfe.
                Technical Coordinator at Orbit Solutions Pty Ltd.

                Comment


                  #23
                  Originally posted by duke22 View Post
                  What determines what VT asset a given texture is stored in? This is important when breaking up assets for streaming.
                  I might be wrong, but I think the textures are streamed from their individual assets into a VT in memory as needed, not stored into the VT assets. The whole point of VT is to not have everything loaded at once and break textures into individually streamable blocks, so you can have only a portion of it loaded, or different parts loaded with different mip map levels.
                  Last edited by Manoel.Neto; 07-05-2019, 12:27 PM.

                  Comment


                    #24
                    What would be terrain workflow with runtime textures ? I don't remember seeing anything that would allow texturing large landscape, for which resolution of a single runtime texture is insufficient.

                    Comment


                      #25
                      Originally posted by Manoel.Neto View Post

                      I might be wrong, but I think the textures are streamed from their individual assets into a VT in memory as needed, not stored into the VT assets. The whole point of VT is to not have everything loaded at once and break textures into individually streamable blocks, so you can have only a portion of it loaded, or different parts loaded with different mip map levels.
                      This is basically how it works. It's all stored... I dunno how it's done in UE4, but other than hopefully with good compression it's not totally relevant to a lot of concerns.

                      Since there seems to be confusion as to how VT works and what it does here's the best tl;dr I can do: All textures are broken down into little blocks. All non translucent objects then reference these blocks. Then the VT system figures out which blocks are needed to texture the current, onscreen content, and loads that content from disc into ram. Only the current, onscreen texture blocks needed are ever loaded, so regardless of what you have onscreen textures only ever take up a fixed, small amount of ram.

                      Now there's a bunch of details glossed over, and a bunch of stuff I don't know about how UE4 does it. Does UE4 support translucent VT? How are these texture blocks compressed? You can keep extremely low res mips of textures in memory at all times to avoid texture missing errors if the streaming doesn't get load the block in time at the cost of more ram, is this what UE4 doe? You might also want the former for say, raytracing purposes because that needs offscreen textures. Etc. But the basic overview is above. And the basic overview is, streaming is just handled for you. Unlimited streaming, of unlimited texture variety regardless of what asset type it is and limited only by final game package size. Unlimited texture detail is also handled, limited by bandwidth bottlenecks (say, HDD to ram speed) as well as, again, final game package size.

                      Comment


                        #26
                        Originally posted by Deathrey View Post
                        What would be terrain workflow with runtime textures ? I don't remember seeing anything that would allow texturing large landscape, for which resolution of a single runtime texture is insufficient.
                        Imagine your landscape uses a single texture of gargantuan dimensions where each texel is unique, but instead of storing the monster into disk it's dynamically generated on demand by running your blending material and caching the results into the virtual texture blocks around the camera position. There are special material nodes to support that workflow too and baking decals into the VT (and yes, this means the fabled spline decals become a reality).

                        Comment


                          #27
                          Originally posted by Manoel.Neto View Post

                          Imagine your landscape uses a single texture of gargantuan dimensions where each texel is unique, but instead of storing the monster into disk it's dynamically generated on demand by running your blending material and caching the results into the virtual texture blocks around the camera position. There are special material nodes to support that workflow too and baking decals into the VT (and yes, this means the fabled spline decals become a reality).
                          No, I mean I am not asking how procedural virtual texturing works, but how Procedural Runtime Textures(which is the name for PVT in Unreal) are meant to be used to texture landscape, that needs texture size beyond 500k~ x 500k~ texels, for it is maximum size of PRT.

                          Comment


                            #28
                            Originally posted by Deathrey View Post

                            No, I mean I am not asking how procedural virtual texturing works, but how Procedural Runtime Textures(which is the name for PVT in Unreal) are meant to be used to texture landscape, that needs texture size beyond 500k~ x 500k~ texels, for it is maximum size of PRT.
                            I assume these would be authored by your landscape creation tool. I've wondered the same question since I first read about megatextures in Rage and later with that one Granite demo with the glider.

                            Comment


                              #29
                              Originally posted by Deathrey View Post

                              No, I mean I am not asking how procedural virtual texturing works, but how Procedural Runtime Textures(which is the name for PVT in Unreal) are meant to be used to texture landscape, that needs texture size beyond 500k~ x 500k~ texels, for it is maximum size of PRT.
                              That's exactly the point: there is a "500kx500k" texture, but it's virtual, so it doesn't really exist. The parts close to the camera are proceduraly generated by blending the tiling landscape layers as needed. Geometry further away gets a lower res mip map generated, and thus requires less memory. As the camera moves closer, the higher mips are generated. This is all placed on a fixed memory pool.

                              Of course, you could also pre-generate a gigantic texture as UDIM files, Rage-style, but in modern hardware it's usually a better trade off to dynamically generate by blending layers and decals asynchronously instead of constantly streaming from disc. In Rage the entire virtual texture streaming tech took every ounce of power in the PS3 and X360 consoles, so they had no choice but to prerender everything at the texel-level (the lighting is baked directly into the textures, which is why there's almost no specular reflections in Rage). Doom and Wolfenstein don't do that anymore. Farcry 4 and 5 also use run-time generated VT on their terrains, with great results.
                              Last edited by Manoel.Neto; 07-10-2019, 09:34 PM.

                              Comment


                                #30
                                Originally posted by Manoel.Neto View Post

                                That's exactly the point: there is a "500kx500k" texture, but it's virtual, so it doesn't really exist. The parts close to the camera are proceduraly generated by blending the tiling landscape layers as needed. Geometry further away gets a lower res mip map generated, and thus requires less memory. As the camera moves closer, the higher mips are generated. This is all placed on a fixed memory pool.

                                Of course, you could also pre-generate a gigantic texture as UDIM files, Rage-style, but in modern hardware it's usually a better trade off to dynamically generate by blending layers and decals asynchronously instead of constantly streaming from disc. In Rage the entire virtual texture streaming tech took every ounce of power in the PS3 and X360 consoles, so they had no choice but to prerender everything at the texel-level (the lighting is baked directly into the textures, which is why there's almost no specular reflections in Rage). Doom and Wolfenstein don't do that anymore. Farcry 4 and 5 also use run-time generated VT on their terrains, with great results.
                                I don't think you've got the point of the question. It is related to specific implementation and tool set in UE4 rather than how procedural virtual texturing works or generic theory or how it is done elsewhere.

                                Simply put, You are given:

                                WorldComposition world, that consists of 16x16 505 landscape tiles at 1 vertex per meter.
                                Runtime Virtual Texture actor, that defines bounds of what is getting rendered into runtime virtual texture and its coordinates.
                                Runtime Virtual Texture asset.
                                Landscape material, with two networks, one for rendering into specific runtime virtual texture and the other one that samples from the same runtime virtual texture.


                                Do tell me, how to combine these into properly textured landscape.

                                In case the pattern of what I am hinting at is still unclear, if you place runtime virtual texture actor with maximum possible virtual texture size to cover all 16x16 tiles of your world composition, you get stunning 60 texels per meter of resolution.

                                Comment

                                Working...
                                X