Linked workfiles

General
1

Goal
To be able to launch any task and share the same workfile/project.

Motivation
For DCCs like Unreal Engine, the most common workflow is to share one project between multiple artists. This though can be become a management mess when dealing with shot workflows. Take an example like this:

  • sh0010/lighting is assigned to Artist A.
  • sh0020/lighting is assigned to Artist B.

The options available at the moment are to:

  • have a common task for both artists to launch.
  • create multiple projects.

Common Task
This will create a disconnection between the task and the work data. What is most likely to happen is that the artists task will be left behind in favour of the common task, meaning management mess.
Reviewables will be published to the common task, which will make it difficult to organize review sessions.

Multiple Projects
This will create a storage issue along with DCC specific problems like sharing plugins/code between projects in Unreal Engine.

Implementation
The most generic approach would be to link tasks together, then its up to the launcher to figure out what files to launch. Linking sq0010/lighting > sq0010sh0010/lighting would mean that launch sh0010sh0010/lighting opens the project files for sq0010/lighting.

Further Thoughts
Unreal Engine workflows could be taken further by launching into a level per shot/task.

Although Unreal Engine is primary DCC considered for this feature, it could be considered for others like;

2

Would love to hear comments from @simonebarbieri on this.

3

I’ve worked on a whole project that used Blender and Unreal, I’ll share my experience :slight_smile:

The idea of the project was to use Blender to produce most of the assets, prepare the layout, and animate, while using Unreal to prepare the lighting, the shaders and render.

It was a short animation series with few short episodes, so initially we tried having one Unreal project for each episode. But we realized that it was complicated to handle many projects together for a few reasons:

  • It was an early implementation of OpenPype in Unreal, so, for instance, we still couldn’t publish/load any uasset (so no Materials, etc), and so they needed to be imported manually every time for every episode.
  • Those files had to be stored for every project. This resulted in massive Unreal projects, even though a big part of those assets were the same for all the projects.

So, we changed approach, and we tried dedicating a task specifically for Unreal. This approach had advantages and disadvantages, not entirely related to Unreal itself, but also to the way the Unreal project was managed. I still think it’s worth mentioning because it might be a common setup.
The main advantage is that, with a single Unreal project, it became much easier to handle the assets, as they were all in the same project, and as a consequence we had a significant reduction of the space reserved for Unreal.
However, the Unreal project was stored on Google Drive, so it became difficult to access it from different computers, because all the files of the project needed to be synced fully before being used. We ended up having a dedicated computer for Unreal, and only one artist accessed it remotely. This was not ideal, but it was the best we could do at the time.
Moreover, we had problems on handling the rendering. The rendering itself was ok, but the publishing became very complicated to handle, with some publishing requiring even 12 hours, and thus requiring a specific publishing process to cut the time :sweat_smile: Again, this it not entirely related to Unreal, but it was a problem we had to solve.

As conclusion, I think that having a single Unreal project is a good idea, but it’s important to have a good workflow to handle it. I really like the idea to have some tasks “linked” to specific Levels, or to specific files.
I think that everything comes down to handling multiple artists working at the same time. For this, in particular, we need the Perforce integration. Definitely Google Drive (and similar) is not the right instrument to share the project.

Moreover, it might be worth reading Epic’s whitepaper on the production of a Fortnite Trailer, produced with Unreal. It’s not 100% fitting, because a trailer it’s very short, but it gives a few insight on how Epic themselves thought of how to integrate Unreal in an animation pipeline. And it inspired how Levels and Level Sequences are handled in OpenPype :stuck_out_tongue:

4

I think that everything comes down to handling multiple artists working at the same time. For this, in particular, we need the Perforce integration. Definitely Google Drive (and similar) is not the right instrument to share the project.

Yeah, for studios to really adopt OpenPype with Unreal Engine we need some version control support. Whether its Perforce or git.

Have you looked at Virtual Assets and One File Per Actor yet?
Would imagine this would help with the remote workflow issues, but version control is still a big missing piece.

5

Have you looked at Virtual Assets and One File Per Actor yet?

Having a look right now! They both seem definitely something we want to handle in the workflow. The Virtual Asset explicitly require not only any version control, but Perforce specifically, so an additional push to implement support for it :sweat_smile:

OFPA instead seems already doable :thinking: I’ll have a look as soon as I have some time!