Sparse Virtual Texture For RealTime
This proposal suggests adding
Sparse Virtual Textures (SVT)
as an optional feature in Blender’s rendering engines (Cycles/Eevee/Viewport).
SVT lets artists use extremely large or numerous textures
without overloading GPU memory
, because only the visible parts of each texture are streamed to the GPU in real time.
Why It Matters
Modern projects often rely on
huge textures and many UDIMs
.
Today we must either reduce texture size or buy expensive GPUs.
SVT solves this by
streaming texture “tiles”
on demand so the GPU only keeps the tiles you can actually see.
Examples in the industry :
- Adobe Substance 3D Painter uses SVT to paint and preview extremely large assets.
- id Software pioneered the concept with their MegaTexture technology in games like Rage .
- Amplify Texture brings virtual texturing to Unity for massive worlds.
- Open-source demos like Silver Spaceship SVT and StudioPixl’s article show clear, practical approaches.
Resulting benefits:
- Work with virtually unlimited texture size
- Lower VRAM usage
- Faster viewport interaction on complex environments
How It Works (in simple View)
Think of a giant image cut into small square pages:
- Blender keeps a low-resolution version always loaded.
- As the camera moves closer, the system streams higher-detail pages where you look.
- Old pages you no longer see are released automatically.
This happens in the background, so artists just paint and render as usual.
Vulkan & Performance
Vulkan already supports SVT via
Sparse Images
, which let the GPU map only the needed pages.
Real-time performance is solid when streaming is well managed.
Some drivers still need optimisation, but production tools show it is practical today for interactive work and final renders.
Proposed Implementation in Blender
- New Option : Enable Sparse Virtual Textures in Scene or Render Settings.
- Parameters for page size and memory budget.
- Works in Cycles, Eevee and the real-time viewport.
- Automatic fallback to normal textures if hardware does not support SVT.
Benefits for Blender Users
- Massive environments such as cities or landscapes without texture downsizing.
- Heavy asset libraries with many 4K/8K UDIMs.
- Reduced memory pressure on mid-range GPUs, keeping scenes responsive.
SOOOOOOO
Sparse Virtual Textures would let Blender handle extremely large texture data with much less GPU memory, bringing professional game-engine and film-production techniques into open-source 3D creation by combinning multiple technics and not only one like MipsMaps could be insuffisant !
5 Comments
Donovan - these suggestions always look like you've come across some tech on the internet, and think no one else has seen it - including people who live and breath GPU coding.
Saying "here's a white paper, add the feature!" is practically useless. It's hardly different than saying "I just read a paper that explores a new engine design for a jet, and Gulfstream should use it!"
useful link
publications.lib.chalmers. se/records/fulltext/155126.pdf And silverspaceship.com/src/svt/
It looks like this is in development for Cycles and EEVEE
Almost, but not really !
But it is. What you're promoting is texture streaming what is implemeted in Cycles with the points you mentioned. So please don't tell people in a one liner that it ain't.
Yes it doesn't use Vulkan, it ain't called the SVT but that is just technology. Users should not care about the technology part (how it is implemented, which GPU feature is utilized) to provide the functionality.
For EEVEE this is a different topic. We already did the math and it doesn't seem to be realistic in the short term and has quite some drawbacks that is known when using sparse resources. Texture streaming (not sparse) will reduce memory usage, but is far less than expected. We also have an issue that we currently cannot implement it in OpenGL due to binding restrictions and requires an overhaul of the OpenGL backend and EEVEE.
Performance wise it also doesn't add up and the overhead (also present (even when turned off) is much more than users would expect. docs.vulkan.org/samples/latest/samples/extensions/sparse_image/README.html (also a basic application already mentions these draw backs).
The examples you provide have a different complexity and for them it works. But that doesn't mean that it will work for us.
So in the short run. Cycles will get similar functionality soon, EEVEE isn't unless we can reduce the complexity and performance that virtual texture streaming will introduce.
Lets also talk about inconsistency in your proposal just so your next proposal will be better. If an feature is optional (user needs to enable it) you don't need a fallback as this can be tested up front. Sparse resources are part of the vulkan 1.0 specification so which GPUs/platforms are you referring to. It would be awesome if you don't promote a GPU feature but just what users want. It requires a lot of technologic knowledge to map a GPU feature to what users want. This proposal just is a case where you want to add a specific GPU feature even when it would downgrade most user workflows, without mentioning these draw backs or have any understanding of them