AWS Thinkbox Discussion Forums

strange nuke batch mode behavior

Deprecated Deadline 6 Beta Discussion
#1

When nuke is started in batch mode, it appears that deadline starts sending it render messages even before its fully inialized:

0: INFO: Argument: -t “C:\Users\scanlinevfx\AppData\Local\Thinkbox\Deadline6\slave\LAPRO0709-secondary\jobsData\53e11c0c5b86390664eb24f6\SQU_039_0510_sky_moving_v0041_tbo.nk”
0: INFO: Startup Directory: “C:\Program Files\Nuke7.0v8”
0: INFO: Process Priority: BelowNormal
0: INFO: Process Affinity: default
0: INFO: Process is now running
0: Plugin rendering frame(s): 1039
0: INFO: Deadline RenderTasks called
0: INFO: Rendering write node WriteBot2
0: INFO: Sending command to nuke: nuke.execute(“WriteBot2”, 1039, 1039, 1, continueOnError=False)

THEN nuke starts:

0: STDOUT: Nuke 7.0v8, 64 bit, built Jun 7 2013.
0: STDOUT: Copyright © 2013 The Foundry Visionmongers Ltd. All Rights Reserved.
0: STDOUT: QCoreApplication::applicationDirPath: Please instantiate the QApplication object first
0: STDOUT: NUKE RAW ARGS:
0: STDOUT: [‘C:\Program Files\Nuke7.0v8\Nuke7.0.exe’, ‘-t’, ‘C:/Users/scanlinevfx/AppData/Local/Thinkbox/Deadline6/slave/LAPRO0709-secondary/jobsData/53e11c0c5b86390664eb24f6/SQU_039_0510_sky_moving_v0041_tbo.nk’]
…
0: STDOUT: Scanline Site Initialized
0: STDOUT: ======================================================================================
0: STDOUT: Shotgun API: <class ‘shotgun_api3.shotgun.Shotgun’>
0: STDOUT: 2014-08-08 02:00:00.862000
0: STDOUT: pgBokeh v1.3.5, built on Nov 30 2012 at 21:12:46
0: STDOUT: © 2011 - Present by Peregrine Labs, a division of Peregrine Visual Storytelling Ltd. All rights reserved.
0: STDOUT: –Initializing ATOMKRAFT–
…
Then starts rendering:
0: STDOUT: >>> [16:55.37] Warning: Transform42: request() clipped from xywh=-354,-4,14708,7008 to xywh=0,-4,14000,7008
0: STDOUT: [16:55.37] Warning: GridWarp3_1: request() clipped from xywh=-1,-1,14002,7002 to xywh=0,-1,14000,7002
0: STDOUT: [16:55.37] Warning: Transform42: request() clipped from xywh=-353,-4,14706,7008 to xywh=0,-4,14000,7008
0: STDOUT: [16:55.37] Warning: Transform42: request() clipped from xywh=-352,-4,14704,7008 to xywh=0,-4,14000,7008
0: STDOUT: [16:55.37] Warning: Transform42: request() clipped from xywh=-351,-4,14702,7008 to xywh=0,-4,14000,7008
0: STDOUT: .1.2.3.4.5.8
0: STDOUT: Writing //inferno2/projects/sea/scenes/SQU_039_0510/2d/precomps/SQU_039_0510_sky_moving_v0041/linear_sea177/SQU_039_0510_sky_moving_v0041.1039.exr took 450.61 seconds
0: STDOUT: Total render time: 7 minutes, 31 seconds

and only after this does it say “READY FOR INPUT”? Isnt that weird?

0: STDOUT: .9READY FOR INPUT

#2

Hey Laszlo,

This is currently by design, since it didn’t seem like there were any issues in doing it this way (the rendering doesn’t start until Nuke has loaded). Are you guys running into any problems that you think might be related to this?

Cheers,
Ryan

#3

Nuke has some really strange std out handling behavior, regular prints and nuke.tprints show up out of sync, interleaved, sometimes with considerable delay (you get the tprints 4 minutes after it actually happened and nuke is processing something else completely) which makes troubleshooting a real challenge. Wasnt sure if this is somehow related to that… A bit confusing is all, but it works.

Is there a purpose for the READ FOR INPUT string if its not actually used to start feeding input?

#4

I logged the our-of-sync buffer flushes to The Foundry quite some time ago (~Jan this year). I did chase them once about it and was told that Engineering were looking at it…
Would be good if you guys also reported this issue as a separate ticket number :slight_smile:

#5

It tells Deadline that nuke has finished rendering so that it can move on to the next task.

Privacy | Site terms | Cookie preferences