I would like to request the addition of dependency-level dependency options, as opposed to the current global, job-level options. When building out dependency graphs, we don’t necessarily want all jobs to be frame-dependent (or not), and we may want to control the state(s) in which each dependency is considered “satisfied” separately.
Sorry, missed that one. We don’t have overrides for enabling/disabling frame dependencies on a per-dependency basis because it’s not really necessary. For example, if at least one dependency would have frame dependencies disabled, then it wouldn’t matter if the other ones did or not because the entire job couldn’t be resumed until that non-frame dependency finished. We simply couldn’t figure out a case where it made sense to make this a per-dependency option during design (either a job is frame dependent or it’s not).
If you have some thoughts to argue otherwise, let us know, because maybe we missed something!
OK, that mostly makes sense to me. However, I guess maybe I just need to be clearer about what behavior to expect in certain situations.
Say I have the following setup:
[code]Job A
Frames: 1001-1024
Job B:
Frames: 1
Job C:
Frames: 1001-1024
Dependencies: Job A, Job B[/code]
If I turn on “Frame Dependent” for Job C, how does the dependency chaining work with Job B? Do the tasks from Job C even consider it to be a dependency if the frame numbers don’t line up? In other words, would I need to manually set a frame offset of 1000 for that job so that it aligns with the other jobs? And what about frames after the first one?
Or is Deadline’s expectation that Job B would have a “frame range” of 1001-1024 even if it only had one task (which is something I want to avoid)?
Thanks for the example. In hindsight, we feel a bit silly that this case didn’t come to mind when designing the dependency overrides. What we’re going to do is add a per-dependency option to ignore the Use Frame Dependency setting for the job to properly handle cases like this.
So in this example, you would make Job C frame dependent, but in the dependency overrides for Job B, you would ignore frame dependencies.
We considered making the system a bit more flexible so you could also disable frame dependencies for the main job setting, but then you could enable frame dependencies for specific dependencies. However, it turns out that this would require significant refactoring in some areas. In the end, it’s not a big deal though because you can achieve the same results by turning on frame dependencies in the main job setting and then ignoring them for specific dependencies.