Note
I’m not very familiar with the Unreal Engine integration, so the thought I give here might be redundant, in which case let me know 
Goal
To simplify users experience working on a shared Unreal Engine project.
Motivation
For users switching between DCC’s and UE, the experience should be largely the same.
Users should be able to work in parallel without the complexities of source version control, but source version control is needed for collaboration.
Abstract source version control concepts from the user in order to make the workflow “backend” agnostic, so studios can any source control version software.
Implementation
We should be able to map the workflows from other DCC’s to source version control:
- Loading workfile > update to latest (branch) commit
- Publish workfile > commit and push local changes
- Validate workfile > flag merge conflicts
- Extract workfile > commit local changes
- Integrate workfile > push commit
This leaves us with “just” one concept to tackle; what happens if two artists have been working on the same thing, ei. merge conflict?
For this I have some thoughts but no solution:
- Merge conflict is flagged at publish, but might be too late?
- We could reduce the chance of a merge conflict by using One File Per Actor.
- Flag merge conflict at launch. This would be similar to how flagging FPS in Maya.
Would like to get @simonebarbieri thoughts on this.
Hey! I definitely agree that the workflow should be similar to other DCCs. I’m not sure if @antirotor has already an idea of how the Perforce integration should work!
The only concern I have from your idea is that we should be able to handle everything even in case a studio doesn’t want to use version control, but something like this: Multi-User Editing Overview for Unreal Engine | Unreal Engine 5.1 Documentation .
Conflict is definitely a problem. In case of conflict in binary data, I doubt Perforce or any version control system could do anything. One File Per Actor might help, but only if artists are working on a level. If they’re making changes to the assets themselves, we still have conflict! I think the best thing would be to lock specific tasks that involve assets directly, but maybe keep unlocked them if they involve only levels. I’m not sure how to handle this at the moment, probably needs more thinking
The only concern I have from your idea is that we should be able to handle everything even in case a studio doesn’t want to use version control, but something like this: https://docs.unrealengine.com/5.1/en-US/multi-user-editing-overview-for-unreal-engine/ .
I think my proposed workflow can still handle this. The UE project in the case of multi user session, would just work as if a single user is in the project, since all files (at I understand multi user sessions) will be on the same machine so no conflicts would occur?
I think the best thing would be to lock specific tasks that involve assets directly, but maybe keep unlocked them if they involve only levels. I’m not sure how to handle this at the moment, probably needs more thinking
We could maybe add more measures for catching conflicts early on. File locking or check in/out, would be one way but I think that is very specific to Perforce?
To catch conflicts earlier than publishing we could also:
- have a timed or otherwise triggered callback, that check for conflicts similar to suggested launch check.
- compare changed files (unstaged) against latest main branch, in the conflict check, to catch conflict even when the user has not staged or published files.
In perforce, you need to check out something to make changes on it, so this is basically locking. With perforce integration, it would mean that commits to perforce must be basically done by publishing (to synchronise changes between Ayon and Perforce)
@antirotor what are your general thoughts on this?
Does it align with perforce integration atm?
Current P4 integration is concerned only about individual asset - files that can be mapped to loaded subsets - loading fbx as static mesh in v001, will push it to p4, loading it to unreal, checking it out, modifying it there and commiting back will result in v002.
Stuff “published” to P4 is using its own changelog, so you can easily handle access to that changelog if need be to solve conflicts. and at the same time allow “normal” workflow with P4 outside of AYON.
This is theory, we are now implementing bits and pieces of it. FIrst step is to solve binary dependency of P4 API to various Python versions (so we don’t need to distribute tons of versions for every combination of python in maya/unreal/you name it) - there will be only one for main AYON interpreter and rest will be handled by websockets.