MxS and Backburner

Become a member of the CGSociety

Connect, Share, and Learn with our Large Growing CG Art Community. It's Free!

Thread Tools Search this Thread Display Modes
Old 02 February 2013   #1
MxS and Backburner

The two never go particularly well together, but this one is really causing me a headache.

I'm submitting renders by creating a new job, setting all my properties, then running job.submit along with a server list. Everything works fine, until I have a scene which doesn't start at frame 0. Before submitting the job, I set the start and end frame to be the current rendStart and rendEnd values*. When the scene gets submitted, in the BB monitor, the First Frame and Last Frame in the Job Details tab is a-ok - it has my proper values. But the actual frames rendered are not correct. They are the same breadth of frames, but starting from 0. So, for example, if I submit a render from from 30 --> 80, it'll render 0 --> 50. And it is the latter, incorrect value that is in the Task Summary frame list.

Any idea why this is the case? It's clearly "accepting" the frame start and end time, but not using it properly. Perhaps I could try giving it a list of frames in the "frames" property of the new job, and create a string that's "30-80"?


*(though I have to do some ridiculous string operations to get rid of the 'f' from the end, then convert it to an integer - does anyone know how to get around doing that, and just get the render range as an integer?)

Old 02 February 2013   #2
(30f as integer / ticksperframe)
Maxscript Made Easy...
Old 02 February 2013   #3
Originally Posted by DaveWortley:
(30f as integer / ticksperframe)

Lovely, thanks Dave!

Re: The main problem, I just tried assigning the range as a job.frames value (ie newjob.frames = "30-80")with no luck. It's still always starting at 0.

Last edited by DanGrover : 02 February 2013 at 01:11 PM.
Old 02 February 2013   #4
Originally Posted by DanGrover: Lovely, thanks Dave!

Re: The main problem, I just tried assigning the range as a job.frames value with no luck. It's still always starting at 0.

I gave up on Backburner years ago...
Maxscript Made Easy...
Old 02 February 2013   #5
Originally Posted by DaveWortley: I gave up on Backburner years ago...

Tell me about it. I used Deadline at my last place, it was absolutely beautiful. Right now I'm shoehorning this whole system of dependencies using cmdjob and custom made groups based on text files, and 80% of the code is due to deficiencies in what you can do with Maxscript and Backburner vs what you can do in UI max. You have to write 100 lines of script to get 20 lines worth of extra functionality, as it were.

Old 02 February 2013   #6
Sorry for the bump, but I'm getting to the curious conclusion that the whole thing might just be broken. Things I've tried...

- Setting the fromFrame and toFrame before submitting the job.
- Setting it after.
- Setting the "Frames" parameter to be a relevant string.

To things I'm going to try now, but I'm very un-hopefuly....

- Setting the scene to render from the active range and then altering the active range.
- Sending a job and fiddling with it in the listener to see what happens then.

But in all cases so far, the job will change its size to be the equivalent of (toFrame - fromFrame) but start at 0. Mysterious.

Old 02 February 2013   #7
since you mentioned dependencies, this thread may be useful to you:
How to: Net Render with dependencies
Old 02 February 2013   #8
Hi Gravey,

Thanks for that - I did see that when I first went on my beautiful voyage of discovery into Backburner and it's clearly a great solution. Unfortunately, this system of scripts has evolved into something where, basically, I'd need to actually understand what was in the script for it to work!

Re: The topic, I've worked out that the .frames property only works when nonSeqFrames is false, but that it still doesn't help - whatever combination of frames you have in that string, it just does that many frames from 1. So if you have "1,3, 5-10", you'd actually render frames 1-8. The active range also makes no difference at all, as expected.

Additionally, the nth frame parameter does the same thing - if you have a sequence render from 1-100 and set the nth frames to 10, it'll render frames 1-11. Thanks, Backburner. Thackburner.

Last edited by DanGrover : 02 February 2013 at 02:20 PM.
Old 02 February 2013   #9
Aaaaand it's fixed! It seems that the problem came from the hacked up fix I had from the pre-PU6 build where submitting from MxS was broken. I'd had it set up to automatically pause the job after submission, change the end frame and then resume the job, and it seems that something to do with this was messing with it. I'll try and work out what it was so that this is actually useful to someone...

Old 02 February 2013   #10
Thread automatically closed

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.
CGTalk Policy/Legalities
Note that as CGTalk Members, you agree to the terms and conditions of using this website.
Thread Closed share thread

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Society of Digital Artists

Powered by vBulletin
Copyright 2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump

All times are GMT. The time now is 03:05 AM.

Powered by vBulletin
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.