Is there a reason why we can’t have task dependency outside of the area.
Example
If I create a anim task, I want to track the upstream dependency on the layout task and also the required rig tasks.
Is there some way to open up to any task in the project?
Correct me if i’m wrong, but the upstream, and downstream dependencies are meant for within the same shot/asset if you wanted outside context’s to trigger status’s of a specific task within a shot from an asset or from all assets in a project to all shots that is when you want to start looking at the shotgun event daemon.
That actually exactly what I use the daemon for… you can trigger it when a rig task has a new publish (or the first publish) it would set say an anim task ready to start within the shots of the same project for example.
But I might be wrong here,
Ross
Hi Ross
At the moment I are not looking at automatic trigger but as a means of letting the artist know when they can start work and also towards procedural scene building.
Given the fact that artist workflow is task-centric, we want to build a clear communication as when they can start work if they are waiting on other tasks. If I open up my task and see layout is done but the rigs are not ready, then I should simple move on to the next task.
Similary in lighting I can put put the dependency on the anim tasks and shading tasks. In theory the anim can be done, but the shading is still in progress. Once that is done, then all I need to get the published products from those task and connect the shading with the anim alembics. This is true for both the artist and the any procedural tool.
The question is why should the upstream and downstream task dependencies be locked to a shot and asset, when the data can flow from anywhere according to the published file entity through the published file entity.
Even if I have a event daemon, where a rig task has new publish then it still needs to let the downstream anim (or layout) department know that something got changed. Offcourse one can argue we can track on the published file level, but it would good for a clear line of communication from a task to task level.
Let me know if that makes sense?
Cheers
Pritish
Hey Pritish,
That actually does make a lot of sense. Something I have never really looked too much into is trying to leverage:
and tying them together with linked entity fields.
This will allow you to link assets to shots, and by adding a shot level field you can view the asset’s “ALL TASKS” or specific task progress. I was not able to find a way though to link specific tasks on a shot to an asset. It seems that it is designed to link assets to shots, but not particular shot tasks to particular asset tasks.
if you scroll down to the bottom of the tasks and steps page there’s info about linked asset/shot fields:
what you would end up with is something like below, where you have an asset “testShipAHi” linked specifically to a shot. And under the shot there is a little running list of tasks. In this case 1 out of 3 tasks is final, so it shows 33%… There’s also a little “I” that will allow a fly out window that displays the tasks from that linked asset, and their current statuses.
maybe this sort of path will work with a little more investigation?
Hopefully someone with a little more experience with manually linked assets > shots will shed some light on aspects I’m missing.
-Ross
Hi Ross
Thank for that. While the shot to asset link it something we are aware, however we would like to be extremely granular.
For example there might some assets which have just a model and no rig, so a layout artist dependency would be on the model task
In case a rig is being created then the dependency would be on the rig task, since rig itself is dependent on the mdl task.
@pritish.pixomondo & @Ross_Macaluso,
Thanks for the tag and feedback. I’ve given the thread a read and distilled what I think are the ultimate goals here, but let me clarify with you guys. Are you trying to link Tasks (dependencies) between different entity types?
If so, from the Task page, just select the two Tasks, right-click, and select Dependencies > Link Selected.
If you’re more interested in status changes based on events, like dependencies upstream > downstream (and even vice versa), an event daemon trigger would be worth looking into as you have discussed. So let’s say the last Task in the Asset is complete, and the first task in the Shot is ready to start—and you’d like the Shot’s Task status flipped to reflect that, automatically and based on events. You’d need to create and run a trigger to handle that automatically. We have documentation around this as well as example triggers you can use and build from here.
Additionally, we’re also working on Webhooks, currently in beta, which handles the same kind of scenario: Check out this documentation if you’re interested in joining the beta program.
Does this help clear things up a bit further?
Cheers,
Shayna
Are you trying to link Tasks (dependencies) between different entity types?
That is correct. I am glad to see that this is possible, but doing this via task page is going to impossible since we have sometimes 14000 tasks on a show.
I would have expected to able to type in task via upstream /downstream dependency field itself.
Right now tasks entities it is restricted to the current parent entity. If that field is able to search the task entities in the projects then that solves our issue.
@pritish.pixomondo, thanks for the feedback and for clarifying!
…
Let me see if there is a better way to handle your workflow of setting the dependency between entity types via the upstream/downstream dependency field (instead of linking them).
Hi @pritish.pixomondo - just weighing in with a bit more background here. As a former production manager, I have looked to set up similar dependency chains in the past, to make sure the whole complex web of production dependencies are represented. That said - we tend to recommend against going this route for a couple of reasons.
The primary problem with connecting everything this way, is it tends to result in some behavior that is not always clear to everyone interacting with the site. The more you have dependencies across the context of different entities (Shots, Assets, etc), the more you have people seeing things shift around on the schedule without knowing exactly why. We find this causes more confusion than it is worth in the long run, compared to a trigger-based status flipping approach, or simply offering convenient ways to view status of dependent things.
There is also a performance concern here, as if you created dependencies between all 14k of your Tasks, then each one of those would have to recalculate start/end dates every time there was a change to any one of them. Also considering the fact that many clients have well beyond 14k Tasks, and may have 10’s or 100’s of users changing dates at any given time, you can imagine how this could become a massive computing challenge.
I think suggestions so far in this thread are all good ones - if your artist can jump over to the linked Assets tab on the detail page for their Shot, and scan the Pipeline Step columns to see approval status of all their required Assets - that makes for a pretty simple workflow IMHO. You could also add the connection field (as mentioned by @Ross_Macaluso) to identify when a particular Asset has a non-standard dependency, or have a list field on the connection to choose what Task or Step the dependency requires.
I hope that helps a bit. I would recommend (if you haven’t already) submitting any ideas you have on how to improve this workflow to our public roadmap portal. 
@tommy.kiser At the moment none of the production team is using dependency tracking for scheduling as explained in your video. So if this was a performance issue where date change in one task affects dates in another, then we would simply like a way to turn that feature off on certain project or site wide basis.
Each task the shot are dependent upon different tasks of the asset.
Eg
Anim/layout - rig
CFX - CFX setups
FX - mdl
Lighting - Shaders
In addition to this our task name in the asset are not standardised, eg they have special task in a asset where they are creating a variation for a shot specific need, so we would like to make our shot tasks track that task instead of the generic mdl task.
In the end we wanted to go towards procedural scene building and without the ability to cover those edge cases it would be hard to do that without the help of the database.
Even in the link that @shaynad mentions one of the suggestion states
This is exactly the sort of thing we want to do, ie as soon as a rig is ready, we want animation to to get notified via status change.
Acknowledging it could be confusing in some workflows when changes happen, without such dependencies, it can easily result in a lack of overall information on the impact of changes. Status flipping seems more like a process for managing a work queue (which is important and relevant), but without dependencies, the planning aspect of scheduling becomes much more difficult. In particular, it is difficult to predict when a downstream task could possibly start and conversely (and arguably more importantly), be aware of when a change to an upstream task will create an impact that results in a delivery date not being feasible.
