Announcement

Collapse
No announcement yet.

Virtual Texturing Feedback

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

    Originally posted by krz9000 View Post
    i can confirm that the "runtime virtual texture sample parameter" does not take the instance linked RVT. it always renders the RVT that is set inside the "virtual texture sample parameter"-node. this is a pretty big dealbreaker for my project since i use a quite complex landscape shader and many, many worldcomposition sublevels.

    is epic aware of this issue?
    I reported it, but due to the pandemic I have yet to hear anything about it.

    Comment


      Originally posted by beningram View Post
      Lightmaps don't use UDIM (also udim bug has always been there), so this is likely something different. First I've heard of it, I will try to investigate soon.
      Hello,

      WorldHeight is said to be storing data in 16Bit but it doesn't.

      I'm using world position B channel to create a gradient on the landscape along Z axis and storing that into WorldHeight, when I sample from it, it's 8Bit. Step like artifacts are quite obvious.

      Have you been aware of this?
      Artstation
      Join the support channel
      Gumroad Store

      Comment


        To everyone having a problem with runtime virtual textures on tiled landscapes in PIE:

        I discovered that the Runtime Virtual Texture Component (which is the component attached to a Runtime Virtual Texture Volume) has an incorrect decorator on the RuntimeVirtualTexture property. It is set to DuplicateTransient, instead of NonPIEDuplicateTransient.

        When you press play in the editor, all scenes currently open are copied to a PIE version, so that moving things around in the scene isn't permanent. Unfortunately, due to the DuplicateTransient decorator on the aforementioned property, this will reset that field in the PIE version of all scenes that were open when you pressed play, and all scenes that are streamed in during PIE will have no bounds to assign from.

        Changing the above decorator will fix this issue, and I have submitted a pull request for it.

        A couple of workarounds that I can think of now:
        (Note: i have not tested any of these workarounds, as i simply fixed the decorator in my own custom version of 4.25 )

        1. Have your perisistent level be an empty level that loads a sublevel via blueprint which contains the Runtime Virtual Texture Volume in it, and that sublevel contains all of your world composition tiles as sublevels, and make sure that this sublevel is not open in the editor when you press play.

        2. Reassign the runtime virtual texture component's VirtualTexture property after the level containing it loads. This looks like it will need manually calling some code present in the RuntimeVirtualTexture's PostEditChangeProperty, in the actor whose job it is to reassign the property on load:


        Code:
        #if WITH_EDITOR //the notify functions are only available in the editor, which is ensured if you are in PIE anyway, where the bug happens.
        runtimeVirtualTextureComponent->VirtualTexture = runtimeVirtualTexture;
        RuntimeVirtualTexture::NotifyComponents(runtimeVirtualTexture);
        RuntimeVirtualTexture::NotifyPrimitives(runtimeVirtualTexture);
        #endif
        I hope this helps


        Comment


          > Does VT unload tiles after some time? For example, when we don't need specific texture mips anymore? Is it implemented at all?
          VT tiles are stored in a fixed size cache. Once the cache fills up, tiles are evicted using a simple LRU scheme to make room for new tiles.

          > I've heard that UDIM's were fixed for FBX, what about Alembics?
          The latest UDIM fix should work for all mesh import formats.

          > So we cannot use raytracing, if we use VT Textures?
          Raytracing shaders won't update the VT feedback buffer. So I think it's possible for ray-tracing passes to sample from VT, but they won't cause higher resolution tiles to stream in. This might be OK if you're using RT reflections combined with normal rasterization for other rendering (since the raster passes will trigger VT feedback). You may end up with low-res VT for reflected objects that are not present in the base pass though.

          > Is this about being able to import higher resolution textures or did I miss something?
          Right, I was making the point that if you have higher resolution textures, you may not need as many texture layers inside your material. Separate tiling detail textures may not be needed for example, since you can just bake the detail into the main (virtual) texture if resolution is high enough.

          > Is this still an issue, we have ton's of large textures
          Texture import code should all be properly using 64bit sizes now, but everything is still kept in memory. So large VTs are possible if you have lots of ram. 8k textures should not be a problem.

          > Hi, there is an issue with tiles not streamed for a material on a mesh that is occluded by a mesh that has a translucent material with VT textures
          Yeah there have been a few bugs related to this. I think I've fixed them all, but I'm not sure if all the fixes have made it into the 4.25.x stream yet.

          Comment


            beningram Thank you for all the answers!

            Comment


              I have another problem with RVT. When I open my project, some of the texture's mip maps are black. When I move my runtime virtual texture volume actor, or change it in some way, it usually goes back to normal, but not allways or not everywhere. Interesting thing is that the my roads that are also baked onto the same RVT works fine. When I move my camera around, it seems to finally bake. Also. I have noticed that when I have this RVT on, it causes hitches during the game.

              Click image for larger version  Name:	RVT.jpg Views:	0 Size:	228.6 KB ID:	1778736

              Comment


                I see some people telling they're using RVT with tiled landscapes, can someone explain their setup please?

                Comment


                  Originally posted by Haoris View Post
                  I see some people telling they're using RVT with tiled landscapes, can someone explain their setup please?
                  You might loose your mind currently. Each tile needs its own material. Each material needs to specify the rtvt. Each tile needs to render to the correct rtv.
                  It works, but on anything large enough to require world composition it is a massive amount of work and needless files.
                  if/when they patch the instances to accept interchangeable rtvs, then the process would be a little easier. Create an instance for each tile and set it up on the tile itself.

                  Comment


                    Originally posted by MostHost LA View Post

                    You might loose your mind currently. Each tile needs its own material. Each material needs to specify the rtvt. Each tile needs to render to the correct rtv.
                    It works, but on anything large enough to require world composition it is a massive amount of work and needless files.
                    if/when they patch the instances to accept interchangeable rtvs, then the process would be a little easier. Create an instance for each tile and set it up on the tile itself.
                    Ok, that's what I thought, each tile would need its own RVT. Yes, that would be a lot of work for 1000+ tiles (I'm just reminding that Novigrad map of The Witcher 3 is made of 2116 tiles )

                    We should be able to use only one RVT on the main landscape actor but then we go back to this point and there's no more news about this :

                    Originally posted by beningram View Post
                    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.
                    Last edited by Haoris; 06-27-2020, 09:57 AM.

                    Comment


                      2116 tiles equals 2116 impostor/lod drawcalls. Thats a lot of wasted calls.
                      performance would be better with something closer to 8km tiles. Less tiles, less draw calls.

                      Comment


                        Originally posted by MostHost LA View Post
                        2116 tiles equals 2116 impostor/lod drawcalls. Thats a lot of wasted calls.
                        performance would be better with something closer to 8km tiles. Less tiles, less draw calls.
                        I don't see any performance issue in The Witcher 3. The reason why open world like Witcher 3 has 184m² tiles (58.5m² for TES: Oblivion) is bigger tiles means more objects per tile so slower loading/streaming times

                        Comment


                          Let's not completely derail the discussion.
                          loading times may be lower, but drawcall count is higher impact so they must be doing something different with the far portions of a landscape, like a custom lod system.

                          adding rtv to an 8km tile doesn't really increase performance on a good material. On a bad one it does wonders.
                          its essentially a give and take - as well as how much man power you have.
                          you could set 100k tiles up with rtvs now, via automated scripts, in a couple days or so.
                          BUT, the final size of the project would be impacted...

                          Comment


                            i think i found another issue with RVTs:

                            i have a landscape with plenty of height-blended-layers (baselayer is alpha-blended). i write the resulting basecolor, spec, roughness and normal into the RVT-output.
                            in my lets say rock-material i use a RVT sampler to lookup the landscape RVT and do some distance based blending (using another RVT from the landscape that writes height).

                            now the problem:
                            all channels in the blend appear fine beside the basecolor one. the basecolor only shows the alpha-blended baselayer form my layerblend. all other channels (normal, spec, roughness) show up in the blend correctly (as in show the different e.g. normal maps of my different painted layers). only the basecolor shows nothing of my painted layers beside the baseone. i tried different RVT colorformats and compression without solving effect.

                            does the basecolor in the RVT ignore heightblend layer-input? how is the RVT node able to recognize them? and why doesnt it ignore height-blend for e.g. the normal if this tries to be something clever?
                            Last edited by krz9000; 07-03-2020, 04:24 PM.

                            Comment


                              Ok so RVT actually works on tiled landscape with only one single RVT and one RVT volume.
                              - RVT volume in persistent level. Scale of the volume should be set manualy to whole landscape size because "copy bounds" returns wrong scale
                              - RVT size has to be set really high to get correct texture quality on landscape (had to set mine to 4096-1024-4). Texture resolution looks 1:1 to non RVT landscape material with 8km² landscape. Larger landscape would still need adaptive virtual texture to be added to the engine.
                              - Unfortunatly, the virtual texture asset has to be manualy assigned to each LandscapeStreamingProxy because they don't use the Landscape actor settings. It's time consuming if you work with 1000 tiles (you can load many tiles, select all LandscapeStreamingProxy and set the virtual texture in one time if you have enough RAM/VRAM to load them)

                              RVT is cool for final optimization but can't really be used while working on level design because:
                              - Layers preview in the paint tool are all black (so you have to chose a good name for your layers and remember how they look)
                              - RVT updates really slowly in editor so painting landscape layers is not realtime but takes time to update

                              Comment


                                We tested out RVT for tiled landscape yesterday to get a feel for the Memory and Processing effects and the overall runtime cost and benefits seemed pretty good. But the actually setup and working with RVT for a tiled world as others have stated are pretty painful. The first test we did used 3x3 1km tiles and the largest RVT size with a volume set to capture the whole area. This worked fine, but the resulting texel density was too low compared to our needs and ended up creating a noticeably low res landscape compared to other objects in the scene. Switching to using separate volumes per tile each with its own RVT and then modifying our master RVT version of the landscape material to use a series of switches to use the proper sampler let us somewhat simplify the process, but this would not be feasible for all the tiles in our world and it was still painful. Placement of the volumes based on tiles is tedious as it has to go in the center and the copy bounds doesn't let you use the proxy as a source for instance.

                                Given that currently our designs on focusing on making a specific 1x2 km section of the world our playable test area this really wouldn't have deterred us since we actually unload any Landscapes beyond the immediate bordering ones to optimization and use Static Mesh LOD's and a very simple and lower resolution Material which we bake the textures for separately. But this would eventually need to be expanded upon over time and most importantly the borders for the tiles would need to be completely seamless. Unfortunately for us we found very noticeable seams were being created with separate tile RVT as shown in the attached images. It's actually most notable from a distance from various angles, no amount of adjustment would eliminate it that we could find.

                                We'd really like to use this feature in our large open world setup, but currently given the visible seams, and some of the other reasons given in this thread we've decided not to make the switch for now and just watch for future improvements to hopefully make it more viable for this setup. It looks very promising as we would love to leverage the benefits of the approach.

                                It is worth noting that we have also implemented SVT in our project for objects using large textures, and likely have more optimization to do for using that, so we were very interested in seeing how both implementations would work together.
                                Attached Files

                                Comment

                                Working...
                                X