I’ve been going round in circles trying to lock down a reliable, standardized A-to-B pipeline for Runtime Virtual Textures (RVTs). Looking through the UDN and public forums, everyone seems to have highly unique setups or bespoke issues. Now that we are in 2026, I’m wondering if anyone has achieved a stable, high-quality RVT workflow for a single 16k terrain
The Current Workaround: The only viable solution I’ve found so far is to split the 16k terrain into 4k sections, utilizing separate landscape materials and separate RVT volumes for each quadrant which is as massive pain to setup and just seems wasteful.
The Roadblock: While this works for the landscape itself, it completely breaks down for our game’s procedural content. Because our spawned assets rely on height blending and reacting with the RVTs, using four distinct RVT volumes means we would have to duplicate the procedural content and their materials to point to each specific volume, swapping them dynamically based on the quadrant they spawn in. This is highly inefficient and unsustainable for our pipeline.
The Question: Has anyone successfully implemented a high-quality RVT setup across a massive 16k landscape that allows a single material setup for procedural content to blend seamlessly, without resorting to multi-volume duplication? Any insights into a cleaner pipeline would be hugely appreciated.
If you split the world into 4 rvt quadrants, in theory you could get objectWS in the master material of things that need rvt blending, do some math to figure out the quadrant, and plug that into Ifs/switches to select the correct rvt. Dunno how efficient it would be tho to have refs to all 4 rvts inside the main material.
That’s actually one of the ways to do it.
You should probably go smaller. it depends on total drawcalls really.
I have a 144km^2 - obviously if I cut that into 1km^2 blocks then there’s an endless amount of drawcalls that the system is forced to handle, so I can’t go that small.
But in your case, 16*16 or 256 draw calls at worse are trivial, so you CAN go that small and get some performance back if you are obstinate to keep using the landscape system that has never worked right.
No one really bothers using the landscape system or RTV in production except for Tim’s idiots on Fortnite. And you can see the “quality” that they have…
The main thin is you don’t need to. You make meshes, you pre-compute everything, and your objects can sample the mesh they sit on if they really need to somehow blend “dynamically”.
which, they usually do not.
And no, it’s not “MORE WORK” or “Unsustainable” - it’s just that no-one in their right mind works in engine on this type of stuff. You build in a decent DCC, you export to the engine once it’s ready.
