From: "Mr. Daniel Browne" <dbrowne@(email surpressed)>
Subject: Re: Submit Confirmation
   Date: Thu, 05 Jan 2012 20:49:29 -0500
Msg# 2184
View Complete Thread (23 articles) | All Threads
Last Next
That sounds like it would switch the confirmation off across all apps; I simply one to reduce it down to one, so it sounds like I have to make a modification myself to .common.pl.

I wasn't aware of the ability to address write nodes that way, however we've gone a more user friendly direction by breaking them up into fields in the submit window.



On Jan 5, 2012, at 2:48 PM, Greg Ercolano wrote:

On 01/04/12 17:49, Mr. Daniel Browne wrote:
> [posted to rush.general]
> 
> Hi Greg, Happy New Year.
> 
> Before the holidays I had made a modification to our Nuke submit to =
> split off each write node into a separate job. The downside is that if =
> you have a lot of write nodes, you have to click through a whole lot of =
> "Ok" messages after hitting the submit button. Is there an easy way to =
> suppress this, or do I have to customize the RushSubmit() routine inside =
> .common.pl?

	There are a few things I'd suggest.

	The newer .common.pl files have an option to turn off the
	OK messages. If you email me your .common.pl file, I can send
	back the file with the newer code for RushSubmit() that you can
	use to disable those dialogs.

	Also: if you have a *lot* of write nodes, I'd suggest trying
	to consolidate them into a single job by using rush's ability
	to use floating point frame numbers.

	For instance, if you have a range of 5 frames specified as:

frames 1-5

	..which gets you:

0001
0002
0003
0004
0005

	..but let's say you have 3 write nodes (A, B and C).
	Then you can use rush's floating point frames so that
	the number to the left of the decimal is used as the
	frame number, and the number to the right of the decimal
	is used as the write node.

	So for instance:

frames 1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2 3.3 4.1 4.2 4.3 5.1 5.2 5.3

	..would get you:

0001.1		-- renders frame 1, node 'A'
0001.2		-- renders frame 1, node 'B'
0001.3		-- renders frame 1, node 'C'
0002.1		-- renders frame 2, node 'A'
0002.2		-- renders frame 2, node 'B'
 :
 etc
 :
0004.3		-- renders frame 4, node 'C'
0005.1		-- renders frame 5, node 'A'
0005.2		-- renders frame 5, node 'B'
0005.3		-- renders frame 5, node 'C'

	You can have as many nodes as you want, since
	you can control how many digits in the frame specification.
	So if you had 100 nodes, you might have:

frames 1.001 1.002 .. 1.099 1.100 2.001 2.002 .. 2.099 2.100 3.001 ..etc..

	..which would get you:

0001.001	-- renders frame 1, node #1
0001.002	-- renders frame 1, node #2
  :
  etc
  :
0001.099	-- renders frame 1, node 99
0001.100        -- renders frame 1, node 100
0002.001        -- renders frame 1, node 1
  :
  etc
  :

	It's pretty easy to have the script parse out the digits
	to the left and to the right of the decimal at render time
	from the floating point value in the RUSH_FRAME variable, eg:

		if ( $ENV{RUSH_FRAME} =~ /(\d+)\.(\d+)/ ) {
		    my $frame = $1;
		    my $node  = $2;
		    ..etc..
		}

	This way /one/ job can render all the nodes on separate processors,
	with clear logs and simple control without having dozens of separate
	jobs that have to be managed separately.


-- 
Greg Ercolano, erco@(email surpressed)
Seriss Corporation
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)ext.23
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)



Last Next