Official Feedback Wanted: Streaming Virtual Texturing

What are the cons for using virtual texturing? When wouldn't I want to use it?

 

You want to use it for open-world type of games or corridors but with highly detailed environments, non-repeating materials, mostly first-, third-person games.


So if you not fall into this category, you can skip them.


In general virtual texturing means higher load in artistic department in the first place, since you have to create a lot more, unique textures and materials. Obviously it's not first choice for mobile platforms, mostly because of the space requirements and latency in loading up required texture tiles from the storage, which breaks gameplay.


There's additional cost related to computing which part of giga-texture-atlas engine should currently load up from the storage and make available for the shaders. Shaders are little bit more complicated and sea of storage is required to store full PBR materials.


On consoles and PCs it's forgettable cost however, so it’s in use for a decade already, at least.


Took unity some time to integrate it from the company they acquired, few years back.



Anyway, great that it coming to unity. Hopefully together with camera stacking….

 

It's good to understand the technical limitations and what you can gain from it to be able to draw your conclusions when to use it.

main gain is:
- you can use higher resolution texturing with very little GPU RAM, meaning sharper texturing on GPU's that have less physical VRAM.

potential downsides are:
- since the VT streams in texture data based on what's currently rendered on the screen, quick scene changes or fast camera rotation can momentarily display lower resolution data on your game world until the streaming catches on. This also happens with traditional texture streaming. I think old Granite integration used to have API call you could use to give VT system a hint that you'll be switching to different view soon, not sure if this new system yet has something like that (it's especially useful for things that you know will happen in advance, like camera cutscenes for cinematics etc)
- since you can use higher resolution textures, the obvious downside is that they can take a lot more disk space. This will be way bigger issue on say, open world game than in say, game that just has more limited environment.

 

I'm suffering with Texture Streaming in Unity 2019.3. For distance object, it just fine but for near object first spawned object shows lowest mip level and it streamed to high mimap at next frames. User can see texture flickering in this timing. I think that same problem can occur with virtual texturing. Will Unity provides APIs for fine tuning and handling these problems?

 

I mentioned this on the above post. For regular texture streaming they let you preload the textures for new camera position, see "Camera cuts" section on this doc: https://docs.unity3d.com/Manual/TextureStreaming-API.html#ControlCameras

 

Exciting! wonder if lightmaps will take advantage of this even if at future and if stuff like impostors could take advantage too.

 

For sure. At the moment i use 8K Lightmaps.
So i have around 12x8K custom Lightmaps . One per interior PBR Material.


The problem is that PLM never can calculate these quality and sizes.
You have to use external lightmappers.

Check the Unreal implementation. Lightmap streaming done right.

Would be nice if you could provide an
Experiemental Fontainebleau branch with Virtual Texturing implementation.
Then we must not do all the testing alone.)

Please use Adressables from beginning in your development.
For projects with Virtual Texture Streaming is quite obvious.

Sorry. I am still stressed out because all Granite projects we had to stop last year.
You also were loosing some good customers with reference projects to EPIC because of this more than one year of information blockade.

However. Please try to get it in preview fast in a package who fits the latest Unity 2020.1.0bx + HDRP 8.x-Preview. You referencing an HDRP 9.x-Preview?
We could not wait any longer too and because of this i must mirrror our complete pipeline on unreal for an test.

 

@AljoshaD How do we enable the the debug tiles on this (which are enabled on all your screenshots)?
I saw GRA_DEBUG_TILES in GraniteShaderLib3 but it's actually commented out so it will not do anything. It's kinda hard for users to tell what virtual texturing is doing without ability to visualize the tiles.

 

Hi.
How i can enable the old granite debug view or the debug view showed in the user guide.

I found this one but its hard to interpret.




added:

old DebugTiles are here
VirtualTexturing/Debug T iles

 

So this is a gamechanger for stereo equirecangular VR applications because you can do now uv reprojection passes
in R32G32 or two in R32G32B32A32.
They need this precision and minimum size of 8K better 16K.





edit:
ooh i saw under Important Notes they are not supported.
So please support them. This would be an real game changer.

 

Are UDIMs going to be supported eventually or is it a limitation that will hold due to the approach taken on the texture import workflow?

 

Hi. I did a very fast test in the example scene with Adressables and i seemed to work on a build.



However. This need some further testing.

As an Use Case example here some dots why Adressables are important

We have large data

• so car interior is up to 4GB
• car exteriror is up to 3GB
• car tracks are up to 20GB and splitted through multi scene and Adressables.

Everything is loaded/unloaded per Adressables and the Build is now very confortable (4GB limit)
Now we could use even larger scan textures for cars and tracks who were on hold for 1.5 yrs.
Combined custom Lightmaps up to 64k.
Scanned Track and Car Textures up to 16K for primary scene views.

So a working and solid Addressable compatibility would be very important.

Also the custom Lightmaps are always in the process of improvement. Even after project end.
When there is free GPU/CPU time they will be auto improved up to FullGI GroundTruth for different lighting situations.
So they are marked as Adressable and often renewed.

 

The old WETA Demo who s an really perfect VT example on mobile phones was using UDIMS

https://graphinesoftware.com/blog/2...-ARHorse-razor-sharp-glance-into-future-of-AR

We start to switch to UDIM now because Blender got an nice implementation.
So i hope UDIMS will be on the List too.

 

I also tried this briefly on DX12 and DXR. Some of the raytracing effects seem to work with VT, some throw errors and for example raytraced reflections just render pitch black.

 

