Incoming links

[tokejepsen]

Hey,

I'm would like to utilize the incoming and outgoing links more in Ftrack. When looking at incoming links I seem to be missing the api for a certain workflow.

The workflow I'm interested in is linking asset versions to shots and tasks. In practice we want to import/build an initial work scene, either Nuke or Maya, from these asset versions. This would be for example importing rigs or importing Nuke nodes exported from NukeStudio.
Seems like you can only link asset versions to asset versions, and shot/task to shot/task?

[Mattias Lagergren]

Hi Toke, where are these nuke nodes or rigs are exported currently? I.e. how are they parented - under an asset build/task or some other shot?

[tokejepsen]

Hey Mattias,

The Nuke script is export from NukeStudio. Since we don't know which task to associate the assetversions with, we just parent the asset to the shot.
Since we have to have a task when creating an assetversion, the task for the assetversion is the editing task that NukeStudio was launched from. This is a bit of a hack, because it creates an odd hierarchy where the assetversion is parented to the shot but linked to a task which is not under the same parent.
Hope that makes sense, else let me know and I'll to illustrate better.

So what I would like to do instead is to link the assetversion from the editing task directly to the shot.
I've explained it with the example of a Nuke script exported from NukeStudio, but the workflow can be extended to rigs (or other assets) in Maya. The idea is that you link the assetversions to a shot, so when you launch a task you can import all the linked assetversions for the shot.

[Mattias Lagergren]

22 hours ago, tokejepsen said:

Since we have to have a task when creating an assetversion, the task for the assetversion is the editing task that NukeStudio was launched from.

The task is actually optional and you should not need to associate the asset version with a task.

22 hours ago, tokejepsen said:

So what I would like to do instead is to link the assetversion from the editing task directly to the shot.
I've explained it with the example of a Nuke script exported from NukeStudio, but the workflow can be extended to rigs (or other assets) in Maya. The idea is that you link the assetversions to a shot, so when you launch a task you can import all the linked assetversions for the shot.

I see, and that makes sense. I think the intended workflow would be to publish the asset version either to a shot or asset build without associating it with the editing task. (If there is a task that makes sense you could you that one of course.). You would then link asset builds to the shots, and ideally our import interface would make it easy to list asset versions that are published on objects linked to the shot. This is something that we plan for the future update of the import interface. What are your thoughts on this, would that make sense and could it replace the necessity to link the asset version to the shot itself?

[tokejepsen]

5 hours ago, Mattias Lagergren said:

You would then link asset builds to the shots, and ideally our import interface would make it easy to list asset versions that are published on objects linked to the shot.

I can see why linking asset builds to a shot might be helpful. Let's walk through how I imagine that to work out, and let me know if I'm misunderstanding something.

You have an assetbuild called "characterA" where you have a "rigging" task. From the "rigging" task you publish a Maya scene with a rig in it. You then link the assetbuild "characterA" to shot "sh0010".
An animator opens an "animation" task on shot "sh0010". Now the asset importer would list all the assets on the assetbuild "characterA", because it is linked to the shot, and the animator would need to choose which asset (assetversion) to import.
In a more advanced pipeline you would be able to "build" the shot by importing all the assets needed. We work from the "animation" task launched, finding the assetbuild "characterA", and then we need to assume what assets we want to import.

This workflow could definitely work, but it would be very prone to production mistakes. What asset should the animator import if there are different versions of the rig? This kind of information is usually something a supervisor or coordinator would know. The animator would probably ask, but that doesn't really get us to a very optimized workflow, because we could just skip the linking and the animator would just import the rig asset directly from the "characterA" assetbuild by asking.
Another problem with this workflow is when it comes to exporting Nuke scripts from NukeStudio. Here we end up with a lot of assets (one per shot usually) which the compositor needs to filter through to get the Nuke script asset for their shot.

The ideal workflow is that the supervisor or coordinator can link/setup a shot, and the users get all the assets needed for the shot.

If we go down the case from above, but with the feature of being able to link assetversions to shots, here is how I imagine it going.
You have an assetbuild called "characterA" where you have a "rigging" task. From the "rigging" task you publish a Maya scene with a rig in it to an asset called "rig" with a version of 1, hence referred to as "rig_v1", with a "main" component. We now link "rig_v1" to shot "sh0010".
An animator opens an "animation" task on shot "sh0010". Now the asset importer would list all the assetversions linked to the shot. In this case we only have the assetversion "rig_v1". The animator imports "rig_v1" without the need to ask anyone in the production about which assets should be used in the shot.
This scales up nicely because the decision about which assets to use in the scene has already been made for the animator, so you could essentially have a "Import all linked assetversions" button.
Linking assetversions to shots/tasks also works well when exporting Nuke scripts from NukeStudio because the compositor does not need to filter through all the other export assets but only gets the list of linked assetversions in importer, or the pipeline can easily make that assumption when hitting a "Setup script" button.

There are some areas where this workflow falls a bit short; components and updating.
If a studio utilizes different components than for example "main", it'll be difficult to assume what to import if there is a "Import All Linked Assetversions". This can however be overcome by just bringing all components or the studio making its own "Import All Linked Assetversions".
When publishing a new assetversion, the already linked shots/tasks would have the old assetversions still linked. You would easily traverse the dependency graph and update the links, or leave it and let the asset management part of ftrack-connect handle updating. You would only really need to import all the linked assetversions once, but in the "Import All Linked Assetversions" there could also be a follow up "Scan for newer versions".

Phew! That was quite a post  I hope it makes sense, or at least some of it.

[Mattias Lagergren]

A lot of interesting ideas there for sure and I can see your point. I've added some thoughts below: 

