I’ve been using Deadline for a while now, and one thing that I still haven’t gotten comfortable with aesthetically is how to best organize my jobs. I often write pipelines that essentially do this pseudo-code:

for item in my_items:
  for process in item_processes:
    submit_process( item, process )

In my last render management software package, a single job could contain multiple processes, which makes something like this very clean (a batch to encapsulate the overall operation, and each item could have a job of multiple processes). But in deadline I end up with a batch for the overall operation with a whole lot of jobs under it (imagine I have 20 items and each one has 30 processes). This makes it really unpleasant to do things like see the process of each item, check to see if a certain item is rendering properly, etc. The alternative is to use a batch for each of the 20 items, which then spams the render queue.

Is there a better way to organize my jobs that I’ve been missing for all this time? Or should I stick with my giant batches? It’s not a huge deal - everything still works properly, it’s just a bit of a hassle when nItems and nProcesses get large.

Thanks!

Unfortunately, for now you’re stuck with the large batches.

Just so I’m sure, would a batch hierarchy help out here? Outside of the visual organization batches don’t have any effect on the queue, but would being able to pretty it up be a win here?

Yeah, that’s exactly what I’m thinking of - just a way to clean out some of the clutter into meaningful visual groupings. Definitely a low-priority request since it doesn’t actually improve functionality, but it would put my neurotic tendencies a bit more at ease.

Yeah, fair enough.

We’ve got a tracking issue for this internally (which this thread has been added to), and I’m told the challenge is handling the model updates. I take that to mean aggregating stats from children and grand children.

Yeah, I can totally see that if it’s just a view-model implementation. We didn’t run into that with the previous system because there was an actual object layer in code (the job that contained multiple tasks) that updated itself and could be queried cheaply. It’s definitely not worth adding at the expense of a significant UI slowdown, but if there’s a slick way to do it I’d be a happy camper. Thanks for the quick responses!

Any time man.