The recently released Unreal Engine 5.1 brought a new feature to help with faster and smaller data syncs: Virtual Assets.
Currently in Beta, Virtual Assets provide a way to decouple structured data from bulk data, enabling developers to sync only what they need from source control systems such as Perforce. This results in smaller workspaces and faster syncs for developers who don’t need access to the full object data.
In this tech blog, Senior Product Manager Grace Yen and Lead Developer of Virtual Assets Paul Chipchase from the Unreal Engine team take a deep dive into Virtual Assets so you can assess whether they’d be a good fit for your project.
What problems do Virtual Assets solve?
Over the last few generations of game development, we’ve noticed some interesting data trends relating to project sizes. Not only are project sizes getting bigger (we informally polled some of our licensees to verify this), but many developers are moving to a Games-as-a-Service (GaaS) model, with continuous updates through multi-year game lifecycles.
We’ve also seen teams continuously evolving the way updates are delivered. Some teams opt for “feature streams” to help keep bleeding-edge features from affecting the rest of the team until the build has been stabilized, ready for release.
We’ve observed some team members work between release lines of their products (to support live services), and also models with “main” and “advanced” type dev workstreams.
This poses another challenge, where team members are often at the brink of exhausting their SSD space and sometimes have to make wasteful decisions to unsync a workstream they will likely need again soon, in order to make room for the current work they are doing.
Pre-pandemic, some studios (including ours) experienced challenges with sync sizes and sync times. We deployed solutions such as Performance Edge servers to try to give users a faster access point. However, when we were required to work from home back in 2020, we started to experience the pain of team members not having reliable internet connections, or having wildly varying internet speeds.
Putting together the best teams sometimes means that team members are located in different places—and we think that dynamic is here to stay. Even in the hybrid scenario where team members spend time in two locations, we can have the compounded problem of needing to sync up multiple times to hardware assigned by location.
With powerful technology such as Nanite, UE5’s virtualized geometry system designed to achieve pixel-scale detail and high object counts, we expect project sizes to grow even bigger in the future.
In summary, people are spending increasing amounts of time and space syncing, because:
Projects are getting bigger
Games are living longer, and therefore more content is being added
The problem is being magnified because:
Teams may need to sync multiple workstreams, like new feature releases or the management of live services
Physical hardware (e.g. SSDs) is more costly, difficult, and time-consuming to provision
Larger team sizes can make it harder to work efficiently
Hybrid workers and remote workers have sync challenges
Teams starting to leverage Nanite are getting higher visual fidelity, but also bigger data sets
What’s the Epic approach to Virtual Assets?
Our Virtual Assets solution is built upon the fundamental idea that you should only sync the data you need, and additional data that you later require should be quick to access.
It’s a shift from some of the ways teams might have been working around the problem. Teams (including ours) have become really good at teaching developers to set up overnight syncs, planning well ahead to minimize downtime. Virtual Assets won’t take any of that away. What they offer is a faster and more efficient way to sync data for everyone, especially on the occasions when you can’t plan ahead and an urgent issue comes up on a workstream that you don’t already have up to date.
We evaluated our package files (.umap/.uasset) and saw a huge opportunity to trim down the data that users had to sync. Often, users only need enough information about an asset to be able to display it in a meaningful way in the Editor. In the case of a texture, for example, you might need a thumbnail and Editor properties such as coordinates and scale. But the bulk data of a UTexture object is the original raw pixel data, which you don’t actually need upfront. Based on that, we’ve split these assets up into two parts behind the scenes:
The “structured data” remains where your assets currently are in your source control. It contains everything the Editor needs to load and represent the asset
The “bulk data” is the portion that you likely don’t need, and it’s split off into a separate area of source control
One of our principles in developing Virtual Assets was to maintain our users’ existing workflows. Team members should be able to sync and work in the same manner, but faster. By splitting up and leaving the core asset metadata in the original source location, users can sync data in the same way they did previously. The tool takes care of the behind-the-scenes work to fetch bulk data from a new source location if needed. To get this going, you will need to work with your source control admin to set up a separate location with the same access permissions as your original source control location.
We split assets up so the bulk data is stored in another source control location
Users work as before, but sync to smaller core asset metadata pieces
In the rare case that they need the bulk data they haven’t got, users can fetch this on demand
How can I deploy Virtual Assets?
The Virtual Assets feature is currently in Beta, which means it’s in a good place to try out, but that its form might change, so you should use it with caution in production projects. We’d like to highlight, however, that it has been robust enough to be used in the production of Fortnite from Season 22 onwards.
We have a few modes to help teams enable Virtual Assets:
Depending on the size of the project and your production schedule, you might want to try different approaches. For example:
If you are starting a new project, we recommend you try turning on Virtual Assets right away.
If you have a project in full production, you might want to avoid bringing this into game areas or assets you are iterating heavily on—but you could do a pass of larger assets that haven’t been touched in a long time.
Or, you might just target your top assets by size and virtualize those assets as “low-hanging fruit.”
Caveats to consider:
While we don’t have a “Work Offline” mode implemented yet, we recognize that this is a beneficial feature. It’s next on our list and planned for inclusion in 5.2. . This means that if you have users who might be working while disconnected (e.g. on a plane), Virtual Assets won’t fully work for them right now. They might get to a place where they can’t retrieve the bulk data for something they want to edit. The Editor shouldn’t crash, but they will need to reconnect to grab the bulk data they need.
There is a split of your primary data. Though not an issue during production, it does add an extra consideration if you plan to ship the content data of your game outside of your existing infrastructure. In this case, you can use the standalone UnrealVirtualizationTool to “rehydrate” your virtualized assets back into their original form (by storing the bulk data in the package file once again).
This implementation only works well if your users have access to a shared data cache with reasonable connection speeds. Otherwise, the user will see noticeable hitches and might be better off taking all of the sync time and space upfront. More on this in the next section.
Currently, we only support Perforce source control.
This tech is still in Beta. Although we have deployed it internally and are currently working on it, there is no guarantee when Virtual Assets will move to Production-Ready status or how the feature will be supported in the future.
Are Virtual Assets a good fit for my project?
There isn’t a definitive answer as to whether Virtual Assets will benefit you, as many different factors are involved . But the questions below should help you decide if this is an appropriate solution for you to try. It’s also important to note that virtualization is not a one-way street. You always have the opportunity to re-hydrate any (or all) virtualized data if you choose too.
Is your team currently experiencing disk space issues, or do you see your data growth continuing to a point where you expect such issues?
Do team members often need to sync more than one version of your project, generally sharing a large amount of content between the versions?
Do your team members have access to a good shared Derived Data Cache (DDC)?
This is also a loaded question. If most of the team members do have access to a shared DDC, and you have some outliers, you might use Virtual Assets across the project, but allow certain team members to opt out. They will “devirtualize” assets when they check in, but you could try to run scripts to catch this and fix up automatically—although this comes at the cost of source control churn.
Tips for maximizing the benefits of Virtual Assets
We recommend you look into using the Unreal Editor check-in workflows. Going through this path, there are checks in place to ensure assets are still virtualized when checked in. Although we provide some tooling that can be run from Perforce to check for virtualized assets, there is always a chance a user bypasses this and skips it.
Virtual Assets in action
Often with features we release in Unreal Engine, we like to be our own first customers—to “eat our own dogfood,” as the saying goes. In addition to enabling Virtual Assets on internal/sample projects, we have also introduced the feature to Fortnite. The numbers below are provided as illustrative examples only to give you an idea of the space and time savings we saw on Fortnite. Your mileage will vary depending on the makeup of the asset types in your game. For example, we ran this on Valley of the Ancient (which in no way represents a real game), and due to the heavy use of Nanite meshes, we got a 50x saving.
On Fortnite, here is what we measured:
Looking to the future
In Unreal Engine 5.1, Virtual Assets:
Works with Perforce
Supports Textures and Audio assets
Provides different modes to enable (by asset type, package path, or all)
Has bulk data referenced by a hash of the asset’s contents
We have a lot more Virtual Assets features on our radar, including:
Work Offline mode (to sync all data ahead of time)
More asset type support (e.g. Static Meshes, including Nanite)
Support for other source control solutions
And there you have it. We hope you have found this tech blog useful. If you’d like to find out more about Virtual Assets, check out the documentation.
Get Unreal Engine today!
Get the world’s most open and advanced creation tool.
With every feature and full source code access included, Unreal Engine comes fully loaded out of the box.