11 hours ago, tokejepsen said:

What asset should the animator import if there are different versions of the rig?

An idea here is that the animator should be able to rely on the status of the version. That means of course that you agree on a common set of statuses and what they mean - e.g. "Work in progress", "Pending review", "Internally approved", "Client approved" - or whatever makes sense for you. If a published version is approved to be used in shots by the supervisor - the status would refelect this.

11 hours ago, tokejepsen said:

Another problem with this workflow is when it comes to exporting Nuke scripts from NukeStudio. Here we end up with a lot of assets (one per shot usually) which the compositor needs to filter through to get the Nuke script asset for their shot.

A possible solution here - that we've been investigating - is to build a version 0 of the Nuke script in NukeStudio and submit it. I.e. with the necessary read nodes / write nodes already there.

~

Another problem I could see with the linking of asset versions solutions that you propose is that you may want to decide at a later point than publishing that a new version of the rig should be used. E.g:

1. Following some feedback a new rig for Character A is published (rig_v2) to ftrack - the artist needs a supervisor to review it.
2. A few hours later a supervisor reviews it and approves it to be used.
3. At this point the new and approved version must somehow be linked to all the shots that uses the previous version of it.

In the other workflow the supervisor would set it to a status that means that it can be used. The asset management system would detect this and say that there is a newer "approved" version to be used.

[tokejepsen]

13 minutes ago, Mattias Lagergren said:

An idea here is that the animator should be able to rely on the status of the version. That means of course that you agree on a common set of statuses and what they mean - e.g. "Work in progress", "Pending review", "Internally approved", "Client approved" - or whatever makes sense for you. If a published version is approved to be used in shots by the supervisor - the status would refelect thi

The case of having two versions was not explained properly. When I meant two versions of the rig, I didn't mean two assetversions, but two different rigs.
For example having a two rigs of "characterA" with different clothes. You would end up with two assetversions "rigA_v1" and "rigB_v1". In this situation the animator does not know which to use unless they ask a supervisor.
 

18 minutes ago, Mattias Lagergren said:

A possible solution here - that we've been investigating - is to build a version 0 of the Nuke script in NukeStudio and submit it. I.e. with the necessary read nodes / write nodes already there.

Where would this version 0 of the Nuke script reside?
This is essentially what we do atm. We build a Nuke script and publish it to the shot, because we don't know which tasks needs the script.
Our current issue is that there aren't any differentiating criteria that makes the the Nuke script publish to the shot unique from other assets on the shot. You could argue that you could examine what task the shot is linked to and see which assetversions are linked to the editing task, but since this already seem like a hack I wanted to investigate better solutions. Linking assetversions seems like a more universal approach, since you don't need to know about the studio schema or workflow because you explicitly define what assetversions should be used.
 

25 minutes ago, Mattias Lagergren said:

At this point the new and approved version must somehow be linked to all the shots that uses the previous version of it.

Yeah, the updating part of assetversion linking is definitely an issue to tackle, and the more I think about it it seems like there would need a large infrastructure to handle this.

An alternative to assetversion linking would be to link assets to shots/tasks.
At this point the importer would work the same way as it currently does, where it does not make any assumptions about which version of an asset to make available to import.
The missing feature of "filter by status" in the asset importer would still be a very useful and valid feature.

[Mattias Lagergren]

Thank you for further explaining this and I can see what you mean. It would be interesting to hear how other studios solve this problem

[Eric Hermelin]

Hey, to me the idea of being able to link a shot / task to a "Asset" as opposed to a specific asset version makes more sense, this would allow you to control the version being loaded easily through the statuses of the published asset versions under the asset ie "Approved" / "Rejected" etc..

 

This would make the updating process less heavy as you would only need to change the asset version status in order to propagate new versions throughout the project.

 

That being said in some cases you might end-up in a situation where different shots require different versions of the same asset. While splitting the asset into multiple at this stage might be the "clean" workflow that is of course not always a possibility and might cause issues later in the project. It would thus also be useful to be able to link a specific asset version as a override/locked version.

 

One implementation of this is to introduce a separate asset / asset version that contains the information to build the shot published under each shot,  versioned separately and basically contain references to each asset ( or specific asset version ) required to build the shot, it could be represented as a simple json file. The big downside to this however is that it would not be visible or modifiable through the web interface without implementing special actions.

 

It would be great to hear more thoughts on this as I am sure there are many different implementations and considerations on this!

 

cheers

Eric

[tokejepsen]

7 minutes ago, Eric Hermelin said:

Hey, to me the idea of being able to link a shot / task to a "Asset" as opposed to a specific asset version makes more sense, this would allow you to control the version being loaded easily through the statuses of the published asset versions under the asset ie "Approved" / "Rejected" etc..

 

This would make the updating process less heavy as you would only need to change the asset version status in order to propagate new versions throughout the project.

 

That being said in some cases you might end-up in a situation where different shots require different versions of the same asset. While splitting the asset into multiple at this stage might be the "clean" workflow that is of course not always a possibility and might cause issues later in the project. It would thus also be useful to be able to link a specific asset version as a override/locked version.

That is a good point. I was thinking that once an assetversion is imported through the incoming links, it would be the responsibility of the artist working on the task to version up if needed. Equally if they need a to stay on a specific version, they would just not update.
Its kinda also on the asset creator shoulders to maintain backwards compatibility, and it the cases where you need to introduce breaking changes, the creator would either fix the existing files or maintain two assets.

[tokejepsen]

Is this https://trello.com/c/hz4agtYK/65-new-custom-attributes-link-entities-type a solution to this problem?

[Erik]

Chiming in on linking Asset to TypedContext (Sequence/Shot/Task/etc). Would be really useful.