We tested out RVT for tiled landscape yesterday to get a feel for the Memory and Processing effects and the overall runtime cost and benefits seemed pretty good. But the actually setup and working with RVT for a tiled world as others have stated are pretty painful. The first test we did used 3x3 1km tiles and the largest RVT size with a volume set to capture the whole area. This worked fine, but the resulting texel density was too low compared to our needs and ended up creating a noticeably low res landscape compared to other objects in the scene. Switching to using separate volumes per tile each with its own RVT and then modifying our master RVT version of the landscape material to use a series of switches to use the proper sampler let us somewhat simplify the process, but this would not be feasible for all the tiles in our world and it was still painful. Placement of the volumes based on tiles is tedious as it has to go in the center and the copy bounds doesn’t let you use the proxy as a source for instance.
Given that currently our designs on focusing on making a specific 1x2 km section of the world our playable test area this really wouldn’t have deterred us since we actually unload any Landscapes beyond the immediate bordering ones to optimization and use Static Mesh LOD’s and a very simple and lower resolution Material which we bake the textures for separately. But this would eventually need to be expanded upon over time and most importantly the borders for the tiles would need to be completely seamless. Unfortunately for us we found very noticeable seams were being created with separate tile RVT as shown in the attached images. It’s actually most notable from a distance from various angles, no amount of adjustment would eliminate it that we could find.
We’d really like to use this feature in our large open world setup, but currently given the visible seams, and some of the other reasons given in this thread we’ve decided not to make the switch for now and just watch for future improvements to hopefully make it more viable for this setup. It looks very promising as we would love to leverage the benefits of the approach.
It is worth noting that we have also implemented SVT in our project for objects using large textures, and likely have more optimization to do for using that, so we were very interested in seeing how both implementations would work together.