AWS Thinkbox Discussion Forums

Delay slave from starting job?

Using standalone vray submitter, the job references the vrscene file in its submitted network location (ie I don’t believe there is an option to cache/send to the repo, but please correct me if I’m wrong).

This works great, however, when my machine is offsite, the syncing could take a couple minutes for the vrscene file to come thru (especially if there is a large queue). Is there a way to configure a delay for a single slave? or automate the dependency process somehow so that my rig only picks up the job when the vrscene file shows up?

Actually, yes! But you need to add some data to the job info file at submission time. Enter, asset dependencies:

docs.thinkboxsoftware.com/produ … pendencies

That drives this UI:

[attachment=0]2018-06-01 10_36_50-Job Properties.png[/attachment]

If the job is submitted as “pending” it won’t start until the files are where they need to be.

right, i know I can edit the job props to add the dependency. I guess this solution would work if there was a way for it to autopopulate for the file. For example, when you submit a vray standalone rendering, it would auto add that vrscene file to the dependency list. Is there a way to automate that via a macro/token/whatever its called.

For example, it seems in the submission script, “scenebox” or “sceneFiles” defines the vrscene file. So could I somewhere in the script add in:

RequiredAssets = sceneFiles (obviously using the proper syntax)

Yeah, you can! Look for “Plugin=” in the script, that’s where we’re writing the job info file. The asset dependencies seem to be this:

“RequiredAssets=c:\some\path\to.vrscene”

The script is going to be this file:

“[repo]\scripts\Submission\VraySubmission.py”

It looks like you can use the “sceneFile” variable sooo… I think you can do this:

...
            writer.WriteLine( "Plugin=Vray" )
            writer.WriteLine( "Name=%s" % modifiedName )
            writer.WriteLine( "RequiredAssets=%s" % sceneFile )
...

Back up “[repo]/scripts/Submission/VraySubmission.py” before editing it though. If that works out, I’ll see if we can add it as a feature or if too many people would be confused as to why their job wasn’t starting…

whelp, script works, and it seems to have auto filled in the asset dependency. Will test it over the next few days and see how it works out, but man, this is a great option for slightly remote setups such as ours. Really excited about this, thanks so much!

So far, working great for the standalone vrscene submitter, and has definitely fixed a bunch of issues.

Is there any way to modify the dependent draft tile assembler somehow like we did for the vrscene submitter? I know its more complicated because it would need to pull in all the various tile names for all the render channels, but hoping there is something in there we can do. Or maybe an optional wait function for us?

Well, the assembly job shouldn’t run until the job is done rendering.

As far as adding the SceneFile to the job info, I’ll see if that’s a project we can push for.

Random thought: It should be possible to create an OnJobSubmitted() event script that automatically adds all “SceneFile” entries to the asset dependency list. Anyone want to try and create that?

Right, its just that at the time, I had 2 drives that were mirroring each other via a sync across WAN (which was pretty slow, so the job was technically done, but the main location hadn’t received the files back yet and would error). I spoke to Charles yesterday and I was also having issues with some remote control stuff and AWS portal stuff because I’m offsite, so I needed to rethink my whole approach.

I created a vpn this morning and am using regions and path remapping for my offsite location so it has direct access to the main network share - seems to work out much better and my test jobs have seemingly worked out fine using this method, presumably because the render task isn’t actually done until the file is saved and uploaded across the vpn to the main server, so even though it may take longer, its all accounted for (opposed to the sync).

Ah, that makes a lot of sense. Remote workflows are the toughest workflows…

Privacy | Site terms | Cookie preferences