I just imported the packages in our project on 2020.1b2, virtual texturing is activated in the package manager, but a console info says it's disabled and I neither get the option in the player settings nor in the pipeline asset.
I already tried disabling and reenabling the package. (the sample works in 2020.1b2 by the way)
Does someone have an idea what could have gone wrong?

 

use this packages in your project
\StreamingVirtualTexturing\StreamingSample_2020_0_0b2\Packages



and it should work

 

thats exactly what I did, I can also see the virtual texturing menu in the toolbar, but the option in the player settings is just not there..

 

Are you sure you look in the right place? It's right at the top of Player settings on same place where you set company and product name, default icon etc.

 

Thanks, that was it , I was looking in "other settings" where these things usually are (and also in the compact guide).

 

Feature request: Universal Render Pipeline support.

 

Without UDIM support this will be basically pointless for our project. If it had UDIM support we would be using this for our mesh terrain.

 

Building with IL2CPP doesn't work, Unity tells me that the c++ tools and windows sdk have to be installed, even though I have everything installed. Is this a known bug, or did I miss something?

Update: never mind, seems like something was broken with my vs installation.

 

First of all I wanted to say it's amazing for this early state how easy to use it is (even more comparing it to earlier versions of granite and amplify texture). You guys did a great job of integrating it thoroughly into the known workflows.
I just built a scene with almost 50gb of texture data (most of the textures 8k or 4k), and loading times are almost non-existent, everything looks great and is very performant.

There are some situations were textures just don't appear though. Here is a screenshot which shows the problem and the granite error in the console. One thing the incorrectly textured characters have in common is that they are spawned in runtime. Might this be the reason for it? Do you know any way to fix this? Besides of that it's very usable already.

 

it seems not good at mac,very low fps,and get 1G texture memory...

 

how to show feedback feature in vertex shader ?

 

I did not change anything about this example,and the textures 's "Virtual Texturing Only" is enable .

 

I couldn't find the "support for VT" in player settings even enbabled the built-in module “Virtual Texturing” in the Package Manager. unity 2020.1b4

 

I found it finally.^^
It's under the Icon setting.

 

16K is the maximum for a single object? I'd like to use at least 32K texture, since I'm making solar system planets and I need as much resolution as I can to get sharp views from low orbit.

 

Are there any guide for how to use it for terrain or HDRP lit shader?

 

Then I can't get the point. 16K is not that much. I'm already using a planet shader that combines 4 images to get a 16K texture, and it runs smoothly even on mobile. Today's hardware is very powerful. Efficiency is OK but breaking the limits is the exciting thing. The old plugin should still be available for those who need that feature.

 

Apple A9 GPUs (iPhone 6S and 6S Plus) introduced texture support for up to 16384 px. Earlier iOS devices support up to 8192 px only.

There is currently no iOS GPU that supports textures larger than 16384 px, see https://developer.apple.com/metal/Metal-Feature-Set-Tables.pdf for details.

Unfortunately, Android devices are so diverse, that there exist no single feature set table like on iOS. I would assume similar or slightly worse limits on recent Android devices.

Here is a brief overview how much memory different texture sizes cost at 8 bits per pixel:

• 8192x8192 @ 8bpp = 64 mb
  
• 16384x16384 @ 8bpp = 256 mb
• 32768x32768 @ 8bpp = 1 gb
• 65536x65536 @ 8bpp = 4 gb

I guess, even just disk storage wise it gets unpractical on a majority on mobile devices to have 32k / 64k textures.

 

do u can run this demo on mac?get 340m memory?

 

Hey all,

I was wondering if eventually the feature will be available for the Universal Pipeline, and if so does it make sense to use this in a VR context (and to a far lesser extent mobile VR)?

It's not so much the need for full uniqueness but really to reduce material complexity and reduce separate textures and reduce ram requirements, so any information would be great.

My questions are probably about a year too soon aren't they?

 

Hi Aljosha, sorry I have totally missed your reply. I'm trying to reconstruct it, but it's hard to recreate with another project, and it's impossible to send you ours with the bug reporter (the project excluding the library is about 90gb...)
What does the error message mean? (Granite Error in Graphine::Granite::Internal::Trancoder::Tick: The transcoded bitstream was invalid, this may indicate a corrupted file or incompatible transcoder version)
That might help me dig deeper and nail down the cause.

I have also noticed, that the system seems to have problems with objects behind transparent surfaces.I know that it doesn't work with the transparent surfaces themselves and that's fine, but it should be possible to render objects behind them correctly. When we were using amplify texture some years ago, I could change the layer of transparent objects to "transparent FX" so they were ignored by the texture streaming. Something like that would be a good solution, or even better: Just read out if transparency is enabled on a material for example.

One more improvement idea: Currently the models display nothing if the textures aren't loaded yet and in our case they appear black until the streaming system loads the data. It would be great to have at least an option to load let's say the lowest mip (128x128) for each material on start, so it won't be as obvious (and should be small enough for most people to not steal too much precious memory )

 

I just tried it and I totally understand why it's "experimental", using it makes everything exactly 10 times slower

Thank you, looking forward for the next iterations

 

Does VT has any plan for supporting Ar Foundation in further ?

 

I hope with URP mobile devices on iOS that support metal and have 3GB Ram will be supported.

For example iphone 7plus is the lowest device I would expect to work.

Everything lower than that spec is not reasonable