Official Feedback Wanted: Streaming Virtual Texturing

,3q~,but this demo player setting had enable Virtual Texturing , not work.

 

OK， need hdpr 9.0.0-preview.54

 

comfused with virtual texture momery still very big.and some time can not show the virtual texture profile.

 

any help?It seems vt not work in 2020.2.0.a19

 

confused with the rendertexture got 1g memory in editor mode .when make the level ,the momery will be crazy big too.vt seems can work,but total texture memory > > vt's 384m .Thanks for your reply ~,and when will get HDRP 10 .

 

We are developing an RTS game where you will only view a small segment of terrain at a time. I would think that depending on camera angle VT would allow higher detail non-tiled terrain textures.

 

We would not be tiling / blend textures. Ideally just one big custom ground texture.

 

Any update on the ability to use the Parallax Occlusion Mapping node in ShaderGraph with Virtual Textures?

 

The documentation states that Virtual Textures do not support AssetBundles. Does that mean objects loaded from bundles cannot use virtual textures at the moment? Is there a rough ETA for asset bundle support?

Another question: Linux does not show up in the "Supported Platforms" section, although Vulkan is supported. Is Linux really not supported, or is it just missing in the docs?

 

Hi, is there any support planned for URP and mobile? There was android support in 2018.

https://graphinesoftware.com/blog/2018-02-21-granite-unity-now-available-android

Isn't it?

 

Is there already a solution for objects behind transparent objects (windows etc.)? Something like a layer mask to ignore transparent objects maybe? Currently the system isn't able to handle the fetching of textures behind transparent objects, which really is a big problem for production use.

 

Thanks for the quick answer Aljosha! Does that mean in the 2020 cycle? We would ideally like to stay on 2020 LTS.

 

And while we are at it: A simple (revised) example script that demonstrates the fetching api (for example fetching the lowest mip of everything at start) would be great too. The current example breaks when a mesh renderer has more than one material assigned.
Even better: An option in the sample VT node (something like always fetch lowest mip). Usually it's not a problem having blurry textures during fast movements as long as there is something that resembles the actual texture instead of just a color. I think for most people on modern platforms the cost of having a 128x128 version for all textures being in memory would be negligible (especially compared to what "not streaming" would cost).

 

Great, thank you!

Regarding transparency: Do you mean supporting transparent objects, or fetching the textures of objects behind transparent objects? The latter is the one that's very problematic for us.

 

I was just testing the VTManualRequesting script and I encountered a very strange behaviour: I get a null reference exception when I have reflection Probes in the scene (the problem is solved by disabling the reflection probes) What makes it strange is, that this doesn't occur if I create a new reflection Probe, only with ones that have been in the scene for I would guess more than a year or so.. Do you know if something changed with the reflection Probes? I remember that in one of the earlier HDRP versions, there was an actual mesh renderer part of the reflection Probe to display the chrome gizmo. I might have traces of these old (hidden) mesh renderers still in my reflection probes, but I have no idea how to access them.

 

Ok solved it, for anyone who encounters the same problem: You can access the old mesh renderer by using the inspectors debug mode. You can then simply remove the mesh renderer component.

 

still confuse with profiler, Texture show 1.26g, VirtualTexture show 384m.Which is correct??

 

What is the difference between Virtual Texturing and Sampler Feedback with DirectX 12 Ultimate? This is assuming there is a difference. If the technologies are trying to achieve the same goal, is one better than the other and is Virtual Texturing going to be implementing the tech described with Sampler Feedback or are they different sides to the same coin?

 

Tiled resources tier 1-2 are DX12 and Sampler Feedback and Tiled resources tier 3 are DX12U features. DX11.2 also had tier 1-2. This Virtual Texturing is DX11.

Those are hardware features while this is software. The DX features are also building blocks while this is a complete system. Unity has for a long time had a DX11.2 Tiled resources implementation called Sparse Textures. These are limited to 16k.

Hopefully, this Virtual Texturing will eventually implement some of the DX12 features, since DX12 adoption is becoming mainstream. Widespread DX12U feature adoption is still far in the future.

 

