Version Control for Multi-User Sessions in UE4.25

Version Control for Multi-User Sessions in UE4.25

Multi-User Unreal Engine Screen Capture

This is the second post on the subject of setting up remote Multi-User workflows within Unreal Engine using a secure Virtual Private Network (VPN). In our first post, we reviewed the setting up of the VPN itself, and we outlined how we soon came unstuck when it came to something called version control, I say unstuck essentially we never had any and that was the main reason for our frustrations in our first post. Our bad.

What is version control?

Version control is a way to keep everyone in sync with the project files and in our view it is something you are going to need to understand if you want to run remote virtual production sessions in Unreal Engine; In fact if you want to work in the industry, we recommend you get your head around this now, as regardless of where you fit into the mix, version control is a valuable concept and skill to learn.

StormCloud VPN

The On-Set Facilities team, DreamWorks and Universal Pictures take StormCloud VPN for a spin.

Version control it’s not just for software development.

A quick multi-user over VPN UE4 version support round up,

  • 4.23 – is doable with some ninja skills.
  • 4.24 – much better than 4.23.
  • 4.25 – best so far, and works really well over VPN and when mixed with solid version control.

After Epic gave us some pointers we went with Perforce for version control. We’ll report more in the coming weeks, as we continue to test both Unreal Engine 4.25 multi-user workflows with StormCloud VPN and Perforce. Join our FB Virtual Production Crew group or follow our Facebook page to keep in the loop.

Adding Version Control to Multi-User UE Sessions

Hosted on the Microsoft Azure cloud, StormCloud VPN provides a solid and reliable network for anyone wishing to host multi-user remote collaboration sessions in Unreal Engine. But as we found out, having a solid VPN is not enough. After all connecting we could all see each other, we started creating together but we soon started to loose track of the project file and we encountered engine crashes and file sync problems. Knowing our VPN was up and solid, these problems were nothing to do with the VPN itself, it was all down to the project files not keeping in sync, which is where version of source control comes in.

When we posted our last post, the Epic enterprise team jumped in and pointed us towards Perforce, the version control solution that seems to be the games industry standard, its called Perforce Helix P4V to be exact. And as we soon discovered version control is not just for game developers, it’s now something those like us in the virtual production space need to get a grip of.

Having our own cloud servers, it did’t take us long to spin up our own Perforce server running alongside our StormCloud VPN. Within about an hour we’d issued our own Perforce user accounts and we’d all downloaded the Perforce client on to our local OSF computers. After some initial tuition from our trusty dev team, we had a solid multi-user environment in UE4.25 up and running.

You can run up to 5 Helix user accounts for free.

If you have any experience with web servers and organising remote directories, using source control will seem fairly familiar very quickly. The basic idea is a remote server that manages all the clients local copies of the shared project directory. But this isn’t as automatic as I first thought it would be, you still have to SUBMIT your changes to the Perforce directory, and everyone else has to PULL the changes down to their local computer. But, it’s just so much more solid than having to try and transfer actual project folders between your remote users.

We found everything so much more stable with version control in place, and once we’d set Unreal Engine to utilise the version control server, things started to work.

In our lab it’s our job to break things. So as soon as we got everything working nicely all building together on the UE session, we soon found ourselves trying to trick the Perforce server with as many noob requests, submissions and gets as we could muster. It didn’t take long to find a few chinks in the Perforce armour.

But this time, when we did loose sync between remote users flying around and updating the project like mad, it was not a big problem, with version control in place it was easy for the session Director to say “OK stop, now Session Server please save and Submit your latest version to version control” (moments later, not hours like before) “ok everyone ‘Get Latest’ and lets all log out and log back in.” Within a couple of minutes we’d all caught up with each other and got back to creating.

On first view it seems that version control is designed for teams working in a very organised manner, like when a game developer wants to work on a certain asset in the project. They can check that item out, modify it, meanwhile others will see that the asset is being worked on, then the asset is checked back in and now someone else can modify it. Thats the basic idea.

Our exploration now is going to be focused on using version control for virtual production. We are very much still learning how version control works, and in the use case of virtual production, which is a very different use case than a studio team developing a game. Using the StormCloud VPN we can potentially connect up to 30 users on one virtual VPN server, all working remotely on an Unreal Engine multi-user session.

Thats potentially 30 virtual production crew, all doing various jobs on the virtual set, from building lighting to set design, virtual scouting and even mo-cap streamed live into the session to visualise and block actors. Like I say, on first appearance version control seems like it is not exactly designed for this potentially manic VP set environment, and so we are exploring now, the use case and especially the way to ‘conduct’ or ‘direct’ such sessions, specifically for the use case of remote virtual production.

We have already been testing ideas on control and virtual set discipline, especially for committing source code changes. We have sneaky feeling that in our next tests we’ll be setting up the session so that only the session host can commit the source code changes. It’s things like this that we are now investigating.

That’s for another post.


%d bloggers like this: