AWS Thinkbox Discussion Forums

Simple Slate DNxHD doesn't work as independent draft

I assume this is since it is triggered from a monitor submitted job instead of as a draft project for a previously rendered job.

I would like for Draft plugins to be far more resilient. It seems like an erroring Draft job is the norm not the exception. Top of my list for “Cookbook” recipes would be a base starting point that is bulletproof that I can muck with.

This is indeed because the Draft job was submitted standalone from the Monitor. That particular template is expecting there to be an original job it can pull info from, and fails if the job ID isn’t passed to it.

As for a “bulletproof” template, I’m not sure what you’d be looking for exactly. What kind of errors are you encountering regularly, that you would rather be dealt with differently?

In this particular instance, failing because the ‘deadlineJobID’ wasn’t found seems like the right thing to do to me, since that particular template requires it to be there. We do provide a utility function in DraftParamParser.py that DOESN’T fail on missing arguments – ParseCommandLine_TypeAgnostic( argv ), for the record – so maybe I could whip up a template that uses it when I have time.

Cheers,

  • Jon

It has to be brain-dead simple for artists to use. The flexibility is great but it’s going to prevent adoption if it’s not stupidly easy to use (or even better invisible).

I wouldn’t expect it to fail. I would expect it to just not have any deadline job info in the slate. I would also compartmentalize everything.

Whether or not you slate should be a flag not a separate template. Admittedly that flag would be dependent on the script so every script would need to define what flags it needs from the UI.

“StraightfaceDraftScript.py” -inFile “C:\VideoThing.mov” -slate TRUE -watermark FALSE -slateduration 24f

That should just work. It should by default then output to wherever the Script defaults to. Most likely C:\draft\VideoThing.mov

Alternately I should also be able to say:

“StraightfaceDraftScript.py” -inFile “C:\VideoThing_####.exr” -slate TRUE -watermark TRUE -slateduration 24f -startFrame 0 -endFrame 100 -DeadlineJob 382ADF3i891 etc…

There should be enough resiliency to survive on reduced information. It needs more artificial intelligence as well as user settings. I’m mocking up a visual demonstration of how I think it should work.

I agree that this is desireable. In examples I think there is a tradeoff between simplicity and resilience. We’ll want different cookbook examples that run the gamut.

I agree that a dynamic UI would be useful. But to me things like the slate, watermark, slateDuration, etc. feel like decisions that should be made by an authority. I guess it depends what kind of end user we’re talking about.

I imagine you will have at least three different kinds of Draft users: people who write Draft scripts; people who decide on template settings for each show, stage in your pipeline, etc; and artists.

What you’re describing seems like it would be useful for the decision makers. Perhaps you’d want to store a mapping from show, stage in pipeline, etc, to a set of Draft parameters. The controls you described could be part of a UI that controls this mapping.

I think Draft should be invisible to artists. They may need to choose StraightfaceDraftScript.py, but they’d never need to choose any other script, and they’d never need to touch any other controls.

This means that StraightfaceDraftScript.py needs to make some templating decisions based on the job information. Somehow you need to tell it everything it needs to know to make its decision, such as the show, stage in your pipeline, etc. Perhaps these are part of the inFile path? This will depend on how the rest of your pipeline is set up.

You may ultimately want a few different Draft templating scripts. If so, StraightfaceDraftScript.py would choose a script based on job information, and it would load and run that script.

It may be useful for us to put together a complete example, but I imagine people’s requirements will vary widely. You probably want something very different from the system I outlined here.

I look forward to seeing your mockup!

Privacy | Site terms | Cookie preferences