blafeber

@ollieblanks Do you have any new updates on this matter?

Hello, Thanks for responding, it seems you understand our requirement indeed. A seperate branch with artists working and reviewing there is actually exactly how we worked before (besides using the code review system, which sounds like a good idea). However, we ran into issues with that seperate branch. Tens of thousands of models we handle using our pipeline, so no artist touches these. These get added on the development branch. Also on the development branch we sometimes change things like folder structures or prefabs. Artists work in these prefabs aswell, so ideally they would have the updated versions to prevent conflicts. Maybe letting artists change those prefabs shouldn't be part of our workflow then? Or we just deal with these conflicts? We would also run into conflicts if developers moved a folder on the development branch while artists are working on something inside that folder on their artist branch. Or artists would create a new folder (or multiple) in what they think is the correct location, because they dont have the updated folder structure yet. This would not give the developers a conflict, but it does force them to spend time moving the folders to the correct location. This meant that we would need to merge the development branch to the artist branch pretty often to make sure they have the updated prefabs and folder structure etc so developers dont have to keep spending time solving conflicts or moving wrongly placed folders whenever a developer would grab a changeset from the artist branch. However, merging the development branch to the artist branch would also ask us to merge those tens of thousands of files aswell . And that is a lot of wasted time spent on merging files the artists dont need. The only way i could find to prevent that meant we would have to cherry pick all the development branch changesets, except the changesets that adds those tens of thousands of models, to the artist branch. But that would mean we had to switch our workspace to the artist branch, which would give us a long loading time due to unloading those tens of thousands of files. I do not know a way to cherry pick from branch x to branch y without having to be on branch y. So that is also a lot of time wasted on swapping to the artist branch, cherry picking branches 1 by 1 and swapping back to the development branch. And that is why we tried out the workflow with artists working on the development branch. So they could just easily configure their workspace to not include those tens of thousands of files and just keep having access to the updated prefabs and folders. But that left us with the reviewing problem stated in the original post. So what should we change in that workflow to keep the time spent on merging, solving conflicts/problems like described above as low as possible if we were to work with a seperate artist branch again? Thank you for your assistance.

Hello, We would like to know what the proper/ideal workflow would be that would allow the following situations: Developers work with the regular Plastic GUI Our developers are the ones actually working in the main scene in Unity, so they need to know when models are ready. Artists work with Gluon Artists edit the .blend files, but we want to use only the exported .fbx files in Unity (for lower import times since we work with tens of thousands of files). So we have another location on another plastic repo where these source (blend/substance/indesign etc) art files are stored. They edit these, export them as fbx / image files and then check them in the unity project repo. (Its a seperate repo because we reuse many assets in different projects, therefore no cloaked folder outside the unity project) When we have interns or new artists, we want senior modellers to be able to review their work before their .fbx gets updated in the unity project. For example to make sure there is no wrong normals, proper material/texture names, applied locations etc. Since these would mess up prefabs if the corresponding .fbx would be wrongly updated. Ideally we want to use the gluon system of checking out and locking models so everyone in the team knows which files not to touch. And every changeset can be seen by all members of the team. However, as far as i know this does not allow proper reviewing. Meaning if our game-designers/developers would notice an update was made to a file, they might think it's ready to be used. Ofcourse we use a ticket based system, which keeps track whether a model is 'in progress', 'testing' or 'done'. And artists could add the status in a changeset, but it's not ideal that the developers will have to keep checking those to keep track of model status. If we would let the reviewing happen on the art source location, we lose a part of the overview on all the models. Only artists will be able to see the actual status of models, since only artists are part of this repo. And since the model will only be placed on the unity repo once it's finalised, the changesets developers can see in their repo will contain jumps from, for example v1.0 -> v2.0 instead of v1.1 -> v1.2 etc. And if all senior modellers are ill or on holiday, developers cannot easily take over the reviewing as they will need to 'pull' the entire art folder or learn and use Gluon. Which just does not seem ideal. Can we for example let the intern check in the changes while keeping it locked, but manually/automatically transfer this lock to a senior artist, so they could review it first and then release the lock if the review was passed? Meaning a developer would try to use a model and see it's locked, it's not to be used and if it's not locked, it's free to use. How would we set something like this up? Thanks in advance.