Nice Presentation, especially the profiling part was really helpful to determine the GPU Cache Size we need. On question though: What's the best way to determine the CPU Cache size? What's the effect of the CPU Cache in general?

 

Another question related to the manual requesting. The script you posted earlier here works great, and looking at the profiler, the Request Region calls seem to be really fast, although "VirtualTexturingEditorManager.FindTextureStackHandle" costs up to 9 ms on our Dev machine... Is there any way to optimize this? Or is this going to be optimized as VT matures? Unfortunately we can't afford this cost in the actual game as is. Thanks

 

Hi @AljoshaD,

great video! We were using granite in the past with built-in RP, however we have switched to URP and we would like to know ETA for URP support mentioned in the video. I mean whether this is something near completion (2020.2/2021.1) or something far from experimental (2021.2+).

Also could you elaborate more on support of Linux? It is not listed under supported platforms even though Vulkan API is already supported.

 

@AljoshaD I did notice that Procedural Virtual Texturing API itself is already on Unity 2020.2 core: https://docs.unity3d.com/2020.2/Doc...ce/Rendering.VirtualTexturing.Procedural.html

I'm assuming we can't really do anything with this yet though?

 

Could you please elaborate more on steps required for URP implementation? It would be great if you could provide us some basic documentation for custom SRP (in this case URP) implementation. I mean something similar to the "Converting shaders" section in the original documentation (add three Granite specific properties, include GraniteUnity.cginc, use #pragma multi_compile __ GRANITE_RW_RESOLVE for single pass resolver etc.).

One additional question, what is the resolver implementation in the latest version? Presentation only mentions automatic detection based on main camera, are you using the single pass resolver with additional output buffer or is this something new/superior?

 

URP port:
Migrating cache settings, initial setup etc. are quite straight forward. URP + Shader graph + SVT seems to working too (I haven't made deep analysis of the shader yet). However texture is rendered in the lowest mip. Detection of the active tiles looks hardcoded to the HDRenderPipeline along with some GBuffer injections etc. Is SVT implementation deferred only? If so how are you planning to implement SVT for forward URP, because at the moment it seems that you can't add SVT support without the GBuffer or am I missing something?

 

I just want to throw in my two cents and say I am eagerly awaiting SVT in Universal RP.

I've tried it out in HDRP and I am very impressed. I tacked on the full eight 20k textures of NASA's Blue Marble on a single sphere and while it did take 7 min to load, it did eventually and with minimal artifacts.

Higher speed globe rotations did result in the google maps like block by block loading along the edges of the camera but that's just me playing around with a 80k texture on a single object.

While HDRP did result in some very pretty globes, its additional post processing and everything else is very annoying and quite excessive for the miniproject I'm intending on making.

So I'll just slam my 16k texture onto a single sphere and hike my minimum requirements up to a 2GB GPU. I'll be content on waiting the 2 or 3 years required for SVT to be ported to URP. It's a great feature but not necessary.

 

The globe looks amazing. Runs at a solid 4.5 ms / frame where base requires 3.7 ms. Absolutely magical. Bravo in making it work.

Anyways, I couldnt get this feature out of my head so I threw together a trial project experimenting with the limits of virtual texturing and I've noticed a few things.

First is the most obvious, the lack of support for transparancy is a major roadblock. I've managed to make some overlays work by merging some of the layers together and playing with material UVs but the fact that a lit material can not be overlayed with an unlit one is noticable.

Second is the enforced bilinear / trilinear filtering on materials. Even if they have been designated as point textures. I encode rendering data inside the color values of a texture for use in a shader and any sort of filtering or post processing destroys that information. I've got the antialiasing down to a two pixel wide boundary between colors but I would prefer if there was an option to scale by nearest neighbor instead of average color.

I know the enforced filtering is due to the VT itself and not anything else because I've overwritten the unity generated mip map textures with my own nearest neighbor downsampled versions. On a plain unlit shader using SampleTexture2D, not virtual texture, the color replacement works perfectly. Using the same texture or setting as VT only then replacing the mips again, there's evidence of bilinear filtering. Even if nothing else has changed.

Otherwise, it's amazing. My requirements are very niche and as a whole, VT is an amazing feature.

Edit: Virtual textures crashes entire unity editor on limited mip mapped textures. (Texture with defined mip map count and then mip maps inserted into asset using Graphics.CopyTexture.) Well, there goes that plan.

 

Hi @AljoshaD,

two questions.

1. How to adjust global mip bias offset? Reducing texture quality is crucial for lower quality settings (equivalent of the Quality settings in the legacy version)
2. How to visualize current content of the cache? Debug tiles feature is great, but for deeper debugging it is not sufficient.

 

1. Please link this to the texture quality parameter in the Quality Settings, because it is quite annoying to balance multiple texture systems (e.g. it looks awful to have reduced texture quality on transparent objects, lightmaps, vegetation... while having opaque objects in high res, consistency is really important here).

2. With the cache overview it was much easier to adjust cache size, mip biases, prefetching etc. because you could easily detect what is being streamed, how often, utilization of the cache, how long does it take to populate the cache after load/teleport etc. This is much hard to do so with only tile debugger and renderdoc or something like that.

3. Why does resolver requires CommandBuffer in the Process function? I am in the process of converting SVT from HDRP to URP. Shaders, cache management, VTFeedback rendering (additional forward buffer) with downsampling are working as expected, but the Process function in the resolver (followed by the VT.System.Update) has zero effect (cache remains empty, but doing manual requesting works correctly). I've probably bug in the command buffer execution when downsampling the color buffer, but still I don't understand what is the additional usage of the buffer in the resolver. The resolver only needs the latest lowres VTFeedback texture for tile streaming evaluation, right? Or is there some additional GPU buffer processing which is done internally?

*Edit* Ok I think I understand now. The process function wraps async readback done by ProcessVTFeedback. However the async readback is never performed even though the execution flags are valid and the RTI of the downsampled RT is provided. Since it is injected method I can't progress without knowing why it fails :/ The Internal_ProcessVTFeedback_Injected throws zero errors/warnings

 

@dieterdb thanks for the advice!

I've solved the issue. The problem was that the RT passed to the resolver had to be manually created using the RenderTexture.Create function. But discovering this issue was really challenging. Please add check to the resolver that the passed texture is actually created, also someone should improve the documentation on this subject, because the whole rt = new RenderTexture vs rt.Create() is shrouded in mystery. It would be more than helpful to have explained in the documentation how can allocation using just the new RenderTexture(...) be suitable for shader outputs, read/write operations in buffers etc. and when you have to manually add .Create (so that operations like the async read back in the resolver are working).

However after this was resolved I've encountered another problem. I am currently working on support for multiple cameras (scene view, game view...), resolution changes etc. When the resolution is changed I am recreating the render textures that are used for VTFeedback, but for some reason once the resolver was populated with proper RT, calling UpdateSize has zero impact and console is spammed with:

AsyncGPUReadback - Out of bounds arguments - src offset(0,0,0,0) dst dim(240,135,1) src dim100,56,1)

The previous VTFeedback was discarded, new VTFeedback was created, passed values to the resolver in the UpdateSize function are the same as the width/height of the newly VTFeedback, but for some reason the CurrentWidth/Height in the resolver remains unchanged Is there some additional steps needed to done besides releasing previous RT, creating new RT and updating the size of the resolver to make this work?

 

With Unity 2021.1 in beta now, do you have any news/updates regarding adressables support and a way to render Virtual textures behind transparent objects (like windows) in this tech cycle?

 

In my experience, VTs work on opaque objects behind transparent ones perfectly well.

They just dont work if the material the VT is rendering on is transparent. You can have a VT on a wall behind a window but not on the window itself.

 

Unfortunately it currently doesn't. It' likely because of the way the textures to be streamed are chosen based on the view frustum, everything behind windows for example remains untextured until there is nothing "occluding" the view between camera and the texture to be streamed. (Even if it's a transparent object)