Mipmap steaming and memory usage

In summary - yes you can use texture mip streaming to reduce GPU memory usage.

The following page attempts to introduce the texture mip streaming
https://docs.unity3d.com/Manual/TextureStreaming.html

"The Mip Map Streaming system gives you control over which mipmap levels Unity loads into memory. This system reduces the total amount of memory Unity needs for Textures, because it only loads the mipmaps Unity needs to render the current Camera position in a Scene, instead of loading all of them by default. It trades a small amount of CPU resources to save a potentially large amount of GPU memory."

For textures in a 3D scene with mip maps you can enable texture mip streaming. It will use the object bounds along with camera position, screen size and the mesh uv density to calculate the resolution the texture needs to be on screen. It will use this information to determine how many mips are needed for that texture (considering all occurrences of the texture in the view). It will then load (or unload) texture mips to constrain the GPU memory usage to the texture budget you provide (within the limitations such as max mip reduction level permitted in the chosen settings).

The manual page and individual API settings give more detail, such as the memory budget include the streamed and non-streamed textures.

 

Hi, The mip streaming feature is supported in 2020 LTS. However there are some limitations on what sub systems supported which are listed in the above documentation. E.g if you are calling a draw mesh function directly without a renderer object the texture mip streaming system cannot calculate the desired mips and therefore will only load up the the max reduction. This is because a renderer object is required to provide the bounding box for the mip calculations. Also if you are using a custom shader with complex uv scaling, then the calculated mip could be incorrect as the system isn't aware of scaling within the shader.

It you provide a reproduction case in the bug report then the feedback could be more accurate for your specific situation.

Using the debugging API functions listed on this page can help identify exactly what mips the system has calculated, is attempting to load and the memory usage vs the budget.
https://docs.unity3d.com/Manual/TextureStreaming-API.html

At the texture level:

• Texture2D.desiredMipmapLevel
• Texture2D.loadingMipmapLevel
• Texture2D.loadedMipmapLevel

At the system level:

• Texture.desiredTextureMemory
• Texture.totalTextureMemory

The following document released on the blog has a debug stats script to help with debugging memory usage and a script to help debugging an individual object in front of the camera. Both may help you identify the issue in your case
https://docs.google.com/document/d/1P3OUoQ_y6Iu9vKcI5B3Vs2kWhQYSXe02h6YrkDcEpGM/edit

 

It seems something about the imposter setup is likely to be a key factor. Our main mip streaming tests are focused on standard meshes.

It would be helpful to know more about how you setup the imposters in your project, so we can attempt to reproduce the issue. One possible issue is that the 'mesh metrics' may not have been correctly calculated by the system that created the imposters. If these values are only set to 1 it can be an indicator that they haven't been calculated.

One approach to sharing the setup is to create a new empty unity project and drop in just the key assets that are problematic. Then create a minimal test scene with those assets present. Sending this much smaller prpject in a bug report would allow us to inspect the setup in detail and make sure we target your specific issue.

If you list the bug id here then I would be able to review the report quicker.

 

Offset or rotation would not be a problem as they don't change the texel density on screen.

Tiling does introduce scale that changes the texel density on screen so could be problematic.
Scale applied via the material using Material.SetTextureScale or mainTextureScale will be accounted for in the texture streaming system and the correct mip will be loaded.
If you are calculating or modifying the scale amount within the shader then the mip streaming system will be unaware of that modification, so will be unable to account for in the calculation of the required mip to load.

(If the scaling is a reduction then it will be be visually ok as the system will request a mip detail lever higher than needed and the GPU rendering will simply use the lower mip. So visually ok, but not saving as much memory as it potentially could. If the scaling is zooming in, it will be problematic. To be visually correct a more detailed mip would be needed and the streaming system would not be aware of that).

If you need to bias the mip level due to your own scaling you can request a mip level directly for a texture with requestedMipmapLevel. You could read the calculated mip level via calculatedMipmapLevel, then apply the scaling to this level and call requestedMipmapLevel with this modified value.

Another option is to explore using Streaming Virtual Texturing if you can support its requirements. This performs screenspace uv calculations and therefore handles the custom shader code directly.

 

Hi,
Virtual Texturing does not support Material Property Blocks. You cannot set Textures that are part of a Virtual Texture stack dynamically, including textures on a Material Property Block (see documentation). Mip map streaming also currently does not support Material Property Blocks. This is something however we would like to fix in the future.

 

Yes it does. I remember testing with lightmaps myself.

 

I forgot to answer your question on 'mainTextureScale'. You should be able to follow this approach: Link. By naming your property

_MainTex_ST

you get access to the scale and translate property of a texture. That way, in shader graph, you can query the

mainTextureScale

. So your shader can use the scaling set by

mainTextureScale

and the mip map streaming should use the same property.