Haha, I hadn’t actually thought of that yet. 
I seem to remember a “slate length” in Shotgun somewhere. I’ll let you know when I get that far. 
let me know how it goes, definately keen to implement this on out side too…(wanted to have sth. like this for years!)
cheers
cool template. mind if we get some defaults from you to ship with deadline 5.1?
cb
Nope I can package it all up for you guys. Can Draft read PSDs?
Yup, PSDs should work
So thought/question here. Should we be passing all of this shit to Draft through the command line or should we be passing in just the JobID and using the deadline package inside of the draft template to handle it? That would offer a LOT more flexibility for the template without rewriting the draft plugin for different templates.
Am I being obtuse or does that make sense?
I definitely see your point; I’ve sortof been pondering what the best standard should be. To be honest, I think the best solution is a hybrid of both.
I think passing a JobID so that the Template can figure out extra info on its own, in addition to fairly standard arguments, would be cool. Unfortunately, the standard Deadline .Net script functions aren’t available from Draft scripts (so you’d have to use DeadlineCommand). I don’t think that will change, due to the way we’re launching the Draft job (plus they wouldn’t be available when using Draft without Deadline anyways), though maybe we should include a utility script to do some basic interfacing with DeadlineCommand… No promises though! 
Anyways! I think passing the JobID is a great idea, and I will add that to our Draft submitters It likely won’t make it in the next beta release though, unfortunately.
EDIT: Forgot I had moved this stuff into an event plugin; should be super easy. I might be able to squeeze it in before next release.
Cheers,
- Jon
Oh there isn’t a Deadline Python module yet. Yeah that would make it hard.
Couldn’t you just call DeadlineCommand, get the repository path and then use Python to parse the .job xml? Seems like it would take… a couple seconds to write.
Even better, DeadlineCommand has a GetJob command which returns all job properties in a ‘key=value’ ini-style format. It also has a GetJobSetting command to get a specific property. DeadlineCommand does so much fun stuff!
Cheers,
- Jon
It’s also evidently really really really slow. I tried running it and it did get extra info but it took about 20 seconds to execute. This was essentially instant:
[code]import os
import xml.etree.ElementTree as xml
import sys
deadlineJob = “000_050_000_7fa7af25”
repositoryPath = “\\sfs-file\repository5”
def getDeadlineJob (job, repository):
jobKeys = (xml.parse((repository+"\jobs\"+job+"\"+job+".job"))).getroot()
jobDict = {}
for o in list(jobKeys):
if len(o.getchildren()) < 1:
jobDict[o.tag] = o.text
else:
jobDict[o.tag] = []
for t in list(o):
(jobDict[o.tag]).append(t.text)
return jobDict
jobKeys = getDeadlineJob(deadlineJob, repositoryPath)
print jobKeys[/code]
EDIT: Although I see now that I need to walk the XML tree a little more carefully since there are actually sub-keys. Boo!
EDIT EDIT: Fixed
I’m attaching the current version of my template for anyone who is curious.
It now outputs the following
“\…\Draft<OUTPUT_FILE>.xml” (Shot Info. An XML Slate)
“\…\Draft<INPUT_SCENE_FILE>.nk.zip” (Source file for the render zipped up if source is < 100MB)
“\…\Draft<OUTPUT_FILE>_WEB.mov” (Slated and watermarked Quicktime)
“\…\Draft<OUTPUT_FILE>_Thumbnail.jpg” (Single thumbnail)
“\…\Draft<OUTPUT_FILE>_ThumbStrip.jpg” (Filmstrip of [N] frames evenly sampled throughout the clip)
The only data this template takes in is JobID and inFile. (It currently actually is hardcoded for those two values for testing and waiting for the beta 3 fix to the sys.argv parser).
Ideally the sourceFile would in the deadline job info. (See other discussion). However one change I do want to make is to pull the job’s source file to get zipped instead of the referenced file path that submitted the job. (So that it is in fact the exact file used by deadline to render).
Also be forewarned, this is pretty much my first Python script so YMMV and it may be riddled with mistakes.
StraightfaceDraftTemplate_v02.zip (210 KB)
Cool!
As a side note, I’ve updated the Draft param parser helper module a bit. You will now have the option to do type-agnostic parsing (ie, you won’t have to specify expected types, but it will only return strings). I’ve also changed the existing function to just return a dictionary of the params, instead of the old way (which was a dictionary of dictionaries…). So you’ll just need to do (for example) params[‘inFile’] instead of params[‘inFile’][‘value’]
It just needs a bit more testing and then I’ll put it up
Cheers,
- Jon
(i have not checked if this is still valid for beta3, i just assume it´s not “fixed”…):
we definately need all checkboxes status and links to draft templates to be “sticky”, so every time someone submits sth. draft is either active or not.
otherwise our artist will definately forget to tick that box every single time.
also annoying is the fact that you have to browse for the template file every single time, not even the directory is remembered which really takes too much time.
perfect/handy would be a dropdown of the last 3 presets that where being used…
i also noticed very slow conversion times, i´ll have to check if this is stll valid for beta3 though. i tested jpeg to mov and it took longer to create than the nuke comp itself…
Wrong submission argument?
I’m looking at how deadline submits jobs and it’s
0: INFO: Render Argument: -u “C:/Straightface_DraftTemplate_v02.py” username=“User: Gavin Greenwalt” entity="Entity: " version="Version: " startFrame=1 endFrame=351 outfile=“G:\Output\Draft\Tracking_Shot_.mov” infile=“G:\Output\Tracking_Shot_###.tif”
Are the username, entity and version args correct? Shouldn’t it just pass a clean string?
Sort of bug:
infile and outfile are not camel case
Shouldn’t they be:
inFile and outFile to be consistent?
Probably. Consistency is king, as they say
I’ll change it for the next release
Is there a newer download link for Draft than Windows_Alpha_1 from June?
Also, by “Windows-only”, is it implied that the repository should be on a Windows box? Does it matter?
There is a newer build posted here:
viewtopic.php?f=85&t=6327
The binaries are split per operating system, but the OS of your repository machine shouldn’t matter; it’s only relevant for the machines that the Draft jobs will get run on (ie, the slaves).
Sweet, thanks!