Announcement

Collapse
No announcement yet.

Virtual Texturing Feedback

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

    #91
    Originally posted by beningram View Post
    > Hi, I understand that you worked on virtual texture and not runtime virtual texture but can you ask someone in charge of runtime virtual texture to answer the problem I posted just above please?
    The engineer in charge of runtime VT will be on the UE4 live stream tomorrow (9/19) at 2pm EST. I'll be on as well. That would be a good opportunity to ask questions (or maybe the answer will be proved).

    > Does anyone else get random crashes in a packaged build with VT?
    I've never seen that Assert hit, that suggests there's something wrong with one of your VT textures (size is 0). Are you getting that as you play through a level, or when switching between levels?
    Thanks !

    Comment


      #92
      So from what I understand of the live stream, the texture quality issue is a RVT resolution issue and is actualy locked too low to get usable results for "large" (more than 1km²) landscape?
      But even you increase this resolution in next engine versions, getting the same results than 4k (or even 2k) textures on a 8km² landscape wouldn't mean insanely high RVT resolution?
      And how should I use this with world composition? One RVT volume per proxy bound to proxy level bounds? One RVT volume in the persistant level set to cover the whole landscape component?
      Last edited by Haoris; 09-19-2019, 06:25 PM.

      Comment


        #93
        The resolution of a given virtual texture ultimately is limited by the page table size. VT is typically divided into tiles of 128x128 pixels. Each VT gets a page table allocated, where each pixel in the page table corresponds to 1 tile in the physical texture. So an 8k x 8k VT would require a 64x64 page table texture. This isn't generally an issue for more "normal" sized VTs, but it becomes a problem when you want to create huge VTs to cover terrain. The page table size is limited by GPU texture limits, and it's also an uncompressed texture, so once it gets too large it actually starts to consume a large amount of memory.

        So for terrains, I think the current state of the art is to dynamically adjust the page table as the player moves through the world, so only pages "close enough" to the camera origin are kept in memory. There are various ways to do this, one of them being the Adaptive Virtual Texture method Jeremy mentioned in the live stream. I believe there are slides online somewhere that describe how this works in the context of one of the recent Far Cry games. The plan is for us to implement something like this for future version of UE4, but I don't have any specifics to offer yet. For now RVT will be limited to the current size limits, so it won't work for huge terrains.

        Comment


          #94
          Originally posted by Haoris View Post
          And how should I use this with world composition? One RVT volume per proxy bound to proxy level bounds? One RVT volume in the persistant level set to cover the whole landscape component?
          I'm also interested on the answer to this. Should I use one RVT volume per landscape tile/streaming level?

          Virtual texturing for landscape materials. Right now I have some demo levels that use World Composition (4 x 4 km each, divided in sixteen 1009 x 1009 landscape tiles, if I remember well), and it would be great to simplify the landscape materials, because I ended up having to strip them down of some stuff to make them performant again. As they won't change at runtime in the game, it would be great to kind of bake down their layers (snow, grass etc etc). Also that possibility, in the Virtual Texturing Quick Start docs, of also including textures of static meshes in the VT asset used for the landscape opens a lot of possibilities, for richer, less repetitive terrain, integration of paths etc.

          Comment


            #95
            Based on answers from the stream, I have a bit of a follow-up.

            If layout of RVT is to be hardcoded, It would still be good to have one extra slot. Given the way RVT is likely to be used, many will inevitably run into needing to pass something custom(eg. wetness/puddle maps for landscape). Perhaps 3 more layouts(Usual attributes plus BC4, BC1 or BC3) coupled with extra material pin on RVT output, would be taken into consideration ?

            Comment


              #96
              I'm getting UVs showing up in wrong spots when I import a udim
              my 1002 is showing up in 1032
              is there a way to shuffle the UVs in the import? or am I missing something in the way I'm importing the textures?

              Comment


                #97
                are there limitations to filetype?
                issues with anything like mixing filetypes? limits to 8bit or 16bit?

                Comment


                  #98
                  YuuJin Most likely you're hitting bug with non-power-2 UDIM layouts. The number of textures in both UV directions need to be power of 2, or else UVs will be messed up. This will be fixed in 4.23.1, but for now you'll need to add dummy images to pad your layouts.

                  Comment


                    #99
                    Any filetype normally supported by UE4 should work with UDIMs as well. All image files that make up a single UDIM need to have the same file type however.

                    Comment


                      thx for the input!
                      I've already tried it with dummy files as well, the dummy files are png with 128x128, the bigger ones are 4k (4096px)
                      in a tile set going from 1001-1034 (square shaped)
                      they always mess up in the order when looking at the texture in engine for some reason


                      I tried making big textures with the images as well
                      but there's memory complaints in unreal and it just crashes if the images are too big (seems to die with 16k png that are over 1XXmb?)
                      8k (8192) seems fine, merging all the tiles into one texture
                      right now I'm testing compressing the png files to something smaller with the 16k (16,384) textures, maybe have to drop to 8bit


                      it also seems it's more stable working with the big VTs with dx11

                      so my plan is to prep all the shaders in dx11
                      and then switch to dx12 to do renders with raytracing
                      Last edited by YuuJin; 09-26-2019, 05:57 PM.

                      Comment


                        I changed all the 16k textures from 16bit png to 8bit png and now it works, and doesn't crash UE on import
                        going to test the udims in a bit

                        Comment


                          yah, originally the udims were exported out of substance painter
                          with changing the names to the BaseName.####.[Support Image Format] suggested in the docs
                          all files were png, some files were 8bit some were 16bit

                          a few of the 8bit ones I re-exported out of photoshop with png with the highest comression since that seemed to work well for the 16k textures
                          in the end UE still imports the udims in the wrong slots,

                          so for me, merging the udims seems to be the safest route
                          but is quite a few more steps in the pipeline I'd rather avoid if I can get the udims working

                          Comment


                            I came to this thread looking for a solution to the issue of tiles being shuffled around as well, but I was able to figure it out myself.

                            Here's how my virtual texture looks when imported in the standard UDIM format of tile 1001 in the bottom left, 1002 to its right, 1011 above it, etc (the black is padding to get it to a power of two). Should be pretty apparent that the rows are out of order.

                            Click image for larger version

Name:	UE4Editor_20190927_140120.png
Views:	184
Size:	527.6 KB
ID:	1668682

                            So naturally, here it is with the UDIM V axis inverted, looking correct. So that's 1001 in the TOP left, 1002 to its right and 1011 below it, etc.

                            Click image for larger version

Name:	UE4Editor_20190927_140132.png
Views:	161
Size:	537.7 KB
ID:	1668683

                            beningram Am I misunderstanding something about how virtual texturing works or is this a bug?

                            Comment


                              so the udims are reversed and flipped?

                              Comment


                                looks like it is kinda flipped
                                and it's moved up a tile

                                so i guess if i flip the udim numbers around and move the tile down in UV space the udims will be in the right spots
                                I also had to save the images as png 8bit, as they were originally 16bit and unreal would have a memory crash trying to load it

                                the mesh in the middle picture is actually a 7x7 udim mesh so it repeats after the 4th udim UV space

                                Comment

                                Working...
                                X